Add at least a 1 second delay between setting the volume and playing the chime. Sending multiple commands to any siren/chime related device too close together can cause the device to randomly play the sound multiple times.
Just updating. I’ve yet to hear the chime duplicate itself since these two changes.
- play sound custom action
The delay should make a huge difference on reliability, but because of that extra command to change the volume it wouldn't surprise me if every once in a while it still plays a duplicate sound.
The device supports the chime capability which is what the Chime action in RM uses so using a custom command wasn't necessary...
Okay, well I'm going to leave the rule in place that I have today to see if I have any issues over the next week.
I get repeated chimes on occasion, even when sending a single command. When it happens to me it will play the first 0.5s or so about 4-5 times really fast, then play the whole chime.
Doesn't happen very often, but did it again yesterday. Not a big deal, just an anecdotal data point.
Is there no fix for this?
Doubt it. Although I haven't looked. On my system it rarely happens (maybe 1 time in 30?), and isn't that annoying to me when it does - so I've spent exactly 0 minutes trying to figure it out.
Looked like it happen today. Spoke to soon.
It’s also showing on and off on its own too.
Can you look at your event logs and tell if you see on and off happening on it’s own without actually playing a sound ?
I noticed the drivers for this thing allow for speech. Has anyone gotten that portion to work? I bought two to use specifically as notification players -- thinking that was why everyone was so damn excited about these over the previous models that I already have 4 of.
In the ones you originally posted, actually. If not for speech, why the hell is everyone so excited for this? The LED is not even as effective as the Krypton flash bulb on the previous. Makes this seem like more of a casual notification device.
Umm, I don't have those options either. Which driver are you using? The native driver or custom?
The device can only play the 30 sounds that it comes with. Which light effect are you using?
That's the driver I wrote for SmartThings, you should be using the built-in Hubitat driver.
The only reason that SmartThings handler has the speech synthesis and music player capabilities is so you can play the chimes by number using the built-in SmartApps Smart Home Monitor and Speaker Companion.
That's a real bummer. So can anyone explain why they're so excited about this? Can I at least upload custom MP3s to trigger like I can on my doorbell? Otherwise I see no improvements here.
First, no one said they were 'so damn excited' about anything.
Second, people like the device because pretty much no other siren/chime device actually works 100% right (including the previous aeotec model). This one actually doesn't either, but is really close.
Third, yes, you can make more capable devices by rolling your own so you can use MP3, etc, but that isn't what this is about. Many people just want a dang chime/siren that works when they need it do, without a ton of configuration/setup. If that isn't for you / isn't what you are looking for, that's fine.
Fourth, I'm not sure why you would have bought 2 of them without understanding what the device's capabilities are first. Maybe that is why you are coming across as combative/cranky - I don't know. I'm sure you can eBay them or something, though.
I purchased two from the driver showing speech. That being said, they're super cheap, so it's not a big deal. Just more sirens now. They seem to function about the same in terms of reliability as the old ones.
Picking up extra Google home minis from Lowe's for half price. $25 each. If you could make them play a chime or siren track without the cloud, it might be the better device though. Haha. I know they don't get nearly as scary loud, but I digress.
It is puzzling, why sirens & chimes appear to be so hard for manufacturers to get right.
It’s not that they have to report or monitor so much.
It's the prioritization of the messaging. For example, with the doorbell model, if the siren is going off, you don't want the doorbell being pushed to override that, you want the siren to keep going off. Whenever you have to have software make a decision about something there's a potential for that decision to not only cause the wrong thing to happen but to have extra things happen or nothing happen at all, which was the failure of the doorbell 5.
It's a z-wave issue...
If the hub sends the command to play a sound and the device doesn't respond within something like 50ms it sends it again and usually does that 5 times and then tries routing it through another device multiple times.
As soon as the device acknowledges the command the hub should stop sending it and the device should only execute the command it acknowledged, but sometimes extra commands slip through due to timing issues.
Most hubs have this issue and the problem is worse if you send multiple commands to the device at the same time which is why adding a delay between changing the volume and playing the sound made a big difference for the user with the duplicate issue.
I believe the duplicate command issue happens with most devices, but it's not an issue for a light, valve, switch, siren, etc. because if you tell it to do something multiple times and it's already doing it the device can easily tell it's a duplicate and ignore it.
Sending multiple play sound commands to a chime in a short period of time is sometimes done on purpose so the chime can't just assume that it's a duplicate.
The Aeotec Siren/Doorbell 6 does a much better job of differentiating between what's a duplicate command and what it should play so it's much more reliable than the other chimes I've worked with, but it's still not perfect so it still occasionally stutters or plays the sound multiple times.