We have moved at community.getvera.com

Author Topic: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB  (Read 365494 times)

Offline kevinnutech

  • Jr. Member
  • **
  • Posts: 55
  • Karma: +2/-0
Re: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB
« Reply #930 on: June 15, 2015, 11:08:27 pm »
ok, I've beat my brain and exhausted my search capabilities to try to get this thing working and am coming up empty.       Vera Edge, on latest firmware (1.7.1181)     I just added a new AD2USB.
I connected to the AD2USB and set the address to 31  (Vista20se), and confirm it is talking to the panel.

Installed the plugin for the AD2USB (ver 3.12) and go two devices created.   One is the panel, one is partition 1
I then went into the Partition 1 device and set the keyboard address variable to 31.
My dashboard shows the panel device with error "Can't detect device"
the partition 1 device appears without errors but if I try to change the alarm status, I get error "Device communication failure"
The UI also shows "Vista Alarm Panel: Connection down" at the top.

I found some much older posts regarding configuring the serial port, but I get to that screen and it says
"if you connected the USB/serial device and it's not displayed here, reload Luup", and it's not listed there, and reloading Luup doesn't change anything.

I've deleted devices multiple times and started over, power reset the AD2USB and the Vera as well.

I see others have this working with the Vista 20se so I know there is hope !!!     Any suggestions are appreciated.

Thanks

Contact Vera about a software update that will update the USB drivers on your Vera Edge - this will allow the Edge to detect the AD2USB correctly, and you can then go to the serial port configuration screen properly.

Offline kand

  • Newbie
  • *
  • Posts: 8
  • Karma: +0/-0
Re: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB
« Reply #931 on: June 16, 2015, 08:52:52 am »
Thank You!      I will be contacting them today.

contacted Vera support,  5 rings... answer, they connected remotely and updated the drivers.    when I checked, still no USB device showing, so one more call and they took care of it.
I now have control over the alarm, and off to experiment with zones and other features.

thanks again
« Last Edit: June 16, 2015, 09:15:47 pm by kand »

Offline hugheaves

  • Full Member
  • ***
  • Posts: 241
  • Karma: +11/-0
Re: RFX! Errors
« Reply #932 on: June 16, 2015, 09:43:45 am »
I keep getting false triggers with my AD2USB interface. I get a tripped response in Vera sometimes even when the door sensor on my alarm is closed.
Looking at the logs:
Normally I get an RFX! (id),a0 to indicate open and RFX! (id),80 when the door is closed.
The false triggers have been trace to a RFX! (id), 84.  It appears that response is undefined, but triggers a tripped in Vera.
Is there a way to make the plugin ignore those messages?

Protocol documentation states that if bit 1 is set in the RFX Message then the loop indicators should be ignored.  Vera needs to update plugin to address this.  http://www.alarmdecoder.com/wiki/index.php/Protocol#RFX

To be fair, the old documentation (on which the plug-in was based) didn't mention that messages with bit 1 set should be ignored, merely that its function was "UNKNOWN at this time". Nonetheless, somebody needs to fix the plug-in. As I wrote the RFX / REL / EXP portion of the plug-in, I'd be happy to fix it, but I don't know if Vera would rather do it as they've made some further changes since I submitted mine.

(Original doc here:)
http://archive.nutech.com/index.php?option=com_fireboard&Itemid=0&func=view&catid=4&id=5

bit Meaning
============
1 UNKNOWN at this time
2 battery
3 supervision
4 UNKNOWN at this time
5 loop 3
6 loop 2
7 loop 4
8 loop 1

The HA "collection" so far: MiCasaVerde: 1x VeraLite, RTCOA: 3x 3M-50, GE: 1x 45606, 3x 45613, 5x 54614, Kwikset: 1x 99100-004, Intermatic: 6x CA3000, 6x CA600, 8x HA01, 2x HA02, 12x HA03, 2x HA04, 3x HA05,  6x HA07, 7x HA09, Honeywell: 1x Vista 20P, NuTech: 1x AD2USB

andreimios

  • Guest
Re: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB
« Reply #933 on: June 16, 2015, 10:03:16 am »
Hi hugheaves,

