Historically I used the notificationvolume channel to set/update my notification volume on my Sonos speakers. As of 2.3, that was moved from a channel to a thing property. Unfortunately, I have not found a way to adjust the volume now that it is a property. I used to have a rule that would decrease the notification volume in the evening while everyone was sleeping and then increase it again in the morning. Now I’m stuck at full volume all day. I’ve considered updating the thing properties through the API, however my things are defined in the .things file and not in the database so they are not editable through the API. My only other option is to adjust it myself in the rules but that is complicated and probably unnecessary. Thoughts?
Can’t test ATM, but can’t you use the say-command like “say(myText, mySink, myVolume)”?
Dear all,
I am afraid I cannot test it either. I try to tell you my knowledge about those notifications. The notificationVolume configuration is an optional value. I suggest NOT to set it in your thing handler configuration because at the time you set it, it will be used every time you try to play/say something. Currently there is no chance to change it during runtime. When the notificationVolume is empty the current volume will be used unless you pass a volume via the say or playSound actions in a rule.
I have to add one more thing: It is possible to adjust the volume globally in rules with setMasterVolume, increaseMasterVolume or decreaseMasterVolume actions.
I’ll adjust to using the volume through the say command and see how it goes. What was the reason that this was changed between 2.2 and 2.3? It seems that it is better to have something dynamic instead of something static.
I’ve modified my rules and it looks like it works on the say() command. I read through the discussion on github, I can understand why it was done, and I guess it makes sense to have it just in the say() command. Only oddity is that I still have an item created, just not tied to a channel, which I’m ending up sending to the say command. I update that item twice a day via cron rule to make it quiet and loud now. Only thing left to figure out is why PollyTTS is double-hitting the Sonos and messing up the restore URI/volume.
That are good news. I am happy that everything is working like expected. To let you know: we are planning to introduce an improved notification API for the ESH framework as well as a way to group different audio sinks to play audio synchronized.
Why do you think that? To use such a proxy item is a basic design pattern for smart rules. I have created nearly the same amount of unbound items like items linked to a channel. Just for more flexibility and a better way to control the behavior of my own system.
I’m very glad you are working on the new synchronized playing, I do that almost exclusively and it’s been a pain to get everything synced up.
I have noticed recently that if you play notifications “quickly” some of the URIs are not deleted from the queue on the player itself. This causes some weird quirkyness to happen and one of those URIs is put back as the “last known good URI” instead of the actual thing I had been playing last. I had not noticed this until this morning, all of my players had over 30 old URIs in the queue.
As for the proxy items, I have about the same, it’s just somewhat funny to me that we had an item linked to the channel and now just have a proxy item to do the same thing.
Most of the bindings dealing with audio sinks and playlists could have this issue. I observed it with my Kodi instances too. The reason is that the bindings have to serve the audio streams / URLs for a specific duration. By default this are 20 seconds. You can try to play around with the notificationTimeout configuration to decrease the timeout. The downside could be that notifications which exceeds the length will be cut off regardless.
In the meantime I have worked on the documentation.