Aeotec Indoor Siren 6 replacement New driver issues

I replaced my Aeotec Indoor Siren 6 when the speaker on my old one appeared "blown". So, the new device works. However, for whatever reason when I paired this Z-Wave device it got added with the driver "Aeotec Siren 6 New". I used the "Swap Apps Device" function to get all of the dashboard, rules, and webcore pistons to honor the new device.

It works great, However, the "chime" function which I use when a door opens is sound "29" which is a ding dong. The thing is that the new device does a ding dong when a door is opened about half the time. The rest of the time it does a ding dong followed by 2-3 traditional doorbell sounds. This is driving me crazy and I have no idea what is causing this.

Does anyone have a handle on this?

Is no one going to comment?

I'll comment, lol.

How about using the driver the other one was using? It looks like there are two Hubitat drivers available:

image

Doing a search, it seems people were bitching about the 'new' driver three years ago.
That's all I got.
I like my Ecolink chime/siren. :slight_smile:
edit: But that can be finicky at times too.

I had my old Aeotec Siren 6 speaker die. I bought a new one because I loved the old device. I have worked with the new one somewhat over 60 hours to no avail. So, when I bought the new device (Note both are Aeotec Siren 6) I used the swap device function to move all my automations.

That worked. However, one of the functions that I have the device do is to sound a simple chime when any of three doors opens. That's always worked great and it still works. The downside is that after my simple chime, about every 3-5th time I use the automation, it sounds the chime and also a "ding dong" anywhere from 3-6 times. I have no such automation that does that. Here's my rule machine rule:

Here's my preferences on the device.

If I mute the chime, the automation won't work If I enable the chime I get multiple sound evens but only every 3rd to 5th time.

I deleted and created the rule from scratch. No improvement.

The old device used to have the "Aeotec Siren 6" driver. When I deleted it, the driver does not show in the list anmore. Now I have the "Aeotec Siren 6 New" driver and I think its the new variant that is driving me insane. I'm about ready to just buy another device. Any suggestions?

I am guessing the new driver implements supervised packets, which if the device does not respond back quick enough the driver might be sending a retry to it.

If you turn on debug logging for the device it might show you the supervised info and attempts.

Also that would help to show if the hub is sending out additional commands or is the device just acting on its own with these additional chimes. You also might have some luck looking in the event log since it will show all the commands triggered on the device and what app called them.


I merged your two separate topics about the same thing together. Makes it much easier if you just keep to one post.

1 Like

I would love to have the old driver back. When I deleted the device, the driver was no where to be found. That's a first. Generally deleting a device doesn't cause the driver list to change. The Aeotec Siren 6 New is the parent device and the Component chime is the child device.

1 Like

It is. How do I turn off these "supervised packets"?

The system drivers don’t have an option to disable the supervision.

Have you confirmed the supervision retries are what is causing the extra chimes?

I could possibly make a custom driver for the device to try and fix the issue.

If you don't mind including the device without S2, that would also likely eliminate the problem if Z-Wave Supervision is the cause (though that's just a guess without more information--check the above first?).

3 Likes

I disabled S2 by re-pairing the device. I still have 3-5 sound events for each door opening. Is there no way to get the original driver back that worked? Is there a better door chime that I could purchase? I'm pretty much done with fighting this one.

After another 10 hours of solid testing, I can't determine what is happening. The log says one chime. The device gives anywhere between one and five chimes. I pair the old device with the bad speaker and it chimes once. Although both devices have the same model number they are somehow different. I have two HSM-200 devices with the same model number that are very different as well. I am just inclined to send it back to Amazon unless you have a better idea. It's hard to rely on automations when you replace a device that is faulty with the same model number and it doesn't act the same.

If the debug logs are only showing the chime being sent ones to the device with no retries or other commands I am inclined to believe either their firmware is defective or you got a defective device.

Did you also check the event log to be sure the chime command was not being called multiple times? This is an example from a light, but each command call will generate a "command" line showing what app called it.

1 Like

So the old device works with the new driver... interesting.

I recall having a less than fabulous time getting my Aeotec switch and monitor up and running. I spent a while looking at the manuals, with all the different configurations and z wave parameters. I don't think there were official drivers.

The good thing is that those parameters are documented, incomprehensible as they might be to a rube like me.

Maybe you could look at the manuals for both devices. See if the parameters for the two devices match, etc, etc, etc. Maybe you'll come across something.

Edit: Those manuals were on the Aeotec website.
Perhaps an internet search. Maybe another platform had a solution. You probably did that already.

By the way, I have searched for the old device driver code with the idea that may be something to try. Any idea where I might find it?

You wont find it, they do not publish the driver code for the public.

1 Like

Opened the Kitchen door once just now. I got FIVE upwards tones.

Here's the logs for the same time.

Here's the rule from Rule Machine.

I know you said it does not always happen but if you could reproduce with debug logging enabled on the device that would be the most useful logs. That would show if it was doing supervision retries. You would have to get it within 30 minutes as the debug logs turn themselves off after that typically.

Otherwise everything you have shown it looks like it should have only gone off once.

I said up above I could try making a custom driver as well but then you said you were giving up so I did not pursue it any further. Would be nice to have confirmation if it was a retry from the driver debug logs causing the issue, before I spend time on it.

1 Like

The log above is where it did occur. Am I missing providing something I have not?

On the device page turn on debug logging, then see if you can get it to happen again with debug turned on.

You've poked around the Aeotec web site?
Maybe firmware update?