@hilbrand thanks for this great binding. Testing it for a few days now and really enjoying it.
However, I discovered some (small) issues:
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.
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.
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.
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?
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.
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).
@boehan I’ve done some investigation and testing myself and found an issue with starting play of inactive devices. I’ve fixed it and updated the market place binding. If you reinstall the binding from the market place it should work now. Thanks for the feedback, it gave me an idea where to look and identify the problem.
I’m using this binding an it works great. But my Amazon Echo gets discovered as an new thing on every restart - so my list of Amazon Echos gets longer and longer. Does anyone have a solution for this problem?
@fuslwusl If a device is getting added every time, it means the identification to identify a device changes every time. It would mean the id changes every time. Can you confirm this is the case? The id is available as the Spotify Device ID in a Spotify Device configuration. It would also mean a Amazon Echo added as Spotify Connect Device Thing before might not be usable anymore as the id has changed. Is that also the case?
So i have upgraded to 2.4 milestone 7, cleared the cache and still have the same issue - device name on the bridge shows the UID - anything else I can try?
Did you recreate the thing? By removing it and then add/discover it? In a sitemap configuration you should use Selection instead of Text. But that doesn’t make a difference in PaperUI.
Thanx for your feedback. The device was detected with a new device id but it was usable with both thing items. I removed all items and added the devices again and now the problem seems to be gone for the moment. Is there a way to view and if necessary clear some of the detected spotify connect device ids in the openhab database?
@hilbrand, really nice binding you have put together here.
However, I am experiencing some problems getting it to work with my Sonos speakers.
It works fine if i start up my Sonos from Spotify connect on my phone or laptop.
Then i can see it changes the device type from laptop/smartphone to speaker, but the device id does not change, so I am guessing my speakers don’t have their own unique ID.
I tried to start up Spotify though the Sonos app, with the result that the binding can’t see spotify is active and i don’t receive any information (track artist cover etc), and can not either control.
I’m not sure what is happening. It might be the Spotify api doesn’t return the device, or returns the information in a way not expected by the binding. You can enable TRACE logging on org.openhab.binding.spotify. This will dump the json returned by the Spotify Api. This will give some insight in what can be expected. If you are unsure about how to interpret the data you can send me the logging (you can send it via a private message) and I’ll have a look. Don’t forget to set logging back to normal (DEFAULT) otherwise your log will be spammed
Thanks for your swift reply hilbrand.
I have no clue what to look for in the log, not even sure if got your suggestion executed correctly, my log did suddenly get a LOT of information, so something did happen.
Can you give me a hint what to look for in the log, just so i don’t send you 50000 lines of non usable log lines ?
You’ll probably see a lot of json data. That’s what is returned by the Spotify API. The refresh rate in the Spotify Bridge Binding is by default set to 5 seconds. You can change this a little higher for the test, because that triggers the large json data sets, and than test specific use cases. and see what the log contains. I should not have a problem browsing through those lines.
I messaged you my log after playing a bit around with the binding.
I found that whatever i do on my HABpanel, play, pause, next, change playlist etc. stops my spotify from playing when i connect to my sonos speaker through my phone or laptop.
Like start up spotify on my phone and start a track -> change device to sonos speaker -> interact with spotify biniding on my HABpanel -> spotify stops…
I’m having some issues with the beta binding from market. I can’t get my spotify bridge to stay ONLINE… I see this in my logs every 60 seconds:
2018-12-20 17:14:45.388 [hingStatusInfoChangedEvent] - 'spotify:player:dd997e5e' changed from OFFLINE to ONLINE
==> /var/log/openhab2/openhab.log <==
2018-12-20 17:14:45.571 [INFO ] [nternal.handler.SpotifyBridgeHandler] - Unexpected error during polling status, please report if this keeps ocurring:
java.lang.NullPointerException: null
at org.openhab.binding.spotify.internal.handler.SpotifyDeviceHandler.updateDeviceStatus(SpotifyDeviceHandler.java:99) ~[?:?]
at org.openhab.binding.spotify.internal.handler.SpotifyBridgeHandler.lambda$8(SpotifyBridgeHandler.java:379) ~[?:?]
at java.util.stream.MatchOps$1MatchSink.accept(MatchOps.java:90) ~[?:?]
at java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1359) ~[?:?]
at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126) ~[?:?]
at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498) ~[?:?]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485) ~[?:?]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:?]
at java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:230) ~[?:?]
at java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:196) ~[?:?]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
at java.util.stream.ReferencePipeline.anyMatch(ReferencePipeline.java:449) ~[?:?]
at org.openhab.binding.spotify.internal.handler.SpotifyBridgeHandler.lambda$7(SpotifyBridgeHandler.java:379) ~[?:?]
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174) ~[?:?]
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) ~[?:?]
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) ~[?:?]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:?]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) ~[?:?]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) ~[?:?]
at org.openhab.binding.spotify.internal.handler.SpotifyBridgeHandler.updateDevicesStatus(SpotifyBridgeHandler.java:380) ~[?:?]
at org.openhab.binding.spotify.internal.handler.SpotifyBridgeHandler.pollStatus(SpotifyBridgeHandler.java:333) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
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) [?:?]
==> /var/log/openhab2/events.log <==
2018-12-20 17:14:45.629 [hingStatusInfoChangedEvent] - 'spotify:player:dd997e5e' changed from ONLINE to OFFLINE
My spotify bridge connect refresh period is set to 60 sec.
@MikaelL From your logging the Sonos device is not available on the Spotify API. This means you can only play it via or the other devices. When playing from the Sonos app I’m not sure what happens. Possible it uses an old Spotify api, meaning it’s not visible in the API used in te binding. I would suspect it also doesn’t show up if you open the Spotify App. You then can’t select the Sonos app or see it’s playing on the Sonos App. Is that right?
@sjef86 I think that was a bug in an older version of the binding (I thought I uploaded a newer version of the binding, I’ll check). Or do you know if you have the latest version?
If I remember correctly this was due to some device player that is added but is not correctly initialized or half deleted. Brute force was to remove all devices and recreate them (Or see which device player thing isn’t correctly configured anymore).
I know this isn’t mainly adressing the binding itself, but has anyone else the problem that the spotify device IDs change from time to time?
I am using two amazon echos, and they tend to go offline when rebooted since the spotify device id changed.
Therefore I have to look for new devices, copy the ID and change the ID on my existing devices
Is there any known workaround for this?
?