Idea for Binding: Spotify Connect binding

I have in Beta, perhaps my binding list hadnt refreshed earlier - all good is there now thanks!

Im just playing and added deviceName in but it seems to show as deviceID

String spotifydevicename ā€œdevice name [%s]ā€ {channel=ā€œspotify:player:spotify:deviceNameā€ }

Text item=spotifydevicename

I donā€™t know if this is something 2.3 specific, but what does it show when you look in Paper UI? The deviceName is populated with all available devices as option list, with id as key and name as value. If this isnā€™t handled correctly it might be the cause why it shows the id and not the name.

@hilbrand - awesome binding. Thanks!

I have a small issue with the following values not updating: albumName, albumImage
and artistName not updating. Should I be doing something to trigger this? (running the latest build off the marketplace)

==> /var/log/openhab2/events.log <==                                                                                                                                                                    
2018-10-19 16:50:56.562 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackPlayer changed from PAUSE to PLAY                                                                                             
2018-10-19 16:50:56.564 [vent.ItemStateChangedEvent] - SimonSSpotify_DeviceShuffle changed from OFF to ON                                                                                               
2018-10-19 16:50:56.564 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackProgress changed from 0:00 to 0:18                                                                                            
2018-10-19 16:50:56.566 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackRepeat changed from  to off                                                                                                   
2018-10-19 16:50:56.567 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackProgressMs changed from 0 to 18669                                                                                            
2018-10-19 16:50:56.567 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackDurationMs changed from 0 to 165304                                                                                           
2018-10-19 16:50:56.567 [hingStatusInfoChangedEvent] - 'spotify:player:simon' changed from ONLINE to OFFLINE: Value must be between 0 and 100                                                           
2018-10-19 16:50:56.569 [hingStatusInfoChangedEvent] - 'spotify:device:simon:Pixel2' changed from OFFLINE (GONE): Device not available on Spotify to OFFLINE (BRIDGE_OFFLINE): Spotify Bridge Offline   
2018-10-19 16:50:56.569 [hingStatusInfoChangedEvent] - 'spotify:device:simon:All' changed from OFFLINE (GONE): Device not available on Spotify to OFFLINE (BRIDGE_OFFLINE): Spotify Bridge Offline      
2018-10-19 16:50:56.570 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackDuration changed from 0:00 to 2:45                                                                                            
2018-10-19 16:50:56.570 [vent.ItemStateChangedEvent] - SimonSSpotify_Playlist changed from  to spotify:user:spotify:playlist:37i9dQZEVXcENLFdCnYPBN                                                     
2018-10-19 16:50:56.570 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackId changed from  to 0aUiK0MlOjha5hUmG2AVzm                                                                                    
2018-10-19 16:50:56.570 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackHref changed from  to https://api.spotify.com/v1/tracks/0aUiK0MlOjha5hUmG2AVzm                                                
2018-10-19 16:50:56.570 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackUri changed from  to spotify:track:0aUiK0MlOjha5hUmG2AVzm                                                                     
2018-10-19 16:50:56.570 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackName changed from  to empty                                                                                                   
2018-10-19 16:50:56.571 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackType changed from  to track                                                                                                   
2018-10-19 16:50:56.571 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackNumber changed from 0 to 1                                                                                                    
2018-10-19 16:50:56.571 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackDiscNumber changed from 0 to 1                                                                                                
2018-10-19 16:50:57.561 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackProgressMs changed from 18669 to 19669                                                                                        
2018-10-19 16:50:57.561 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackProgress changed from 0:18 to 0:19
2018-10-19 16:50:58.564 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackProgressMs changed from 19669 to 20669
2018-10-19 16:50:58.565 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackProgress changed from 0:19 to 0:20
2018-10-19 16:50:59.564 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackProgressMs changed from 20669 to 21669
2018-10-19 16:50:59.566 [vent.ItemStateChangedEvent] - SimonSSpotify_TrackProgress changed from 0:20 to 0:21
    

edit: config here - https://github.com/imaginator/system/commit/dee62ae9f994caa13bdd4b90c9a2b56c3473d9f9#diff-a22bada3200b331d2344eaad49fbe38f

I think there is a problem with the popularity channel. If you remove it and it works then itā€™s the problem and I need to fix it.

@hilbrand can confirm - removing the popularity channel and now Album art and Artist name works perfectly. Thanks!

Same in PaperUI

I dont see an option list have I defined the item wrong?

Just checking if it is currently supposed to work like this to get the Binding authorizedā€¦

My setup uses NGINX proxy and I connect with HTTPS to it using a public domain name with Letā€™s Encrypt certificate (so, no self-signed stuff). When I enter the HTTPS address in the callback URI like https://openhab.domain.ext in Spotify and open the https://openhab.domain.ext/connectspotify page in the browser, pressing the green authorize player button responds with ā€œINVALID_CLIENT: Invalid redirect URIā€. This is actually to be expected since the binding passes http://ā€¦ in the authorize request as can also be seen in the screenshot below, despite opening the https://ā€¦ address.

Only when I change the callback address to HTTP to match what the authorize request sends to Spotify it works (I redirect HTTP to HTTPS in the proxy). Is this the expected behavior?

I would think this should be ok. Maybe itā€™s something related to 2.3. Iā€™ll going to check if itā€™s something 2.3 specific and report back to you.

