@patrik_gfeller : you will find a new jar in my PR in GitHub. This one will be running in 3.1 M4.
1 Like
@Lolodomo I can start the new version of the binding :-). It seems to work for the normal operations like controlling the player and to display meta information. It also shows the artist and title if I play a spotify playlist.
If I play a spotify playlist and issue a say command with openhab:voice say Hallo it stops playing and plays the TTS text, so this works. However - it does not resume the playlist, the player remains stopped. If I play a sonos radio station and use TTS the player resumes after the text has been spoken.
I’ll keep the PR binding version active to see if it works stable. Is there anything I can do to help with the spotify resume issue? If I need to collect logs I would need to know how to enable trace loglevel for the binding (I know it is log:set TRACE ... - but I do not know the namespace I have to change.
Maybe you can reproduce the issue with a free spotify account as well.
Good to know that it works (except playlist restore).
Regarding the restoring playback of the Spotify playlist after the notification, this was already impossible when the playlist was started outside Sonos (meaning from the Spotify app for example). Now, with vli feature used, it might become even impossible even when the playlist is started from Sonos app ? That is a pitty because it was possible before they use vli. I tried to implement what makes sense to me, that is restoring URI + metadata. I will not be able to investigate more without active Spotify account, I am sorry.
From a free account, this is already known that the playlist was not restored after the notification. Could try again one day but I doubt I could find a solution.
I did start the playlist from the spotify app, if I start the playlist from the sonos app the resuming of the playlist works - so the vli did not break this 
.
For me it is not a big deal if the resume does not work if the playlist is started via spotify - as my main use case is TTS as part of my alarm clock, and this uses a sonos radio station. So this works well.
So at least we are at the same point as before. Good.
@Lolodomo I noticed one function that does not work anymore with the M4 & the PR binding: If I select a favorite station in the UI it does not play it. This used to work with 3.0.2. Shall I create an issue for this?
How do I enable trace logs to help to troubleshoot this?
For information, the fix was merged yesterday.
If I select a favorite station in the UI it does not play it.
Using which channel ? radio or favorite ? Is your station a tune-in station ?
I just tried my radio station channel and I was able to start the playback of one of my favorite radio stations which is a tune-in station.
Snapshot 2361 build after M4, the next day I believe.
I experimented a little more and can confirm that it works to set the station via ui. My problem was that I selected the station via rule and then immediately played a notification. I assume that the player did not yet start to play the favorite station and therefore the say command did not resume the station. I now send the text first to the player and wait 30 seconds to start the radio station. This works.
This is probably not a problem with the binding, but a sonos thing that it takes time to start a station. Probably the meta data was not yet set that the binding uses to resume.
Hi,
I can not seem to play any sound or TTS though my Sonos speaker. Not sure when it stopped working.
I can still change the volume and play/pause when music is playing, but there is no sound when playing an mp3 to it as an audio sink (same doorbell.mp3 I’ve been using for years, not not an incompatible mp3).
There is also no log messages in the events or openhab log files.
I’m using openHAB 4.0.3
I have the same issue, did a freash install of OH4 and copied over the settings from my prevoius OH4 installation. And now I can´t play the doorbell.mp3 over Sonos.