Alarm system integration (DSC or Ademco) -- Can I actively poll a zone?

I am designing my home-automation system from the ground up based on OpenHAB. Have done ~20 hrs. of reading and research, and I have a good background in electronics, networking, Linux, etc.

I’m pretty clear on most of the concepts and capabilities. The core of my system will be either a DSC or Honeywell/Ademco alarm system with 64 to 128 zones (haven’t decided on max # yet.) All contacts & sensors will be hard-wired wherever possible, which is >90% of locations.

I will use either an Envisalink EVL4 (with DSC system) or an AlarmDecoder w/ the Pi/Ethernet option (with a Honeywell/Ademco system) to allow OpenHAB to talk to the alarm system.

One important question I am still not clear on: In either of the above configs (DSC or Honeywell / Ademco) is it possible to actively poll a single zone?

I understand that the basic mode of operation is for the alarm panels to report a status change in any sensor, and that via the EVL4 or AlarmDecoder unit OpenHAB is always listening for status changes. But what if, for system reliability & consistency reasons, I have a case where I want OpenHAB to be able to actively query the status of a given zone?

The more I think about it, the more this seems like perhaps an irrelevant question – the alarm panels are designed to always report a sensor status change no matter what. I am just concerened about possible edge cases where perhaps due to system load or any other contingency, somehow OpenHAB does not receive a zone status update when it occurs.

For crucial rules and special situations I would want to have OpenHAB ask the alarm system, “Hey – what is the current status of zone …?” before undertaking some action.

Appreciate any and all answers, comments, suggestions, and thoughts on this subject.

I am using AlarmDecoder and it works well.

The only way you would be able to POLL a zone is if there is a keypad sequence to poll the status of a zone this is because (at least with alarmdeocder) the only path openHAB has is via a simulated keypad.

I am no alarm system expert.


The DSC Panels can be told to broadcast their Zone status. Typically the integration software will do this at startup, and also upon detecting a TP (or IT100) disconnect.

After that, they’re delivered as change notification events. These come in series over the comms channel (Serial or IP) so you won’t see them drop in most cases.

You could probably trigger this with the DSC Binding, since it exposes a general hook to make calls. The results will come via the normal channels though, so there you’d have to wait for a regular Item updated/change (IO is typically async)

The older 2DS Envisalink boards used to be short on memory and, in some specific cases, they’d have problems on larger networks. Most of that was fixed up a few yrs back (I have this combo for code I developed a few yrs back)

The main caution is to keep the number of network pieces, between the openHAB and the Envisalink module, to a minimum… And to ensure these pieces are all on a reliable, battery backed up, power source.

I’ve run this type of combo, albeit with a Paradox panel attached to a MiOS/Vera, for ~6 yrs now, and it’s great… Never felt the need to externally force a refresh… I have the plugin do it at all the failure points.

Thanks for your detailed reply so far.

Point taken re: network reliability, I will have everything running on a dedicated gigabit LAN w/ quality cat 5e or cat 6 cabling, and probably just 1 physical Ethernet switch hop from the EVL4 and/or the AlarmDecoder Pi/IP unit to the OpenHAB server. Of course all w/ quality battery backup power.

Can you expand a little on what you mean by “… I have the plugin do it at all the failure points…”?

I.e. give an example of a case involving a switch / sensor (in a DSC zone) that you consider a failure point (i.e. a possible case for a mis-read or skipped notification, or an ambiguous open / closed state?) and how you deal with that?

It may be that I’m worrying over a non-issue but I want to be sure before I invest a few grand in NUC’s, alarm system, sensors, etc.

Alarm decoder binding sets all contacts to closed the moment it gets a “ready to arm” status. That one is retransmitted continuously, so will be picked up sooner or later. There is no way to directly poll a single zone. However, the messaging from panel to alarmdecoder is so reliable that I do not recall a case where a zone status went stale.

The failure points are typically between the Alarm Panel and the EVL, or between the EVL and the HA Controller.

In most cases, these come down to some form of loss of communications.

When these connections are lost, that loss can be detected and acted upon. In some cases the EVL will tell you of the loss, and in others it’ll be the fact that the code lost the TCP connection.

Since the Zone states might have changed during the period of loss, you routinely reload the Zone state defs at that point to ‘resync’ the HA Controllers copy.

This is rare, but it can happen, so you want the Binding to tell you it occurred, so you can act, and then you want it to correct the data sync issue.

For Zones themselves, make sure you wire the tamper resistor at the sensor end, not the Panel end. This will help you know if the sensor is tripping or if the wiring is failing. Apart from that, it’s binary… there are no intermediate states presented, each Zone is either open or closed.

Then panel itself uses (configurable) micro-delays on the Zones before notifying you they’ve changed state

FYI: I updated the AlarmDecoder bindings to include “Zone” tracking. It will track and predict RESTORE events for onboard zones. All that is required is a system to send * to the Ademco panel to get it to dump a fault list when the panel has a fault.

Feedback needed so if you can please take a look.


Interesting new development, or new to me at any rate:

I rec’vd a Vista BPT128 panel today, which has a paper addendum sheet. It lists 3 new features present in Rev. 12 (or later) firmware.

The 3rd and most interesting new feature is:
"With this firmware revision, zones programmed as Type 23 (No Alarm Response) generate an event/notification on Total Connect 2.0 and other Remote Interactive Service (RIS) applications. This is only applicable to INPUT types: HW (hardwired), SL (serial polling loop), RF (supervised transmitter), and UR (unsupervised transmitter."

I wonder if this is relevant to AlarmDecoder in any way, i.e. if it will facilitate faster or better notifications for non-alarm contacts through AD binding. Does TotalConnect2 work through the RS232 port? Or it is some kind of daughterboard or otherwise communicating through a non-standard interface.

I have this panel in my lab its a nice commercial panel. I do have Beta firmware for the AD2* that will allow an AD2* to work on its VPLEX bus to access its expanders but unlike a Vista 20P this panel does not support standard expanders so no EXP messages or relay devices on the keypad bus only VPLEX. This will take a dedicated AD2* and attach it to the VPLEX bus and it will report any of the 100+ zones attached to expanders on this bus to the UART host. You would need another AD2* connected to the keypad bus to get alarm state though.

Zone type 23 is used often to do as you say create a zone used for utility purposes but the problem happens when you arm an Vista alarm it wont eject ZONE fault messages any longer so zones on expanders are preferred for this purpose.

the TC works through a special adapter that connects to the keypad bus similar afaik to the AD2* and has its own protocol to talk to newer firmware 10+ I think. Older boards or firmware afaik need update to work fully.

AD2* works with all ages of Vista panels even the 20+ year old 10SE

Sean M

Actually it turns out I got a revision 11.4 BPT128 board, the new “zone type 23” setting only applies to revision 12 and later. It’s going to be a pain to RMA this unit & wait for the vendor to get stock on the Rev. 12 –

Do you think I need the Zone Type 23 or does it not really matter for my application?

What I want is – even if I have to buy a 2nd AD2* unit – to be able to get contact / VPLEX device open/close/fault messages with DISARMED zones. (I understand the armed-zones limitation you described.)

I would rather just accept this Rev. 11.4 BPT128 if it will work fine.

Hmm. I am having problems processing that you do not have zone type 23. Did you confirm this in programming mode of the panel?

In order for Vplex to work you have to program the zone into the panel so you would have to assign these zones some ALARM status if 23 did not exist. This ‘still’ allows you to closely monitor all Vplex ZONES regardless of Armed state so all of your interior zones will report OPEN/CLOSE instantly over Vplex when armed stay. This works well for motions as well so you can get dual use of interior motion sensors but sub second response times.


I have not yet powered up & connected to the panel – because once I do I cannot return it.
I am trusting that the addendum sheet, which is very clear that the new Zone Type 23 is only in Rev. 12 and later firmware, is not going to be available in Rev. 11.4 firmware.

If you are confident that I can get good contact monitoring using a 2nd AD2* unit on the VPLEX bus, with or without Zone Type 23, then I will go ahead and use this Rev. 11.4 panel. Probably it’s fine to do this because the Zone Type 23 firmware change is intended for Honeywell’s “TotalConnect” system, whereas using AD2* w/ new firmware you are bypassing Zone Type 23 and getting the same info directly off VPLEX bus?

Do I need to return this v.11.4 panel and wait for a Rev. 12+ panel, or can I just use this v11.4?

I will certainly stand by my work and if you are not happy make it right but I am very confident it will work what I am not confident in is what “it” is :slight_smile:

Do you plan on also buying keypads and connecting sirens and arming and disarming or are you just looking for a very cost effective contact tracking for your home automation / security alerting system?

What “It” is is:

  • Vista 128BPT panel w/ Rev. 11.4 firmware
  • AD2* unit, currently I have 1 for the keypad bus, if I need to I will get another for the VPLEX bus.
  • OpenHAB running on Ubuntu 14.04 LTS

I will be using the Vista 128BPT as the primary security method of course, w/ motion sensors, door contacts, etc.
I want to use the Vista128’s contacts as much as possible for home automation w/ OpenHAB, i.e trigger actions when a particular contact opens/closes. I will have each contact as its own zone. So, when Zone 39, with 1 PIR motion sensor, trips, and the alarm is either disarmed or Armed Stay, I want that ZOne 39 PIR motion sensor trip to be transmittied ASAP (shortest possible latency) to OpenHAB, so that OH can take appropriate action (whatever that is, i.e. turn on a light, send a notification, etc.)

---- Side note-----
I have been taking a hard look at the ELK M1 series panel and it is built from the get-go for this type of stuff, also expandable to 200+ zones, but there is no VPLEX-style sensor bus that I’m aware of, so you have to run a physical wire loop for all 200+ zones. And the zone expander boards are ~$140 per 16 zones. If the ELK M1 had a sensor bus for zones I would not bother with Ademco because ELK’s stuff is much better documented (e.g. they publish a complete RS232 control / reporting command set.) The other thing that keeps me away from ELK is that it doesn’t look like anyone has done an OpenHAB binding for it. That’s a lot of work I don’t have time for.

Ya your system design sounds fine. AFAIK how its working now the OpenHAB driver for AD2* wlil work for the VPLEX side too. It is the same protocol in that it will send out EXP messages for each programmed zone on the Vplex bus.

With the price of vplex devices or even the standard expanders for the 20P panels makes adding sensors to a HA system inexpensive and reliable sensors for everything.

Here is the note on firmware for vplex support.

Sean M

Appreciate your prompt responses.

I already bought one AD2USB unit from you last week. What I’m understanding here is:

1 x AD2USB unit on keypad bus will control alarm functions (arm / disarm / etc. – remote keypad basically)
1 x AD2USB unit (separate unit) on VPLEX bus will receive & forward VPLEX notifications.

Just curious – will the VPLEX-attached unit allow sending of any commands? I imagine probably not, i.e. because VPLEX is a reporting bus, not a control bus?. But just curious.

Edit: I see from the AlarmDecoder website that I can flash the firmware w/ various utilities as needed if I want to move my AD2USB device to a different firmware rev.

Yep spot on. You need one for each bus.

Being able to Send or be a “Virtual Zone” is still in the works on the VPlex firmware I just need more people using and giving feedback on the vplex support and it will happen.


OK, please count me in as one of your available BPT128 / VPLEX beta testers. I have the panel now & am starting integration with OpenHAB. The panel is not “in service” yet, i.e. not in active use, it is sitting on my workbench so it is in an ideal state to do beta-testing.

Some more questions:

  1. You implied in an earlier post that while AD2* does not yet support simultaneous attachment to both Keypad and VPLEX buses, it might some time in the future? Am I understanding that correctly? I don’t see how that would be possible without a hardware revision as it would involve physically connecting the VPLEX and Keypad bus wiring to the same 4 terminals on the AD2*, would it not?

  2. Can you point me to AD2* documentation on the specific limitations of using it with a BPT128 panel? I have read elsewhere that, for example, while the BPT128 claims having 128 zones, only 96 of these zones are “actually usable” within OpenHAB – is that true? Or will that no longer apply when using a 2nd AD2* connected directly to the VPLEX bus?

Thanks for your help - I am covering ~3000 sq. feet with 20 doors, 40 window contacts, 30 IR break-beam curtain sensors, 30 interior motion sensors, etc. - I need to know what the upper practical limits for zone usage are with BPT128 + AD2* (or dual AD2*'s) + OpenHAB.

I think its 119 vplex zones + 9 onboard zones = 128 ie BPT128.

You could mix and match between wired and wireless but in the end I think it has 128 MAX zones.
You can use zone doubling or group some of your zones together but as you know you then loose visibility of what exact sensor went off.

That being said your panel should support your 20+40+30+30=120 you will have a LOT of zone expanders.

for such a large configuration I suggest using our Compas driver so you can upload and download programming directly.

The 128BPT supports ECP bus access for Compas so AFAIK our driver will work with it.


Hmm, I had read somewhere, I’m not sure exactly, that for some technical reason the effective limitation with OpenHAB + a Vista128 panel was 96 zones, and the other 32 zones could only be accessed with some kind of hack or work-around. I will update this thread if I get solid information on that one way or the other. Thanks for your replies to date.