Honeywell Ademco Vista Alarm Panels Plugin via AD2USB

Plugins & Plugin Development Unmaintained
741

Here’s what I’m trying:

A Scene with a trigger of Exit Delay for the alarm panel. (I’ll later use PLEG to differentiate between exit delay and entry delay as I don’t think my panel supports entry delay)

vDev55ID = 55
vDev55Name = "Zone #2 - Front Door"
local vDev55Tripped = luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1", "Tripped", vDev55ID)
local vDev55LastTrip = luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1", "LastTrip", vDev55ID)
if (vDev55Tripped == "1") then
  luup.call_action("urn:upnp-org:serviceId:IOSPush1", "SendProwlNotification", {Event= alarmstate, Description=tostring(vDev55Name), Priority=2, URL=tmp_url}, 378)
end

vDev56ID = 56
vDev56Name = "Zone #3 - Laundry Door"
local vDev56Tripped = luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1", "Tripped", vDev56ID)
local vDev56LastTrip = luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1", "LastTrip", vDev56ID)
if (vDev56Tripped == "1") then
  luup.call_action("urn:upnp-org:serviceId:IOSPush1", "SendProwlNotification", {Event= alarmstate, Description=tostring(vDev56Name), Priority=2, URL=tmp_url}, 378)
end

vDev57ID = 57
vDev57Name = "Zone #4 - Front Garage Entry"
local vDev57Tripped = luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1", "Tripped", vDev57ID)
local vDev57LastTrip = luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1", "LastTrip", vDev57ID)
if (vDev57Tripped == "1") then
  luup.call_action("urn:upnp-org:serviceId:IOSPush1", "SendProwlNotification", {Event= alarmstate, Description=tostring(vDev57Name), Priority=2, URL=tmp_url}, 378)
end

I prefer this because it appears it will create less traffic and use less overhead. If the Tripped state proves unreliable, I’ll try compare the LastTrip to NOW and use like 5 seconds.
I have a lot more zones, but I’m only posting a few.

742

I just wanted to come here and write a post of thanks! I’m really impressed with the current plugin.

I’ve been using a custom C# app for a couple years now to deal with RFX and REL messages. I finally took the plunge today and migrated my old Vera1 to Vera2. This means I was able to try the Ademco AD2USB plugin directly. I was surprised to see that I was able to use these things directly with the current version of the plugin. Bravo!

PJJP - If you are trying to use sensors for triggers, you really need to figure out the serial / loop (RFX - for wireless sensors) or configure relay support (REL - for hard-wired sensors). Configuring these things allows for fast, reliable communication of events back to Vera. If you don’t have them, Vera has to watch the display and wait for the name of the faulted zone to appear on the display. This is super slow (progressively slower depending on how many zones are faulted), and not reliable.

If you have SSH access to your vera, you can enable debug mode and search for these events in the log by doing:

cat /var/log/cmh/LuaUPnP.log | grep processExMessage

My entry motion sensor looks like this:

luup_log:120: (VistaAlarmPanel::processExMessage) Decoded RFX message: serial = 0681732, loop 1 = true, loop 2 = true, loop 3 = false, loop 4 = false, flags.unknown2 = false, flags.unknown1 = false, flags.battery = false, flags.supervision = false <0x741c>

My hard-wired door sensor looks like this:

luup_log:120: (VistaAlarmPanel::processExMessage) Decoded REL message: address = 01, channel = 1, faulted = true, supervision = false <0x6817>

RFX messages are easy - you’ll always get them for any wireless sensors. Even ones that are not linked to your panel! REL messages take more work to get, the panel needs to be configured to generate them when the hard-wired zones are faulted. Check out the AD2USB forums for more information on that. This also removes the differences in behavior when the panel is or isn’t armed.

743