I updated the plugin and tried to include the fix you did for "overnetwork" so users will have the both versions on the same plugin. I did it because we got some requests for this and I didn't know if you want to do it yourself, you didn't response to my PM. It would be batter if you want to make the changes, I don't have the alarm panel in order to test.
So if you still want to maintain the plugin, there is no problem from our side.

All the Bests,

- Andrei -

Offline hugheaves

  • Full Member
  • ***
  • Posts: 241
  • Karma: +11/-0
Re: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB
« Reply #934 on: June 16, 2015, 10:50:24 am »
Hi hugheaves,

I updated the plugin and tried to include the fix you did for "overnetwork" so users will have the both versions on the same plugin. I did it because we got some requests for this and I didn't know if you want to do it yourself, you didn't response to my PM. It would be batter if you want to make the changes, I don't have the alarm panel in order to test.
So if you still want to maintain the plugin, there is no problem from our side.

All the Bests,

- Andrei -

Sorry for not responding to your PM. I just now looked, and realized I'd missed it!

I can take a more active roll in maintaining this plug-in if you like. A couple of quick questions though:

What is the license for the existing source code? Is it GPLv2, V3, or something else? (MiOS proprietary?)

Where are we on UI7 support for this plug-in? I haven't worked with UI7 yet, so I'd need to get 'up to speed' to maintain a UI7 version as well. I wasn't sure if the current version was even intended to support UI7.

Hugh
The HA "collection" so far: MiCasaVerde: 1x VeraLite, RTCOA: 3x 3M-50, GE: 1x 45606, 3x 45613, 5x 54614, Kwikset: 1x 99100-004, Intermatic: 6x CA3000, 6x CA600, 8x HA01, 2x HA02, 12x HA03, 2x HA04, 3x HA05,  6x HA07, 7x HA09, Honeywell: 1x Vista 20P, NuTech: 1x AD2USB

Offline hugheaves

  • Full Member
  • ***
  • Posts: 241
  • Karma: +11/-0
Re: RFX! Errors
« Reply #935 on: June 16, 2015, 03:22:07 pm »
I keep getting false triggers with my AD2USB interface. I get a tripped response in Vera sometimes even when the door sensor on my alarm is closed.
Looking at the logs:
Normally I get an RFX! (id),a0 to indicate open and RFX! (id),80 when the door is closed.
The false triggers have been trace to a RFX! (id), 84.  It appears that response is undefined, but triggers a tripped in Vera.
Is there a way to make the plugin ignore those messages?

I keep getting false triggers with my AD2USB interface. I get a tripped response in Vera sometimes even when the door sensor on my alarm is closed.
Looking at the logs:
Normally I get an RFX! (id),a0 to indicate open and RFX! (id),80 when the door is closed.
The false triggers have been trace to a RFX! (id), 84.  It appears that response is undefined, but triggers a tripped in Vera.
Is there a way to make the plugin ignore those messages?

Protocol documentation states that if bit 1 is set in the RFX Message then the loop indicators should be ignored.  Vera needs to update plugin to address this.  http://www.alarmdecoder.com/wiki/index.php/Protocol#RFX

Actually, unless I'm getting the bit order incorrect, bit 1 (aka the least significant bit) is clear on both of these messages.
    bit: 8765 4321
0xa0 -> 1010 0000
0x84 -> 1000 0100


It looks like the 0x84 message has the supervisory bit set, and for these types of messages I still use the loop status bits to update the state of all the loops in case a prior transmission was lost. In this particular case, it looks like the door sensor is using loop 2, and the 0x84 message is just reaffirming that the door is in fact closed.

@dlemmink,

I'm not sure what's going on here, but a section of the logs after the 0x84 message is received would be helpful to diagnose the issue.

Hugh


The HA "collection" so far: MiCasaVerde: 1x VeraLite, RTCOA: 3x 3M-50, GE: 1x 45606, 3x 45613, 5x 54614, Kwikset: 1x 99100-004, Intermatic: 6x CA3000, 6x CA600, 8x HA01, 2x HA02, 12x HA03, 2x HA04, 3x HA05,  6x HA07, 7x HA09, Honeywell: 1x Vista 20P, NuTech: 1x AD2USB

