"after alarm" event is not captured by handler

[KraskoVladimir]

Alarm system

EVO192, IP150

Environment

Linux (CentOS 7), python 3.8.10

Question

Hi folks, thank you for a great project! In
https://github.com/ParadoxAlarmInterface/pai/blob/dev/paradox/paradox.py
there are handle_event_message and _on_property_change methods, among others. In handle_event_message we are capturing arm and disarm events and processing them. Everything works fine, except this case: if we have arming time (30 seconds) and we don't interrupt that, the system will be armed and alarm will be triggered. After that, if we try to disarm the system, it will be successful, but without new entry in handle_event_message (no new LiveEvent created). If we check in babyware, there is "Disarmed After alarm with software" event recorded, but no "after alarm" content in handle_event_message. On the other hand, _on_property_change handler recorded that change, so ChangeEvent is created successfully. Until now, we were only once able to catch that event with the mentioned handler, and 4-5 times it wasn't the case. In evo/event.py, that is event with eventGroup 22 and subgroup 3. Why "after alarm" event does't enter into handle_event_message handler?

[yozik04]

@KraskoVladimir If you do not see "Error creating event" in debug logging level then panel might not send the event. Is System Options -> Communication -> “Transmit zone status on serial port” enabled on the panel?

[KraskoVladimir]

@yozik04 There is no "Error creating event" in log.

“Transmit zone status on serial port” - we couldn't find that option in Babyware before, today we've found it and it's been checked. After that we've tested again, I've sent arm command 4 times via mqtt (2 times payload was plain "arm", 2 times "arm stay"); after each time I disarmed the system (payload was "disarm"). Success is 25%, i.e. only once we were able to catch that "after alarm" event with handler. All 4 times we had "partial arming" (some zones were affected). After each disarm, we had to wait ~10 seconds for all zones to be restored.

[KraskoVladimir]

Also, we are using IP connection method, not Serial, so I don't know how relevant “Transmit zone status on serial port” is.

[yozik04]

It is relevant because IP150 transmits all that is on the serial.

Currently I have not idea what is wrong. I recommend you capture debug logs of the both behaviours and compare. PAI receives and decodes everything that IP150 sends to it, nothing is skipped.

[KraskoVladimir]

after digging deeper into the logs, I found the following situation: after sending the arm/arm_stay command and letting the system count down for 30 seconds, each time I came across these records in the logs: "Partition XYZ triggered alarm", "Partition XYZ has alarm in memory", "Partition XYZ was in alarm", "Partition XYZ alarm is audible". Then, after pressing the Disarm button there are 2 scenarios: when the Disarm live event appears and when it doesn't. When it does not appear, I found these entries in the logs: "Partition XYZ alarm is silent", "Partition XYZ was not in alarm", "Partition XYZ away arm inactive". If these 2 events do not appear ("Partition XYZ alarm is silent" and "Partition XYZ was not in alarm"), then the Disarm live event appears.

Regardless of whether the Live Disarm event occurs or not, the Change event: "Partition XYZ is disarmed" always occurs.

Also, if we look at the history-buffer, the event "Disarmed after alarm" can be seen there every time.

At the moment it is not clear to me why the events "Partition XYZ alarm is silent" and "Partition XYZ was not in alarm" sometimes appear after disarming, that is something I want to investigate next.

[yozik04]

Interesting. But does not ring the bell yet. :)