AlarmDecoder zones alternating on and off forever upon HA start if multiple zones are open #36298
Comments
|
alarmdecoder documentation |
|
@melyux, I'm the codeowner for AlarmDecoder. just wanted to confirm that I've seen this issue and it's on my radar. I'll look into it when I can, though I have a few other things to address first (namely #35728). It looks like binary_sensors in the AlarmDecoder component are initialized with a default value of |
|
The AlarmDecoder doc confirms that the sensors are w/o value at initialization. I believe there is a compunding issue with rf triggered zones. Whean rfzone is open and a second wired zone opens and closes a state chg is triggered for the first zone reporting open. if two rf zones are open at the same time, the alarm alternates between them again as well with AD triggering state change each time. -- the one door we leave open on nice days is rf and each time a motion is triggered the door automation reports the door open. Newbie here doesnt understand why the badges are not affected, |
|
I was looking at this further today and need to correct my prior stmt regarding the challenge I face. When there are one or more zones reported On and an additional zone reports On I've seen one of the previously On zones go to off (it was very brief and not in the logbook). When the most recent reporting zone goes off the previous returns to on. Maybe this is just how the alarm works but if so, I've not found a way to reproduce the keypad chime correctly. Always when there are two. One possible important detail. The two doors we leave open both happen to be connected via an RF board. All other zones are hard wire. I would be interested to know if there is anyone else experiencing the same or if there is a possibility there is some zone configuration setting in the Vista-20p I am missing |
|
Yeah, this has gotten even worse. If I have more than one zone faulted at the same time, Home Assistant keeps alternating the first one open and closed forever and ever and ever if I open a second zone. Every single time now; before, it was occasional. Really annoying. |
|
@ajschmidt8 Have you had a chance to look into this? |
I've looked into it briefly. I was just able to reproduce it about a week ago (not on purpose, it just randomly started happening when a few sensors were open). I started looking into using AlarmDecoder's So tl;dr, yes I've been looking into it as time permits, but I don't have a fully fleshed out solution quite yet. |
|
I am far from a power user of HA but have a way of getting that flip flop
condition to happen. I have two wireless sensors. If either is left open
they will report a state change after any other sensor opens and closes so
I could test. I would need a little guidance(doc) on how to install from
Github.
Thanks for working on this We quite enjoy have such a convenience
…On Sat, Oct 17, 2020 at 5:44 PM AJ Schmidt ***@***.***> wrote:
@ajschmidt8 <https://github.com/ajschmidt8> Have you had a chance to look
into this?
I've looked into it briefly. I was just able to reproduce it about a week
ago (not on purpose, it just randomly started happening when a few sensors
were open). I started looking into using AlarmDecoder's Zonetracker class
to report sensor statuses (link
<https://github.com/nutechsoftware/alarmdecoder/blob/master/alarmdecoder/zonetracking.py#L74>)
and it seems like that'd be a better solution for reporting statuses than
what's currently implemented in Home Assistant. However, in my brief
initial exploration, I discovered that Zonetracker doesn't work with
AlarmDecoder's virtual relay expanders to report sensor statuses when the
system is armed. The code seems to indicate that it should work with the
virtual *zone* expanders, but I'd have to first re-program my panel to
use the virtual zone expander instead of the virtual relay expander, which
I haven't gotten a chance to do quite yet.
So *tl;dr*, yes I've been looking into it as time permits, but I don't
have a fully fleshed out solution quite yet.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#36298 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALNOXUXA2DWWQWO4NXR53H3SLIM55ANCNFSM4NO2NRMQ>
.
|
thank you, @MickPBduece. I should be able to reproduce it again, but if I have any issues I won't hesitate to reach out. |
|
I have no wireless sensors, but I am seeing this issue as well. I am willing to run test code, provide logs etc if needed. |
|
quick update. I haven't made too much progress unfortunately. I do think that AlarmDecoder's Zonetracker class is still the best way to keep track of the zones. It contains a few hundred lines of code that will accurately keep track of zone statuses and prevent the alternating issues that we're experiencing. But that class doesn't support reading bypassed zones when the system is armed which is a feature I use personally and I'm sure many others do as well. Also, I think the virtual zone expander solution I proposed in my previous comment was incorrect. So at this point I'm kind of stuck. I'll keep digging, but I'm open to suggestions if anyone else looks at the code and has any ideas. |
|
@melyux, @MickPBduece, @jdesai61, can you guys post the complete zone list for your systems? I've made some progress. I'm curious about whether or not you guys have any wireless zones or any zones on the virtual relay or zone expanders. here's mine for example: zones:
01:
name: Front Entry
type: door
02:
name: Garage Entry
type: door
03:
name: Living Room Window
type: window
04:
name: Dining Room Window
type: window
05:
name: Sun Room Window
type: window
06:
name: Master Bath Window
type: window
07:
name: Sun Room Motion
type: motion
relayaddr: 12
relaychan: 1
09:
name: Sun Room Entry
type: door
rfid: !secret alarm_sensor_serial
loop: 2
10:
name: Master Bedroom Window
type: window
11:
name: Guest Bedroom Window
type: windowEDIT------- Please also include your alarm panel brand (Honeywell/Ademco or DSC). |
|
After further digging, it seems that this is an upstream issue with the AlarmDecoder Python package itself. See the link below. |
|
A problem well defined is half solved?
My config is in the integration with bypass on and code required for
arming. The zone configurations are all just the zone number and the
name.
The RF config for the wireless zones is all in the Alarm system is the
alarm system. Zones 44 & 45 are wireless.
02 Kitchen Door
03 Upstairs Motion
04 Downstairs Motion
05 Basement Door
06 Front Door
44 Patio Door
45 Outside Garage Door
I use an automation on status change of the doors (only) to replace the
chime on the alarm panel. When 44 or 45 are "on" and then the motion is
triggered it's as if the door that was open was cleared and then it noted
that it is open and then another chime. I think I had overstate this
before when I said I was sure I could make this occur because tonight as I
tried to confirm, I was not able to but I do recall a few days back having
the patio door open and walking through the motion.
Thanks for looking into this.
Jeff
- alias: notification of doors opened
description: ''
trigger:
- platform: state
entity_id:
- sensor.garagedoor_door_west_state
- sensor.garagedoor_door_middle_state
- sensor.garagedoor_door_east_state
to: Open
for: 00:00:01
- platform: state
entity_id:
- binary_sensor.basement_door
- binary_sensor.front_door
- binary_sensor.garage_service_door
- binary_sensor.kitchen_door
- binary_sensor.patio_door
to: 'on'
condition: []
action:
- service: notify.jc_notifier_group
data_template: # data segment for notification overall
title: Door Open Notification
message: '{% if trigger.to_state.state == ''on'' %}
{{trigger.to_state.attributes.friendly_name}}
is Open {% elif trigger.to_state.state == ''Open'' %}
{{trigger.to_state.attributes.friendly_name}}
is Open {% endif %}'
data: # data segment for notification specific to IOS
push:
thread-id: "Notification-of-doors-opened"
mode: single
…On Sun, Nov 22, 2020 at 4:42 PM AJ Schmidt ***@***.***> wrote:
After further digging, it seems that this is an upstream issue with the
AlarmDecoder Python package itself. See the link below.
nutechsoftware/alarmdecoder#50
<nutechsoftware/alarmdecoder#50>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#36298 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALNOXUVWVMKR6TZBD43KDJ3SRGHWLANCNFSM4NO2NRMQ>
.
|
|
Hey @ajschmidt8, the AD bug you referenced is something I experience as well, but it’s not quite as bad as the bug with HA. I have notifications set up from both AD directly and HA. The AD spazzes out momentarily, but always restores sanity after one mistake. The HA integration can go into infinite loops of alternation, and it also makes mistakes with zones being wrongly faulted and restored more often than the AD code. I have 6 zones hardwired, 8 zones on a zone expander, and 1 wireless zone. No virtual stuff. |
|
thank you @MickPBduece and @melyux. @melyux, there were some other potential issues I found in the Home Assistant implementation as well. For instance, look at all of the event callbacks that set the state of the binary sensors here. There are no conditional statements that prevent the expander or RF callbacks from setting the sensors' states when the system is disarmed. Because of this, when the system is disarmed, Home Assistant is using both fault/restore events and expander/RF events to set the states of sensors. This means that there are extraneous and potentially conflicting events that could skew the actual sensor states. Ideally, I think we'd want to use fault/restore events to set the state when the system is disarmed and expander/RF events to set the state only when the system is armed. I haven't tested this yet, but I think it sounds logical. It looks like there was a PR merged to address the AlarmDecoder bug that I mentioned previously (nutechsoftware/alarmdecoder#52). When I tested that locally, it did seem to resolve my Home Assistant issues. However, I don't have any zones on a zone expander as you do (I just have a single virtual relay expander). So you'd probably also need the fix I described above to get your sensors reporting 100% accurately. The problem I face now is that, although an AlarmDecoder fix was merged for this bug, it has yet to be released. And even when it is released, we won't be able to upgrade to it since there are outstanding issues in the latest AlarmDecoder version that currently prevent us from upgrading (see #31385 and nutechsoftware/alarmdecoder#47). Unless these outstanding issues are fixed in the next release, we can't upgrade. And also who knows when the next release will even be (AlarmDecoder upgrades have seemed to move slow in my experience). So at this point I'm thinking about just forking and publishing the AlarmDecoder library with the zone fix applied to the version of AlarmDecoder that Home Assistant uses (1.13.2). That's not ideal, but it could at least resolve this issue while the other AlarmDecoder issues get worked out. I'm open to any thoughts, comments, or suggestions on this. |
|
Another update. I opened up a PR for AlarmDecoder (nutechsoftware/alarmdecoder#56) that should hopefully fix the issue that prevented us from previously upgrading to the latest AlarmDecoder version, |
|
Still waiting on a response to my PR from the AlarmDecoder author. If anyone wants to comment on this PR, it might help get his attention. I got an email today from another user who is affected by the issue described in my PR. |
|
My PR was just merged to AlarmDecoder which should allow Home Assistant to successfully update to AlarmDecoder v1.13.9+ (link). v1.13.9 also has some fixes that should help address the alternating zone problem. I have one other user besides myself that tested it and confirmed it's working. I'm looking for a few others. @melyux, @jdesai61, @MickPBduece, can you help? Here are some instructions on how you can install the latest AlarmDecoder changes. These commands should be run from the machine you're running Home Assistant on: pip show alarmdecoder # verify current AlarmDecoder version (should show 1.13.2)
pip install git+https://github.com/nutechsoftware/alarmdecoder.git@dev # installs AlarmDecoder's development branch
pip show alarmdecoder # verify that AlarmDecoder was upgraded (should show 1.13.9)
# Restart Home Assistant now that the new version of AlarmDecoder is installed.
# Test the AlarmDecoder integration (i.e. arm/disarm the system a few times,
# open several doors/windows to make sure everything is reporting correctly, etc.)
# After testing is complete, run:
pip install alarmdecoder==1.13.2 # re-installs the original version of AlarmDecoder
pip show alarmdecoder # verify that AlarmDecoder was successfully downgraded again to 1.13.2Please post here with your results or if the instructions are unclear. Thank you!! Also, please make sure the firmware on your AlarmDecoder device is up to date as well! |
|
AJ
Apologies for the delay. I'm grateful for the updates and - I am terrible
about checking mail. I saw this today and gave it a go.
And apologies for knowing nothing about python but when I run "pip show
alarmdecoder" or "sudo pip show alarmdecoder" I get a carriage return and
that's it.
If it matters, I am running Supervised and Docker and honestly I don't
recall how I even installed AD to start with.
I ran pip list (below) and don't see AD listed and was reluctant to
just pop it in there since it must be running from somewhere else?
Anyway thanks again and maybe with a little guidance I can load this up and
test it out
pi@ha:/srv $ pip list
Package Version
----------------- -----------
arandr 0.1.9
asn1crypto 0.24.0
automationhat 0.2.0
blinker 1.4
blinkt 0.1.2
buttonshim 0.0.2
Cap1xxx 0.1.3
certifi 2018.8.24
chardet 3.0.4
Click 7.0
colorama 0.3.7
colorzero 1.1
cookies 2.2.1
cryptography 2.6.1
drumhat 0.1.0
enum34 1.1.6
envirophat 1.0.0
ExplorerHAT 0.4.2
Flask 1.0.2
fourletterphat 0.1.0
funcsigs 1.0.2
gpiozero 1.5.1
idna 2.6
ipaddress 1.0.17
itsdangerous 0.24
Jinja2 2.10
keyrings.alt 3.1.1
MarkupSafe 1.1.0
mcpi 0.1.1
microdotphat 0.2.1
mock 2.0.0
mote 0.0.4
motephat 0.0.3
numpy 1.16.2
oauthlib 2.1.0
olefile 0.46
pantilthat 0.0.7
pbr 4.2.0
phatbeat 0.1.1
pianohat 0.1.0
picamera 1.13
picraft 1.0
piglow 1.2.5
pigpio 1.44
Pillow 5.4.1
pip 18.1
pycairo 1.16.2
pycrypto 2.6.1
pyflakes 2.0.0
pygame 1.9.4.post1
PyGObject 3.30.4
pyinotify 0.9.6
PyJWT 1.7.0
pyOpenSSL 19.0.0
pyserial 3.4
pyxdg 0.25
rainbowhat 0.1.0
requests 2.21.0
requests-oauthlib 1.0.0
responses 0.9.0
RPi.GPIO 0.7.0
RTIMULib 7.2.1
scrollphat 0.0.7
scrollphathd 1.2.1
sense-emu 1.1
sense-hat 2.2.0
setuptools 40.8.0
simplejson 3.16.0
six 1.12.0
skywriter 0.0.7
sn3218 1.2.7
spidev 3.4
touchphat 0.0.1
twython 3.7.0
unicornhathd 0.0.4
urllib3 1.24.1
Werkzeug 0.14.1
wheel 0.32.3
…On Sat, Jan 23, 2021 at 8:51 PM AJ Schmidt ***@***.***> wrote:
My PR was just merged to AlarmDecoder which should allow Home Assistant to
successfully update to AlarmDecoder v1.13.9 (link
<nutechsoftware/alarmdecoder#56>). v1.13.9 also
has some fixes that should help address the alternating zone problem. I
have one other user besides myself that tested it and confirmed it's
working. I'm looking for a few others. @melyux <https://github.com/melyux>,
@jdesai61 <https://github.com/jdesai61>, @MickPBduece
<https://github.com/MickPBduece>, can you help? Here are some
instructions on how you can install the latest AlarmDecoder changes. These
commands should be run from the machine you're running Home Assistant on:
pip show alarmdecoder # verify current AlarmDecoder version (should show 1.13.2)
pip install ***@***.*** # installs AlarmDecoder's development branch
pip show alarmdecoder # verify that AlarmDecoder was upgraded (should show 1.13.9)
# Restart Home Assistant now that the new version of AlarmDecoder is installed.# Test the AlarmDecoder integration (i.e. arm/disarm the system a few times, # open several doors/windows to make sure everything is reporting correctly, etc.)# After testing is complete, run:
pip install alarmdecoder==1.13.2 # re-installs the original version of AlarmDecoder
pip show alarmdecoder # verify that AlarmDecoder was successfully downgraded again to 1.13.2
Please post here with your results or if the instructions are unclear.
Thank you!!
Also, please make sure the firmware on your AlarmDecoder device is up to
date as well!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#36298 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALNOXUW3NMLEIJ7N2ERUC6TS3ODKJANCNFSM4NO2NRMQ>
.
|
|
@MickPBduece, I appreciate the reply. I can provide personalized help with the testing if you're interested. You can email me at me@ajschmidt.com. |
|
AJ, I've installed it (command lined into the HA docker container and ran the commands there). Will try it out tomorrow. |
|
It seems to be working well as far as zones are concerned. But recently had a power outage, and had the "check zone" and "battery low" come up at the same time. Although AlarmDecoder itself recognizes these separately, Home Assistant keeps alternating the battery status between OK and LOW over and over and over again. Same with the "check zone" notice. |
Ok. Did this happen prior to you testing the new changes? If so, you should probably open a new issue for that. Since the zones seem to be working better now, I will try to update some things in Home Assistant this weekend to get this fix published to everyone. |
|
I thought it would be almost identical to this issue since it's another one of those parsing problems where HA thinks alternating messages from AlarmDecoder means the statuses are actually alternating. |
|
Thanks AJ
It’s appreciated
…On Thu, Feb 18, 2021 at 9:00 AM AJ Schmidt ***@***.***> wrote:
It seems to be working well as far as zones are concerned. But recently
had a power outage, and had the "check zone" and "battery low" come up at
the same time. Although AlarmDecoder itself recognizes these separately,
Home Assistant keeps alternating the battery status between OK and LOW over
and over and over again. Same with the "check zone" notice.
Ok. Did this happen prior to you testing the new changes? If so, you
should probably open a new issue for that.
Since the zones seem to be working better now, I will try to update some
things in Home Assistant this weekend to get this fix published to everyone.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#36298 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALNOXUXMQWKY55WIVP3KEKLS7UTRTANCNFSM4NO2NRMQ>
.
|
@melyux, ok. can you elaborate on the issue a bit more? I'm not sure I fully understand what's happening. Any relevant screenshots or stack traces would be helpful also.
@MickPBduece, no problem! |
|
Sure @ajschmidt8. When the alarm panel has the "check_zone" flag set, the status it sends is e.g. "CHECK 107 WIRE EXPANSION". Like the problem here where multiple open zones seem to open and close infinitely (because apparently Home Assistant thought that when the message for one zone being open came up, that it meant the other open zones were closed). So it seems like an identical problem with the zones alternating, like in my issue here. Every time the CHECK message comes up on the screen, HA sets the "check_zone" attribute to true. Then when the next message comes up, e.g. "DISARMED Ready to Arm", HA sets the "check_zone" attribute to false, even though it's not cleared, it simply moved onto the next message to display. When the cycling messages come back to "check_zone", it sets the attribute to true again. Here's the alarm panel display status over time compared to the "check_zone" flag's status over time in HA: |
|
@melyux, I understand now. I don't think that's an easy fix unfortunately. The AlarmDecoder team would have to write some code to keep track of all the currently displayed messages to determine when the I think the best path forward for this request would be to raise the issue with them. |
|
I've just opened up #46841 which will update Home Assistant to use the latest changes from the AlarmDecoder team. |
|
@ajschmidt8 Ah okay, then on the surface it's the same problem, but has different causes. AD doesn't even seem to have a way to send notifications for this Sounds good with the PR, you've done a superb job with this saga. Sucks that the AD team seems uninterested in supporting their own product. |
|
Thanks AJ
…On Sat, Feb 20, 2021 at 6:15 PM AJ Schmidt ***@***.***> wrote:
I've just opened up #46841
<#46841> which will update
Home Assistant to use the latest changes from the AlarmDecoder team.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#36298 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALNOXUR7LK45U4RH22DVTRDTABGAZANCNFSM4NO2NRMQ>
.
|
|
Sorry people :c( For a few years now it is just me and I have been busy working the C++ api. I will look this over today and if anyone wants to contribute I am looking for people to add to the project to help support it long term. At some point we will have to rewrite the Python code to fix all of the old issues that the C++ API I am working on addresses by design. If anyone wants to contribute and needs equipment or help on the AD2* protocol please send me a message. Best |
|
Hey All, Just a quick update. I reached out to Sean (the AlarmDecoder creator, above) via email last week and we had a video call yesterday to talk about AlarmDecoder. He's given me permissions to help maintain the AlarmDecoder Python project while he works on a new IoT implementation of AlarmDecoder for embedded devices like the ESP32. Since our discussion yesterday, I've published a new version of the AlarmDecoder package, v1.13.10 which includes some of the changes necessary to help resolve this alternating zone issue. I've incorporated this new release into my PR (#46841) and from the looks of the latest comments on that PR, it should be in the March Home Assistant release. Once the new HA release is out, please let me know what your experience is with the zone problem. Thanks for everyone's patience here! |
|
Thanks AJ
Sean helped me a little when I bought my AD. It's nice to see people come
together over a common goal when there is so much divisiveness.
I really enjoy having the AD and it's wonderful to look forward to not
having the flip-flop.
Thanks
Jeff
…On Sun, Feb 28, 2021 at 3:36 PM AJ Schmidt ***@***.***> wrote:
Hey All,
Just a quick update. I reached out to Sean (the AlarmDecoder creator) via
email last week and we had a video call yesterday to talk about
AlarmDecoder. He's given me permissions to help maintain the AlarmDecoder
Python project while he works on a new IoT implementation of AlarmDecoder
for embedded devices like the ESP32. Since our discussion yesterday, I've
published a new version of the AlarmDecoder package, v1.13.10
<https://pypi.org/project/alarmdecoder/#history> which includes some of
the changes necessary to help resolve this alternating zone issue. I've
incorporated this new release into my PR (#46841
<#46841>) and from the looks
of the latest comments on that PR, it should be in the March Home Assistant
release.
Once the new HA release is out, please let me know what your experience is
with the zone problem. Thanks for everyone's patience here!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#36298 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALNOXUUSXIMNDQVIEWFBFCTTBKZPFANCNFSM4NO2NRMQ>
.
|
|
hey all. i know this issue got closed when my PR was merged, but i wanted to check in to see how the zones are working for you guys now |
|
I’ve got an issue with Supervisor not starting with HA and stopping
periodically and I find tonightv also preventing upgrades. I suppose I
will be reloading soon so will remit after that
Thanks and regards
Jeff
…On Sun, Mar 7, 2021 at 5:18 PM AJ Schmidt ***@***.***> wrote:
hey all. i know this issue got closed when my PR was merged, but i wanted
to check in to see how the zones are working for you guys now
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#36298 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALNOXUTRLMI3AMOXWOWZFSDTCQCURANCNFSM4NO2NRMQ>
.
|
|
I am on 2021.5.3 version of HA now and this issue (zone faults not showing up properly when multiple zones are faulted) is still not resolved for me. |
|
Hey @ajschmidt8, what did we have to do to get on the fixed version again? I'm on the latest HA and I thought this was working, but I had the same problem again today. I checked the AlarmDecoder web interface itself and saw it had updates pending, so applied those. Updating both HA and AD was required, right? |
|
I don't have HA as a custom integration (in config/custom_component), so I assume that when I get a new version of HA, new code for AD comes with it. |
|
@jdesai61, yes that should be correct. |
|
I've just now started the using the Alarm Decoder integration. I have a very old version of Alarm Decoder running... it was working reliably with my Indigo system so I haven't updated it for probably 3-5 years. As soon as I switched on the HA integration, I started getting weird faults on my wireless sensors. As in faulting when they were closed. I thought it might have been a range issue, so I installed a repeater (5800RP), but that didn't help. Is it even possible that the HA integration could be causing this? Sorry, I'm kind of new with this stuff. |
|
I explored this some more today. I'm a bit stumped. I was experiencing the zone alternating issue with my Home Assistant installation earlier today, but after rebooting, it seems to be working okay again. Not perfect, but okay. I'm not sure zone reporting will ever be perfect with AlarmDecoder since it relies on parsing keypad messages to determine faulted zones. |
|
This issue should be reopened in the meantime since it's still the same. AlarmDecoder itself is detecting the open zones just fine, but Home Assistant keeps alternating the zones forever upon start. @bdraco |
|
It's gotten really bad. Even restarts of both the AD and HA itself don't fix it anymore. Can we get this reopened? @bdraco |
|
@ajschmidt8 Is there no way to hook into AlarmDecoder's API to determine faulted zones instead of writing independent code to do it in HA? AD itself never seems to get this alternating issue, it's just the HA implementation that's going haywire |
|
I gave up on Zone Tracking algorithm.. As noted too many things can cause it to "flap". I instead went with timeouts. This approach has instant notification of faults but restores take up to the timeout time. If a zone fault is not seen in that time then it is restored. If the panel shows "READY" then all faulted zones are restored. This is sufficient for occupancy sensing for lights ON events etc. |
|
@f34rdotcom Can you give any information on how one might use the time outs? I am seeing zones not clear properly and would like to implement a timeout. The link you linked too, is that installed somewhere in Home Assistant that i can modify. Any guidance there would be much appreciated |
|
Hi Sean
Sorry to bother you directly but I need to change some settings on my
Vista20 or maybe 20p. The keypad is not allowing me to enter developer
mode so I was looking to download the Keypad program. When I try to access
that - IE and Chrome just blink. Is there a link you can suggest or if the
file is small enough could you send that please?
Thanks
Jeff
…On Thu, 3 Feb 2022 at 12:16, Sean Mathews ***@***.***> wrote:
I gave up on Zone Tracking algorithm.. As noted too many things can cause
it to "flap". I instead went with timeouts. This approach has instant
notification of faults but restores take up to the timeout time. If a zone
fault is not seen in that time then it is restored. If the panel shows
"READY" then all faulted zones are restored. This is sufficient for
occupancy sensing for lights ON events etc.
https://github.com/nutechsoftware/AlarmDecoder-IoT/blob/master/components/alarmdecoder-api/alarmdecoder_api.cpp
—
Reply to this email directly, view it on GitHub
<#36298 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALNOXUVVLGPSHXCJIHDV4WDUZLA7DANCNFSM4NO2NRMQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
The problem
When you start Home Assistant and your alarm system has 1 or 2 or more zones open (the more zones, the more likely the problem), the AlarmDecoder integration's zones repeatedly fault and restore in a loop, forever. Sometimes it's fixable by restarting Home Assistant multiple times until it "syncs" correctly. Looks like a problem with the state machine in the parser.
When it does stop alternating after a lucky restart of Home Assistant, this time some of the zones are reported as closed when they're actually open. They don't show the real state until the zone is physically restored and faulted again. This may be the same as #26154.
Environment
Problem-relevant
configuration.yamlTraceback/Error logs
Additional information
The text was updated successfully, but these errors were encountered: