Hubitat exposes all the functionality this device has to offer...
If you want to be able to play custom mp3s you have to use a different device like Aeotec Doorbell GEN5 or Zooz Multisiren.
Is there a currently available product that can be used as a door chime? The Dome is unavailable, as is the Zooz Multisiren and the Aeotec Doorbell Gen 5. Thank you!
I understand what you are saying but what I was trying to say was that if you send the siren the parameters in the order I have them in the pic then it works correctly every time no matter how long it has been sitting. Maybe that is the difference.
It's the first command that gets duplicated and your example sends it 4 commands before turning it on which is why you're not running into the duplicate problem. The problem is worse for some users than others so that probably wouldn't completely solve the problem for everyone.
The Neo Coolcam Siren has the same problem except it's even worse than the Dome Siren so I made my ST handler send a basic get command before sending the indicator set which causes it to send multiple reports back instead of playing the sound multiple times, but it adds a delay before the chime turns on.
I just realized that setting one of the configuration parameters that aren't being used before playing the chime would eliminate those reports, but it should still reduce the duplicates so I'm going to modify my Neo handler to do that and see if that helps with the delay.
Long story short, setting those config params before playing the sound isn't what's solving the problem, but you reminded me that sending it something before playing the sound does improve it so a change could be made to the built-in driver that would reduce the duplicates.
If users don't mind a slight delay before the chime turns on then maybe that change can be implemented in the built-in driver.
I understand what you are saying I just have never had any problem with it doing it that way. I have even put a 1 second delay between each parameter to give it a little time to make the changes to each parameter but not sure if it affected it or not. Does add 4 sec. but not a huge thing.
Are you doing that from Hubitat?
The underlying issue is that the device often takes about 500ms to respond to the first command and if the hub doesn't receive an ack response within about 50ms it sends the command again. That means that by the time the device responds the hub has already sent the command 10+ times and sometimes to multiple routers which results in the device executing at least one of the duplicates.
I know ST uses a similar retry delay, but if you're using a different platform the delay might be longer which could reduce the chances of the duplicate chime. If you're using a different platform/hub then your mesh won't be identical either and that plays a role in how severe the duplicate chime issue is.
Long story short, unless you're doing a comparison using the same hub, the results are kind of meaningless...
If those commands are being sent through Hubitat or the duplicate problem exists with the hub you're using then it's the extra commands you're sending before turning it on that's preventing the duplicate commands, not the actual commands you're sending or the order that you're sending them in. Sending any command to the device 4 times before turning it on would have the same effect.
The Aeon Doorbell is a slow device and tons of people complain about the speed because they want the chime to play immediately when a door is opened so sending 4 unneeded commands to the Dome Siren isn't really an option, but adding 1 command should still improve the duplicate problem so maybe that can be done to the built-in driver.
In case anyone is wondering, I know what's happening between the hub and the device because I've watched it with a z-wave sniffer
1 Like
The reason for the pic was to show what parameters it has and what they do as well as better explanation of each. Each parameter needs to be able to be selected individually based on what you want the siren to do. I tried setting the parameters in the device driver and it just kept repeating the melody for the time that was selected in Alarm Duration. Once again it is taking over and is not allowing the Chime Repeat to do it's job. This driver needs to have each of the parameters available to select IF you want the siren to do that. No Defaults! A separate section for the sirens and a separate section for the chimes as I specified in the post above (P1) thru (P7).
The pic is an event from HS. It shows that you should only choose the parameters you want to execute and nothing else. Once the parameters are selected and configured then as you know a simple On is all that is needed.
The driver just needs to be simplified into P1-P7 and labeled as such. Then a configure to set them. Then an ON.
You're wrong about the built-in driver because you don't fully understand how this device works.
The Zooz Smart Chime and Neo Siren have the same functionality and I worked with all 3 manufacturers to write their Official SmartThings handlers so I know what I'm talking about...
Yes, your method of playing the chime does work, but sending the configuration parameters before turning the device on is not how the device is designed to work.
If parameter #7 is set to 1 then the device is a siren and sending the on command, which is Binary Switch Set(0xFF), will play the sound stored in parameter #5 at the volume stored in parameter #1 for the duration stored in parameter #2.
Saving those settings in Hubitat updates the configuration parameters stored on the device so there's absolutely no need to set them again before sending the binary switch set command to turn the siren on.
If parameter #7 is set to 1 you have to use the Indicator Set command to play the chime. The Indicator Set command plays the specified sound # at the volume stored in param #4 for the number of times specified in param #3.
If you set parameter #7 to 2 it reverses the behavior of the device so that the sound stored in parameter #6 gets played when binary switch set is sent.
Parameter #6 isn't used for anything when parameter #7 is set to 1 and parameter #5 isn't used for anything when parameter #7 is set to 2.
The only complaint I've seen about the built-in driver is the random duplicate beeps. It doesn't happen to everyone, it doesn't happen every time, and it doesn't repeat for a full minute which is what would happen if it was using the siren length setting.
Hubitat automatically sets parameter #7 to 1 and it plays the chimes using Indicator Set so if you used another utility to change parameter #7 to 2 after joining the device then indicator set would use the siren settings which would explain the behavior you're seeing with the built-in driver.
I'm starting to think you might not understand how the device is intended to be used within Hubitat which might be contributing to why you think there's an issue with it.
If you select the device as a switch or siren in any app and turn it on, it will use the siren sound, volume, and duration specified in the settings.
If you select the device as a Tone device in Rule Machine and execute the Beep command it will use the chime sound, volume and repeat specified in the settings.
If you use the speak message action in Rule Machine with the "Use Speech Device" option it will play the chime number you enter into the "message to send" field and use the repeat and volume values specified in the settings.
I may not understand how to do the coding part but I do understand as a user if something is over-complicated. Having choices in a device page that really don't fit the device does just that. Things like "Use Speech Device" and "Beep Command". Those to me are irrelevant in a logical way.
What I see (see pic) is a simplified way of doing this driver. Please don't take anything I have said in a negative way, it is not intended that way.
Based on the percentages ST mentioned about the number of users that use custom code and the forum, the number of users that look at the advanced configuration parameters in the manual is probably less than 5% and some companies, like Aeotec, don't even include them in the manual that come with the device anymore.
Making the driver settings match the manual might make things easier for a handful of advanced users like yourself, but it would be way more confusing for everyone else.
If a user wants their front door to play chime 1, side door to play chime 2, and back door to play chime 3, how can they do that with the built-in apps using your recommended driver implementation?
Rule Machine allows you to add a device's custom commands and the built-in driver has a custom command for each chime. Once the custom command is added you can use it in any Rule Machine action.
You can also use the built-in driver's speak method I mentioned in the post above which is easier because it eliminates the step of adding the custom command to rule machine, but that method isn't as straightforward.
If Hubitat had a Chime capability that was supported by the built-in apps then playing the chimes by number would be a lot less confusing, but it doesn't...
Since each device has it's own device ID then each can be set to different sounds using the same driver. Since each device has it's own device page the parameters will be set there. You can then select as many devices as you want in a rule and they will all play different things at the same time.
If there is a situation where the different sounds are not given in a manual then the parameters could be used to demonstrate their sounds by use of an additional box added to my pic that has a drop-down of all the sounds and choosing one would give an example as to what it sounds like. Something like that. You get the picture.
Your asking beginners to know custom commands. That to me is more of a deterrent. They want to be able to hear it and select the one they want. Kind of what you have with all the individual boxes but combined into one box. So there are 1-4 Chimes/5,6 Melodies/7,8 sirens/9 4 tones/10-12 has 2 tones. 10-12 sound the same to me.
So the drop-down to me would have:
Chime 1
Chime 2
Chime 3
Chime 4
Melody 1
Melody 2
Siren 1
Siren 2
2 Beeps
4 Beeps
LOL, if a user wants to play a different sound for 3 doors, your solution is to have them buy 3 sirens...
With the built-in driver a user could have 100s of automations using the same siren to play all the different chime sounds.
No matter how many real-world examples I provide that clearly demonstrate that the built-in driver is implemented in a way that's less confusing to the average user and provides a lot more functionality then your method, you're never going to agree so I'm done trying to convince you.
All I can say is that you're not going to find any built-in drivers that are implemented like that and most likely won't find many community drivers like that either so if that's what you want then you better start learning Groovy because you're going to have to write them yourself...
2 Likes
I am convinced and I do see what you are saying. I agree that this is enough and that it needs to be put to rest. I wish I did no Groovy because then I probably wouldn't have argued with you to begin with. So thanks for being so patient and I will learn to use it as is.
1 Like
When you're used to doing things a specific way with one platform it can sometimes be difficult to see how Hubitat tries to make the device as functional as possible without requiring the user to know the inner workings of the device.
One other thing, when you setup a custom command in Rule Machine it has you select the device and then it lists all of that device's custom commands so you don't actually have to know the commands.
I'm glad you started this conversation because you reminded me that sending a random command before the chime reduces the duplicate beep problem so they might be able to improve the reliability of the built-in driver.
1 Like
Well I am glad there was something good that came from it. That is good news. Yes I need to quit trying to do the same thing in HE that I do in HS. Thanks again for all the explanations and patience.
BTW, I haven't been able to try using custom commands. I think I will go check out what you are referring to.
1 Like
What program are you using to set the parameters... I do not recognize the interface in the image and have yet to discover how to make the Dome device ring differently for different doors in HE -- works fine for a single chime. I will continue to read this topic and others for clues. Thanks.
This is actually a LOT easier than that. Just create an "Action" within RM. Call that action the specific chime noise. Then all you have to do is call that action from another rule to get the tone. Within that action, just select the send a message, enter the number of the tone you want to produce, select the speech device of the siren and boom...done.
Oh, I’m gonna try that with my CoolCam Neo, version of Dome Siren.
Thx
Wow, thanks for that tip. I didn't know you could just create an action. Hmmm, my imagination is in overdrive now 
1 Like
