This was the final piece of automation I needed to fully implement an ESPHome LCD displaying my current Spotify media and control it with an APDS-9960 gesture sensor, not only this solved that annoying delay but now data on the LCD updates instantaneously, making it so much user friendly. I cannot thank you enough for this idea.
Thanks for this, I was unaware of the update_entity service. I came here looking for a way to change the polling interval of the Spotify integration and found this solution. But I am trying to move away from polling wherever I can, and I ended up with a different solution: I have an Android TV box hooked up to a monitor that I use as a media player and dashboard. I have the HA companion app installed, and the media player widget for the Spotify integration on my home screen (the widget is the main reason I needed to reduce the lag). I am also a big fan of Tasker, and Tasker has a ‘Music Track Changed’ event. I use that event to trigger a webhook call to HA, which runs the update_entity service whenever that webhook is received. Works like a charm, without extra polling! The ‘Music Track Changed’ event comes with a lot of built-in variables with info about the current track, queued tracks and player state which you can use for automations on the local machine (Tasker), or send back to HA as the webhook payload. I also used the Tasker AutoInput UI Action event to detect clicks on the album art portion of the widget (it has a text element ‘Media Playing Preview Image’ which you can use to filter clicks) to open the Spotify app.
Thanks! It’s work perfectly (in 2024).
I actually made some changes so the scan will scan 24/7 and not just when playing.
That’s because when I start playing music, it still take 20-30 seconds to refresh for the first time.
Be careful you don’t get rate limited by the Spotify API. Running that automation constantly twice a second means that it’ll call the API 172,800 times a day!
That’s a surefire way to get yourself (and others, if Spotify decides HA is a security threat) in trouble.
Officially, no, so far Spotify’s own documentation doesn’t state that you’ll get banned. You’ll just get constant 429 errors (twice a second) if you’ve made too many requests in the past 30s.
Depending on how quickly you realise this happened, your logs would be swamped with errors eg. If it takes you just an hour to realise, that’s 3600 entries in your log eating up your disk space.
The wider implications for the rest of the community go beyond your errors though. If Spotify determines that HA is making too many requests, they have ways to restrict access, or worse, get lawyers involved to get the integration removed. It’s happened a couple of times with other integrations in the past year - look it up.
All this because you couldn’t wait 20-30s to see updates for your first song.
Here. this should work. It’ll update Spotify ONCE when starting, as well as every second while it’s playing.
I have developed a new SpotifyPlus Home Assistant custom component integration that expands the built-in Spotify capabilities. It’s a simple install to the “custom_components” directory via a HACS UI custom repository installer.
I also developed the underlying SpotifyWebApiPython library that interfaces with the Spotify Web API.
With the release of v1.0.11, player status changes are detected in near real-time IF changes are made via Home Assistant (e.g. UI, service call, automation, etc).
This was accomplished by changing the integration SCAN_INTERVAL from 30 seconds to 1 second, but also adding logic to the update method to only call the underlying Spotify Web API at selected intervals:
call every 30 seconds if no user or track change activity.
call if a player command is issued: set_volume_level, media_play, media_pause, media_previous_track, media_next_track, media_seek, play_media, select_source, set_shuffle, and set_repeat.
call every second for 5 seconds after a player command is issued. This allows for extra time it may take for the Spotify Connect Player to update it’s status after the command is processed.
call if the nowplaying track position has less than 5 seconds remaining. This is accomplished by subtracting the nowplaying DurationMS value (e.g. length of the track) from the nowPlaying track ProgressMS (e.g. current position of the track) value. This logic adds a few more calls to the Spotify Web API, but not many. It’s not perfect, but the acceptable trade-off is near real-time updates of Spotify Connect Player status.
Note that Spotify Connect Player changes are NOT detected in near real-time if controlling the Spotify Connect Player from another non-HA service (e.g. Spotify Web App, Spotify Mobile App, etc). In this case, changes will be detected within 30 seconds by the HA state machine. For example, if you advance to the next track from the Spotify Web player, it will not show the change in HA for up to 30 seconds. This is a limitation of the Spotify Web API, in that Spotify does not offer a websockets API that informs clients of Spotify Connect Player status and relies on client polling.
Thought you would like to know, and hope it helps!
This code worked for me for a long time, but some time ago it stopped working, probably due to some update… Has anyone managed to update this code to keep it working?
