Hey @hilbrand,
thanks for working on the binding. I did some testing with my setup that consists of 3 Chromecast Audio devices and an Audio Group with all devices. The Chromecasts are only discovered when the Spotify app is active, which means that they also are shown as offline after playback stops. But that’s what I expected and rather a Chromecast issue there. I solved this using a spare android phone and tasker to select the target device there.
I noticed a few issues with the binding:
Album and Artist are not displayed (Track names work)
Album Image is also missing
I’ve noticed that it did around 18000 API calls yesterday. Don’t know if that is a problem though. Just seems a lot
What is working for me is setting volume and shuffle.
Chromecasts: It looks like they go into some sort of sleep mode when not playing. Then they are not reported by the Spotify API. Maybe it’s possible to wake them up using the chromecast binding and a rule that is triggered when clicking on play in the spotify binding.
No Album, Artist and Image: I can’t reproduce this. From what I found about this, some type of sources don’t give this information and some older devices also don’t seem to report this information. You could compare this by running the Spotify webclient and see what that reports. Also if you set log level to TRACE (org.openhab.binding.spotify) you can see what the Spotify API returns (Don’t forget to set the loglevel back to DEFAULT because it creates a lot of logging).
Lot’s of API calls: The default configuration option calls Spotify every 5 seconds (with 2 calls). The API is rate limited, and the binding should handle that, but I haven’t seen any problems.
If this would be(come) a problem it would be worth to add some more logic to reduce the number of calls, but it might limit response time if Spotify is controlled outside. For example only call API at the end of a song and not when it’s not playing (that would not get updates when the user for example controls Spotify from a phone) and/or additional update on Refresh command.
I’ve updated the Spotify Binding jar. The code has also been added to the PR and unless there will be lots of feedback this version should be close to what will be the finished version to be.
Hi, thanx for your great work!
I replaced the old spotify connect binding with your version.
Now my redirect url doesn’t work anymore - the old one did.
Is it possible to use https://home.myopenhab.org and what do i have to set up to get this work?
You need to go to the local connectspotify page, which should be accessible via your local openhab dashboard (for now, possible this will be removed) or http://<your openhab ipaddres + port>/connectspotify This will show the redirect uri. (Possible if you remove the last part (/authorize) of the redirect_uri it should work I think)
I’m not sure if myopenhab.org can be used. I haven’t tested it, and am not familiar with how myopenhab.org works. Can you access your dashboard from myopenhab.org?
Hi thanx a lot. The local connection works and i am testing it now. A connection with myopenhab.org would be great for security reasons (no need to open your openhab system for connections anymore).
I am using openHAB 2.3.0-1 (Release Build) an have the following problem:
Title, Playback time etc is not shown - but PLAY, PAUSE commands are working.
Log shows following warnings:
[WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
at org.openhab.binding.spotify.internal.handler.SpotifyBridgeHandler.updatePlayerInfo(SpotifyBridgeHandler.java:325) ~[?:?]
at org.openhab.binding.spotify.internal.handler.SpotifyBridgeHandler.pollStatus(SpotifyBridgeHandler.java:266) ~[?:?]
at org.openhab.binding.spotify.internal.handler.SpotifyBridgeHandler.lambda$0(SpotifyBridgeHandler.java:130) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Hmm… great it works. The error is related to changes in the smart home core. It’s available in the 2.4.0-snapshot… (Incidentally I was the one who submitted this method to the core and so started using it, but it breaks with current releases… so much for progress…)
I’ve updated the jar file in the url provided above that removes the use of this method, so that jar should be compatible with 2.3 (at least for not having this problem). The final release will have the methods.
I’m trying to authorize my account but I get INVALID_CLIENT: Invalid redirect URI for both local IP and myopenhab.org when I try to set it up. Suggestions?
Edit: Had to add the redirect uri in the Spotify dashboard…
If I understand correctly there currently is no functionality to start playing a song/playlist on one of the devices from OpenHAB? My first goal with this would be to automatically stop playing in headphones and keep going in the living room when I come home. So much potential in a good Spotify binding!
Possibly. I suppose I am supposed to send the track to that item somehow? Can not find any information about format, link type, track id etc anywhere so I’m just guessing right now.
Edit: Found the documentation…doh. However I have tried sending both Spotify uri and href of a song to the trackToPlay using a string item but can’t get the song playing on my computer to change.
spotify_tracktoplay.sendUpdate("spotify:track:abc123")
spotify_tracktoplay.sendCommand("spotify:track:abc123")
'spotify:player:f7a68189' changed from ONLINE to OFFLINE: Non supported context uri
Got it working with a playlist
…sendCommand(“spotify:user:spotify:playlist:abc123”)
I did a quick look-up and it looks like playing a track requires a different call in the spotify api. But that is not supported by the binding (yet: I’ll add it). It should be able to play albums, playlists.
Also if you want to transfer playing to another device you can simply start play on the other device in openHAB (you have to add that device as thing and start play on it). It will then start playing the song already playing on the other device.
so i have the bdining installed i can see it in paper UI
i have secert and clinet id
i added a thing with the above
:24:22.977 [INFO ] [smarthome.event.ItemStateChangedEvent] - infoDate changed from 2018-09-23T14:21:22.976+0300 to 2018-09-23T14:24:22.977+0300
14:24:44.854 [ERROR] [est.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/spotify:player:SpotifyBridge/config'
java.lang.IllegalStateException: Thing with UID spotify:player:SpotifyBridge has no handler attached.
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.
can someone please tell me how to add this to the item file?
i dont like doing it from UI…
I have done some experimenting with this today and come to a few conclusions. The Chromecast issue can be solved by hosting a x86 Android machine, run Tasker on that and then trigger that virtual tablet to cast to the correct device. The binding will then automatically update current device etc. This should be possible to automate 100% from OpenHAB calls to Tasker on this “virtual tablet”.
It’s not very pretty but it seems there is no support for anything better by Spotify/Google as of now.
Update: It is possible to ask Google assistant to “play music on the tv” to trigger the Spotify Chromecast device to wake up.
Hi! Kudos for all your work.
I think there is a bug with the binding, so i explain what i want to do :).
I have a Amazon Echo infrastructure at home, but dont like the sound. I have a parallel Soundtouch (Bose) Infrastructure and i would like to hear the music with the soundtouch infrastructure, although triggering natural (without skills) commands to the echo in the room. (i.e. Alexa, play music).
Therefore my idea is: Track the Player State and afterwards check which device plays. Detect the corresponding Soundtouch Device and transfer the current play to the soundtouch device.
The Problem is:
The following doesnt work:
“Also if you want to transfer playing to another device you can simply start play on the other device in openHAB (you have to add that device as thing and start play on it). It will then start playing the song already playing on the other device.”
When i press the play button on another device although there is already a device playing, simply nothing happens.
Therefore i have made an (i dislike it because it could be all done with this binding) own solution by making a curl request to switch to the device( spotify api supports it-> Transfer a User’s Playback in Spotify Api Console).Great thanks to that, because i can use the authorizationtoken from the related item, to make my curl request
Do you think you can fix this?
Another question:
Do you have an example things file for the binding? This way we could choose whether we want to add things via paperui or manually as file (my preferred way)
I’ve got the same problem. The controlls of the device don’t work. If I start music via my mobile on a connected device, I can pause, play, change playlist via the bridge, but the controlls of the devices don’t work. Also switching to an other device does not work.
