wireless zone extender spam, delay and a bug

[alarmjoe]

Hi -

just installed the RPI hat with an RPI3b+ and the prebuilt image, which i then updated with apt and also updated the alarm decoder stuff thru the web gui. i'm on the stable branch, not dev.

i have a SE panel with a wireless zone extender. i noticed that when any window with a wireless contact switch is open, eventually the logs start showing that the zone has been restored and faulted. this happens seemingly at random, though opening another window seems to trigger a storm of these events. i guess my first question is, is this expected behavior? there seems to have been a recent commit regarding a similar problem but if it was intended to address this issue i guess it didn't fully fix the problem.

i noticed the zone delay and "suppress zone tracker restore" settings in the notification i created, which seems to me like it might be intended to handle this case (and thus it is expected behavior.) unfortunately setting a zone delay other than 0 stops all notifications from occurring and looking at the logs the code in ad2web/notifications/type.pl is unhappy with the delay variable reference in the call to time.mktime. i believe datetime.timedelta(minutes=delay) is a typo and should read (minutes=n.delay). i have made this change in my local copy and it does work - it suppresses most of the spurious notifications from the wireless sensors, though with the cost of a 1 minute delay on the first message. the fact that this code was broken makes me think that the zone spam is unintended.

another anomaly is that i see in the logs messages like this:

Apr 14 21:03:39 AlarmDecoder gunicorn[541]: [2021-04-14 21:03:39,679] DEBUG in types: Event: Zone <unnamed> (-32) has been faulted.
Apr 14 21:03:41 AlarmDecoder gunicorn[541]: [2021-04-14 21:03:41,196] DEBUG in types: Event: Zone <unnamed> (-32) has been restored.

which seems to me there is some problem with parsing the raw messages coming from the panel.

please let me know if there are any particular logs or config files that you might need to see if you have time to look into this issue.

thanks

[mathewss]

Please send a capture of raw messages from the alarmdecoder device over a few minute period with zones opening etc.

Sounds like a system fault or something is breaking the zone tracker. Also send firmware version or be sure you are on the latest 2.2a.8.9. this has some fixes and better debugging if needed.


Best
Sean M.

[alarmjoe]

thanks, do you have a pointer to instructions on how to see the raw serial data? can i just cat /dev/tty<whatever> even while the python packages are running?

as for firmware i am on 2.2a.8.8, which looks like the latest stable. in the list of firmware in the web gui, i see 2.2a.8.9b-306 under betas. is this the version you are referring to?

thanks

[mathewss]

thanks, do you have a pointer to instructions on how to see the raw serial data? can i just cat /dev/tty<whatever> even while the python packages are running?

as for firmware i am on 2.2a.8.8, which looks like the latest stable. in the list of firmware in the web gui, i see 2.2a.8.9b-306 under betas. is this the version you are referring to?

thanks

Ok thanks for firmware info. That is good.
If you setup HA you probably have ser2sock running so try using putty to connect to the IP address of your Pi on port 10000. It should connect and start spitting out raw messages.

Best
SM

[alarmjoe]

ok thanks. but still unclear, should i upgrade to 2.2a.8.9b-306?

i rebooted the pi and the problem stopped happening. i'm guessing that given the bogus zone numbers seen in the gunicorn log, something must have gone wrong with the serial port. with ser2sock running, now i can at least monitor what the python code is seeing to see if it goes south eventually. i guess just using cat to monitor the serial device consumes the data and doesn't let the python code see any alarm traffic, but ser2sock obviously works right.

i suppose there could just be plain old corruption on the serial port. while i'm testing, i'm using short wires which are not twisted pairs between the panel and the pi.

[alarmjoe]

actually - it started happening again. maybe this is what's causing the problem:

i am not sure what should be redacted from these messages, let me know if you need to see all the hexadecimal stuff...

Code: Select all

