Problem with Sonos notification sound

Hi Jürgen,

i want to give a feedback on this one. After “splitting” the Rule…it seems to work.

Thx again :slight_smile:

1 Like

About playing after “say”, I have this strange behaviour too.
After the “say” sentence is finished, Sonos play for about 5-10 seconds the first song in the latest played playlist. After that time, they go back to doing whatever they were doing, so playing the song that was playing before the “say” or just stay stopped.
The issue seems to desappear for a while when restarting Openhab.
This is kind of annoying since, for example, I do not want my welcome greeting to start AC/DC when coming late at night!
Playing with volumes, like setting Sonos volume to zero before the notification, does not help.

That sounds like an issue worth reporting on githud. @Lolodomo WDYT?

After some tests, here some more details on the issue, maybe can help.
My set up is 3 Sonos (2 set as stereo +1 constantly associated to the others) all under the same WiFi.
I have 3 Android devices + a Windows 7 able to control the speakers with the Sonos app at the same time.
I do not use music services but play my own mp3 on local disc.
Openhab is installed on Windows 7 and controlled mainly by the tablets.
One workaround that I found (result still to be consolidated) is to start an album by folder and not by playlist (m3u) in the Sonos app. This seems to work although, if a push a notification to just one Sonos (one that is in the stereo and not the others), I do hear just 1 sec. of music after the “Say”. (Bye the way, when speakers are grouped pushing a notification to just one speaker does not work well and most of the times all speakers speak).
Lately even restarting Openhab is not fixing the issue.
I will keep trying to test with workarounds but I believe there should be something to be fixed in the field “automatic time for play-pause” or “channel-mixing/influences” in the notification channel of the binding.

I’ve had weird issues too, linked to notifications and say. Most notably the entire house being woken up by a playlist kicking off at 3am. My ugly fix is a rule which clears the Sonos queues after a couple of hours of the system not being used.

After a couple of days of joy thinking that avoiding m3u was the solution, the problem got back for playlists as well.
And even worse, since sometimes, after the 5-10 sec of music following the “Say” command, the music won’t stop even if it was in stop/pause before.
Last night this joyned to a strange issue of Openhab not recognizing a switch set to SLEEP MODE and hence firing notifications in the middle of the night (although the rule inibits that and always worked fine)… of course followed by not stopping music :frowning:

Thanks Dan for the suggestion, I will try that, although I now have the music starting automatically when I come home, and I’d like to play always the current queue.
I could try to save the queue, clear it an restore it when necessary, I believe this is possible in some way…

Wow, I just found out that if, in the Sonos app, the loop/repeat mode is selected, also the notification go in loop for 20 sec (time allowed for notification), hence repeating the same sentence for 20 sec. This seems not to happen if the speakers are ungroupped and was not happening since the latest Sonos update.
Is it just me having such weirdness? Does it depend on Sonos, Openhab or the binding?
Bye the way, clearing the queue, as Dan said, does solve the music issue after notification, but this workaround does not match my scopes.

Incidentally, has anyone updated to the latest Sonos firmware, and verified if it works with the binding?

A simple working workaround for the issue:

In the .rule file: store the state of Sonos before triggering the notification and restore it after.

var Temp_Sonos_State = null

rule "Notify CO2"
	when
		Item Netatmo_Indoor_CO2 changed     //example of channel to notify
	then
		Temp_Sonos_State = Sonos_State.state
		{
		 playSound("WhateverXX.mp3")           //Sonos is the default audiosink
		 say(Netatmo_Indoor_CO2.state.toString.substring(0,4) + "  parts per million")      //Sonos is the default audiosink
		 switch (Temp_Sonos_State)
			{
			 case "PLAYING":
				Sonos_Controller.sendCommand(PLAY)
			 case "PAUSED_PLAYBACK":
				Sonos_Controller.sendCommand(PAUSE)
			 case "STOPPED":
				Sonos_Stop.sendCommand(OFF)
			}
		}
end

Of course in .items file there must be all necessary Sonos (and in my case Netatmo) items declared.

String Sonos_State        "Status [%s]"      <text>             (Sonos) {channel="sonos:PLAY1:RINCON_xxxxxxx:state"}
Player Sonos_Controller   "Controlli"                           (Sonos) {channel="sonos:PLAY1:RINCON_xxxxxxx:control"}
Switch Sonos_Stop         "Stop"             <sonos_stop>	(Sonos) {channel="sonos:PLAY1:RINCON_xxxxxxx:stop"}

Number Netatmo_Indoor_CO2 "CO2" <carbondioxide> { channel = "netatmo:NAMain:xxxxxx:Co2" }

It works with me, I hope it can be useful for someone else :slight_smile:

I’m going to check back in with you in a week to see if it’s woken your house up with the playlist at 2am!

