Honeywell Ademco Vista Alarm Panels Plugin via AD2USB

I have done a lot of testing and experimenting over the weekend and have determined that the issue with devices showing up as motions is due to the way the code is written, it creates all zones as motions, it will also append any changes to the device_type, and device_file every time luup is restarted. There is no complete fix to this issue unless someone smarter than me can fix the code in the plugin to add a device type column to the cheat sheet and then modify the code to assign the correct information accordingly. Currently the code is written only for motion types.

There is a work around that seems to be working for me. You can change the catagory_num, subcategory _num, and the device_file fields under advanced and they will remain without changing back. This does fix the main page icons and what they are categorized as, but once you go into the device it will still look like a motion and scene creation still have motion choices. It is an acceptable work around. If you change the device_type it will fix the internal icon and the scene creation choices, but as soon as you reload the luup engine, you will lose all that work you did so not worth doing that in my opinion.
Example: to change a device from the default motion setting to a door. Go into the advanced tab for the device, set catagory_num to 4, subcategory_num to 1, and device_json to D_DoorSensor1.json

Hopefully someone with coding experience can fix the plugin with a device type column and associated coding to make them correct, but there is for sure no error in anyone?s setup, I read through the code and unfortunately that motion assignment is what it is written to do.

Anyone still grappling with this? In UI5, the “motion sensor” would remain tripped. I could then use it in my PLEG but now it resets to “untripped” for a duration depending on my TTL.

I used this trigger extensively before. Any suggestions would be awesome!

Hey Guys,

I have an issue that I tried searching through this post to find a solution but was didn’t see it. Given the life of this thread it seems to be the best one to ask on.

I’ve had my Veras for 8 years and I used to have a GE Caddax system connected. I’ve recently switched over to a Vista 20P and have it talking to my Vera just fine.

When I arm or disarm, open/close zones, everything is great.

My issue is when the system is armed and a Perimeter zone (such as a window) is opened. The 20p alarms correctly and the Vera sees that. When I disarm the system the alarm stops but the Zone is stuck in ALARM. I’m unable to clear it by entering my alarm code twice.

When I disconnect the AD2USB and perform the same test everything on the keypad works and the system goes back to ready state.

I only have 1 Keypad and it’s on address 16 and the AD2USB is default on 18. I do have 3 zone expanders (4229s) connected but they are address 7, 8, & 9. So I’m not sure quite what the issue could be. Most other postings are with systems that have multiple keypads and there is an address conflict.

The Vera Plus is on 1.7.4001 firmware and the app is on 3.12.

I appreciate any assistance that is provided.

*** Update: I thought I had manually updated the LUUP files but I don’t guess I did. After updating the files the system is no longer getting hung up on a zone that tripped. The Vera can still Arm/Disarm the Vista 20P. However, the Vera is now showing “notready” and does not get any status back as for zone or alarm states. So it’s almost like it’s not RXing any status updates now.

*** Update 2: Turned on logging under the device and ran tests like arming/disarming, open/close zones, and also just watched. After every action I see “ERROR: Invlid Message.” Even though the text comes through just fine. It appears there is something that isn’t parsing it correctly. Here are some snippets:

