However, this integration has revealed an issue in the EV3's state reporting, related to falsely reporting zone closure events. In short, when I have too many zones open at once, most of them appear to "blink" closed every few seconds.
The issue with Honeywell panels and zone closure reporting isn't exactly news, as it's explained in this part of the Envisalink TPI Documentation:
Also, this appears to be basically the same issue as a user is having in another Eyez-On forum thread. Once the number of faulted zones gets to a certain number, the time between reports gets to be too long and the Envisalink guesses that the zones have closed.3.5 Zone Timer/State Limitations
Ademco panels are not very sophisticated compared to other security systems and provide limited zone information to their peripherals. Ademco panels only provide real-time information of when a zone is faulted (opened) but not when it is restored (closed). A further annoying limitation is that the panel does not provide any zone information while the panel is armed.
To provide a more homogenous interface for developers, the Envisalink attempts to infer that a zone has been restored based on a few heuristics. These include the partition state, the length of time since a fault was reported, and the sequence in which faults are recorded.
The TPI developer should understand that if a zone is restored (closed), it may be 60 seconds or more before the Envisalink decides that the zone has been restored. This is unfortunate, but we have very little alternatives. As well, the TPI developer should remember that absolutely no zone information is recorded while the partition is armed.
But the issue in my case is that this is happening with relatively few zones open, and well inside the 60-second timeout window described in the TPI docs. As soon as I have just 3-4 persistently faulted zones (like having several windows open), some of them will "blink"--reporting a quick close/re-open periodically. And the zones that are blinking are doing it on more like a 5-10 second cycle, around the same time as the keypad update loop. When I have many zones faulted it appears that two of them (generally the lowest- and highest-numbered zones) remain steady, while all the others blink.
At first, I thought this was a Home Assistant issue, and worked with the Envisalink plugin's developer to find an answer. But it became evident that the false closure events weren't a Home Assistant bug; rather, they were actually being reported that way by the EV3. I was able to determine this by checking the web interface of the EV3, and refreshing often enough to catch zones that were momentarily being restored.
So, it seems like it's all an artifact of the Honeywell panel and the tricks that the Envisalink has to use to simulate real-time zone closure information. Unfortunately, there's no control given by Eyez-On to adjust that timeout or otherwise influence how the Envisalink "guesses" at a zone closure. This isn't normally a big deal, except for those of us who are using that state information for home automation. In my case, I can't reliably create an action based on, say, a window being open for an hour, because none of my windows are ever open for more than 5 seconds! And the constant barrage of open/close/open events is making garbage of my state history, as well as crating an event log in Home Assistant that gets really big really fast.
Is there a way to change this behavior? Can you control the EV3's timeout period for zone closing? Or would my issue require a workaround by the third-party software...like ignoring quick state toggles?
Thanks in advance for any help the community can provide...
-----------------------------
Here's the information that I think might be pertinent to understanding my issue:
Vista 20P panel with Envisalink 3,
13 wired zones, 7 wireless zones
2 partitions: most in P1, two wireless zones in P2
Blinking behavior occurs with any combination of more than 3-4 zones, regardless of sensor type or partition.