Offline kevinnutech

  • Jr. Member
  • **
  • Posts: 55
  • Karma: +2/-0
Re: RFX! Errors
« Reply #936 on: June 16, 2015, 09:42:20 pm »
I keep getting false triggers with my AD2USB interface. I get a tripped response in Vera sometimes even when the door sensor on my alarm is closed.
Looking at the logs:
Normally I get an RFX! (id),a0 to indicate open and RFX! (id),80 when the door is closed.
The false triggers have been trace to a RFX! (id), 84.  It appears that response is undefined, but triggers a tripped in Vera.
Is there a way to make the plugin ignore those messages?

I keep getting false triggers with my AD2USB interface. I get a tripped response in Vera sometimes even when the door sensor on my alarm is closed.
Looking at the logs:
Normally I get an RFX! (id),a0 to indicate open and RFX! (id),80 when the door is closed.
The false triggers have been trace to a RFX! (id), 84.  It appears that response is undefined, but triggers a tripped in Vera.
Is there a way to make the plugin ignore those messages?

Protocol documentation states that if bit 1 is set in the RFX Message then the loop indicators should be ignored.  Vera needs to update plugin to address this.  http://www.alarmdecoder.com/wiki/index.php/Protocol#RFX

Actually, unless I'm getting the bit order incorrect, bit 1 (aka the least significant bit) is clear on both of these messages.
    bit: 8765 4321
0xa0 -> 1010 0000
0x84 -> 1000 0100


It looks like the 0x84 message has the supervisory bit set, and for these types of messages I still use the loop status bits to update the state of all the loops in case a prior transmission was lost. In this particular case, it looks like the door sensor is using loop 2, and the 0x84 message is just reaffirming that the door is in fact closed.

@dlemmink,

I'm not sure what's going on here, but a section of the logs after the 0x84 message is received would be helpful to diagnose the issue.

Hugh

You are correct and that is correct behavior - in a rush I used MSB instead of LSB, my bad.  Regardless it is a good time to bring up the known protocol change.  As far as anything on archive.nutech.com - that is for historical purposes and years out of date - alarmdecoder.com is the official place for anything ad2 related.   A new firmware is in the works and there will be protocol additions as well as proper DSC panel support for the device.  Documentation will be updated in the wiki on alarmdecoder.com :)
« Last Edit: June 16, 2015, 09:46:34 pm by kevinnutech »

andreimios

  • Guest
Re: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB
« Reply #937 on: June 17, 2015, 05:05:14 am »
Hi Hugh,

I don't know exactly the full story for the plugin, but i can tell you the short version : initially it was developed by MiOS but after that was maintained by community. It is an open source project and as long as you use our repository( you are already listed as contributor on both code and apps) there is no problem if you maintain/improve the plugin.
Regarding the UI7 support for plugins, you shouldn't worry about, there are minor changes that needs to be done to migrate a plugin and I can assist you with this. We can discuss more via Skype/email/PM.

Best Regards,

- Andrei -

Offline kand

  • Newbie
  • *
  • Posts: 8
  • Karma: +0/-0
Re: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB
« Reply #938 on: June 17, 2015, 01:11:33 pm »
I am trying to set up the zones in the cheat sheet, but unsure of the two fields for Address and Loop/channel are required or from where get them.     
It is for a Vista 20se panel and I do have the original configuration sheet with zone information some of which are wired and a few wireless.
Is just a zone number required, or do I need the other fields?   
It lets me enter all the zones but I do not get any additional devices created in Vera
(Vera edge, latest firmware)     
---UPDATE--   seems I stumbled on the correct way.     I went back to the alarm panel device and changed the "automatically configure" parameter from "yes" to "Default" and when I saved that, the devices entered in the cheat sheet all got created. 
« Last Edit: June 18, 2015, 10:02:02 pm by kand »

Offline dlemmink

  • Newbie
  • *
  • Posts: 8
  • Karma: +0/-0
