SpotifyPlus Integration

@ReinierZon
Forgot to mention … if you have a Windows operating system machine, you might want to install the SmartInspect Console Viewer (free download) to view integration test data while you are researching. It’s Windows OS only unfortunately, but it can listen for activity from any HA instance that’s on your local network. Just ensure port 4228 is not blocked via firewall.

You can also drive trace data to the log viewer AND the trace log file simultaneously. This allows you to view activity in real-time via the console log viewer. Just update the Connections entry in the smartinspect.cfg file on the HA instance(s) to the following (change the host address to your Windows OS that is running the SI Console Viewer):

Connections = tcp(host=192.168.1.1,port=4228,timeout=30000,reconnect=true,reconnect.interval=10s,async.enabled=false), file(filename="/config/smartinspect.sil", encrypt=false, key="123456", rotate=daily, maxparts=3, append=true)

I have multiple HA instances setup, and can view real-time trace activity from all of them at once. Super helpful in debugging problems like this.

Hope it helps!

Hi there. I have a similar experience to soulcrash, in that my Denon Heos devices update very slowly, or not at all when I group/ungroup.

I’m running v1.0.113 spotifyplus, v1.0.46 spotifyplus card.

I’ve found that reloading spotifyplus immediately resolves the issue, and I get updated heos devices, grouped or ungrouped. I don’t group/ungroup all that often, so I don’t mind the idea of reloading the integration. I thought that this behavior might give a clue to what might resolve the problem. (Or my problem is different in some way.)

I did perform the web authorization steps, and verified sp_user_has_web_player_credentials = true.

I have not done the Oauth2 steps, as that seemed to pertain to sonos devices.

Any advice from anyone that is having more success? Thanks!

1 Like

Hi, I need some help. Yesterday I installed the spotifyplus component via hacs, restarted HA and wanted to configure the integration. When typing the oauth name I made a typo and got INVALID_CLIENT: Invalid redirect URI.
The issue is now, that I can do what I want. It is not possible to come back to the configuration window. I tried to deinstall the component but it says that the integration is already configured and should be deinstalled first which brought me back to the redirect issue. What can I do?

ok, gelöst: Ich habe den Eintrag in core.config_entries gelöscht. Jetzt hats funktioniert.

@Pirol62
Follow the steps in this FAQ wiki document.

You basically need to remove the SpotifyPlus application credentials, logout of Spotify, and restart the SpotifyPlus install process.

@brett91
I have opened up issue #104 for this. Please have a look at it for thoughts and further instructions.

I will respond further after I return from vacation on Monday.

Thanks - Todd

Hi Lucas, I’m experiencing the same problem when adding credentials (No application_credentials platform for spotifyplus). I’m using the last version of everything.

What I’ve noticed is that SpotifyPlus is at the end of list and not after Spotify, even tough I have rebooted HA.

1 Like

@vis_9
This error can occur sometimes when installing / updating the SpotifyPlus integration via HACS. Not sure what is causing it, and it’s only happened a few times so I cannot reproduce it.

To fix this, you need to do ALL of the following:

  1. Uninstall the SpotifyPlus integration, and restart Home Assistant after uninstall is complete.
  2. Verify that the https://my.home-assistant.io/redirect/oauth uri is listed in the Spotify Developer Application settings “Redirect URIs” list. This is an internal url that Home Assistant uses to intercept the OAuth2 request redirect result. The entry must be listed exactly as it is spelled (case-sensitive), and without the ending slash.
  3. Go to the Home Assistant Application Credentials settings (under Settings \ Devices, click on 3 vertical dots menu in upper right and select Application Credentials) and see if it created any OAuth application credentials related to SpotifyPlus (or Spotify if you’re installing Spotify). If so, delete them.
  4. Open the Spotify Web Player in a new browser window and logout of Spotify. This will force you into a logon screen the next time you try to authorize the OAuth request.
  5. Re-install SpotifyPlus via HACS using the Installation Instructions.

Thank you Lucas! I’ve tried what you suggested but I still was getting the same error.

I’ve solved it by clicking on the SpotifyPlus integration under settings/devices/integrations and in this way a new OAuth application credential form showed up.

After having filled the fields, I was able to continue as written in your guide.

The only “strange” thing I’ve done before installing your integration was having started to install the Spotify official integration that I’ve aborted when the OAuth filling form showed up. On the credentials list there was nothing related to Spotify.

I hope it helps to track the problem.

1 Like

@soulcrash
FYI - just released a new version of the SpotifyPlus integration.

Be sure to check out the SpotifyPlus Card Dashboard as well.

