Zone faulting and restoring when held open

[drewsonian]

I have a Vista-128 and when we have a door held open for more than a few seconds, we get logs in alarmdecoder every few seconds saying that the zone was faulted and then restored. Is this normal operation or do I perhaps have this configured wrong? It's causing SmartThings to act as if it opens and closes every few seconds as well, so alerts get repeated every few seconds while the door is open. The zones are 5800 wireless, so should I consider using the RFX features in the alarmdecoder service instead?

Edit: changed "unfaulting" to "restoring"

[mathewss]

Sounds like zone tracking is getting confused. Could you post some of your LIVE log from your panel while you open, hold open, close the zone. What are you using for software to talk to the AD2*

if you are using 5800 sensors please confirm your firmware version. I did find a RFX message bug and the fix is in 2.2a.8.9

Best
Sean M.

[drewsonian]

I am on firmware V2.2a.8.9b-305, because I thought maybe going to a beta release might help. I am just using the web interface for AD2PI and SmartThings to listen for notifications.

I think maybe the panel is configured incorrectly, I just noticed that these zones are not doors held open, they are constantly faulted and the door is closed. But here are the live logs anyways.

Timestamp Message
2019-07-25 13:09:39 [00000001000000003A--],032,[f70100040032000c08020000000000],"****DISARMED**** ZONES FAULTED "
2019-07-25 13:09:32 [00000001000000000A--],018,[f70100040018000008020000000000],"FAULT 018 ZN 018 "
2019-07-25 13:09:32 [00000001000000000A--],032,[f70100040032000008020000000000],"FAULT 032 ZN 032 "
2019-07-25 13:09:25 [00000001000000000A--],016,[f70100040016000008020000000000],"FAULT 016 ZN 016 "
2019-07-25 13:09:18 [00000001000000000A--],014,[f70100040014000008020000000000],"FAULT 014 ZN 014 "
2019-07-25 13:09:04 [00000001000000003A--],032,[f70100040032000c08020000000000],"****DISARMED**** ZONES FAULTED "
2019-07-25 13:08:57 [00000001000000000A--],032,[f70100040032000008020000000000],"FAULT 032 ZN 032 "
2019-07-25 13:08:50 [00000001000000000A--],016,[f70100040016000008020000000000],"FAULT 016 ZN 016 "
2019-07-25 13:08:50 [00000001000000000A--],018,[f70100040018000008020000000000],"FAULT 018 ZN 018 "
2019-07-25 13:08:43 [00000001000000000A--],014,[f70100040014000008020000000000],"FAULT 014 ZN 014 "
2019-07-25 13:08:36 [00000001000000003A--],032,[f70100040032000c08020000000000],"****DISARMED**** ZONES FAULTED "
2019-07-25 13:08:21 [00000001000000000A--],018,[f70100040018000008020000000000],"FAULT 018 ZN 018 "
2019-07-25 13:08:21 [00000001000000000A--],032,[f70100040032000008020000000000],"FAULT 032 ZN 032 "
2019-07-25 13:08:14 [00000001000000000A--],016,[f70100040016000008020000000000],"FAULT 016 ZN 016 "
2019-07-25 13:08:07 [00000001000000000A--],014,[f70100040014000008020000000000],"FAULT 014 ZN 014 "

[mathewss]

Well Yuk! That is a mess. The order the messages are returned in your dump are not what I would expect. I will want more info on the panel firmware at some point. So let me be sure I understand the test.

I see 4 zones open
18,32,16 and 14

It repeats this but the order keeps changing and that is not normal. You say you are holding a zone open? And the other zones are also open but if you close this zone all seems normal. A dump of that setup would be interesting and I expect no longer out of order.

It is the order that the messages are returned that allows zone tracker to do what it does because as far as I have ever seen the report of faults has a very specific pattern that we can use to detect a zone being restored.

Best
SM

[drewsonian]

This is at a client site that I can't get to right now, but I think I may have a zone misconfigured as I think all of those zone are loop 1 on a 5816, which may not have had their contacts connected yet. I thought it was being held open, but now I suspect this instead. As soon as I can get onsite to verify which devices these are, I'll report back if my suspicions are correct.

[drewsonian]

Well Yuk! That is a mess. The order the messages are returned in your dump are not what I would expect. I will want more info on the panel firmware at some point. So let me be sure I understand the test.

I see 4 zones open
18,32,16 and 14

It repeats this but the order keeps changing and that is not normal. You say you are holding a zone open? And the other zones are also open but if you close this zone all seems normal. A dump of that setup would be interesting and I expect no longer out of order.

It is the order that the messages are returned that allows zone tracker to do what it does because as far as I have ever seen the report of faults has a very specific pattern that we can use to detect a zone being restored.

Best
SM

So I think I figured out what was going on. A few of the 5800 series sensors had yet to be installed. 32 was a 5800MINI which had the magnet taped to it, but then was thrown into a bag with other magnets, so I think it was in a constant state of competition from different magnetic fields 14, 16, 18 were the first loop on a 5816 that had not been connected, and they also were in the bag with other magnets, so they may have been a bit messed up in their signals too :man_shrugging:

Anyways, right now it all looks like it's working right since I got the sensors set up correctly.

However, I do have one question - with the SmartThings integration would it be more "reliable" or "faster" or anything "better" to have it use the RFX messaging vs the zone tracker since we have a lot of wireless sensors? Thanks!

[mathewss]

That makes sense! I was scratching my head on that log

As for RFX vs Zone Tracking I would use my new RFX ST Device constructor.
It will actively capture just that one PUSH event and not wait for the slower reaction time(depending on setup) to Zone Tracking messages.
You could also turn off some events you do not want and just keep RFX and maybe LRR or ARM/DISARM etc to keep the noise on the channel down to a minimum. For even faster times you could use the same ST code on Hubitat and bypass any lag from the cloud with ST. From my experience its not very much lag but if you want it as fast as possible then that is something to consider.

Best
Sean M