Re: RFX! Errors
« Reply #939 on: June 20, 2015, 06:40:54 pm »
I keep getting false triggers with my AD2USB interface. I get a tripped response in Vera sometimes even when the door sensor on my alarm is closed.
Looking at the logs:
Normally I get an RFX! (id),a0 to indicate open and RFX! (id),80 when the door is closed.
The false triggers have been trace to a RFX! (id), 84.  It appears that response is undefined, but triggers a tripped in Vera.
Is there a way to make the plugin ignore those messages?

I keep getting false triggers with my AD2USB interface. I get a tripped response in Vera sometimes even when the door sensor on my alarm is closed.
Looking at the logs:
Normally I get an RFX! (id),a0 to indicate open and RFX! (id),80 when the door is closed.
The false triggers have been trace to a RFX! (id), 84.  It appears that response is undefined, but triggers a tripped in Vera.
Is there a way to make the plugin ignore those messages?

Protocol documentation states that if bit 1 is set in the RFX Message then the loop indicators should be ignored.  Vera needs to update plugin to address this.  http://www.alarmdecoder.com/wiki/index.php/Protocol#RFX

Actually, unless I'm getting the bit order incorrect, bit 1 (aka the least significant bit) is clear on both of these messages.
    bit: 8765 4321
0xa0 -> 1010 0000
0x84 -> 1000 0100


It looks like the 0x84 message has the supervisory bit set, and for these types of messages I still use the loop status bits to update the state of all the loops in case a prior transmission was lost. In this particular case, it looks like the door sensor is using loop 2, and the 0x84 message is just reaffirming that the door is in fact closed.

@dlemmink,

I'm not sure what's going on here, but a section of the logs after the 0x84 message is received would be helpful to diagnose the issue.

Hugh


Logs from the particular event.   It seems to be a supervisory function but triggers a tripped status.  Event occurs about every hour with my system on each of the sensors.

50   06/20/15 18:20:57.886   luup_log:415: (VistaAlarmPanel::processIncoming) Incoming data = '!RFX:0941315,84'. <0x312f8680>
50   06/20/15 18:20:57.887   luup_log:415: (VistaAlarmPanel::processExMessage) Decoded RFX message: serial = 0941315, loop[1] = true, loop[2] = false, loop[3] = false, loop[4] = false, flags.unknown2 = false, flags.unknown1 = false, flags.battery = false, flags.supervision = true <0x312f8680>
50   06/20/15 18:20:57.888   luup_log:415: (VistaAlarmPanel::updateZoneByAddress) Looking for zone, address = 0941315, channel = 1 <0x312f8680>
50   06/20/15 18:20:57.888   luup_log:415: (VistaAlarmPanel::updateZoneByAddress) Found zone 12, setting faulted to true <0x312f8680>
06   06/20/15 18:20:57.889   Device_Variable::m_szValue_set device: 419 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: LastTrip was: 1434834606 now: 1434838857 #hooks: 0 upnp: 0 skip: 0 v:0xe0bdb0/NONE duplicate:0 <0x312f8680>
06   06/20/15 18:20:57.890   Device_Variable::m_szValue_set device: 419 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 1 #hooks: 4 upnp: 0 skip: 0 v:0xe3bbd0/NONE duplicate:0 <0x312f8680>
07   06/20/15 18:20:57.891   Event::Evaluate 49  scene Alarm - Back Door Opened is true users: allow:1 <0x312f8680>
08   06/20/15 18:20:57.891   Scene::RunScene running 111 Alarm - Back Door Opened <0x312f8680>

Offline adamjs83

  • Sr. Newbie
  • *
  • Posts: 21
  • Karma: +0/-3
Re: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB
« Reply #940 on: June 26, 2015, 09:27:55 pm »
Can anyone tell me if there is a known method to get the ad2usb recognized by a Vera Edge running ui7?  I have one set up and connected to my panel and the edge is not recognizing that there is a serial port.  I tried searching but I can't find anything definitive on this subject.
Thanks

Offline kand

  • Newbie
  • *
  • Posts: 8
  • Karma: +0/-0
Re: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB
« Reply #941 on: June 26, 2015, 10:02:33 pm »
yes,  I had the same issue.....    about 10 posts prior.