[ 1.0.114 ] - 2025/04/23

  • Updated underlying spotifywebapipython package requirement to version 1.0.200.
  • Added logic to detect device name changes when speakers are grouped / ungrouped. This can happen for devices that are added to / removed from groups and do not correctly inform interested parties via a zeroconf OnServiceStateChange event that the name has changed (e.g. Denon HEOS devices, etc).

Note that it takes between 1-30 seconds for the SpotifyPlus integration to detect any speaker group changes made outside of the HA environment. This delay can be controlled via the Spotify Polling Scan Interval configuration option.

I’ve been working with @brett91 via GitHub Issue #104 to diagnose and fix this issue. Thanks Brett for your assistance.

@ReinierZon
Just checking in to see if you were able to rename that Spotify Chromecast device?

Interested to see if it can be done.

Hey, I’ve not been able to do much yet, but I did managed to confirm a few things:

  • There is really no option in the Android app to rename the Spotify device. Also did a little bit of Googling but didn’t find a workaround for this either.
  • If I rename the Chromecast itself, the name changes for both the devices, so Spotify really uses the device name. I was hoping it might have been 2 separate strings somewhere and if I’d change the Chromecast device name to ‘CC’ the Spotify name might stay ‘Chromecast’, but it doesn’t do that.
  • I had a look at the Spotify Web API reference and there the device_id querystring parameter appears to be optional for most operations. The docs state the following: ‘The id of the device this command is targeting. If not supplied, the user’s currently active device is the target.’. I also tested this, if I skip a track using the Web API directly and leave out the device_id, casting continues and it doesn’t switch to the other device.

What I’m about to do is have a look at the integration and the Python SDK you created around the Web API, my gut feeling is that somewhere in there you made the device_id parameter mandatory? If so, can we change that and maybe add another setting in the integration to ‘Do not automatically transfer playback’ and when that is set, the device_id parameter is left out for all operations that have it as an optional parameter?

Or, maybe easier, in the function ‘GetDeviceByName’ you return the first device from the list where the name matches. You could check if there is an active device with that name first and if so, return that one. Not quite as sturdy as a solution, but I think it would solve this particular problem. There you go: Changed the GetDeviceByName method so it prefers an active device over an inactive device by rvanmaanen · Pull Request #3 · thlucas1/SpotifyWebApiPython · GitHub

this card is truely awesome!!

At the moment when the card loads it lists all my speakers. Is there any way to restrict it to always play on one specific device?

1 Like

@hamd01
Check out the SpotifyPlus Card deviceDefaultId configuration option. This allows you to hide the Devices section, and utilize the specific device for all service requests that require a deviceId. Note that other devices can still be selected by the Devices section, if it remains enabled.

You can also use the SpotifyPlus Integration Default Player Device ID configuration option. This option contains the Device Name and ID of the Spotify Connect device that will be used to play content when ANY of the following conditions are met:

  • when there is no active device.
  • when the default player device id (e.g. *) is specified for a service that requires a device id parameter (e.g. play, pause, transfer playback, etc).
  • when the media player is initially powered on; in this case, the active player is transferred to the specified default player device id if there is no previously selected source.

@thlucas
Hi Todd
I found a new issue: When I listen to Spotify on my iPhone when SpotifyPlus is “on” to show what’s playing on my iPhone, everything is fine. But when I turn “off” SpotifyPlus, then stop the app on my iPhone, then turn “on” again SpotifyPlus (configured to not start playing when turned “on”) after a few seconds, Home Assistant shows the following error: “The action media_player/turn_on could not be executed. Spotify Player device “iPhone” was not found in the Spotify Connect device list; verify the device is discoverable via Zeroconf on the local network”.
Why SpotifyPlus tries to do something with the last device it was playing from when it is turned “on”?

1 Like

@Kamblian
If you have the Auto Select Source on Turn On configuration option set (true by default), it will automatically try to use the last source that was set when the integration was turned off.

What’s happening here is that you are closing the Spotify app on your iPhone, which removes the iPhone source from the Spotify Connect device list. Since it’s no longer in the device list, SpotifyPlus does not recognize it and returns the error message.

You could set the Default Player Device ID configuration option to automatically select a source if a specified source is not found.

You could also set the Auto Select Source on Turn On to false (e.g. unchecked) to not automatically try and select the source when the integration is turned on.

Thank you very much, that helped. I haven’t seen there was a new version to download with this new option. Great work again!

1 Like

FYI - just released a new version of the SpotifyPlus integration.

Be sure to check out the SpotifyPlus Card Dashboard as well.