The url constructed to use as callback is derived from what the webserver running the connectspotify page gives. The code itself doesnā€™t specify http as such. So it might be related to what the proxy passes to the webserver. Maybe there is a solution to pass this information, but Iā€™m not familiar with the proxy to give a complete answer. In general the callback is only used for authorization so after that step itā€™s not used. So to answer your question. From the binding side this looks like it works as I would expect it to work.

Thanks @hilbrand. It is a one time issue indeed. Just wanted to let you know. It is related to proxy settings for sure. I just would have expected (not an NGINX expert myself) that

proxy_set_header X-Forwarded-Proto    "https";

might have helped. I guess notā€¦ :sunglasses:
Perhaps you can add a remark in your README for others using a proxy and doing http to https redirection? :innocent:

Iā€™m trying to setup a button to play the daily mixes. Itā€™s most likely that this is Spotify restriction rather than a binding issue but I thought I would check. When sending:

smarthome:send AllSpeakers_TrackPlay spotify:station:user:1131378623:cluster:5Ma1xhkL7wRQbmPSL2XHGY

shows up with a Non supported context uri error.

The logs show:

2018-10-24 16:25:50.080 [ome.event.ItemCommandEvent] - Item 'AllSpeakers_TrackPlay' received command spotify:station:user:1131378623:cluster:4FfrekUbXVWg9FmALhXzsv
2018-10-24 16:25:50.082 [nt.ItemStatePredictedEvent] - AllSpeakers_TrackPlay predicted to become spotify:station:user:1131378623:cluster:4FfrekUbXVWg9FmALhXzsv
2018-10-24 16:25:50.132 [hingStatusInfoChangedEvent] - 'spotify:device:simon:All' changed from ONLINE to OFFLINE: Non supported context uri

Iā€™m imagining that this is due to the Daily Mixes being infinite playlists. However the awesomeness of being able to select one of the Daily Mixes from Habpanel made me thought it was worth double checking.

1 Like

The Daily mixes donā€™t seem to be accessable via the api unfortunately and also canā€™t be started via the apiā€¦ So yes this seems to be a Spotify issue and not something that can be fixed :slightly_frowning_face:

1 Like

I was just working on the documentation and found out this channel should be configured as a Selection and not as a String. Maybe that will solve your problem.

1 Like

are you able to give me a rundown of the items and sitemap you have working - mine doesnt work with:


Item
String spotifydevicename "device name [%s]" {channel="spotify:player:spotify:deviceName" }

	Text item=spotifydevicename - gives an ID Number
	Selection item=spotifydevicename - shows nothing at all

Your items and sitemap look ok. If you had installed a earlier version of this binding it might be some caching problem. Clearing the cache and remove and then readd the thing can help in such case. Other than that I can only think of that it is a version 2.3 specific issue.

@hilbrand thanks for this great binding. Testing it for a few days now and really enjoying it.
However, I discovered some (small) issues:

  1. Sometimes, when I switch the playing device to standby the bridge state changes from ONLINE to OFFLINE:
    'spotify:player:9faed77b' changed from ONLINE to OFFLINE: Player command failed: No active device found
    'spotify:device:9faed77b:543d' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE): Spotify Bridge Offline
    'spotify:device:9faed77b:3688' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE): Spotify Bridge Offline
    Afterwards the bridge comes back to ONLINE again, but then I canā€™t start playback again from the bridge. If I try to select an active device, the state always jumps back to "". I have to start it from another controller device (e.g. smartphone). Oddly enough, the described behaviour doesnā€™t occur every time and I havenā€™t found a pattern so far.

  2. The Volume channel does not support ON/OFF/TOGGLE and INCREASE/DECREASE commands. I know, that I can easily workaround these by sending distinct values, but I thought as the channel is a Dimmer it would have to implement these commandTypes as well.

Greetings, Hans

Hans, Iā€™ve some additional questions/comments:

  1. This is probably a timing issue. Meaning the binding polls the spotify api and possible if that happens at a certain moment when the device is set to standby the Spotify api returns with an error. This error triggers the binding to go offline. But since it was a temporary error the binding recovers and will in the next polling call returns normal results and set the binding online again. Iā€™m only not sure why itā€™s not possible to select an device. Iā€™m going to do some testing to see if I can reproduce this problem.
  2. ON/OFF should indeed be supported as itā€™s a dimmer. But the question is should it work as defined, which means ON is 100% volume. It probably should not do that as it could result in unpleasant results. I donā€™t know what the best approach is. A dimmer channel is compatible with the INCREASE/DECREASE commands, so from openHAB point of view that should not be supported. Also the Spotify api doesnā€™t support it, so how much would volume change an increase or decrease be?
  1. Maybe I should mention that I usually turn off both of my spotify devices simultaneously via an openhab group item, but I donā€™t think that this should be an issue.
  2. I donā€™t think that turning ON to 100% for the dimmer switch would be the way to go, because this would simply be too loud in most cases. I thought there would maybe be a MUTE command available by the API, but it doesnā€™t seem to be. Best way would be to return to previous set value but I donā€™t know if this can be done through openhab. Concerning the INCREASE/DECREASE commands I agree that it does not make much sense to define any random increment value as it will never fit evverybodyā€™s preferences.

@hilbrand I did some more investigation on this and it seems that this only seems to happen if the playing/active device is my Denon AVR and I turn it off then (or change its input source). Then all items of the spotify bridge are reset and I canā€™t start playback from the bridge itself anymore on any device.

However, even though this seems to be an issue with the receiver, it still doesnā€™t explain why I can perfectly start playback again from any other controlling device (e.g. smartphone, web player) but not from openhab. Maybe you are able to find a solution (tell me if I should provide any advanced logs or such).