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.
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
Now All work fine. Thanks
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 toschedule_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 namedsoundtouchplus_presets_lastupdated
to correctly reflect the last update datetime. - Modified
media_player.service_recent_list
service to update the extra state attribute namedsoundtouchplus_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 toschedule_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 ofDetected blocking call to open inside the event loop by custom integration 'X' ...
that was introduced with HA 2024.6 release.
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.
Thank you
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.
FYI - just released a new version of the SoundTouchPlus integration
[ 1.0.50 ] - 2024/06/19
- Updated underlying
spotifywebapiPython
package requirement to version 1.0.59.
FYI - just released a new version of the SoundTouchPlus integration
Note - If you are using the SpotifyPlus integration, you will also need to update it as well since it uses the underlying Spotify Web API Python library.
[ 1.0.51 ] - 2024/06/21
- Updated underlying
spotifywebapiPython
package requirement to version 1.0.61.
FYI - just released a new version of the SoundTouchPlus integration
Note - If you are using the SpotifyPlus integration, you will also need to update it as well since it uses the underlying Spotify Web API Python library.
[ 1.0.52 ] - 2024/06/21
- Updated underlying
spotifywebapiPython
package requirement to version 1.0.62.
Apologies for the back to back updates, but the underlying spotifywebapiPython
update fixes a potential memory leak with the Zeroconf discovery process.
FYI - just released a new version of the SoundTouchPlus integration
Note - If you are using the SpotifyPlus integration, you will also need to update it as well since it uses the underlying Spotify Web API Python library.
[ 1.0.53 ] - 2024/06/24
- Updated underlying
spotifywebapiPython
package requirement to version 1.0.64.
FYI - just released a new version of the SoundTouchPlus integration
Note - If you are using the SpotifyPlus integration, you will also need to update it as well since it uses the underlying Spotify Web API Python library.
[ 1.0.54 ] - 2024/06/27
- Updated underlying
spotifywebapiPython
package requirement to version 1.0.71.
FYI - just released a new version of the SoundTouchPlus integration
Note - If you are using the SpotifyPlus integration, you will also need to update it as well since it uses the underlying Spotify Web API Python library.
[ 1.0.55 ] - 2024/07/02
- Updated underlying
spotifywebapiPython
package requirement to version 1.0.73.