Spotify originally removed the “Made For You” playlists from their Get Current Users Playlists endpoint on 2024/11/27. I was able to restore this functionality by using the Spotify Web Player Cookie Credentials (e.g. SP_DC, SP_KEY values) on 2025/02/22. They just closed that loophole on 2025/05/03, so as of now / going forward the “Made For You” playlists will not be returned by the Spotify Web API.

This means that any “Made For You” playlists (e.g. “Daily Mix”, “Discover Weekly”, etc) cannot be returned in the GetPlaylistFavorites method results. User-defined playlist favorites will be returned as normal.

Note that you can still define User-Presets in the SpotifyPlus Card configuration to these “Made For You” playlists, so they can still be easily found and played (using the SpotifyPlus Card).

Also note that the “Made For You” playlists still show up in your favorites when using the official Spotify Apps (e.g. Mobile, Web, Desktop). This is a slap in the face to developers using THEIR Spotify Web API, in that it will not return the same list as what you see in their official Apps! It totally frustrates me why they do this! Just had to voice that. :slight_smile:

They also removed the GetTrackRecommendations and GetGenres methods, so those services will no longer function as expected; they will now return a SAM1010E ... deprecated exception.

Wish I had better news, but I’m at the mercy of the Spotify Developers on this one.

[ 1.0.121 ] - 2025/05/04

  • Updated the __init__.py.options_update_listener method to only acquire a token updater lock if the token is being refreshed. Prior to the fix, the lock was being acquired if the token was refreshed OR if integration configuration options were updated. This was causing a thread deadlock to arise if the Spotify token was refreshed while configuration options were being updated, which would hang the Home Assistant user-interface.
  • Updated underlying spotifywebapipython package requirement to version 1.0.204.
  • The above spotifywebapiPython package will now return an exception due to the functions being re-deprecated by the Spotify development team as of 2025/05/03. More information can be found on the Spotify Developer Forum Blog post that was conveyed on November 27, 2024. The following methods will now raise a SpotifyApiError exception due to the Spotify development team changes: GetTrackRecommendations, GetGenres.
  • Due to the above changes made by Spotify, any Algorithmic and Spotify-owned editorial playlists are no longer accessible by certain services (returns a 404 Not Found error). This means that any “Made For You” playlists cannot be returned in the GetPlaylistFavorites method results. User-defined playlist favorites will be returned as normal.

Hi Todd,
I’m using Spotify Plus from about 6 months and my experience got better, update after update, but there’s still a thing that I would like to fix somehow. Like other users I switch from home to car or car to home and I made a small automation that transfer the playback to my Linkplay adapter (connected to my HiFi), checking the device_tracker and the activity sensor of my iphone. It happens that, if my Linkplay is on idle state, it doesn’t resume my current listening, but always play my fav track playlist, from the beginning. I remember you told me that you can’t make tests on a Linkplay device, but do you have a clue of what could happens, a few months ago it behave differently (sorry, I can’t remember which updated changed this…)
It happens the same if I use my custom:button-card with a tap-action, if the target device (Linkplay) is on idle state.
I have SI installed on my laptop, I could do some tests eventually and forward here.

My transfer service:


    service: spotifyplus.player_transfer_playback
    service_data:
      entity_id: media_player.spotifyplus
      device_id: >
        [[[ return variables.spotify_id; ]]]
      play: true
      refresh_device_list: true
      force_activate_device: true
      delay: 3

My automation:

action: spotifyplus.player_transfer_playback
metadata: {}
data:
  entity_id: media_player.spotifyplus
  device_id: 7b34bc2f886500abc3b04e6d21732a3316193f4e
  play: false

EDIT: if I trigger this automation the player start, even if play is false :thinking:

Thank you in advance!

@Sofa_Surfer
Do you have the Spotify Web Player Cookie Credentials SP_DC / SP_KEY set in your SpotifyPlus configuration options? If not, I would suggest you set those and they try the transfer playback service call.

As for device id 7b34bc2f886500abc3b04e6d21732a3316193f4e, is that a Google Chromecast device perhaps? If so, then the play attribute is ignored as Google Cast requires play to start in order to activate the device.

Hi @thlucas, I have added sp_dc and sp_key and now it looks I can’t connect at all to any device (Sonos or Linkplay), if both transfer or start a new content, or within the SpotifyPlus card, I have to use the Spotify app on my phone.

I have the errors:

Impossibile eseguire l'azione: spotifyplus/player_transfer_playback Validation error: Not found

Could not select source. Not found

I’m not sure if there’s something else wrong in my config/auth…