0 or -1- either way 
1 Like
Setting zonedump_interval: 0 was exactly what I needed to stop the “zone flapping” that was occurring with my EVL 4 + DSC PC1616 setup. Before this, I did not specify the parameter because it was documented as optional for DSC systems.
When I would trigger a zone, the open/close updates were instant in HA, since they are sent from the EVL. Perfect! But a moment later, the zone would re-open, stay open for some time, and then close again. This lined up with default polling timing in the logs.
After setting the interval as described, zone updates are instant with no false positives. (Thank you for this fantastic component!)
Great!! Glad it’s working for you!
Interesting. I think this may explain the behavior I’ve been seeing with my HA setup communicating with my Envisalink+DSC1864 as well. I have a DSC wireless sensor on our kitchen pantry door (hey, they’re cheap and reliable). I also have LED strip lights in the pantry plugged into a sonoff switch. Automations in HA toggle the LED strip lights on/off when I open/close the pantry door. Works great, except every once in a while I notice the lights come back on with the door closed. Eventually they go off again so it’s not a huge deal. I’m going to try setting zonedump_interval to 0 to see if that fixes it.
For those folks using envislink to talk to a DSC panel set zonedump_interval to zero. That will disable that command. The plugin does not handle the response from the panel correctly - and causes
zones that are open to show closed. When the plugin is restarted - and opens a new session to
the envislink board - it will issue a command (001) that tells envislink to send a status of all zones.
That command is only issued when the TCP session first starts - but that will sync your panel to HA correctly. After that zones opening or closing will updates correctly and in real time…
@Cinntax curious your thoughts on frequency of polling zonedump on a Honeywell panel? The default of 30 is far from real time but is there a reason for it? If I want to get close to real time zone reporting on the Honeywell 20P panel is there any hardware reason it would be a bad idea to reduce the time delay to 10, 5, or even 1 second?
I asked their support department the same question and they told me i shouldn’t poll the zone dump timer directly and that the Honeywell panels should report all zone changes asynchronously which seems to disagree with almost all information I’ve found on the internet.
The honewel/ademco panels do report zone FAULTS in realtime (if disarmed), but not closings, which is why the zone dump timer is important.
I use a 5s zone dump interval and have found that gives the best results, the reason the default is 30 is because the hardware has to get this from the panel, and older panels may (possibly) choke, a newer 20p is fine at 5s. Remember, a zone dump requires the panel to actually do something, if you poll too frequently you might get improper keypad behavior if the panel is busy. I am not sure exactly how much work the panel needs to do, but a 20p is not a high end microcontroller. It also requires the evl to do work, and I have no idea what the load burden is, especially with many zones.
The zone dump uses an internal zone closure tick of 5s, so anything lower than 5s will probably not give you a better response time, and the panel will tick down a few even when it is open, then reset back to 0… apparently, which is why there needs to be a delay of up to 30s for the library to determine the panel has actually closed the zone. This could probably be reduced to anything under 20s, or perhaps less, I do not know if there is varying behavior between panels about how may ticks past 0 can be reported for an open zone.
I am testing fast zone close code in my integration, but it requires all the zones to be referenced to their partition, and only works when a single zone is opened then closes within that 30s check interval, since it looks for the partition to be "ready’ and forces any zone in the partition to report closed. I have also found the alarm.com communicator must have zone kind of fast close detection, because it also reports within about 2s.
Hey Brian-
It’s been a little while since I’ve looked at this, but if memory serves me correctly, the 20P will immediately report if a zone opens, or if a partition faults. So the most important aspect of detecting a possible security violation is asynchronous- however it does not asynchronously report zone closure again (if I remember correctly). So the zone dump was in attempt to detect more accurately both the open and the closure of a given zone. The other aspect about the timer dumps is that i do think they’re more of an estimate- so I would agree that they shouldn’t be used instead of the asynchronous event- however we’re using it for supplementary information.
I don’t remember any hard reason why we defaulted to 30 seconds- so if you want refreshes more often, I don’t see that being an issue (not that I’ve tested it in a long time though).
I think there is confusion as to how how the honeywell keypad emulation works. The panel is not polled per say, it is simply monitored continuously. What happens is that the panel will keep sending fault statuses for each zone, troubles, etc in sequence. The keypad uses those statuses to light up leds and display the messages. The absence of such statuses is what determines when a zone is closed. What needs to happen is to set a “time to live” where if a fault status is not seen within the TTL, it will be marked as closed. If you set your TTL too short, you will be getting continuous open/closed statuses. If you set it too long, that will give you less responsiveness in seeing the closed status. it’s a balance that needs to be met. If you do not have many open zones normally , then you can set the timer to a shorter value.
There is an exception though. What I said above applies directly to the 8 built in zones of the panel. For any zones provided by extender boards such as an RF or 4229 wired extender (zones 9+) , the open/closed statuses can be gotten by monitoring the bus comminucations from those devices directly and with those you will get instant notice of open/close status. I don’t know if the Envisalink monitors those.
With the DSC panel, it’s different, the panel will actually send open/closed statuses of all zones so you can set a shorter TTL.
I dont’ know exactly what mechanism Envisalink uses, but it has to work within the constraints of the panels communications.
In speaking of Honeywell panel internal zones, there is a trick that can be used if you have relay extenders (physical or virtual), you can program zone shadowing on the built in zones. IE, you program your relay outputs to follow the zone status. This way you can monitor the relay outputs data to determine if a zone is faulted/closed even when alarmed/bypassed. I have no idea if this is supported with the Envisalink.