[redacted--],020,[],"FAULT 20 ZONE 20                "
[redacted--],021,[],"FAULT 21 ZONE 21                "
[redacted--],032,[],"FAULT 32 ZONE 32                "
[redacted--],033,[],"FAULT 33 ZONE 33                "
[redacted--],020,[],"FAULT 20 ZONE 20                "
!RFX:redacted,04
[redacted--],021,[],"FAULT 21 ZONE 21                "
[redacted--],020,[],"FAULT 20 ZONE 20                "
!RFX:redacted,04
!RFX:redacted,04
[redacted--],021,[],"FAULT 21 ZONE 21                "
[redacted--],032,[],"FAULT 32 ZONE 32                "
[redacted--],033,[],"FAULT 33 ZONE 33                "



i can see why this might look to the zone tracker code that 32 and 33 had been restored. it's like those RFX messages upset the cadence of the fault messages.

anyway is this bad behavior on the part of my panel or something else??

thanks

[mathewss]

ok thanks. but still unclear, should i upgrade to 2.2a.8.9b-306?

i rebooted the pi and the problem stopped happening. i'm guessing that given the bogus zone numbers seen in the gunicorn log, something must have gone wrong with the serial port. with ser2sock running, now i can at least monitor what the python code is seeing to see if it goes south eventually. i guess just using cat to monitor the serial device consumes the data and doesn't let the python code see any alarm traffic, but ser2sock obviously works right.

i suppose there could just be plain old corruption on the serial port. while i'm testing, i'm using short wires which are not twisted pairs between the panel and the pi.

I would agree the logs did seem to indicate some odd data from the AD2. Ya only one process can access serial data on Linux so using cat on the port would result in driving ser2sock into loosing data. It would be as if any bytes seen by "cat" would not be seen by any ser2sock clients including the webapp itself as it in most common configurations uses ser2sock.

https://www.alarmdecoder.com/wiki/index ... ot-dia.png

[mathewss]

actually - it started happening again. maybe this is what's causing the problem:

i am not sure what should be redacted from these messages, let me know if you need to see all the hexadecimal stuff...

Code: Select all

[redacted--],020,[],"FAULT 20 ZONE 20                "
[redacted--],021,[],"FAULT 21 ZONE 21                "
[redacted--],032,[],"FAULT 32 ZONE 32                "
[redacted--],033,[],"FAULT 33 ZONE 33                "
[redacted--],020,[],"FAULT 20 ZONE 20                "
!RFX:redacted,04
[redacted--],021,[],"FAULT 21 ZONE 21                "
[redacted--],020,[],"FAULT 20 ZONE 20                "
!RFX:redacted,04
!RFX:redacted,04
[redacted--],021,[],"FAULT 21 ZONE 21                "
[redacted--],032,[],"FAULT 32 ZONE 32                "
[redacted--],033,[],"FAULT 33 ZONE 33                "



i can see why this might look to the zone tracker code that 32 and 33 had been restored. it's like those RFX messages upset the cadence of the fault messages.

anyway is this bad behavior on the part of my panel or something else??

thanks

This is interesting. I wonder if that case is not being processed correctly in the algorithm in the Python API.
I bet it saw it as zones 32 and 33 restoring and then faulting again correct?

[mathewss]

FYI and others probably the only data that could be classified as sensitive would be RFX serial numbers as redacted in this post. Also redacted was section #1 data in a standard message. This is just alarm state and has no signature component to protect.

Best
SM

[mathewss]

Please let me know what the RFX messages are here.

!RFX:redacted,04
[redacted--],021,[],"FAULT 21 ZONE 21 "
[redacted--],020,[],"FAULT 20 ZONE 20 "
!RFX:redacted,04
!RFX:redacted,04

It reset back to 20 when it received the first RFX message here. I am going to assume that a zone faulted and restarted very fast here. What zone is tied to this RFX message? Are these all the same serial number on these 2 messages? Maybe remove redact and put in a UID of some sort.

Best
SM