Updates from my side after few months:
the “simple workaround” that I coded in my last post worked great for few weeks. After that the “state” channel of Sonos became unexpectedly quite unreliable, hence I had to quit the workaround because of having the music starting by itself on wrong state assumptions. With surprise everything went quite better thou.
Now I got OH 2.3 and new issues came along:

  • No notification volume channel: I was struggling until I found that the volume attribute had to be given as e.g. “new PercentType(30)”. This is wrongly documented.
  • Sometimes this volume attribute influences the music volume, hence raising it suddenly 1 sec before and 1 sec after the message. I will try to workaround this since it’s very annoying.
  • Problems to address notifications to the proper speaker.

I guess dealing with Sonos and notification is way too tricky than it should. Let’s hope for good fixes.
EDIT: I mainly use playSound(xx.mp3) for my notifications, maybe some delays/silence buffers could be implemented in that function (?)

For information, this seems to work for me since a couple of days: no wierd music volumes before and after playSound notificaton.
Strategy when a notification needs to be triggered: store Sonos state, pause Sonos, wait 1 sec, notify, then restore Sonos state as before the nofification.
For some reason I do not need another wait after the playSound.

Temp_Sonos_State = Sonos_State.state
Sonos_Controller.sendCommand(PAUSE)
ShortTimer=createTimer(now.plusSeconds(1)) [|
	playSound("XX.mp3", new PercentType(40)) 
	switch (Temp_Sonos_State)
	 	{case "PLAYING":
				Sonos_Controller.sendCommand(PLAY)
		 case "PAUSED_PLAYBACK":
				Sonos_Controller.sendCommand(PAUSE)
		 case "STOPPED":
				Sonos_Stop.sendCommand(ON)
		}
	ShortTimer=null
	]
1 Like

@denist Thanks for the hint. I have changed it.

One day I will figure why I periodicly have strange behaviours with Sonos…
Every time there is Sonos update things get unreliable. Currently, I have many times a complete difference between what the Sonos app shows and what Openhab shows: status and current track. They match just after quite some time.
Obviously this messes up my notifications… which continue to present random volumes.
It even happens to have one song playing before the notification and another one starting after. As if there were two different channels.
I have to admit that my Sonos set is maybe a bit unlike: 2 play1 as stereo + 1 single. All 3 joined.
Addressing notification to just one of them is completely unreliable.

Here is an updated, also to keep this issue alive.
Lately it seems that even my workaround mentioned few post above is not working well again.
I have some kind of trouble in storing the “Temp_Sonos_State” variable before Sonos goes in Pause. Hence many times I store a Pause condition, when it was playing, or even a Playback condition, when it was stopped (bacuse the notification itself triggers a Play condition).
I believe that this has something to do with the fact that variables and Openhab events are not forced to happen in the chronological order as the code says. I do not know if that is possible.

I am trying to introduce some Timers so separate the instructions, but that introduces of course nasty delays between music stopping, notification and music restart. The worst is if I have two or three notifcations in a row (e.g. playsound of weather condition and then temperature. I use locally stored mp3 file with my preferred voice).

I am runing Openhab 2.3 on an old Win7 pc, which is suffering the hot summer, this may influence Openhab performance (?)
It seems that restarting Openhab is many times helping, though I’d rather not do it, since - don’t know why - this my current 2.3.0 setup needs several restarts to be fully opertional (and many times I have to delete cache and tmp… and many time I find them written protected… so I have to restart the pc :frowning: )

Any thoughts? Is it just me?

I played around with saving and resuming, dropped that because I couldn’t get it to work as good as the say command does. You just have to take the fixed 20 second length. And yes, I’m only using the say command in one situation, several commands in a row are not happening.
Concerning the full restart of OH, why don’t you just stop and restart the Sonos binding?

Thanks for your sharing.
Unfortunately the Italian voice of VoiceRSS is not as fascinating yet as a Jarvis similar one that I can reproduce by saving mp3 from a TTS website I use (http://www.oddcast.com/home/demos/tts/tts_example.php).
My notifications are never longer than 3-5 seconds. I tried to play around with the Sonos notification time in the Things, but with no result.

Restarting just Sonos binding seems to be not effecting on this issue.

From a user prospective, I have a feeling that there are several aspects that cause these problems, which have a hard time to coordinate: Sonos firmware, Openhab rule management (e.g. synchro), Sonos Binding (e.g. volumes) and nevertheless my hardware and coding.
Maybe developers can express or concretize my doubts/issues better than me.

Here is a new issue I am facing since yesterday with Amazon Alexa Sonos Skill coming in: if I ask Alexa to play some artist songs on Sonos, it works great, but when a notification (Openhab Playsound) comes in, the current track/playlist is forgotten by the system and the previous playlist starts on right after the notification (i.e. with the song playing before my command to Alexa).
Does Openhab/binding store the playing track address somewhere to resume it after notifications and is not saving it in case of Alexa? Or is it referring to the Sonos App?
Issue is not happening when choosing songs from the Sonos App.
Ideas how to workaround this? It’s kind of annoying having relax music given from Alexa and suddenly hearing heavy metal after a notification just because I was listening to that yesterday…:scream:

Hello, I have the same problem with notification sounds in connection with Alexa. I was hoping for a solution with openhab version 2.5, but the problem persists. Is there a solution?