I currently use the Sonos API to call an HTTP request to play a variety of ringtones through my Sonos speakers whenever someone taps my doorbell. I use a Node-RED flow for the automation. It works well… except for the delay. The call I’m making is http://xx.xx.xx.xx:5005/clipall/Door_DingDong2.mp3/60, which translates to, “play this mp3 to all Sonos devices at volume 60.”
I really think the delay comes from the device join that results from using clipall; whatever state the Sonos devices in, and whatever groups, are first stored, then all devices are grouped, the clip is played, then the devices are reverted back to their previous groups and play states. It works well in theory, but the typical result is that by the time the doorbell rings, I’ve answered and opened the door, and sometimes already let the guest in. It’s become sort of a running joke amongst a few people, once they’re standing in my living room… “I’m here!”
I’m considering what changes to make so that the doorbell rings more quickly. Like I said… I think the join is the issue. I have a few options, I suppose, but I think if I could establish in Node-RED which device is the master of a group, it would help:
When music is playing already, just playing the doorbell to the master of a group would be fine. That would at least eliminate the grouping and ungrouping, and hopefully most of the delay. But what I don’t know is how to establish which of a certain number of devices is the master.
When music is playing in the back yard, a delay of five seconds or so isn’t that big a deal. But if I could establish the ‘master’ of the group and play to that as in the first bullet, I might be able to avoid that.
If no music is playing anywhere, I could just play to a single device or whichever group that device is already a part of. That would work just fine for my needs.
I’ve tried using http://xx.xx.xx.xx:5005/clip/Door_DingDong2.mp3/60 without specifying a device, but the API seems to pick a device at random and play to that, regardless of group or play state.
I guess I’m looking for ideas on how to route the messages in Node-RED to Sonos such that it takes advantage of whatever grouping already exists in the Sonos system. Thanks for reading.
Thanks for that thread; I got the script to work, but what I don’t like is that the Sonos snapshot/restore will interrupt whatever song is playing, then start a new/different song when restored. That’s not unique to this script; I’ve seen it elsewhere and it appears to be just how the service works.
What I’ve done to reduce the delay in the meantime is I’ve changed my Node-RED flow so that the doorbell sound just plays to one Sonos device, which is the one I’m most likely to hear if I’m in the house. That eliminates the unjoin/join commands and speeds things up. I use this Sonos API command: http://xx.xx.xx.xx:5005/kitchen/clip/Door_DingDong2.mp3/60
If the kitchen Sonos is playing music as the only device in its group of one, it will stop the music, play the doorbell chime, then resume playing… a different song.
If the kitchen Sonos is playing music as part of a group, the group will continue to play, and that device alone will play the doorbell chime. It doesn’t seem to matter which device is the coordinator.
If the kitchen Sonos is not playing any music, it’ll just play the doorbell chime.
Most of the time, my speakers are either in condition 2 or 3, so it works better for me than the script linked above does. So far, delays are a bit lower.
I wonder if that depends on what service you are using. I typically use spotify. If I’ve started music from the spotify app, the controls through sonos are much worse (e.g. my wife can’t edit the queue if I’ve started it from my phone from spotify, but can if I started it through the sonos app).