I have 4 Bose SoundTouch ST-10’s and 1 Bose SoundTouch ST-300 sound bar (not musiccast devices). They all can play Spotify independently (or as a group), but share the same Spotify account configuration (I think that happens via a cloud interface). I can only define one Spotify account for ALL devices, since they share the configuration.
They sometimes lose connectivity to Spotify Connect as well; the only way to get them back is to reboot the device unfortunately. I have been looking high and low for a workaround for that, as the reboot takes about 2 minutes before the device shows back up in the Spotify App.
@fanful yes that is correct. I have a pair of WX-010 speakers in my living room (configured as a stereo pair), I have an RX-V481 multi-channel surround receiver in my home theater, a R-N602 stereo amplifier in my enclosed patio and an R-N402 amplifier in my garage. To control all of this, I bought a Yamaha WXC-50 MusicCast Preamplifier to be used just as a master device to link the other rooms to. So either myself or my wife will play from any Spotify device (primarily our iPhones, but I occasionally will use my laptop in my office) and then I link which ever room I’m using to the master “Media Player” (the WXC-50). I couldn’t figure out a way to use the Mini Media Player speaker grouping function and have the ability to choose which player was my master player, so I dedicated one for that task. The WXC-50 isn’t hooked up to any speakers so it’s strictly the master player.
Changed all media_player.schedule_update_ha_state(force_refresh=True) calls to schedule_update_ha_state(force_refresh=False) to improve performance. Suggested by @bdraco, along with an explanation of why. Thanks @bdraco!
Changed logic to call session.hass.config_entries.async_update_entry via a hass.add_job call instead of calling directly. This fixes the issue of Detected that custom integration 'spotifyplus' calls hass.config_entries.async_update_entry from a thread other than the event loop, which may cause Home Assistant to crash or data to corrupt that was introduced with HA 2024.6 release.
Changed logic to access local file system files via a hass.async_add_executor_job call. This fixes the issue of Detected blocking call to open inside the event loop by custom integration 'X' ... that was introduced with HA 2024.6 release.
Apologies for the back-to-back releases, but the Spotify DJ exception bug was a pretty big deal as the DJ is a popular Spotify function.
[ 1.0.21 ] - 2024/06/07
Fixed a bug that caused player state to return an error every 30 seconds when playing the Spotify DJ playlist. As the Spotify Web API does not support retrieving the DJ playlist (spotify:playlist:37i9dQZF1EYkqdzj48dyYq), it simply returns a manually built representation of the Spotify DJ playlist with limited properties populated (uri, id, name, description, etc). Note that Spotify DJ support is not supported (as of 2024/06/07) by the Spotify Web API (this includes starting play, retrieving playlist details, retrieving playlist items, etc).
Added service zeroconf_discover_devices to discover Spotify Connect devices on the local network via the ZeroConf (aka MDNS) service, and return details about each device.
Added service zeroconf_device_getinfo to retrieve Spotify Connect device information from the Spotify Zeroconf API getInfo endpoint.
Added service zeroconf_device_resetusers to reset users for a Spotify Connect device by calling the Spotify Zeroconf API resetUsers endpoint.
Updated underlying spotifywebapiPython package requirement to version 1.0.44.
Apologies for the back-to-back releases, but each new release of HA lately seems to break things. Not complaining, as it’s just the nature of software updates sometimes.
[ 1.0.25 ] - 2024/06/08
Fixed a bug that was causing ValueError: list.remove(x): x not in list exceptions to be raised whenever the user changed configuration options for a service. This started appearing with the HA 2024.6.1 release.
Added service zeroconf_device_connect that calls the addUser Spotify Zeroconf API endpoint to issue a call to SpConnectionLoginBlob. If successful, the associated device id is added to the Spotify Connect active device list for the specified user account.
Added service zeroconf_device_disconnect that calls the resetUsers Spotify Zeroconf API endpoint to issue a call to SpConnectionLogout. The currently logged in user (if any) will be logged out of Spotify Connect, and the device id removed from the active Spotify Connect device list.
Removed service zeroconf_device_resetusers and replaced it with zeroconf_device_disconnect.
Updated underlying spotifywebapiPython package requirement to version 1.0.48.
@Fanful, @staceydodds@stennajay
I believe I have the “playback when another Spotify account is controlling the device” issue resolved. I added a new service to the 1.0.26 version of the SpotifyPlus integration that allows you to disconnect the current user on a device, then reconnect a different user to the same device.
Check out the wiki docs for the new Zeroconf Device Connect service. It will disconnect the current user from the device, and add a different user to the device; you can then issue the Play Transfer Playback service call to start play on the device.
Note that the username MUST match the account name (or one of them) that was used to configure Spotify Connect on the manufacturer device; you can’t just randomly select a Spotify account that is not known to the manufacturer device.
Use the ZeroConf Discover Devices service to retrieve the various parameters for the Connect service.
Let me know if it works for you or not. It should work, as it uses the Spotify Zeroconf API, which should be what your device uses to interface with Spotify Connect.
Hello @thlucas . I’m trying to follow your advice here.
A couple notes about the process, in case this might be useful for others.
I think the help text on that field in the service visual editor is wrong (it’s a copy of the previous one):
The field doesn’t accept numbers, it’s a boolean. I haven’t found any mention of SSL in the discover device service results, so I just set this field as false.
I didn’t have a Spotify password, because I used “Continue with Google” to sign up/login. However, it turns out Spotify lets you create a “device password” in the account settings on the website (inside the privacy and security section). So I created one and used it for this service.
And as for the result, I had to fiddle quite a bit, but I think I finally managed it. I will need to test this some more (and with it test the patience of my wife ), but it worked when I separately run the disconnect service, then the connect service without the pre-disconnect. In the end I managed to stop my wife’s session on the device and start playback from my account, all without touching the Spotify app.
Thanks for the notes on the SSL description; I will get that corrected with the next release today. Here is what it should have said: Use SSL? True if the host device utilizes HTTPS Secure Sockets Layer (SSL) support; otherwise, False to utilize HTTP. Default is False (HTTP).
Can I ask what device hardware are you controlling? e.g. Sonos, Google Cast, Onkyo, etc. As well as what the CPath and Port numbers you are using to access your device(s)? I would like to add them to my ZeroConf Device Info by Manufacturer wiki documentation if you can supply me with the details.
Added extra state attribute media_playlist_content_id that contains the Content ID of current playing playlist context if one is active; otherwise, None.
Added property media_player.media_playlist_content_id that contains the Content ID of current playing playlist context if one is active; otherwise, None.
Added property media_player.media_playlist_content_type that contains the Content Type of current playing playlist if one is playing; otherwise, None.
Added property media_player.media_playlist_description that contains the Description of current playing playlist if one is playing; otherwise, None.
Added property media_player.media_playlist_image_url that contains the Image URL of current playing playlist if one is playing; otherwise, None.
Updated use_ssl description on all of the Zeroconf Device services.
FYI - I put together a document on how to reawaken Spotify Connect device id’s that disappear after a certain time of inactivity. It utilizes various services from the SpotifyPlus integration to gather information about the device(s) and re-establish the connection to the Spotify Connect device list. Spotcast is not required by this process.
It contains an explanation of the problem, as well as a solution on how to re-awaken the device. The same procedure can also be used to switch Spotify accounts on a device, IF the device supports it (some devices only support one account, like my Bose SoundTouch unfortunately).
I have had good luck with Onkyo, Bose, PureSound, and Yamaha users that have been able to re-awaken devices with it. I would think it will work with Sonos and Google Cast devices too, or any device that natively supports the Spotify Connect Zeroconf API for that matter.
Added service get_spotify_connect_devices that gets information about all available Spotify Connect player devices.
Added service get_player_now_playing that gets object properties currently being played on the user’s Spotify account.
Added service player_activate_devices that activates all static Spotify Connect player devices, and (optionally) switches the active user context to the current user context.
Added service player_resolve_device_id that resolves a Spotify Connect device identifier from a specified device id, name, alias id, or alias name. This will ensure that the device id can be found on the network, as well as connect to the device if necessary with the current user context.
Added service get_player_playback_state that gets information about the user’s current playback state, including track or episode, progress, and active device.
Added extra state attribute media_context_content_id that contains the Context Content ID of current playing context if one is active; otherwise, None.
Updated underlying spotifywebapiPython package requirement to version 1.0.59.
If you’re having issues with Spotify Connect “device not found” errors, then this is the release for you.
This release allows you to specify a Spotify Connect username and password in the configuration options. These credentials are then used by the various services that utilize a device_id parameter. It will verify that the device exists and is available, and will re-activate it automatically if need be. It will also take control of the device if another user is controlling it. You can also specify either a device ID value or the device name value, as well as any group alias id / name values (for multi-room use if configured).
The Player Transfer Playback service will now transfer playback to either active or inactive devices, as well as switch the user context if need be.
Example:
I also added a new Player Activate Devices service that allows you to re-activate ALL of your Spotify Connect devices on the network with one service call.
Example:
Activate all Spotify Connect player devices on the local network and switch the device user context to our user context. This will disconnect other users from all spotify connect player devices defined to the local network.
You might also try calling the new Get Spotify Connect Services service to retrieve the device list. This is what the configuration options UI is calling to retrieve the device list.
If you cannot execute any SpotifyPlus service, then you might try the getInfo call from a desktop browser. Example: http://192.168.1.82:8200/zc?action=getInfo&version=1.0
Also, are there any related messages showing up in the System Log?
UPDATE - is the Spotify Connect device you are not seeing using IPV4 to connect? or IPV6? I have not tried the device discover process with IPV6 protocol, as all of my gear uses IPV4.
), but it worked when I separately run the disconnect service, then the connect service without the pre-disconnect. In the end I managed to stop my wife’s session on the device and start playback from my account, all without touching the Spotify app.
