-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AlarmDecoder thinks faulted zone is momentarily restored when a function key is pressed #46
Comments
This is also happening quite often even without using function keys. If you have a faulted zone, and you momentarily open your front door, AlarmDecoder will think the faulted zone was restored momentarily. |
Interesting. I will have to dig into this as I implement zone tracking in the C++ api. I would suspect any keypad sending to the panel could trigger the panel to start the sequence over. I expect it would start over in a pre defined way such as from the highest zone # in this case 18. A test would need to be done with 3 or more zones to confirm the order is descending or some other less predicable logic. If that is the case then this is very bad for my original algorithm :c( |
As for the LOW BATTERY or other system message this is fixed in the C++ API and discussions have started about how this could be fixed here. I designed the C++ API do address these issues so its not clear yet what would need to be done to refactor the Python code but hopefully back porting the improvements wont be too painful. The difficulty will be doing this and not breaking any existing implementations. |
Updating to say that this still happens a lot on the latest version. |
I am leaning toward a hybrid algorithm on the new C++ API. If the zone tracker detects it is gone it puts a timer on it just in case it comes back. It will increase the lag by a few seconds. |
Latest beta firmware.
There is a bug with the zone restore/fault parser when a function key is pressed on the keypad. Pressing the function key (either physically or by sending the ASCII codes) seems to trigger a repeat of the last output message as far as I can see in telnet. If this is a zone fault message, it confuses the zone restore/fault parser and causes it to report a momentary zone restore of the non-repeated zones. The bug doesn't occur if you press a function key within ~1 minute of previously pressing the function key. It seems to occur like 80% of the time with only one zone faulted, but with two+ zones faulted when you press the function key, the chances of all of them being falsely restored go up to 100%. If you have a "low battery" or another kind of non-zone message that happens to be the latest message when you press the function key, this doesn't occur.
The text was updated successfully, but these errors were encountered: