wireless zone extender spam, delay and a bug

[alarmjoe]

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

ok - 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?

that is correct, that's exactly what happened.

i don't know what frequency band these wireless transmitters use (they are quite old) but i just noticed a slew of restore/fault notifications when i turned the microwave on. so the missing fault messages might just be the name of the game with old wireless transmitter hardware and a large-ish house, and small amounts of EMI probably disrupt them. heck i think even walking thru the house caused some of the faults to go missing.

so the RFX messages are the raw messages coming from the wireless transmitters, but the panel is translating those to zones and fault messages for the keypad? i assume you're going off the keypad messages for the zone tracking? maybe it makes sense to wait for multiple cycles of fault messages before setting the zone state to restored... i haven't read the code so not sure what it's currently doing...

[quote]
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.
[quote]

Code: Select all

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


the first two messages were from the same transmitter, the 3rd message was from a different transmitter.

i have no idea what the mapping is between transmitter IDs and zones. i had that information and one time when the company came out to service the panel they stole my documentation. i suppose if i open all the transmitters the serial numbers might be printed inside?

no zones are faulting and restoring at least by any human interaction. the windows are just open...

thanks for all your help with this.

[alarmjoe]

actually - i remembered that i managed to claw the documentation back from them after i realized they had taken it. i have a list of zones + stickers from the transmitters with IDs. since this list was generated i think one sensor was replaced, but it's not one of the windows that is open.

interestingly most of the RF messages i am seeing are not on my list of sensors. i think those RFX messages may have come from someone else's system (if i understand it right all receivers in range of all transmitters receive transmitter messages.) in watching for about 5 minutes i only saw one message from a transmitter i could identify, and it's not one of the windows that is open. the status it returned happened to be 0x84 but not sure of the model number of my transmitters so not sure what it means.

[mathewss]

Correct you can see all RFX messages from anyone within range. Also yes I show the 5800 message and its details that are sent to the panel but it may ignore the messages or not depending on programming.

This could have been a rapid state change but if it was I would expect the arguments on the RFX message to indicate a loop open/close happens. This just shows a supervision bit set and AFAIK that should not cause the panel to reset its zone list as it clearly has done.

Looking more and more like a bug in the panel but also IMHO a bug that I may be able to work around with a change in my algorithm. Still braining on this part The code was looking for the next zone in the list in numerical order in this case 32. When it got 20 again it assumed 32 and 33 were restored.

Best
SM

[alarmjoe]

OK thanks. just now i saw this in the log:

Code: Select all


[00000001000000000A--],032,[f70000008032c00008000000000000],"FAULT 32 ZONE 32                "
[00000001000000000A--],033,[f70000008033c00008000000000000],"FAULT 33 ZONE 33                "
[00000001000000000A--],020,[f70000008020c00008000000000000],"FAULT 20 ZONE 20                "
[00000001000000000A--],021,[f70000008021c00008000000000000],"FAULT 21 ZONE 21                "
[00000001000000000A--],032,[f70000008032c00008000000000000],"FAULT 32 ZONE 32                "
[00000001000000000A--],020,[f70000008020c00008000000000000],"FAULT 20 ZONE 20                "
[00000001000000000A--],021,[f70000008021c00008000000000000],"FAULT 21 ZONE 21                "
[00000001000000000A--],032,[f70000008032c00008000000000000],"FAULT 32 ZONE 32                "
[00000001000000000A--],033,[f70000008033c00008000000000000],"FAULT 33 ZONE 33                "
[00000001000000000A--],020,[f70000008020c00008000000000000],"FAULT 20 ZONE 20                "



so without any martian RFX messages the panel just skipped 33 there after the 5th message. this panel is 20+ years old now and it seems to be an rebranded vista20se. i would not be surprised if there were bugs in the firmware.

there's just no way these zones are restoring, the windows are wide open. and for sure those RFX message in the original snippet are not my transmitters. the serial numbers are all way too high, and they are not on my list.

for now the notification suppression is taking care of the spam.

what i don't understand about all this is that it seems that actual messages from the transmitters are few and far between - either when some event occurs or i suppose they just report status every once in a while. i had assumed that the panel messages were all triggered by status messages from the transmitters but that doesn't seem to be the case, hence the theory of the microwave disrupting the messages doesn't make sense. but what is true is that the panel box is currently open with the RPI hanging out of it so the panel has lost its faraday cage. maybe the panel itself is just susceptible to RF and when i seal it all up again this flakiness will go away.

[mathewss]

Interesting I saw that. What is zone 33? That is the RF zone range for that panel as I recall. But if it went POOF for a cycle and we saw no RFX messages then it is a panel issue. Somehow it decides to just skip a panel in the fault list seems likely to be a panel firmware issue Swapping out the 20SE for 20P as long as you have everything well documented and an alpha keypad or AD2* for programming it is only a few hours of fun

Best
SM

[alarmjoe]

actually it might be a rebranded 20P, not sure. it's not in your list of images...

zones 18-36 are all on a wireless expander. i am apparently only seeing this issue on wireless transmitters. i don't think i've ever seen it skip or otherwise mangle one of the wired contacts (of which all 17 are used.)

maybe this is normal but the wireless expander, a cellular backup, two keypads and now the AD2PI are all connected to the serial bus on the panel. i don't know a lot about this kind of hardware but i wonder how they all talk to one another without stepping on each other. maybe there's just too many things connected and some messages are occasionally being corrupted?

[alarmjoe]

one thing i've noticed is that if i watch the keypads, i see the same kind of resetting of the list of faulted zones. the sequence seems to get interrupted by 17, which is a motion detector. after 17 displays then it resumes the list of faulted zones starting at the lowest number again. for some reason i never see 17 in the A2DP console output. so maybe this "invisible" zone is the cause of the problem. are motion detectors special? or do they just look like any other switch?

also i am seeing the "DEBUG in types: Event: Zone <unnamed> (-32) has been restored." message in the API log again but nothing in the serial console seems messed up. seems like something's getting corrupted in the zone tracking code. i'll try to cross-corollate the -32 zone with A2DP console log.

ah - it just happened... strangely i see an expander message in the A2DP log which seems to correlate with both the (-32) API message and activation of the motion detector. !EXP:01,08,01 and !EXP:01,08,00. this may not be the only cause of the faulted zone list reset, but it does seem to be one of them.