Aeotec Siren 6 Chimes at wrong time; java.util Error

I am experiencing some undesirable behavior with the Aeotec Siren 6.
Hopefully, others on this forum who have had similar issues will have
found a work-around or a solution.

I use Aeotec Siren 6 both as a 'door open' chime and as HSM warning
tones and alert siren.

     Siren 6 New;
     hardwareVersion: 164 
     firmwareVersion: 1.06

However, unless I perform a safe hub reboot (from the Hub 'Settings'
page) after each HSM mode change (Disarmed, Armed Night and Armed
Away) the siren will occasionally produce a continuous chime rather
than the single chime defined in the rule below whenever the DoorOpen
rule is triggered:

On my siren 6, chime 30 is a continuous series of chimes. The 'stop
sound' action delayed 1.2 seconds produces a single chime.

The 'ArmDelayChime' rule plays a continuous tone on the siren when
triggered by HSM status 'Delayed Arming ...'.

The 'StopArmDelayChime' rule plays a single tone on the siren to
indicate a new HSM mode is active.

The following error appears in the log after the chime is stopped:
errorjava.util.ConcurrentModificationException: null (supervisionCheck)

The following is my RuleMachine 'Disarm' configuration to change HSM
mode from 'ArmedNight' or 'ArmedAway' to 'Disarmed':

The following is a portion of the log showing the Disarm process.
Note that the StopArmDelayChime rule plays a tone to indicate that the HSM mode
has changed. Also note the Error.

The hub was re-booted after the Disarm mode became active.

It is interesting that Hub re-boots or start-ups are not logged.

A normal DoorOpen log sequence is shown below:

If only single DoorOpen events occur the Error will not show up in
the log. However, the following log shows that the Error returns
during an event when two DoorOpen events occurred and two doors were
open simultaneously. I don't know if two doors open is a cause of the
error or just a coincidence.

Below is a log of what happens after a mode change to 'Disarm' without a hub re-boot:

Hopefully, someone can identify an error in my coding or suggest some
work-around. I really don't like having to re-boot the hub after every
HSM mode change.

I have submitted a support request (#22476) on this topic.

Thanks in advance for reading and commenting on this.

1 Like

Interesting Iā€™m having the same problem , I note the error you have in the logs which I had when I tried to update the siren from different rules.

This error will be fix in the next release according to this thread:

Thank You!

Installed Version 2.2.8.133 and re-booted.
Java error and unprogrammed chime still occurs.

1 Like

Not sure about your unexpected chime as this would have to be coming from an automation.

But the ConcurrentModificationException shouldn't be happening in 2.2.8.. Will check..

It is fixed for me. It used to happen every time and sometimes I hade to issue the stop command 9 times in a row to get it to stop. Now the error does not happen and the siren does not start by itself like before. Thanks @bcopeland , one big frustration gone.

1 Like

Installed V-2.2.8.136.
Unfortunately the ConcurrentModificationException is still present.

In this case the chime resumed sounding after the rule stopped the chime and after the java error. Button 3 is programmed to stop chime/siren sounds.

I'll review my rules.
Thansk @bcopeland for your efforts on this.

1 Like

I've had no errors since installing V 2.2.8.138 .

Thanks, All