[quote author=sound-mind link=topic=7266.msg111295#msg111295 date=1367447129]

[quote author=M2MExpert link=topic=7266.msg111288#msg111288 date=1367444529]

[code] luup.log("SRS: setting fifteen second delay then executing StorePinCode") luup.call_delay('callonme',15) function callonme() luup.log("SRS: delay over, executing StorePinCode") luup.call_action("urn:micasaverde-com:serviceId:VistaAlarmPanel1", "StorePinCode", { PINCode="XXXX"}, PARTITION_DEV_NUM) end [/code]

Hi guys
Just trying to mirror the same for my setup…in the code above, what is PARTITION_DEV_NUM ? If i have just one partition, what would that be?

Thank you

744

@djrobx, thanks for your reply.

I do have relays configured and working well. However, it’s still not quick enough. I think i need to try adding a five second delay so the trip gets logged before I try to send an alert.

745

You should not need to do that. One thing I did notice - if you are using relays, use a fake zone number that doesn’t exist in the cheat sheet. When I used the real zone numbers, I think the old “display based” detection code confused the relay trigger code, and the detections were sloppy and would seemingly get stuck in the tripped state.

With just relays specified along with fake zone numbers (100+), the activity sensors are instant - when I open the door, the action figure in the UI changes, and as soon as I close the door, it goes back to the closed state.

746

@djrobx,

I’m totally confused. I use relays for my hard-wired zones. I also have wireless zones. My cheatsheet is filled out with serial numbers and loops. Where would I use the fake zone?

747

[quote=“PJJP, post:746, topic:168766”]@djrobx,

I’m totally confused. I use relays for my hard-wired zones. I also have wireless zones. My cheatsheet is filled out with serial numbers and loops. Where would I use the fake zone?[/quote]

I am not sure if you figured it out on your own but for anybody else who might be confused: I think what he meant was that if you have zones 01 through 16, you should configure the REL and RFX ones with bogus zone numbers i.e. 101 through 116. This way the plugin is not looking at both the zone number on the display and the relay/rfx serial/loop/address. I have not tried it any other way, but I can confirm that djrobx’s way works flawlessly.

748

[quote=“peterv, post:747, topic:168766”][quote=“PJJP, post:746, topic:168766”]@djrobx,

I’m totally confused. I use relays for my hard-wired zones. I also have wireless zones. My cheatsheet is filled out with serial numbers and loops. Where would I use the fake zone?[/quote]

I am not sure if you figured it out on your own but for anybody else who might be confused: I think what he meant was that if you have zones 01 through 16, you should configure the REL and RFX ones with bogus zone numbers i.e. 101 through 116. This way the plugin is not looking at both the zone number on the display and the relay/rfx serial/loop/address. I have not tried it any other way, but I can confirm that djrobx’s way works flawlessly.[/quote]

Just to confirm, you get notifications of tripped zones wven while armed?

749

[quote=“djrobx, post:745, topic:168766”]You should not need to do that. One thing I did notice - if you are using relays, use a fake zone number that doesn’t exist in the cheat sheet. When I used the real zone numbers, I think the old “display based” detection code confused the relay trigger code, and the detections were sloppy and would seemingly get stuck in the tripped state.

With just relays specified along with fake zone numbers (100+), the activity sensors are instant - when I open the door, the action figure in the UI changes, and as soon as I close the door, it goes back to the closed state.[/quote]

Regarding the fake zone numbers for hardwired zones, as you see in the attcahd pic, I have the address & channel configured to match what I previously ?programmed in the panel. Are you suggesting that I remove the address/channel from these, in the cheat sheet only, create new zones in the cheat sheet only, and add the address and channels there? Do I need to make changes to my alarm panel/virtual relays as well

750

[quote=“PJJP, post:748, topic:168766”][quote=“peterv, post:747, topic:168766”][quote=“PJJP, post:746, topic:168766”]@djrobx,

I’m totally confused. I use relays for my hard-wired zones. I also have wireless zones. My cheatsheet is filled out with serial numbers and loops. Where would I use the fake zone?[/quote]

I am not sure if you figured it out on your own but for anybody else who might be confused: I think what he meant was that if you have zones 01 through 16, you should configure the REL and RFX ones with bogus zone numbers i.e. 101 through 116. This way the plugin is not looking at both the zone number on the display and the relay/rfx serial/loop/address. I have not tried it any other way, but I can confirm that djrobx’s way works flawlessly.[/quote]

Just to confirm, you get notifications of tripped zones wven while armed?[/quote]

I do not have any notifications set up yet, but I can see the sensor changing state in UI while armed.

751
Are you suggesting that I remove the address/channel from these, in the cheat sheet only, create new zones in the cheat sheet only, and add the address and channels there?

I hope I am not speaking out of turn, but I believe that is exactly what he means and certainly what I did. In the cheat sheet, for example for your zone 2 you should clear the address and channel and create a new zone 102 and put the channel there. So for each wired zone you will have two entries.

Do I need to make changes to my alarm panel/virtual relays as well

No, the plugin only seems to be seeing the address and the channel number. The output numbers and output function numbers do not have to correspond to anything. it is just nicer to have them the same as zone numbers so you can keep track of them.

752

I’m also having the exact same problem as mikegk. I’ve actually been having this problem for about a year now and haven’t found anything but I see I’m not the only when anymore. After an alarm, I can silence the alarm from the keypad by entering code+1 but cannot clear the alarm message by entering code+1 again. I can clear the alarm memory message that displays on the keypad from the plugin. I notice that if I enter code+1 from the keypad repeatedly for a few minutes, eventually it clears. I do not have the Envisalink 3. Any thoughts?[/quote]

Hi guys… I have the exact same problem. However, I did a work around… I created a PLEG action that when a disarm is detected from the panel, I send another disarm from the Vera. That clears the alarm… maybe not the more elegant solution, but it works.[/quote]

I am having exact same issue. Based on what skropko said about repeatedly entering code+1 to clear, it seems to me that vera/plugin/ad2usb is polling or otherwise communicating with the security system while person is entering the code and interrupting the entry process. And if somebody tries it enough times, he/she might be able to fit in between these polls.

I would like a real fix as it seems to me that the alarm memory is there for a reason and should not be bypassed.

753

I still cannot get notifications while in Armed mode. All works well in disarm mode.
I removed the address and channel from all my hardwired zones 1-8 on the cheat sheet. I added new “bogus” zones on the cheat sheet beginning with 100, 102, etc. and added the address and channel there. It woks fine and quickly in disarm, but when armed, I get nothing. When armed, upon entering the front door, Ademco plug satus says “ExitDelay”. I expect that. It just does not seem to send any messages while in exit delay.

I really want this to work. If I can’t get it done this way, I may even go the the extent to convert some of these hardwired zones to wireless door sensors, possibly at the panel and use loop 1 so they’ll be hidden. My end game is this: When the alarm is armed, I want a notification of what sensor is tripped before the siren sounds. I also want a photo from the appropriate camera snet to my phone is in away mode.

754

I think I know what the issue is. Does anyone have logs after the alarm?

I suspect they will show the plugin sending a * on ever message. It looks like the plugin is not looking at the sticky bit and its a bit odd how it is determining when to send a *. In our open source Python API we send a * only when we see a specific alpha string in the message.

This logic looks solid but if I am reading it correctly it may get confused on the “STICKY_BIT” #10
Protocol - Alarm Decoder Wiki

It would require adding a small change to this file
L_VistaAlarmPanel1.lua in trunk – Honeywell Ademco Vista Alarm Panels via AD2USB

This is just a guess as I do not have a Vera to test with and it leaves questions as to what should be done with a sticky bit is set.
Maybe it should be auto cleared by the plugin.

— /tmp/L_VistaAlarmPanel1.lua.orig 2014-06-09 08:50:54.271655894 -0700
+++ /tmp/L_VistaAlarmPanel1.lua 2014-06-09 08:52:56.212260564 -0700
@@ -570,7 +570,7 @@
g_partitions[partNo].detailedArmMode = “NotReady”

		-- Send '*' to get the faulted zones, but only if the send star flag is set and the alarm is not active.

  •   	if (ssf == true and not flags.FIRE_ALARM and not flags.ALARM) then

  •   	if (ssf == true and not flags.FIRE_ALARM and not flags.ALARM) and not flags.ALARM_MEMORY then
  		luup.call_delay("sendStar", 1, tostring(partNo))
  	end
  end

Re
Sean M

755

I did some digging and I do not see any relay messages coming from the security system for sensors that are in entry delay mode. What you want to do might not be possible. It is not a limitation of the plugin or ad2usb but a limitation of the Vista security system.

756

[quote=“mathewss, post:754, topic:168766”]I think I know what the issue is. Does anyone have logs after the alarm?

I suspect they will show the plugin sending a * on ever message. It looks like the plugin is not looking at the sticky bit and its a bit odd how it is determining when to send a *. …[/quote]

Looking at the trunk I found that hugheaves already try to address the issue with the DisableSendStar variable in http://code.mios.com/trac/mios_vista-alarm-panel-ad2usb/browser/tags/3.0/S_VistaAlarmPanel1.xml. The note says

Added "DisableSendStar?" setting that disables sending "*" to the panel. (Sending "*" from Vera can interfere with manual alarm operation from the keypad)

I see that the trunk is version 3.0. The version downloadable from MIOS is 2.45. I would test it only if I knew how to either edit the the .lua file on my system or download the latest version.

Edit: I see the version of Honeywell Ademco Vista Alarm Panels via AD2USB as 3.10 in My Apps. However I cannot find the “DisableSendStar” variable anywhere. Also the version reported in the advanced configuration of the plugin is 2.45. <= Is that a variable I can change and get access to 3.x variables? Edit: <= No it isn’t :slight_smile: it reverted right back.

757

I’m afraid you may be correct. So, I may convert my wired zoned to wireless or possiblly even duplicate keeping both wired and wireless. I have plenty of extra wireless snesors.

758

Dealing with an interesting problem. I had the AD2USB device installed and working beautifully. For specific reasons, replaced it with the AD2PI Network Appliance. Got it hooked up to my Vista 20P and it worked without any issues. In the AD2USB plugin, I placed the IP address and port number (10000) in the serial port configuration. Everything works. Now for the interesting part. It only works if I leave the old AD2USB connected to the USB port as when disconnect, the configuration is not accessible.

What is the correct way to configure the plugin over IP without the need to keep the AD2USB connected?

Any suggestion appreciated.

JR

759

I hope you folks start a new thread on the ad2pi because I have a million questions. For now I will try to find a configuration picture to see if it helps me any.

I notice in the picture that it is set for 9600 baud. I can’t see how that would be the issue mentioned, but it sure stands out like a sore thumb.

760

[quote=“pentium, post:759, topic:168766”]I hope you folks start a new thread on the ad2pi because I have a million questions. For now I will try to find a configuration picture to see if it helps me any.

I notice in the picture that it is set for 9600 baud. I can’t see how that would be the issue mentioned, but it sure stands out like a sore thumb.[/quote]

pentium - that is good idea. I will do that later today. To answer your question, I have tried different baud rates. It doesn’t matter. As the connection to the panel is via the AD2PI, the USB/Serial communication parameters have not effect outside of enabling the IP/Port parameters.

JR