@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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
