I just finished playing with this device and I see that the Alarm Duration Time is overriding the Chime Repeat setting. You should be able to choose No Selection for the Alarm Sound and Beep Sound should be labeled Chime Sound. The driver is not correct for the parameters it has in the manual. Perhaps HE can look into this driver and correct it.
When you select No Selection in the siren part and Save Preferences it just goes back to the defaults. It should not do that.
Interesting that even with driver modifications (way beyond my newbie level) that it still chimes extra. Custom mp3s for door chimes would be fun... Maybe eventually I'll go beyond the surface of what Hubitat can do off the shelf...
Here is an example of what is in HS. It shows the parameters and how they are set up. This can be done also in the HE driver the same way. I assume.
P1 is the Primary (siren) volume level
P2 is the Primary (siren) on time duration
P3 is to how many times you want it to play the Secondary (chime) sound
P4 is for the Secondary (chime) volume level
P5 is which Primary (siren) sound you want to hear
P6 is which Secondary (chime) sound you want to hear
P7 is which one you want to hear, the Primary or Secondary sound, when it is given the On Command
Here is a pic. I hope I am not offending anyone by showing this pic.
1 Like
Interesting. There is a dome siren driver for HE that I was playing with. It allowed me to look at this stuff. I just eventually got fed up with it and moved on. I still have it set as a siren though.
The strange part is that if P3 was set to something greater than 1 I would figure it would happen all the time. In my case it would only happen randomly through the day, and only on my back doors. For some reason it never happened on my garage door.
If I ever jump back into it, I'll come back to this post to look at.
I also wanted to add that in the Parameters there are these settings to use. 1 byte.
(P1) vol low =1, vol med=2, vol high=3 (Primary)
(P2) 30 sec=1, 1 min=2, 5 min=3
(P3) 1~14
(P4) vol low=1, vol med=2, vol high=3 (Secondary)
(P5) 8~12 are the sirens
(P6) 1~7 are the chimes
(P7) 1=siren, 2=chime
There's nothing wrong with the driver...
The device has the ability to either play the chime or siren when activated as a switch which is why there are separate config params for default chime and default siren and there's also a config param that allows you to choose which is primary, but those features are only necessary for platforms that can't handle that logic.
The Hubitat driver keeps siren as primary and uses indicator set to play the chime sounds which is why the option for which is primary and the default chime sound settings aren't shown.
The Beep Sound setting is the sound that gets played when you use the beep command of the Tone capability.
"No Selection" in a Hubitat setting field means that nothing is selected and it uses the default value. This is how every drop down setting field works in every driver...
The repeat problem is caused by the device taking longer than normal to acknowledge the first z-wave command sent to it after a period of inactivity. When the hub doesn't receive a response it resends the command multiple times and the device should only execute the command it finally acknowledges, but it sometimes ends up executing more than one which is why it sometimes plays multiple times.
This is a known issue that Dome has confirmed and at some point they're supposed to be releasing a new version that fixes it.
3 Likes
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
