This topic is to give some visibility to the Spotify Binding, If you search for Spotify Binding you will get all kinds of hits, from python scripts to widgets, and some threads about the binding, but they contain mostly old links. And none that promote this new binding as it is available. This binding was initial developed by @astenlund74 and I continued his work
For anyone wanting (or using) Spotify with openHAB there is a Spotify Binding available. While this binding is not yet part of any release, it’s very easy to install the binding because it’s available in the Eclipse Market Place.
To install the binding, enable the Eclipse Market Place in Configuration system with maturity level beta and than the binding will be available in the list of bindings in PaperUI.
The documentation for this binding can be found here (Once the binding is merged I’ll update the url):
Note: The binding in the Eclipse IoT Market place uses the OAuth2 module of openHAB that has been made available in openHAB version 2.4.0. An older version of the binding is still available, but it won’t be updated with fixes: Release Spotify Binding (Old) · Hilbrand/openhab-addons · GitHub (Only install jar from the link if you run openHAB 2.3.0)
If you have the updated version of the binding from the Eclipse IoT Marketplace that supports the deviceName as id make sure you have the version that shows in the title Spotify Binding (Beta 30/04/2019 21:00) or a later timestamp
I’ll be updating this message when the binding status in openHAB changes.
somehow I can’t see the binding in the paper UI. I installed the market place and even with Production/Stable level I can’t see the binding in the PaperUI, even after a reboot of OpenHAB. I made sure that “Include Bindings” is turned on. Do you have any idea?
Did you try the level that I suggested: Beta The level Production/Stable is higher than Beta level. So anything on Beta level is not necessarily available on Production/Stable level. So in this context by using the word even you seem to wrongly interpret how levels work.
deviceName - Name of the currently active Connect Device, set the device ID to transfer play to that device.
I just tried it and it does work with Spotify clients on phones and PCs when the app is running. Changing it to a Google Home device sadly doesn’t work, but I think this is due to the architecture of the devices. Spotify doesn’t have any control over it the moment you change the running “cast app”.
Does anyone know whether it’s possible to force the Home Mini/Chromecast to launch the Spotify app?
I’ve made some changes to the Spotify binding. The new binding is available in the Eclipse IoT Market place
Note 1: This changes some of the channels. So it requires the things to be readded Note 2: This version depends on OAuth client in openHAB and therefore requires openHAB 2.4.0 or higher
The deviceName was a option list with id as key, name as value. However that is not usable in rules. In rules only the id can been seen, so it’s impossible to create a rule that checks on a name.
This change adds a new channel devices specific for selecting and changes the deviceName channel back to only displaying the name.
Also changed it’s possible to select a player by setting the deviceName or deviceId.
For playlists this was the same problem. Therefor a new channel was added playlists that can be used to select a playlist.
Another new playlistName channel is added that shows the name of the playlist being played.
Changed using the device name as representation property instead of the id. This because some devices get a new id when rebooted.
Fixed the bug were the derived playlist name from the playing status didn’t match with the id in the selection list. As a result of that problem when selecting a playlist and the active status was returned the playlist didn’t show what playlist was playing.
Thank you, hilbrand, for the awesome work - it’s highly appreciated!
There’s a minor error in your example in the github-readme:
The first and third items in the spotify.items have the same name (Player spotifyTrackPlayer) which caused a warning.
Would you like to have a pull request on github for this? I never did one but if it saves you even a minute of work to say “yes” than do it yourself I’ll happily contribute!
And one question: Do you have an idea how to DennisVonDerBey mentioned challenge with casting to a chromecast or similar? You mention in the readme that they’re not visible when not active and even when added manually as a device I have no idea how to get a ruleset in place to wake up the chromecast device, transfer spotify over and then take control via your … thing
Thanks for pointing this out. I’ve updated the docs. Since the pr is still open it was simple to just add it.
I have not specifically looked into this. I think it was possible with the chromecast binding. Maybe a rule that triggers on change to play, send signal to chromecast, than schedule another play command after some time to give chromecast some time to wake up.
I’m not sure if I stumbled upon a bug or it’s a user error>
While most API-calls work just fine, including cover art and Progress I’ve found a few which are simply never populated:
All others which I tested work just fine and update live (e.g. trackProgress, album cover, names, etc).
The only pattern for them I’ve noticed is that all of those have an underscore in the spotify API (track_number, duration_ms, etc). Not sure if that helps though.
The (working, except those three) configuration is: