Even though it's old, there could be a parameter in there that could do the trick.
Endless hours of amusement.
Unlike this device, I like the fact that I can record my own chimes on my Ecolink. I use a synthesized voice. It also has loud siren sounds I use for my smoke/co detectors. It also has a built in battery in case the power goes out, so with the hub on a usb, I can get chime/siren notifications from the battery operated devices, eg, z-wave smoke alarm in garage, leak, temp, etc.
Uhg those debug logs are terrible, going to have to decipher them.
Was there anything else before that? Some normal logs? Or anything saying anything about supervision or retries?
That's everything based on the time when the event occurred.
Ok that second one looks a little more useful. I will have to look at it more in depth to fully understand it.
If you want a quick solution, switching over to something like the Eco Link chime would be faster. It might take a bit of back and forth to get a basic driver figured out for this thing especially since I do not have one. I have thought about getting a chime though...
@bcopeland Any insight as to what is going on based on the debug logs above? Since I assume you made the driver you might be able to understand it a little better.
Check out that 2019 spec I linked to.
It has parameters for stuff like how often a tone should be repeated, etc.
I'd say, compare parameters with the old one, since you know it works with the new driver.
Check out, compare firmware versions, maybe update if adventurous.
Perhaps switch driver to "device" and do a printout of all the parameters for both devices and post them here?
How about reset to factory specs, not just exclude/include? Or, did you do that already?
Maybe someone returned it to Amazon after they messed with it?
Interesting, did not know it had those options. Could be onto something there.
If it supports the config command class v3 or v4 my Z-wave scanner should be able to pull in all the settings for easier adjustment.
I've tried to make heads or tails out of the Aeotec documentation for my Home Energy Monitor and Heavy Duty Switch, but mostly failed. You've got the skilz though! 
Ok, I appear to have fixed this. My old Aeotec Indoor Siren 6 I did not include to my network with S2 encryption and so I did not enable S2 on this replacement. I factory reset the device and included it without S2. Results: The same repeated chimes. Then, I factory reset the device again and this time enabled S2. The result is that now there are no repeated chimes and it appears to be working. For the 14+ hours I worked on this issue, I still can't explain why it works now. Hopefully this will help someone else. Oh and I did a device swap to preserve my old settings and the restore worked and still no crazy 3x-5x chimes randomly occurring. I'll call this a win, but I really don't understand why. Inconsistent results in this type of situation are not helpful when trying to help others. Let me chalk this solution up to stand on one foot and whistle...
2 Likes
A theory... if the driver has supervised packets built in, possibly when the device was not paired with security it was not acking the supervision requests (since this is a feature normally only used with S2), but still processing the data sent, and playing the chime. This in turn could cause the driver to assume the device did not get the message and send it again multiple times until it gives up.
Once paired with S2 the device is now responding back saying it got the message, so the driver is happy and does not retry.
Without knowing exactly how the driver is coded this is just a theory but the only explanation I can think of.
2 Likes
Time you'll never get back.
This could make sense. The reason is that I pointed out the same, but older driver was not running the "new" device driver variant and worked fine. When I paired the new device and deleted the "old" one the only variant was the "new and improved" variant. It's always been my experience that newer drivers have their own code. Is it possible that a built-in driver was deprecated from the Hubitat firmware, but continued to be a part of that legacy device until the device was deleted? If this sounds "viable" their might be a use case for deprecated drivers to be migrated to "user" drivers when they are removed from the built-in list. Does anything I have said sound viable?
Yes that is usually hoe they do it. The driver is still in the firmware but hidden from the drop down menu.
It certainly could be done, but they dont publish any of the drivers except for a few basic examples they have provided as part of developer documentation.
1 Like
It might be that I identified a use case for such. To me, one of the key reasons to be a Hubitat user is for local control. That means more than running less in the cloud. It also means having control over the versions of software you are running. If a firmware can deprecate a device driver and the end-user simply replaces a device, he has the reasonable expectation that a new device of the same model number will be running the same device driver. My use case showed that an apparent "new upgrade" resulted in a very different user experience that flies in the face of configuration control.
The old driver was called "Aeotec Doorbell 6" and is still in the list
1 Like
No it is not. The Aeotec Doorbell 6 is another hardware device that is a "chime" only. The Aeotec indoor siren has BOTH a SIREN and a CHIME function. Different drivers and different devices.
