@rene-zuch
Thank you, that is really helpful. It appears that the Chromecast devices are not registered with Spotify Connect ZeroConf, as proven by the IP address of localhost and the IsDynamicDevice = true.
Supporting Chromecast will require similar processing as I do for Sonos devices, which will be a big effort to implement and support. This is not something I would attempt without having a device to test with.
@thlucas I ask you because you have always been kind in helping me. You are doing a great job, and for months I have switched to using Spotify Plus as well as Soundtouch Plus. Now I am confused again. I see updates on Spotcast, and on the original Spotify applications. I have generated many duplicate things, I wonder what is the best solution for me. In the end I am simply interested in being able to start music from spotify on google home, for a lullaby routine for my daughter, everything else I do by voice. I think that only spotcast allows me this, right? Sorry for the trivial question and outside of your automation, but if I understood correctly, this possibility is not on spotify plus, in fact after deleting spotcast, I could no longer obtain this. Correct?
For the same reason, even your beautiful new spotify card, does not show me the google home devices, but only those associated with spotify connect, right?
@Diegocampy Not a problem, happy to help.
Chromecast devices are currently not fully supported by the SpotifyPlus integration. You can perform player functions (e.g. pause, resume, next track, etc) if the device is the currently active player, but you can’t wake up a device or initiate play of tracks / context.
This has been one of the most requested features, and I would love to provide support for these devices. The problem is that I do not have any Chromecast devices to test with, so I am not able to develop a solution.
If it were me, I would continue using the SpotCast features. I saw a post on the community forum about SpotCast V5 that might be of interest to you as well; it sounds like it’s a new version of SpotCast, though I am not familiar enough with SpotCast to know what it adds or replaces.
yes i saw it and i’m trying it. Now i remember how i got to spotify plus, it was the only way to continue playing spotify from my account on my bose soundtouch.
For my needs i will have to continue using spotify plus, spotcast, and soundtouch plus maybe i will be able to abandon the official version of spotify one day, just in case i leave it there now
When i use Get Current Users Profile, i always get Login ID as my username as string. It is not canonical (like 31l77y75hfnhk79f7gk6jkk878mg) as you mentioned. It is only the username without the @ mail address part. Should i use this username as my LoginID?
@febalci
Note that for some Spotify accounts, the LoginId and Username values are the same. Not sure why that is, as it’s a Spotify internals kind of thing.
The LoginId value can easily be found using the Spotify Developer Web portal, using the Get Current Users profile service. Click on the Try It button, then find the id response value.
@thlucas as mentioned earlier in this thread, I have an entirely Chromecast-based ecosystem. I have been looking for this type integration and dashboard panel for Spotify since I started using Home Assistant 4+ years ago. You noted that you do not have any Chromecast devices, however, depending on your model, the Bose Soundtouch may already support it: Chromecast Built-in FAQ | Bose. If you do work on Chromecast support at any point, I’d be glad to help with testing. Thanks, again, for developing this amazing and much needed integration.
Hello everyone, joining this thread as I’m currently struggling with my Spotify Connect integration.
But it’s not clear to me if Spotify Plus integration can solve my issue. I need advice from you, the awesome community
I’m running my HA on a RPI, with a Jack cable connected to my sound system. My goal is to see my HA instance/RPI as a Spotify Connect device. Thus, it would allow me to play music from Spotify Connect directly on my sound system.
Is it something doable with Spotify Plus?
Thanks a lot for your help
@rml
Chromecast is only supported on the newer Bose Smart products; it is not supported on the older SoundTouch line of products, which is what I have.
That should make your RPi show as a Spotify Connect device, which can be controlled by SpotifyPlus, HA Spotify, or even the Spotify mobile / desktop apps.
Sorry folks, but I have some disappointing news from the Spotify Developer API camp. It turns out Spotify has decided to remove the following functionality without any sort of warning or grace period. This was announced on the Spotify Developer Forum Blog on Thursday November 27th 2024 (US Thanksgiving holiday - definitely nothing worth giving thanks for IMHO!).
The Spotify Web API will no longer be able to access or use the following endpoints and functionality in third-party applications (SpotifyPlus being one of them):
What these changes mean for the SpotifyPlus Integration and SpotifyPlus Card Dashboard users is that the corresponding functions that access the above features will no longer work, and in most case will return an error message.
What can I do about this?
You can make your voice and opinion be heard by posting a reply on the Spotify Community Forum. Let them know that this change is not acceptable and how disappointed you are. Please be respectful in the process; scream and shout with your internal voice if you have to (like I did).
Can these functions be replaced with equivalent functionality?
I currently have no plans to try an re-implement the affected functionality, as the deprecated Spotify Web API functions were the only way to retrieve the information. It’s proprietary data, and if they don’t want to share then that’s their prerogative.
In Summary
Spotify is still a great platform for music streaming, but they lost a lot of respect from me today as a Spotify Champion and user of their Spotify Web API. As a developer of numerous API’s myself, it’s unheard of to simply shut off a feature or endpoint without giving some sort of notice or grace period; and we definitely don’t make major changes like this over a major holiday! IMHO, they totally dropped the ball on this one, not to mention dropped the hammer on numerous developers!
Just thought that you would want to know, and sorry to be the bearer of bad news. I will cross-post this in the SpotifyPlus Card community forum post as well.
Updated underlying spotifywebapiPython package requirement to version 1.0.22.
The above spotifywebapiPython package will now return an exception due to the functions being deprecated by the Spotify development team. More information can be found on the Spotify Developer Forum Blog post that was conveyed on November 27, 2024. The following methods will now raise a SpotifyApiError exception due to the Spotify development team changes: GetArtistRelatedArtists, GetTrackRecommendations, GetTrackAudioFeatures, GetFeaturedPlaylists, GetCategoryPlaylists, GetGenres. The following properties were also marked as deprecated for the same reason: TrackSimplified.PreviewUrl.
Due to the above changes made by Spotify, any Algorithmic and Spotify-owned editorial playlists are no longer accessible or have more limited functionality. This means that you can no longer obtain details via the SpotifyClient.GetPlaylist and SpotifyClient.GetPlaylistItems methods for Spotify-owned / generated content (e.g. “Made For You”, etc). A 404 - Not Found error will be returned when trying to retrieve information for these playlist types.
I have a question about the media_player entity state Off, why does it exist?
In the Official spotify integration it always stays in Idle, which is good because if the spotify is triggered by other device (like an alexa) the entity will update itself, in the spotify plus after the music have started, I need to turn on the media_player manually
Is there a way to keep it always on, or go to idle of not playing?
@thlucas that’s basically the thing I asked a few posts ago, when you turn it on it reset the connected device/source (sonos or others) and queue, forcing the user to start again the playlist/track/whatever was playing. Keeping it idle might solve this.
Always trying to find the best solution for everything, I am forced to have 2 active integrations, spotify and spotifyplus.
Is only the official one able to recognize if it is running? Is there a chance that this will be fixed in the future?
It is not essential because I can do it with official Spotify, but if everything that the official one does could be done with plus, I would avoid having two
@Diegocampy I have disable the official Spotify, and use only the Spotify Plus ( I think that’s the way it meant to be used). I also use the Spotify API on Node Red to create a sensor to use in my dashboard footer Spotify Plus integration is a bit in late to refresh but it runs good.
@rafareusch@Diegocampy@Sofa_Surfer
The turn_on / turn_off services were implemented to provide a more compatible media player experience for the Spotify Player. It also executes some extra logic that is required for Sonos device support, as they are considered restricted devices and cannot be controlled directly by the Spotify Web API functions.
The following extra functionality is also provided by these 2 services.
This option allows you to specify a script that will be executed when a turn_on service request is made to power on the integration. The script can be used to prepare the audio output device(s) (e.g. speaker, AV receiver, etc) for playing Spotify Player content. For example, you could have a script that performs the following actions:
turn on AV receiver.
switch AV receiver input to AUX 1.
issue a media_player.select_source service call to activate a source on the device (e.g. force the device to be re-discovered by the Spotify Web API as an available device).
issue a call to service spotifyplus.player_transfer_playback to transfer Spotify Player playback to the device.
The script is executed synchronously, which means the integration will wait until the script ends before proceeding with other power-related events. Any changes to the script take effect immediately - you do not need to restart HA for script changes.
The script configuration option is optional - you don’t have to select a script. If your device or audio equipment does not require any preparation steps to play output then leave the option blank.
gets the current Spotify Connect player state. This is required, in case the state has changed since it was last powered off.
updates the source list (Spotify Connect devices cache).
try to automatically select a source for play.
if Spotify player is not found and a default Spotify connect device is configured, then select it;
otherwise, select the last active device source;
otherwise, select the currently active Spotify Connect device source;
otherwise, we cannot automatically select a source!
activates the selected source.
check if playing content is paused; if so, then resumes play.
This option allows you to specify a script that will be executed when a turn_off service request is made to power off the integration. The script can be used to shut down the audio output device(s) (e.g. speaker, AV receiver, etc) after playing Spotify Connect Player content. For example, you could have a script that performs the following actions:
turn off AV receiver.
turn off speaker device.
The script is executed syncronously, which means the integration will wait until the script ends before proceeding with other power-related events. Any changes to the script take effect immediately - you do not need to restart HA for script changes.
The script configuration option is optional - you don’t have to select a script. If your audio equipment does not require any shutdown steps after playing output then leave the option blank.
@Sofa_Surfer
There is a 1-30 second delay in the refresh of the SpotifyPlus details displayed when the player is controlled outside of the SpotifyPlus integration. It utilizes what I call “smart refresh” processing to provide updates when play is controlled via SpotifyPlus though, which give it more of a real-time feel.
I could make it more real-time by polling the Spotify Web API for status updates every second, but that would be overkill IMHO and is more likely to get you rate-limited by the Spotify Developers since you’re hitting their API every second for status updates.
The ideal solution would be for the Spotify developer team to provide web-socket support that we can subscribe to, which would then notify us when the player status changes (instead of us polling them every n seconds).
First of all, thank you @thlucas@Sofa_Surfer for your willingness to give me all these explanations. It’s not a matter of a 1.5 second delay, it simply doesn’t update if I don’t use spotify plus as a method of starting spotify. Maybe it’s my way of using it that’s the problem. Most of the time I start music with spotify, I do it by voice from my google home devices, or via the app on my smartphone. My previous post highlighted how the spotify integration has picked up the play even if I’m outside the home network where everything is installed. I have to check if the same thing happens when I start music by voice, I’ve never noticed it. Maybe I’ll remain a user who needs to keep both:
The standard one to be able to use spotcast. I need spotcast to wake up google home
the Plus one to resume music on the bose from where it left off, which is not possible with spotify standard, nor with spotcast
I fully understand this functionality you mentioned, and I can easily see the usage of that.
But my point remains… if I tell alexa to start playing some music on spotify, the state never reflects on my Spotify Plus entity, if I want to control via HA, I need to turn on the entity, by doing that, the spotify pauses. (not a big deal tbh, but this is a thing that works flawlessly in the official integration)
Am I missing some configuration?
What is the impact if I make an automation to always keep the entity ON? Currently I’m doing this and seems to be OK