Did you try reading back a few pages and use the instructions in my post not fix the issue?
http://forum.micasaverde.com/index.php/topic,7266.msg209964.html#msg209964
I did try that and didn’t see any change. The system worked but I kept getting the error.
What firmware rev?
Is this a new install?
I’ve got the latest firmware for the AD2USB and I’m also running the latest Vera3 firmware 7.1.569.
It’s not a new install, I’ve had it for over a year, but I just upgraded my Vera3 to UI7. I’m in a mood to play with the Vera right now so I have done the upgrade and tried getting everything back to fully functional. So far this little bug and an issue with a few of my Zwave devices changing identifiers for Homewave were my worst issues. I’m also trying to get the AD2USB to work through a RaspberryPi I had laying around to see how that works. Currently it doesn’t work but I replied to the network thread with a log snippet to see if I can help mcv.andrei get that working also.
[quote=“xuniman, post:924, topic:168766”]I’ve got the latest firmware for the AD2USB and I’m also running the latest Vera3 firmware 7.1.569.
It’s not a new install, I’ve had it for over a year, but I just upgraded my Vera3 to UI7. I’m in a mood to play with the Vera right now so I have done the upgrade and tried getting everything back to fully functional. So far this little bug and an issue with a few of my Zwave devices changing identifiers for Homewave were my worst issues. I’m also trying to get the AD2USB to work through a RaspberryPi I had laying around to see how that works. Currently it doesn’t work but I replied to the network thread with a log snippet to see if I can help mcv.andrei get that working also.[/quote]
I’m not familiar with your approach with the RPi, but I have three of them, so I’m interested in hearing what you’re your doing.
What I’m trying to eliminate is a problem with wiring and the ad2usb itself. If it works with something else as-is (RPi or minicom or…), then it does leave us with the Vera.
The only difference between your setup and mine is that I have a Vera Edge and you have the Vera 3. Hopefully that isn’t the source of the problem.
Edit: I found the thread about the RPi setup. ser2net should have known that would be how it is used. I was thinking more along the lines of a custom image for an touchscreen LCD cape/hat/thingie.
[quote=“sound-mind, post:925, topic:168766”][quote=“xuniman, post:924, topic:168766”]I’ve got the latest firmware for the AD2USB and I’m also running the latest Vera3 firmware 7.1.569.
It’s not a new install, I’ve had it for over a year, but I just upgraded my Vera3 to UI7. I’m in a mood to play with the Vera right now so I have done the upgrade and tried getting everything back to fully functional. So far this little bug and an issue with a few of my Zwave devices changing identifiers for Homewave were my worst issues. I’m also trying to get the AD2USB to work through a RaspberryPi I had laying around to see how that works. Currently it doesn’t work but I replied to the network thread with a log snippet to see if I can help mcv.andrei get that working also.[/quote]
I’m not familiar with your approach with the RPi, but I have three of them, so I’m interested in hearing what you’re your doing.
What I’m trying to eliminate is a problem with wiring and the ad2usb itself. If it works with something else as-is (RPi or minicom or…), then it does leave us with the Vera.
The only difference between your setup and mine is that I have a Vera Edge and you have the Vera 3. Hopefully that isn’t the source of the problem.
Edit: I found the thread about the RPi setup. ser2net should have known that would be how it is used. I was thinking more along the lines of a custom image for an touchscreen LCD cape/hat/thingie.[/quote]
He is using alarmdecoder webapp and ser2sock to share his ad2 on his network, and the vera is then able to connect to the ser2sock instance as the “serial port device” required for the ad2usb plugin. This means ad2pi and ad2serial could also be used. As well as multiple devices (not just the vera) are able to use the device at the same time. Endless fun could be had from many different angles. Plus the webapp has a pretty robust keypad.
Exactly Kevin. I was looking to be able to see the AD2USB log without having to SSH into the Vera and shut down the LUUP engine. I have recently set up the virtual relays and added some wireless sensors that aren’t enrolled in the panel (they are just for Vera triggers). During testing it was a pain to see the AD2 logs directly. Since I was one of the people who tried this method last year when Nutech first released the webapp I thought I’d give it a try now. It seems that some combination of UI7 and the plugin lua file have issues currently that make this unusable. I’m going to keep trying to help in the other thread if mcv.andrie returns.
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?
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
[quote=“dlemmink, post:928, topic:168766”]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?[/quote]
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
[quote=“kand, post:929, topic:168766”]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[/quote]
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.
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
[quote=“kevinnutech, post:930, topic:168766”][quote=“dlemmink, post:928, topic:168766”]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?[/quote]
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[/quote]
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
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 -
[quote=“mcv.andrei, post:934, topic:168766”]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 -[/quote]
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
[quote=“dlemmink, post:928, topic:168766”]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?[/quote]
[quote=“kevinnutech, post:930, topic:168766”][quote=“dlemmink, post:928, topic:168766”]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?[/quote]
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[/quote]
Actually, unless I’m getting the bit order incorrect, bit 1 (aka the least significant bit) is clear on both of these messages.
[tt] bit: 8765 4321
0xa0 → 1010 0000
0x84 → 1000 0100[/tt]
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.
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
[quote=“hugheaves, post:936, topic:168766”][quote=“dlemmink, post:928, topic:168766”]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?[/quote]
[quote=“kevinnutech, post:930, topic:168766”][quote=“dlemmink, post:928, topic:168766”]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?[/quote]
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[/quote]
Actually, unless I’m getting the bit order incorrect, bit 1 (aka the least significant bit) is clear on both of these messages.
[tt] bit: 8765 4321
0xa0 → 1010 0000
0x84 → 1000 0100[/tt]
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.
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[/quote]
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 
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 -
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.
[quote=“hugheaves, post:936, topic:168766”][quote=“dlemmink, post:928, topic:168766”]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?[/quote]
[quote=“kevinnutech, post:930, topic:168766”][quote=“dlemmink, post:928, topic:168766”]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?[/quote]
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[/quote]
Actually, unless I’m getting the bit order incorrect, bit 1 (aka the least significant bit) is clear on both of these messages.
[tt] bit: 8765 4321
0xa0 → 1010 0000
0x84 → 1000 0100[/tt]
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.
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[/quote]
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: e[35;1mLastTripe[0m 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: e[35;1mTrippede[0m 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>