AlarmDecoder reports non-existent restore/fault events

[dssinger]

This issue and the fix are discussed at https://www.alarmdecoder.com/forums/viewtopic.php?f=3&t=1173

I think it's also related to issue #46

[WilsonBradley]

I had this happen while out. Police came to the house for false alarm.

[warthog618]

I've seen spurious restore/fault events on my Vista 20SE, and so far have identified two separate cases that trigger it.

Here a message not starting with FAULT or ALARM trips up the sequence based zone tracking, resulting in a spurious restore on zone 6 (note that the zone events are logged before the corresponding message that triggered them):

2021-06-15 15:53:43 DEBUG handle_message [00010001000000000A--],005,[f70000008005000008000000000000],"FAULT 05 SLIDINGDOOR "
2021-06-15 15:53:47 DEBUG handle_message [00010001000000000A--],006,[f70000008006000008000000000000],"FAULT 06 BACK DOOR "
2021-06-15 15:53:51 DEBUG handle_message [00010001000000000A--],001,[f70000008001000008000000000000],"FAULT 01 FRONT DOOR "
2021-06-15 15:53:55 DEBUG handle_message [00010001000000000A--],005,[f70000008005000008000000000000],"FAULT 05 SLIDINGDOOR "
2021-06-15 15:54:01 DEBUG handle_message [00010001000000003A--],006,[f70000008006000c08000000000000],"DISARMED-Press * to show faults"
2021-06-15 15:54:04 DEBUG zone_restore_callback for zone 6
2021-06-15 15:54:04 DEBUG handle_message [00010001000000000A--],001,[f70000008001000008000000000000],"FAULT 01 FRONT DOOR "
2021-06-15 15:54:07 DEBUG handle_message [00010001000000000A--],005,[f70000008005000008000000000000],"FAULT 05 SLIDINGDOOR "
2021-06-15 15:54:11 DEBUG zone_fault_callback for zone 6
2021-06-15 15:54:11 DEBUG handle_message [00010001000000000A--],006,[f70000008006000008000000000000],"FAULT 06 BACK DOOR "

This could be solved by adding "DISARMED-Press * to show faults" to the list of messages included in the sequence check.

But the other case is similar to the one described by the OP - a motion detector triggered repeatedly can result in a stream of messages that will also trip the sequence based zonetracking. This set of messages is using a zonetracking.py with the _clear_zone() call commented out to disable the sequence based check:

2021-06-16 16:16:47 DEBUG handle_message [00010001000000000A--],005,[f70000008005000008000000000000],"FAULT 05 SLIDINGDOOR "
2021-06-16 16:16:50 DEBUG zone_fault_callback 3
2021-06-16 16:16:51 DEBUG handle_message [00010001000000000A--],003,[f70000008003000008000000000000],"FAULT 03 FAMILY ROOM "
2021-06-16 16:16:56 DEBUG handle_message [00010001000000000A--],003,[f70000008003000008000000000000],"FAULT 03 FAMILY ROOM "
2021-06-16 16:17:09 DEBUG handle_message [00000001000000003A--],003,[f70000008003000c08000000000000],"DISARMED-Press * to show faults"
2021-06-16 16:17:14 DEBUG handle_message [00010001000000000A--],003,[f70000008003000008000000000000],"FAULT 03 FAMILY ROOM "
2021-06-16 16:17:17 DEBUG handle_message [00010001000000000A--],003,[f70000008003000008000000000000],"FAULT 03 FAMILY ROOM "

With the _clear_zones() call in place the repeated zone 3 faults result in zone 5 being restored incorrectly.

So in my setup I've disabled the sequence checking provided by _clear_zones(), and rely on zones being restored by either message.ready or aging them out if they don't appear in the messages for EXPIRE - though I have increased that from 30.

On a related point, the restoration based on message.ready is buggy as it iterates over a list it is deleting from:

           if message.ready and not message.text.startswith("SYSTEM"):
                for zone in self._zones_faulted:
                    self._update_zone(zone, Zone.CLEAR)

which results in only half the faulted zones being cleared.
A simple fix is to iterate over a copy of the list:

            if message.ready and not message.text.startswith("SYSTEM"):
                for zone in self._zones_faulted[:]:
                    self._update_zone(zone, Zone.CLEAR)