[Solved] Zone names in events

[Ron]

Hi,

Using the Python library, I can get zone events (e.g. device.on_zone_fault()), but the zone information has only the zone number, without its name. How do I get the names working so I can have more friendly messages?
I went through the documentation and examples and could not find any reference to that.

[ I'm using AD2USB with Vista 20P (single partition, mostly RF devices). The AD2USB connects to a Raspberry Pi, that runs ser2sock.
On the same RPi I'm running the Python script that connects to the AD2USB via socket. ]

Thanks,
Ron

[Scott]

Hey Ron,

There's currently no support for zone names in the library, but it's on my TODO list now.

I'm not sure exactly how you're looking to use them, but it'll likely end up that you'll define your zones with a name in the code itself, since I don't think it'll really be possible to pull them directly from the panel, for a few reasons:

• Panel fields will differ between the different types of panels
• It would be a rather slow process to query all of the fields
• It would require us to store the PIN for a user with administrator-level privileges

That being said, I think it'd be fine to pull the zone names in your own app logic, if you feel the need to get them directly from your panel.

Not exactly sure when I'll be able to get that in, so you're welcome to submit a pull request if you feel like doing it yourself. Or a quick-and-easy solution would be to set up a simple mapping that you can reference.. something like:

Code: Select all

ZONE_NAMES = {
  10: 'Front Door',
  11: 'Back Door',
  12: 'Garage',
}

print ZONE_NAMES[zone_id]


Thanks!

Scott

[Ron]

Hi Scott,

Thanks for your reply.
The explanation why you cannot retrieve the zone names from the panel makes sense. At the same time zone names look important to your solution. My feedback is that if ~100% of the users who need programmatic access to the AD* product would need to use zone names then it deserves to be integrated better into the interface code, and should not be left to each customer to struggle on their own, even if the solution is simple.
Since the data must come from the user, here's what I would do:
1. Create an JSON/XML (or similar) file to hold user-provided information ("config file"), in particular the zone names, but probably also zone types, zone fault severity, etc.
2. First phase, manually edit by the customer. Second phase, bring a simple editor to create/edit the file.
3. This config file can serve any AlarmDecoder software, whether it is a GUI app or an API - same file content serves them all. All of these s/w modules would load the config file on start and will use it to learn the user's specific configuration.

What you win is that the software now has integrated knowledge of information coming from the panel and from the user, making it much more educated about the events it throws.
Needless to say, such an organized approach cannot come from the community, it can only come from the vendor. Hoping to see something like this in the future...

My 2 cents...
Thanks!
Ron

[Ron]

Oh, and it sounds from what you're saying like it can be possible to retrieve the information from the panel if you have the admin PIN code. Fine, then it could be helpful for building that initial config file, done only once usually (and again for any later alarm system changes like adding a sensor):
e.g. utility:

Code: Select all

read_panel_config -t vista20p -pin 1234 -o myConfigFile.json

Goes to the panel via the user-provided PIN code, locates the needed fields according to the user-provided panel type, reads the data (slowly but who cares), writes it into a config file myConfigFile.json.

Of course, this approach does not require you to save the PIN code (agreed it's not a good idea), you only use it in-memory while the above utility is executing.

[berkinet]

I sort of disagree this is NuTech's responsibility to "fix." Their product is hardware (and firmware for the hardware). The supporting applications and example code is a contribution to their user community. As I see it, it is the responsibility of every capable community member (not just those who work at NuTech) to help the community move forward.

As to the specific request for the inclusion of zone names in some outputs from the Python module. I tend to agree with Scott that there should be a look-up table to cross-reference zone numbers to names. Such a table would be loaded from a formatted file at startup. (json or xml would work, but in this case, I suspect a simple comma delimited file would be a lot easier to maintain -- there are really only 2 or three columns.

As for building the file. If the file were updated/modified on a regular basis, some type of automatic updating process might be worth the effort. However, for the current case, I do not think the effort required to create the file is that onerous -- probably a lot less that actually coding some automatic system that could work on any supported panel.

Finally, there is another approach that can synchronously deliver zone numbers and names: Simply base the state table on the keypad display messages rather than the information contained in the raw data or decoded data fields.

Just my 2¢