Here’s a little project that might interest some DIY’ers out there. It’s an ESPhome custom compoment that creates a direct interface to a Vista20 (Ademco/ADT/Honeywell) system using the ECP bus communications protocol. The features it provides are:
Features:
Full zone expander emulation which will give you an additional 8 zones to the system per emulated expander. Currently the library will provide emulation for 2 boards for a total of 16 additionals zones. You can even use free pins on the chip as triggers for those zones as well.
Relay module emulation (in dev branch)
Long Range Radio (LRR) emulation (or monitoring) statuses for more detailed status messages
Zone status - Open, Busy, Alarmed and Closed with named zones
arm, disarm or send any sequence of commands to the panel
Status indicators - fire, alarm, trouble, armed stay, armed away, instant armed, armed night, ready, AC status, bypass status, chime status,battery status, check status
Optional ability to monitor other devices on the bus such as keypads, other expanders, relay boards, RF devices, etc. This requires the #define MONITORTX to be uncommented in vista.h as well as the addition of two resistors (R4 and R5) to the circuit as shown in the schematic. This adds another serial interupt routine that captures and decodes all data on the green tx line. Currently this data is used to update expander zone statuses for open/close.
Basically, with about 10 dollars in parts, you can have complete control of your alarm system plus the added ability to have more zones added to the system with zone emulation. No need for any other expensive hardware. There might be a few bugs here and there but so far, it’s been running well for me. Have fun.
This is a sister project to my other ESPHome custom component for a DSC system located here.
For those that dont use ESPHome or prefer to use plain MQTT, i’ve created an example home assistant MQTT client ino formated file. You can compile it using the Arduino compiler . It will give an idea how to use the library for your own use. You can find it in the MQTT-Example directory
Idea: If you can monitor other devices on the keypad bus, can you get hardwired zone status while the system is armed?
Or if this is somehow able to tell zone status in an armed or alarm condition that is not needed, consider a “no alarm” or “interior follower” zone where the alarm does not trip when the zone is opened, but you still want to know
With the system as I’ve seen there is limited info sent from the panel when it comes to hardwired zones. Perhaps an F2 command would provide more info as I’ve read in other users experience but the panel I have here does not send those. Monitoring the bus at this point only will only provide info on the external devices such as zone expanders, relay boards, RF devices, keypads etc. You should be able to get all status that they send, armed or not. I only have a zone expander board for testing so cannot confirm for the other devices such as RF receiver/transmitters. if MONITORTX and debug is enabled, then all data packets seen on the bus will be printed.
The code as I posted does not use this data but is there for others to use if they so wish. Perhaps at some later time I can add more functions that expand on this info. At this point it achieves my main goal of providing zone info, system status and zone emulation as well as full control of the panel via home-assistant.
Edit: I’ll add logic to update expanded zone status using the monitored bus data. Modules will send data to the panel on any channel status change and in addition the panel also requests zone updates from the modules every 30 seconds. Both this info can be used to keep expanded zone status updated as far as open/closed is concerned. As to builtin zones, this will depend on the rolling zone messages from the panel only.
As discussed, i’ve added code that will now update zone status from the 0x98 expander responses. These will update the zone instantly on zone changes no matter what the alarm status is. This will also keep the zones status updated every 30 seconds from the periodic polls. As noted though, this will only apply for zones defined in the expander modules ie. zones 9-48. Also, zones that are have an Alarm or Bypass status will not be updated as those statuses have priority from the panel.
I don’t have RF devices so can’t say if this will work the same for those as well. If someone has a dump of the module data responses for those, I can add code to support them if needed.
The RF devices are connected to the keypad bus through the transceiver so that might work already, the keypad just reports it as a zone fault, but there are also supervision commands that do not trip the alarm. And keyfobs (BR) may act differently though they also get a unique zone number per button
Another thing that might be interesting is being able to see the commands sent for output devices like relays, I do not think it would be a good idea to activate them since that might confuse the panel
Relay emulation and monitoring is mostly supported in the dev branch. I don’t have a relay board so guessed at the protocol mostly. It’s very similar to the zone expanders. The software will emulate multiple relay modules the same as zone expanders. If you really want to see activity on the built in zones I believe there is a way to create a zone follower out of a relay and a zone using program *79/*80 so that the panel will activate/deactivate a relay on any zone fault/restore. I have not tested that. Just passing that on for those that want to play with the dev branch version.
I’m pretty sure the RF data will show up but as well, but I as i already indicated I don’t have any rf devices on the vista bus, so I can’t test it, so it’s a moot point. My main system is a DSC.
I got myself a NodeMCU for testing various things, maybe in a week or 2 I will get more components to build the ECP bridge and get some monitoring results from the RF transceiver
Great! I’ve merged the dev branch to master. Therefore use the master branch for testing. I’ve added some checks for RF data. The 9E cmd is used for the RF module supervisory. RF module repsonses should come after that cmd. This branch includes support for relay modules.
I have been glancing at the code and have a few questions:
Is there a specific reason GPIO1 and 3 are not used for panel communication?
Ademco zone expanders have a response time setting for how long a zone is faulted before it reports to the panel, 300ms is the default but the first zone can be set to 10ms. 300ms prevents false faults when wind or a shock trips the wire in a magnetic switch. Is this settable or used at all?
Is EOLR simulated or does this use the actual zone setting from the panel? If it does will it detect line break faults?
I leave 1/3 open for tx/rx for users who want to use those pins for serial comm debugging.Also those pins start as high on boot and can possibly introduce false data on the line at that time . You can use them if you prefer.
There is no delay introduced in the emulated zones since those were designed to be triggered by external software triggers. The delay can be added in the external triggering mechanism. I didnt want to add even more complexity by adding another variable in the mix.
EOLR is simulated because that’s what works on my system by default configuration. Break faults are not detected since again, this was designed to be triggered by external software such as home assistant events eg: PIR triggers, etc. There was no real need to fully simulate a hardware zone with this feature . Currently an open is used as a fault and an emulated resistor termination is used for restore.
Cool project, just found it.
I am currently using an Envisalink 3, and its working fine to interface to HA and my smart home setup.
But I have a bunch of ESPs around the house for other tasks, mostly use the Wemos mini D1’s and keep a few spares on hand. Have some opto’s around too, and plenty of resistors so I may try this out when I have some time. Haven’t used ESPHome yet, using espeasy and tasmota, but this is a reason to play with ESPHome.
This is awesome. I’m waiting on some parts to get this going, but this is super cool. I installed the code on a D1 mini pro it to see how it works, and I’m wondering if there is a specific reason that the zones show up as “Text Sensors”. I used to have a DSC panel with an Envisalink (at a previous home), and the zones showed up as “Binary Sensors”. Since the sensors are generally on or off, this made sense to me, and you can assign a “device_class” of door or window and get the matching icon. If there is additional state that the zone sensor provides (like low battery, faulted, or bypass maybe?), the text sensor makes sense and I can make the icon do what I want.
A zone can be bypassed, alarmed, faulted, clear, trouble, etc. Instead of having multiple binary sensors for each zone to identify each unique state, I chose to use one text sensor for each zone for simplicity. Also, having too many sensors seems to cause issues with the communications with HA as well as creating a cluttered display. Of course, there are other ways of doing this but this method works best for my purposes.
You can modify the yaml, etc to suit your preference if you prefer to use binary sensors with the associated sensor type.
I’ve added a new lovelace alarm panel card that can give you basically the same functionality as a regular keypad as shown below. I’ve also fixed a few issues with the key send functions. NIote, you will need to use the new library code and the modified yaml file in order to use it.
For those that prefer not to use ESPHOME, I’ve also provided an updated MQTT sketch in the master branch to support all features of the ESPHOME version as well as an updated alarm panel card to work with any MQTT or ESPHOME alarm system. It attempts to emulate most functions of a VIsta LCD panel. You could potentially use it to program the alarm panel if you wanted. A bunch of bug fixes also applied.
Tks to all the users that helped with debugging the system. Also thanks to appleguru for the display updates to the lovelace card.
Just found this today. Looks interesting! I’m currently using an AD2USB to connect my Vista 15P system to a Vera Plus. Since my Vista panel is located in a closet with no wired Ethernet, I’ve been using a Powerline adapter for network access for the Vera Plus.I haven’t yet found a way to control the AD2USBthrough the Vera from HA. I’d like to transition away from Vera if possible and go to HA only. This looks like it might help then, correct?
i’m not familiar with the Vera Plus so can’t comment on it but this project will definitively give you full wireless control of your alarm system from HA using MQTT or ESPHOME.
