Bose SoundTouchPlus Custom Component

Device not found

If the Chromecast it’s already in use, works


Only if currently in use, even if stopped by a few seconds it does not work

@Diegocampy - Did you try it after installing the v1.0.7 that I pushed out yesterday? You might give that a try again if not.

If that doesn’t work, then I’m afraid you might still need to use the SpotCast route unfortunately. It works great for my Bose SoundTouch, but that doesn’t help you with ChromeCast.

Don’t worry, you’ve already been too kind.
I haven’t tried because I still have version 1.06. and I don’t see any possible updates notified

EDIT: update with 1.0.7 not work for my Chromecast (no problem for this I use spotify integration standard with spotcast)

Good to know, I will add that to my notes and thank you for trying.

1 Like

I have a small problem, the integrated Bose, after turning it off, does not appear as turned off, but as “waiting”.


This creates problems with automations, because there is no “waiting” among the triggers


Am I the only one to have this problem? Thanks

@Diegocampy it appears you are talking about the SpotifyPlus integration media player instance. It works the same way as the stock Spotify integration media player, in that it cannot be powered on / off. There is no equivalent Spotify Web API call to power on / off a device, which is why it’s always in an “idle” state when not playing.

In your case, you can just use your SoundTouchPlus media player instance to play Spotify content, yes? The SoundTouchPlus does support power on / off options.

no no, I’m talking about the Bose, therefore the Sound Touch Plus integration.
In my images you can also see the Spotify Plus integration, it’s true, but I was talking about the BOSE. It is the one that is always indicated as waiting, even if it is turned off.
In the screenshot: “Cambiato in in attesa attivato dal servizio media_player:Turn off” in english “Changed to waiting triggered by media_player:Turn off service”.
I don’t understand if it’s my problem, or if this is really how the integration works

@Diegocampy Sorry about that - I see what you are referring to. Thank you for bringing this to my attention.

I found out what is causing this, and it is completely on me. It appears that I changed some logic in the media player state method, which returns the current state of the player. Prior to v1.0.28 (released on 2024/02/17), it was returning a state of MediaPlayerState.OFF when the device was in STANDBY mode; after v1.0.28, it was returning a state of MediaPlayerState.STANDBY, which is what you are seeing.

I just released v1.0.36 which will correct the problem. Please update to the latest release and give it a try.

My apologies for introducing the bug.

1 Like

What? Are you really apologizing? Don’t worry, you’re the developer, I’m a miserable end user. It seems to me the slightest sharing bugs to help you solve them. With the update everything works.Tomorrow I will try my automations, but already seeing off gives me hope

1 Like

Now All work fine. Thanks

1 Like

FYI - just released v1.0.42 of the SoundTouchPlus integration

[ 1.0.42 ] - 2024/05/03

  • Changed all media_player.async_write_ha_state() calls to schedule_update_ha_state(force_refresh=True) calls due to HA 2024.5 release requirements. This fixes the issue of “Failed to call service X. Detected that custom integration ‘Y’ calls async_write_ha_state from a thread at Z. Please report it to the author of the ‘Y’ custom integration.”.
  • Added service get_source_list to get the current source list configuration of the device.
  • Modified media_player.service_preset_list service to update the extra state attribute named soundtouchplus_presets_lastupdated to correctly reflect the last update datetime.
  • Modified media_player.service_recent_list service to update the extra state attribute named soundtouchplus_recents_lastupdated to correctly reflect the last update datetime.
  • Added system health information.
  • Modified strings.json (and translations) to remove a placeholder inside single quotes that was embedded in a service description. This was causing hass validation step to fail.
  • Updated underlying bosesoundtouchapi package requirement to version 1.0.59.
  • Updated Python version from 3.11 to 3.12.3 due to HA 2024.5 release requirements.

I have developed a new Home Assistant SoundTouchPlus-Card custom card that adds front-end support to the SoundTouchPlus integration.

I created a separate thread for the SoundTouchPlus-Card on the forum for questions and issues related to the card.

More Information

Check out the following links for more information:

FYI - just released v1.0.43 of the SoundTouchPlus integration

[ 1.0.43 ] - 2024/05/20

  • Added extra state variables related to recently played cache feature: soundtouchplus_recents_cache_enabled, soundtouchplus_recents_cache_max_items, soundtouchplus_recents_cache_lastupdated.
  • Added service recent_list_cache to retrieve the recently played items cache from the file system.
  • Added service remove_preset to remove the specified preset id.
  • 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!
  • Updated underlying bosesoundtouchapi package requirement to version 1.0.66.

FYI - just released v1.0.44 of the SoundTouchPlus integration

[ 1.0.44 ] - 2024/05/21

  • Added extra state variable: soundtouchplus_websockets_enabled. Returns true if websocket support is enabled for the device; otherwise, false if device does not support websockets or if websockets were disabled during device setup.
  • Added extra state variable: soundtouchplus_polling_enabled. Returns true if device polling is enabled; otherwise, false. Polling can be a temporary condition, in that it will be enabled if websocket support is enabled and the connection is lost and has not been re-established yet.

FYI - just released a new version of the SoundTouchPlus integration

[ 1.0.45 ] - 2024/06/06

  • Changed logic to access 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.
1 Like

I have version 1.0.46 but it doesn’t work

Same problem with Spotify plus :hugs:

I’m aware of the issue. The HA 2024.6 release broke some more things in both integrations. I am working on a fix now.

FYI - just released a new version of the SoundTouchPlus integration

[ 1.0.48 ] - 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 device. This started appearing with the HA 2024.6.1 release.

@Diegocampy

1 Like

Thank you :pray:

FYI - just released a new version of the SoundTouchPlus integration

[ 1.0.49 ] - 2024/06/10

  • Updated underlying spotifywebapiPython package requirement to version 1.0.48.
1 Like