Race condition during status update?

[sgruby]

I'm using your component in Home Assistant with a DSC security system and generally it is working well. However, last night I had an issue where closing a door showed up as closed in HA, but then immediately showed up as open and then within maybe 30 seconds went back to closed. This, of course, is problematic as opening the door turns on the light and the open causes it to turn on again after I turned it off.

I believe that there may be a race condition whereby you query for a zone dump, are waiting for a response, get the status change and then when the zone dump comes in, it overwrites the status change. I've changed my zone dump interval to 86400 to reduce this possibility and my testing has not encountered this issue again.

While I'm not sure the logic to handle this (maybe if there is a status update, cancel the zone update and wait for the next zone update), how about adding an option for 0 for the zone dump interval? Looking through the code, I think that passing a 0 to asyncio.sleep for the delay will cause no delay.

Thanks!

[Cinntax]

Hey- yeah i agree that the zone timer dump isn't nearly as important with the DSC panels as it is for the Honeywell ones. The honeywell panels don't do a very good job at all of reporting status, and thus the zone timer dumps are a way of helping us keep updated. With the DSC panels they're much more event based.
Have you tried setting 0 as your interval? This library here will totally disable the timer dumps if it's set to zero already. I suppose it's possible the HA component is forcing it to something though.

    if self._alarmPanel.zone_timer_interval > 0:
            ensure_future(self.periodic_zone_timer_dump(), loop=self._eventLoop)

[Cinntax]

Yeah, actually looks like the HA component just ensures it's an integer. So if "0" doesn't work (like it's being treated as uninitialized and falling back to default), i'd think even a value of -1 would work.

[sgruby]

Thanks, I'll give it a try!

[Cinntax]

Just curious- did this work at all? I just had someone else report a very similar condition, and I recommended this to them also.

[sgruby]

Honestly I hadn't tried it 😀 I just put in -1 and will see what happens. I put in a fail safe in my Node-RED flow that checks to see if a light was turned off less than 30 seconds ago so that even if I get a delayed zone open/closed, it won't pop the light back on.

Thanks for checking in with me!

[crackers8199]

just found this thread: i've been having this issue for months and finally found this on a search...does the above idea work? i just set zonedump_interval to -1 in config but haven't really had a chance to test it yet.

[crackers8199]

preliminary experience seems very good that -1 for zonedump_interval does in fact solve this problem, in case anyone else stumbles upon this thread looking for help like i was. haven't seen the open/close cycle shortly after closing a door or window since i set that up about 4 days ago. will keep monitoring it but for now this seems to be the best solution.

[crackers8199]

just wanted to throw a heads up in here: this seems to have been working well, until yesterday when i updated from HA 2021.9.3 to 2021.10.1 - all of a sudden after the update, i started seeing the bounces in status again, especially on my garage door sensor. i just restarted the envisalink and that seems to have corrected it for now, but i'll keep an eye on it.