Sure–most if it the nonsense required to get the Roku and the AV Amp all rowing in the same direction before any Spotify services get called, but here is the whole script:
Registratore: homeassistant.components.media_player
Fonte: helpers/entity_platform.py:1118
Integrazione: Lettore multimediale (documentazione, problemi)
Prima occorrenza: 6 gennaio 2026 03:01:15 (7947 occorrenze)
Ultimo accesso: 09:30:09
Updating spotifyplus media_player took longer than the scheduled update interval 0:00:01
Hi everyone,
I’m looking for some advice regarding the Spotify Plus integration. While I usually ignore minor errors as the integration seems to work fine most of the time, I’ve noticed a massive flood of warnings in my logs since yesterday.
The log says: Updating spotifyplus media_player took longer than the scheduled update interval 0:00:01
This has occurred over 7,000 times in a very short period. I realize the 1-second polling interval might be too aggressive for my setup or connection latency.
I have a couple of questions:
Is there a recommended way to increase the update interval or mitigate this log spam?
I noticed that these errors persist even when the account owner is not at home. Would it be better to “turn off” or disable the integration when the user is away to avoid unnecessary API calls? Or is there a more elegant way to handle this without losing functionality?
I’d appreciate any suggestions on how to optimize this and clean up my logs.
Hi Todd, I would like to complete an automation that I use when I am going out from home, that transfer the device connected to SpotifyPlus from my Hi-Fi to my iphone. Basically if I am listening to something, when I trigger this automation at the moment the music stop playing, now I would like to “prepare” the Iphone to be ready to resume, and when I jump in my car and the sensor.activity of my Iphone is updated to “automotive”, start to play the music (maybe with a bit of delay). Most of the time it happens that my phone is idle and the playback start on the previously connected device, or it doesn’t start at all. If I open the Spotify App it resume it or complete the music transfer.
Note that at the moment I start my car, my phone is still connected to my wifi.
If this is possible how should I do it correctly? Playback transfer doesn’t find my Iphone, possibly the Spotify app is idle and then not connected to Spotify server.
@Sofa_Surfer
The only way that could work is if the Spotify App is open / active on your iPhone at the time the transfer playback was issued. There is no way (that I know of) to open / activate the Spotify App on the iPhone via automation.
The iPhone only presents itself to the Spotify player device list when the Spotify App is open / active on the device. Your Hi-Fi device is different, in that the Spotify Connect Zeroconf server is always running when it’s powered on (or in standby mode).
You might check the HA Companion App docs to see if it’s possible to send a command via it’s message processing to open an app on the phone. If that could be done, then you could transfer playback to it. Or there might be a way through Apple Home Kit to do it? Just not sure on that one.
@Sofa_Surfer
Regarding opening Spotify Mobile App via automation … I played around with the HA Companion App notify command, and this is the closest I could come to opening Spotify Mobile on my iPhone 16 Pro Max.
I tried a couple of different ways (see YAML below). Basically, you had to have your HA Companion App open / running in the background in order for it to work. You also had to manually confirm that the HA Companion App could open the Spotify App. Maybe not the perfect solution, but a starting point.
description: ""
mode: single
triggers: []
conditions: []
actions:
- action: notify.mobile_app_todds_iphone_iosapp
data:
message: Tap to open Spotify
title: Open Spotify?
data:
url: spotify://
- action: notify.mobile_app_todds_iphone_iosapp
data:
title: Open Spotify?
message: Tap to open Spotify Mobile App
data:
push:
sound:
name: default
critical: 1
volume: 1
actions:
- action: URI
title: Open Spotify Mobile App
uri: spotify://
Thank you! I will play tonight with this start. I was also thinking to Iphone shortcuts and automations, but haven’t checked yet the possibilities.
I will let everyone know if I can do something useful!
Thank you so much for your help! You are definitely one of the most active developers I’ve encountered, always providing clear and fast answers to everyone.
I really appreciate your patience, especially since I could have found this information myself in the documentation. Thank you for not ‘scolding’ me and for the incredible amount of time and effort you dedicate to this project. It is truly appreciated
@ryanhindinger
I would recommend changing the play_media calls to use the SpotifyPlus player_media_play_context service instead. This would also get rid of the media_player.select_source and media_player.shuffle_set service calls as well, since those are options on the player_media_play_context call.
Example:
alias: Play Spotify Weekday Mornings
sequence:
- choose:
- conditions:
- condition: state
entity_id: person.liz_carlson
state: home
sequence:
- alias: Play 'Weekday Mornings'
action: spotifyplus.player_media_play_context
data:
entity_id: media_player.spotifyplus_ryanhindinger
context_uri: spotify:playlist:1GnjPfvJ54k4iwyu1sgh3k
device_id: "Living Room Roku Ultra"
shuffle: true
- conditions:
- condition: not
conditions:
- condition: state
entity_id: person.liz_carlson
state: home
sequence:
- alias: Play 'Christmas'
action: spotifyplus.player_media_play_context
data:
entity_id: media_player.spotifyplus_ryanhindinger
context_uri: spotify:playlist:5XwhnWhx57ut9QRyw9kKTj
device_id: "Living Room Roku Ultra"
shuffle: true
The above replaces the following sequence steps. Note that I am not sure how the play_media utilizes the extra metadata values.
Hi! First of all, thank you for the work you’ve put into SpotifyPlus. I really appreciate it, and I’m sharing this only as hopefully constructive feedback after setting it up.
I set this up yesterday because Spotcast had stopped working. It took me a while to get the tokens working properly for Chromecast players.
A couple of quick notes:
• macOS terminal commands: On Mac, the commands need to use python3 rather than python for things to run correctly. It might be worth calling that out explicitly in the docs where the terminal commands are shown.
• Service naming / documentation: I did eventually figure it out from the documentation, but the player_media_play_context service name could be clearer (or at least highlighted/explained a bit more) so it’s easier to understand what it’s for at a glance.
• Danish characters bug: I also filed a small GitHub bug regarding a token issue with Danish characters (æ/ø/å). In my case, it was resolved by changing my username so it didn’t include “ø”.
One more suggestion: it’s great that when configuring a Spotify user you can already select a default device from a dropdown that shows the (long) player ID in parentheses. It would be awesome if something similar were possible when choosing a device while building an automation, so you don’t have to spend time hunting down/copying IDs manually.
Anyway, thanks again for making this. I’m happy it’s working now, and I can use Spotify in Home Assistant again!
@DIY-techie
Thank you for the feedback, much appreciated.
Work is already in progress on supporting unicode characters in the username credentials. I am just surprised that it took this long (over 2 years) for that to manifest itself. All of the Spotify Connect examples that I followed use the ‘ascii’ encoding, but after looking at the Spotify API docs UTF-8 is fully supported. That will be fixed in the next release.
Regarding the macOS terminal commands … I think the use of python versus python3 to execute a script depends on how you install (or configure the default) python environment, correct? No other users have reported issues with python, but then again I don’t know how many are macOS users. Did you also use python3 AuthTokenGenerator.py to execute the script? or just python AuthTokenGenerator.py? I can make a note of that in the wiki docs.
Regarding the Service naming / documentation … There are so many different endpoints in the Spotify Web API, so I had to come up with a naming standard that equates a service to the corresponding Web API endpoint. Since context play and track play are both part of the Spotify Web API \ Player \ Start a Users Playback endpoint, it was necessary to split them apart into 2 separate services. Unfortunately these names cannot be changed, as they have been in place for awhile now (over 2 years).
Regarding the device_id: argument, you can specify friendly device names there if you want to (insteadof device id). The only time you need to specify a device id is if the device in question supports both Spotify Connect ZeroConf and Google Cast protocol (e.g. Wiim devices, etc). In those cases, you will see duplicate device names (with different device ID’s) in the device list, so you have to refer to the device with it’s ID value (instead of name).
Unfortunately, the auto-fill of device names / id’s for the automation editor is not possible, as these values are resolved at run-time and are / could constantly change. Unlike entity-id’s, which are defined and know to HA internals.
Thank you, Todd, for taking a look at this. I fonally got a chance this morning to attempt to swap out my scripting for the player_media_play_context action like you suggested, but now I am getting a different, immediate error that I am not able to glean much from:
@ryanhindinger
Can you post the updated (complete) script?
The ERROR_MISSING_ACTION denotes that the action parameter was missing on the Spotify Connect Zeroconf call. This usually denotes a problem with discovery of the device that is trying to be activated.
I will also need to see the output of the following service call to see what the discovery process found for the Living Room Roku Ultra device.
action: spotifyplus.get_spotify_connect_device
data:
entity_id: media_player.spotifyplus_ryanhindinger
device_value: Living Room Roku Ultra
activate_device: true
As soon as I send Roku back to its Home screen this action fails with an unknown error (according to HA anyway).
So when I run the full script it works because the full script put the Roku in the Spotify app. Without that, the player_media_play_context action fails.
Thank you for the thorough response! That all makes sense.
Yes — python without the 3 is not a valid command on my system (“zsh: command not found: python”).
I’m not quite sure how to use friendly names here. With Spotcast, I could click target and select a speaker from a list (e.g., when using it in an automation or script) - similar to the media player play media service. In SpotifyPlus, I only see the Device ID field:
Since I can’t remember the entity names of my players (like media_player.nesthubb606), I copy the device ID from the dropdown in the configuration flow.
Also, it might be helpful if the text “Entity ID of the SpotifyPlus device that will make the request to the Spotify Web API.” was phrased more like the Spotify account/profile you want to use (i.e., which SpotifyPlus instance/account is making the Web API request). That description would have been clearer to me.
Thanks again. I am happy that it works - these are just suggestions.
I think I understand what’s going on … the Roku device does not advertise its presence to Spotify Connect Zeroconf unless the Spotify App is started on the Roku device. To confirm that, you could call the get_spotify_connect_device action with the Spotify App not active on the Roku device. With that said, just curious if the Spotify Mobile App (running on your phone) displays the “Living Room Roku Ultra” device entry without the Spotify App running on the Roku?
I don’t have a Roku to test with, so cannot confirm that.
Hey Todd–so I was curious and checked because I have like four Rokus in the house. All of them advertise themselves as available to the app, but none of them respond to the get_spotify_connect_device unless the app is active. So that’s an oddity.
@DIY-techie
Regarding “friendly names”, these would be the names (not device ID’s) of the devices as they appear in the SpotifyPlus integration source list. These are actually Spotify Connect remote names (if you want to get technical). Do not confuse these device names (e.g. “Nest Audio 01”) with HA entity names (e.g. media_player.nest_audio_01) - they are not the same. The HA entity names could represent a device(s) for a manufacturer specific media player, but these are not used by the SpotifyPlus integration media player.
You can specify either the device name or the id to start play on the device.
# play context by device name:
service: spotifyplus.player_media_play_context
data:
entity_id: media_player.spotifyplus_john_s
context_uri: spotify:playlist:6M8n0Sp9895BXEE0MbGPde
device_id: "Nest Audio 01"
# play context by device id:
service: spotifyplus.player_media_play_context
data:
entity_id: media_player.spotifyplus_john_s
context_uri: spotify:playlist:6M8n0Sp9895BXEE0MbGPde
device_id: c90704879d4d6281c6f98d35fa3d069929bbbbd0
The SpotifyPlus integration source_list state attribute contains the available device names that you can specify for the device_id argument:
I will update the service descriptions in a future release for the entity_id value. Something like Entity ID of the SpotifyPlus service account that will make the request to the Spotify Web API.
I’ve recently started getting some timeout errors. In my device list from the action spotifyplus.get_spotify_connect_devices, I have a home speaker group (see long paste below). When I try to connect to the speakers with spotifyplus.player_media_play_context or using the action spotifyplus.get_spotify_connect_device, I get a timeout error (even with the activate option set to true):
Error: Could not activate Spotify Cast application on Chromecast device "2bf3e489ca91766b277d3d288f35d8d4": Execution of wait timed out after 20.0 s.
Once I manually connect to the speakers through the spotify app, I’m then able to connect via spotifyplus. I thought setting the activate_device option to true would resolve this, but I’m not sure what else to try now.