since update to OH 2.2 and the last Sonos update i´ve a problem with the notification sound.
Rule
/* ------------- Türklingel --------------------
*/
rule "Türklingel (EG)"
when
Item EGKlingelsensorState changed from OFF to ON
then
logInfo(filename, "Es klingelt (EG)")
pushover('Es klingelt (EG)!')
if(SonosDoorBell.state==ON){
//Lautstärke setzen
gSonosNotificationVolume?.members.forEach[sonosV |
logInfo(filename, "Setze Notify Lautstärke auf \"50\" für Sonos Member \"" + sonosV.name + "\"")
sonosV.sendCommand(50 as Number)
]
//Sende Klingelton
gSonosNotificationSound?.members.forEach[sonosS |
logInfo(filename, "Sende Klingelton \"http://192.168.XX.XX:8080/static/ding-dong3.mp3\" für Sonos Member \"" + sonosS.name + "\"")
sonosS.sendCommand("http://192.168.XX.XX:8080/static/ding-dong3.mp3")
]
}
end
The volume and the sound are correctly played by the Sonos with a small time offset of about 1-2 seconds, so far OK.
Unfortunately, the Sonos does not seem to put the volume back to its original value immediately after the end of the soundfile ends and it will playback for about 5-10 seconds at the last heard song at volume 50
After that, everything is OK again.
I do see that1-2 second pause before starting the notification and also when ending, however since I do set the NotificationVolume after startup for all members, I do not see the problem with the volume.
Btw:Isn’t a 50 , even for a doorbell , way to loud?
Just split your rule. Use the code that sets the volume in a rule that is triggered at system start.
[Edit]
val Number NotificationVolume = 20
rule "NotificationVolume"
when
System started
then
gPlayer_NotificationVolume.allMembers.forEach [item | item.sendCommand(NotificationVolume)]
logInfo("IntialNotificationVolumeSetting","NotificationVolume set!")
end
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.
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
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.
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.
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
]
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.
. I use this when we are in the garden. Therefor i can switch it on and off.