50 08/09/18 20:03:05.717 luup_log:304: (VistaAlarmPanel::processIncoming) Incoming data = ‘[10000001000000003A–],008,[f70000ff1008001c08020000000000]," Ready to Arm "’. <0x73356520>
50 08/09/18 20:03:05.718 luup_log:304: (VistaAlarmPanel::processIncoming) ERROR: Invalid message. <0x73356520>
50 08/09/18 20:03:15.616 luup_log:304: (VistaAlarmPanel::processIncoming) Incoming data = ‘[10000001000000003A–],008,[f70000ff1008001c08020000000000]," Ready to Arm "’. <0x73356520>
50 08/09/18 20:03:15.617 luup_log:304: (VistaAlarmPanel::processIncoming) ERROR: Invalid message. <0x73356520>
50 08/09/18 20:03:24.525 luup_log:304: (VistaAlarmPanel::processIncoming) Incoming data = ‘[00010001000000000A–],002,[f70000ff1002000008020000000000],"FAULT 02 FRONT DOOR "’. <0x73356520>
50 08/09/18 20:03:24.526 luup_log:304: (VistaAlarmPanel::processIncoming) ERROR: Invalid message. <0x73356520>
50 08/09/18 20:03:28.484 luup_log:304: (VistaAlarmPanel::processIncoming) Incoming data = ‘[00010001000000000A–],002,[f70000ff1002000008020000000000],"FAULT 02 FRONT DOOR "’. <0x73356520>
50 08/09/18 20:03:28.485 luup_log:304: (VistaAlarmPanel::processIncoming) ERROR: Invalid message. <0x73356520>
50 08/09/18 20:03:32.469 luup_log:304: (VistaAlarmPanel::processIncoming) Incoming data = ‘[00010001000000000A–],002,[f70000ff1002000008020000000000],"FAULT 02 FRONT DOOR "’. <0x73356520>
50 08/09/18 20:03:32.469 luup_log:304: (VistaAlarmPanel::processIncoming) ERROR: Invalid message. <0x73356520>
50 08/09/18 20:03:36.404 luup_log:304: (VistaAlarmPanel::processIncoming) Incoming data = ‘[00010001000000000A–],002,[f70000ff1002000008020000000000],"FAULT 02 FRONT DOOR "’. <0x73356520>
50 08/09/18 20:03:36.404 luup_log:304: (VistaAlarmPanel::processIncoming) ERROR: Invalid message. <0x73356520>
50 08/09/18 20:03:40.363 luup_log:304: (VistaAlarmPanel::processIncoming) Incoming data = ‘[00010001000000000A–],002,[f70000ff1002000008020000000000],"FAULT 02 FRONT DOOR "’. <0x73356520>
50 08/09/18 20:03:40.364 luup_log:304: (VistaAlarmPanel::processIncoming) ERROR: Invalid message. <0x73356520>
50 08/09/18 20:03:41.803 luup_log:304: (VistaAlarmPanel::processIncoming) Incoming data = ‘[10010001000000003A–],008,[f70000ff1008001c08020000000000]," Ready to Arm "’. <0x73356520>
50 08/09/18 20:03:41.804 luup_log:304: (VistaAlarmPanel::processIncoming) ERROR: Invalid message. <0x73356520>

*** Update 3: So I went back through this thread and found the exact same problem. Not sure if we can get the file updated or not (L_VistaAlarmPanel1.lua in trunk – Honeywell Ademco Vista Alarm Panels via AD2USB).

Here is the post that fixed my issue:

@hugheaves - not sure if this changed in a firmware update I applied to ad2usb, but the regex match in processIncoming() needed to be updated. The first capture is hex, not decimal:

The message from ad2usb:
Code: [Select]
[10000001000000003A–],008,[f70000051008001c08020000000000],"DISARMED Ready to Arm "

Old regex in trunk rev 83:
Code: [Select]
local sections = {data:match(‘^%[([%d%-]+)%],(%x+),%[(%x+)%],“(.+)”$’)}

Updated regex:
Code: [Select]
local sections = {data:match(‘^%[([%x%-]+)%],(%x+),%[(%x+)%],“(.+)”$’)}

Without modifying the regex I was getting “ERROR: Invalid message.”. The only thing it impacted was the system status. Sending commands was still working fine which made me look a little deeper.

@youataknow - in my setup, once the alarm triggers, you need to go the second device that was created by the plugin (the one that has only one button, “Clear” and the version number of the plugin and where you (hopefully) put in the cheat sheet) and press the “Clear” button. This should reset the AD2USB connection and allow you to use the other keypads again. Sometimes you have to do it more than once, but it does work. Once in a while, I have had to resort to unplugging the USB cable, but very rarely.

Not sure why so many people have issues with the AD2USB - I set mine up 8 years ago and have 26 different door, window, motion and other sensors and they work much more reliably than some of my other zwave sensors and switches!

Hope this helps!

htcheng,

Thanks for the tip. That’s a better work around than going into the AV room and rebooting the AD2USB.

I have another issue now that I’m working on if anyone has had this. My Vista20P was setup with 1 keypad (address 16) and all my zones were in that. My AD2USB is on address 18. I’ve ran wiring over to my shop to have an expansion board and another keypad over there. I’ve set the new keypad to 17 and put it in partition 2, along with all the zones. The system works as expected. My problem is with the Vera. As soon as I go in and set it to 2 partitions, to get a 2nd device, my device looses coms again. if I change it back to 1 it works fine. Anyone got 2 partitions to work?