Contact Vera support.   they need to update the USB drivers for you.

Call them... they will have you enable remote support and do it in a few minutes

Offline copekyle

  • Jr. Member
  • **
  • Posts: 99
  • Karma: +1/-5
Re: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB
« Reply #942 on: July 03, 2015, 11:16:36 pm »
So this plug in locked up on me in the worst moment ever.  We just left on vacation and my vera is showing connection down.  I was using the plug in fine but then I armed my system from the physical panel when I left my home today and now my dashboard shows the connection is down and the status of the alarm panel is "exitdelay"... can anyone help me troubleshoot this problem asap?

Edit: (vacation over)  Came home and found my Vista20P powered completely off.  Went to work troubleshooting.  It seems that my 12V terminals were overloaded, I unplugged one of my panels and the system came back up.  It showed an alarm state pointing to one of my windows.  As luck would have it (not), one of my magnets fell off while I was gone.  It seems that the system triggered the siren and then didn't have enough power to operate and completely shut down.  Lesson learned.
« Last Edit: July 06, 2015, 10:48:05 am by copekyle »

Offline sound-mind

  • Sr. Newbie
  • *
  • Posts: 44
  • Karma: +1/-1
Re: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB
« Reply #943 on: July 07, 2015, 06:03:00 pm »
The devices section of the UI 7 interface indicates my plugin 2.45. Under My Apps it indicates the current version is 3.12. I have auto updates on and it doesn't update to that version.

I noted this commit by Hugh in SVN:
http://code.mios.com/trac/mios_vista-alarm-panel-ad2usb/changeset?reponame=&new=83%40trunk%2FL_VistaAlarmPanel1.lua&old=82%40trunk%2FL_VistaAlarmPanel1.lua

Which includes an update for the VERSION var from 2.45 to 3.89. Then I looked at the diff between r77 and r83 and didn't see any other version changes:
http://code.mios.com/trac/mios_vista-alarm-panel-ad2usb/changeset?old_path=%2Ftrunk&old=77&new_path=%2Ftrunk&new=83

So questions:
1. Where is the UI under My Apps getting the 3.12 from? Is that not tied to the VERSION variable in the code, i.e., it is specific to Apps not the code itself?

2. Am I correct in assuming that that is inaccurate, and the released version would still indicate 2.45 until this update to v3.89 is released? If it is inaccurate, where is the 3.12 coming from and should it be filed as a bug to support?

EDIT: looking at another thread it appears other people are on 3.0+/ I guess another question would be, why am I stuck on 2.45 even if I have auto update checked? Back on UI 5 I manually updating to a beta version via SSH but I'd prefer to avoid that and fix it properly.

TIA
« Last Edit: July 07, 2015, 06:07:14 pm by sound-mind »

Offline cybrmage

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1104
  • Karma: +113/-43
Re: Honeywell Ademco Vista Alarm Panels Plugin via AD2USB
« Reply #944 on: July 07, 2015, 06:37:12 pm »
Edit: (vacation over)  Came home and found my Vista20P powered completely off.  Went to work troubleshooting.  It seems that my 12V terminals were overloaded, I unplugged one of my panels and the system came back up.  It showed an alarm state pointing to one of my windows.  As luck would have it (not), one of my magnets fell off while I was gone.  It seems that the system triggered the siren and then didn't have enough power to operate and completely shut down.  Lesson learned.

The joys of power-limited aux power terminals... At least it didn't fry your panel...

The aux power terminals are limited to 600ma... If you are using them to power all your keypads/AUIs, you can easily overload them... and, as you discovered, bad things happen...

Ideally, you should only be powering zone devices (a single PIR uses 10-30ma), zone expanders (4219 uses 30ma) and a single keypad (a 6160 150ma, 6160RF uses 180ma, don't try to power a TuxWifi as it uses 310ma)...
Additional keypads (such as the TuxWifi) and other non essential devices should be powered from a supplementary power supply (with the ground terminals interconnected)... My preferred choice is a 12VDC 5AH power supply designed for access control use... It provides up to 5000ma and can have it's own backup battery connected..

« Last Edit: July 07, 2015, 06:39:42 pm by cybrmage »