The Vista20SE is an ademco panel, so it falls under the first conditional.
The issue is, for the Vista20SE a fault on Zone 13 shows up as the following expander message:
!EXP:01,04,01
I gather that on other Ademco panels the "Address" portion of this starts with 7. But the Vista20SE panels it seems to start with 1. As a result in my case the calculated zone ends up being -36 instead of 13.
I realize the SE panels are old.
If this code is working properly on all other Ademco panels, I don't see a way out of this at least not automatically. The best solution is likely to alter the main alarm decoder package to handle SE panels as a distinct variant that can be configured on the device. That is more than I feel like dealing with.
The funny thing, is that things will work OK with this error. But the zone tracking for all of the expander zones is only handled by the alphanumeric messages. So many users may not notice the glitch, but as a result, expander zones will flutter ready and faulted as a result of the limitations of alphanumeric zone tracking. If things worked correctly, expander zones are never reported incorrectly.
For my own use, I may just fork off and fix what I need as this repo has become a little stale.
The issue is in the calculation here:
https://github.com/nutechsoftware/alarmdecoder/blob/d392edb87272c18dbcd3259aad90135cf354a86c/alarmdecoder/zonetracking.py#L230-L238
The Vista20SE is an ademco panel, so it falls under the first conditional.
The issue is, for the Vista20SE a fault on Zone 13 shows up as the following expander message:
I gather that on other Ademco panels the "Address" portion of this starts with 7. But the Vista20SE panels it seems to start with 1. As a result in my case the calculated zone ends up being
-36instead of13.I realize the SE panels are old.
If this code is working properly on all other Ademco panels, I don't see a way out of this at least not automatically. The best solution is likely to alter the main alarm decoder package to handle SE panels as a distinct variant that can be configured on the device. That is more than I feel like dealing with.
The funny thing, is that things will work OK with this error. But the zone tracking for all of the expander zones is only handled by the alphanumeric messages. So many users may not notice the glitch, but as a result, expander zones will flutter ready and faulted as a result of the limitations of alphanumeric zone tracking. If things worked correctly, expander zones are never reported incorrectly.
For my own use, I may just fork off and fix what I need as this repo has become a little stale.