**Update

If I move the alarm panel device back to 1 partition everything returns to normal. However, I currently have partition 2 armed and my partition 1 device in the vera keeps switching between armed (partition 2) and ready (partition 1).

**Update

So I was watching the log and everything was looking fine. Which is weird if the alarm panel device didn’t see the AD2USB. So it appears after I made this device set with 2 partitions I was using my scene to reboot the vera. Which is normally fine. However, the only difference I did while testing and looking at the log was I did physically power cycle the unit. Not sure why that made a difference when changing it from 1 to 2 and back to 1 with a reboot scene allowed it to work again. Anyway I’ll keep an eye on this.

I have a scenario I hope someone can help me with. I?m trying to use one of my wired Ademco Vista motion sensors for some of my scenes. When my alarm system is disarmed, I can use the wired motion sensor to trigger scenes without issue. But when the alarm is armed in stay or night mode, the motion sensor will not trigger my scenes. I think the issue is because when my alarm is armed stay or night mode, the motion sensor is actually bypassed by the programming in my Ademco Vista system.

How can I get Vera to see the wired motion sensor tripped even when the alarm is armed stay/night mode?

The scenario you have occurs because the Honeywell panel will not send partition events to the keypad (AD2USB) if the panel is armed. The exception to this is a monitor zone (zone type 12) which will send events armed or not. The way to get around the problem is to set up a second partition and put only your motion sensors on that partition. You can leave the partition unarmed for most occasions (while your primary partition is armed), which allows it’s sensors to send you data, and if you need to arm the motion sensors, you can then arm your sensor partition as well as your primary partition giving you 100% coverage.

Thanks. I think I understand what you mean. That means I will need the installer code for my alarm panel to get in and set up a secondary partition and place the motion sensor in that and leave everything else in the primary partition, correct? This secondary partition cannot be created by the AD2USB plugin for Vera purposes?

Might be wishful thinking getting the installer code from the monitoring service.

I?m thinking it might be easier to just get another zwave motion sensor instead.

Yes, that’s the way to do it and yes, you need the installer code. The partition is a property of the panel, not AD2USB–which is essentially a keyboard. There are ways to reset the code but it’s best that the alarm company give the code to you so everyone’s on the same page. Partitions are typically used when you have two or even three areas that need different security requirements, for a given overall coverage environment. It is no more difficult for the monitoring company to monitor one partition or three. They are monitoring the panel state, not specific zones or partitions.

It’s a fairly straight forward process to modify the panel. Lots of sequential button presses, but very doable. All the manuals are on the internet, and if you follow the step by step, it should not be too difficult.

Thanks Buxton for your explanation.

[quote=“htcheng, post:1004, topic:168766”]Not sure why so many people have issues with the AD2USB - I set mine up 8 years ago and have 26 different door, window, motion and other sensors and they work much more reliably than some of my other zwave sensors and switches![/quote]I strongly suspect they have something else going on that’s causing luup to restart often.

I have had an ad2usb going for many years as well. The device itself is extremely reliable, more so than my old Vera 2 was (crashes due to out of memory become an issue). I eventually programmed my Vera to reboot every day as a preventative measure. Once I did that, maybe 1-3 times a month I’d see a “AD2USB connection down” error. It just sometimes didn’t “open” properly after the reboot. Restarting Luup would fix it every tine.

So if someone has a system where luup resets itself more often, they will see issues more frequently. The AD2USB plugin never attempts to retry if there are issues with the connection. I eventually replaced my vera with a new VeraPlus which hopefully won’t need to be rebooted as often. I haven’t seen connection down yet, but time will tell. If it becomes a thing again I’ll probably look at periodically checking for the error and restarting luup if it’s there. Would be better if retry logic was built into the plugin, though.

After moving to a VeraPlus, I notice the plugin now misses events a lot. For example, right now it’s showing my patio door sensor is tripped open, but the door is closed (and the panel knows it is closed). This never happened on a Vera2 with UI5 in the same config.

After moving to a VeraPlus, I notice the plugin now misses events a lot.
I am having the same issue. My TTL is set to 10 seconds