Hi all,
I have been using Veralite and the AD2USB for a few years now with a few small hiccups. This last hiccup has turned into me losing some hair in trying to solve the issue.
In the Vera?s current state I cannot successfully arm my Visa 20P via the AD2USB connection. Clicking on arm or any other buttons in the Vera devices doesn?t report and error messages or change the color of the button to green. In the past this generally meant that my pin code wasn?t stored. I do get a success when I store the pin.
My scenes that involve the sensors are all working so there is communication between vera and the panel. I have been able to randomly disarm the system through the vera interface. I?ll arm my house and then click disarm in vera and sometimes it disarms right away. Other times I have to click the button multiple times and it finally disarms. It will never arm in this fashion.
Steps I?ve tried:
Restored a backup to a date where I knew things were working.
Power cycled the vera unit
Connected to the AD2USB interface via their GUI app and have full control through my PC
I?ve posted the log below from the unit when I try and run the stay scene. This is with verbose logging and debug turned on for the Ademco Vista Partition?
0 12/11/16 10:10:03.020 luup_log:18: (VistaAlarmPanel::processIncoming) Incoming data = '[1000000110000000----],008,[f70000071008001c28020000000000]," DISARMED CHIME Ready to Arm "'. <0x2e6ec680>
50 12/11/16 10:10:03.021 luup_log:18: (VistaAlarmPanel::getStatusFlags) Active flags: READY, CHIME_MODE <0x2e6ec680>
50 12/11/16 10:10:03.022 luup_log:18: (VistaAlarmPanel::getPartitionState) Got Alarm='None' for partition 1 (device #19). <0x2e6ec680>
50 12/11/16 10:10:03.022 luup_log:18: (VistaAlarmPanel::getPartitionState) Got ArmMode='Disarmed' for partition 1 (device #19). <0x2e6ec680>
50 12/11/16 10:10:03.023 luup_log:18: (VistaAlarmPanel::getPartitionState) Got DetailedArmMode='Ready' for partition 1 (device #19). <0x2e6ec680>
50 12/11/16 10:10:05.955 luup_log:18: (VistaAlarmPanel::requestArmMode) Request new arm mode: 'Stay', device #19. <0x2f16b680>
50 12/11/16 10:10:05.955 luup_log:18: (VistaAlarmPanel::requestArmMode) partNo = 1 <0x2f16b680>
50 12/11/16 10:10:05.956 luup_log:18: (VistaAlarmPanel::getPinCode) Using the stored PIN code. <0x2f16b680>
50 12/11/16 10:10:05.957 luup_log:18: (VistaAlarmPanel::requestArmMode) Current arm mode = 'Ready'. <0x2f16b680>
50 12/11/16 10:10:14.349 luup_log:18: (VistaAlarmPanel::processIncoming) Incoming data = '!Sending.....done'. <0x2e6ec680>
50 12/11/16 10:10:14.360 luup_log:18: (VistaAlarmPanel::processIncoming) Incoming data = '[1000000110000000----],008,[f70000071008001c28020000000000]," DISARMED CHIME Ready to Arm "'. <0x2e6ec680>
50 12/11/16 10:10:14.360 luup_log:18: (VistaAlarmPanel::getStatusFlags) Active flags: READY, CHIME_MODE <0x2e6ec680>
50 12/11/16 10:10:14.361 luup_log:18: (VistaAlarmPanel::getPartitionState) Got Alarm='None' for partition 1 (device #19). <0x2e6ec680>
50 12/11/16 10:10:14.362 luup_log:18: (VistaAlarmPanel::getPartitionState) Got ArmMode='Disarmed' for partition 1 (device #19). <0x2e6ec680>
50 12/11/16 10:10:14.363 luup_log:18: (VistaAlarmPanel::getPartitionState) Got DetailedArmMode='Ready' for partition 1 (device #19). <0x2e6ec680>
My last step would be to clear out the plugin, but then I might have to go and setup my scenes and triggers. Thought I would post here first to see if anyone has experienced something similar. If the whole device wasn?t working I?d start from scratch, but I have a lot of things still functioning. Help please!
I am experiencing the same issue and I believe it happens when you send change state request without a PIN. For some reason the last PIN (which is now blank) is remembered and all buttons (arm, disarm, stay, etc.) stop working. This could happen for different reasons. An app that does not prompt for PIN or prompts, but no PIN is entered. Or as in my case I was trying to set up a scene to overcome limitation of ImperiHome, which does not let me set panel to StayInstant. I stumbled up on it by chance trying not to store PIN in a scene Luup code. This is what the Luup looked like:
So a commonality here is I was using Imperihome as well and found that if I armed or changed modes through the app, my vera seemed to lose the PIN code and I couldn’t change alarm states until I went into vera a re-entered the code. I can’t recall if I had been in the app or not before the issue happened so I don’t know if it’s directly related or not.
I do know that I broke my AD2USB in the process of troubleshooting. My last ditch effort at troubleshooting was to unplug the AD2USB device from my alarm panel to try and reset it. As I was unscrewing the power wires, my USB cord fell out, and upon further inspection the mini USB port has come off the board internally. So now I’m without a functioning board. I have a new one on order and it will be interesting to see if I have the same problem or not. Maybe there was a pin loose?
My new AD2USB showed up in the mail yesterday. Hooked it up and had to reconfigure a few things (had to readd the serial port). The same issue still was happening even with the new device. After HOURS of configurations I finally got it to work. I’m not sure how this happened, but I think my keypad address for the ad2usb was not on partition 1. On my vista 20p I went into programming mode and entered *191 and then 1. After doing this (this was the last thing I did. I must have done 1000 other things in between) I was immediately able to change the status through Vera. PHEW. I was going to break something!
The log still looks fairly similar, but you can see now it goes into the stay mode:
50 12/21/16 19:05:47.736 luup_log:18: (VistaAlarmPanel::processIncoming) Incoming data = '[1000000110000000----],008,[f700000f1008001c28020000000000]," DISARMED CHIME Ready to Arm "'. <0x2e7ee680>
50 12/21/16 19:05:47.737 luup_log:18: (VistaAlarmPanel::getStatusFlags) Active flags: READY, CHIME_MODE <0x2e7ee680>
50 12/21/16 19:05:47.737 luup_log:18: (VistaAlarmPanel::getPartitionState) Got Alarm='None' for partition 1 (device #19). <0x2e7ee680>
50 12/21/16 19:05:47.738 luup_log:18: (VistaAlarmPanel::getPartitionState) Got ArmMode='Disarmed' for partition 1 (device #19). <0x2e7ee680>
50 12/21/16 19:05:47.739 luup_log:18: (VistaAlarmPanel::getPartitionState) Got DetailedArmMode='Ready' for partition 1 (device #19). <0x2e7ee680>
50 12/21/16 19:05:54.173 luup_log:18: (VistaAlarmPanel::requestArmMode) Request new arm mode: 'Stay', device #19. <0x2dfee680>
50 12/21/16 19:05:54.174 luup_log:18: (VistaAlarmPanel::requestArmMode) partNo = 1 <0x2dfee680>
50 12/21/16 19:05:54.174 luup_log:18: (VistaAlarmPanel::getPinCode) Using the stored PIN code. <0x2dfee680>
50 12/21/16 19:05:54.175 luup_log:18: (VistaAlarmPanel::requestArmMode) Current arm mode = 'Ready'. <0x2dfee680>
50 12/21/16 19:05:54.454 luup_log:18: (VistaAlarmPanel::processIncoming) Incoming data = '!Sending.done'. <0x2e7ee680>
50 12/21/16 19:05:54.945 luup_log:18: (VistaAlarmPanel::processIncoming) Incoming data = '[0011030110000000----],045,[f700000b1045038028020000000000],"ARMED ***STAY***May Exit Now 45"'. <0x2e7ee680>
50 12/21/16 19:05:54.946 luup_log:18: (VistaAlarmPanel::getStatusFlags) Active flags: ARMED_STAY, CHIME_MODE, BEEP <0x2e7ee680>
Issue came back after a day or so working. I don’t think it has to do with the AD2USB or my alarm panel since I didn’t touch a thing. I noticed my disarm scene didn’t run this morning so I tried to run it through the UI in vera and the same thing was happening where I would click on disarm and the color would not change to green. It’s stuck on stay.
I have found after some testing that if the system is in Stay I can click on the disarm 3-4 times and it will sometimes actually disarm the system and other times it will disarm the system 3-4 times in a row. I can’t get it to go to any other states that way.
Anyone know what I can do to make this work the way it used to for the last few years?
When I am in the AD2USB configuration I have the option of selecting multiple addresses. If I have 17 and or 18 selected the behavior is still the same. A review of my settings is much appreciated!
Yes. It functions through the AD2USB control without issue.
My scenes through Vera that are linked to the controller function as well. Example: I have a scene where when the door opens my outside lights turn on at night. This runs without issue. I can also see when I manually go to the keypad and change the alarm state it updates in the Vera interface to the new state.
I have not had a problem since I realized that The VistaAlarmPanel plugin is storing the last entered PIN. So if you aren’t able to change state from the main devices tab, go into your Alarm → Alarm Partition, enter your PIN in the PIN Code text box and without clicking on Store, click one of the states. This will remember the PIN code until the next time you send a wrong/empty PIN code, or maybe LUA restart/whole unit reboot - I am not sure about that one.
Alright. Digging back in. I opened up the log to be wide open, verbose, and debug on for my device.
I noticed my logs weren’t totally matching. Your logs showed the pincode being used whereas mine showed USING STORED PINCODE. In the log below I hit STAY, then changed the pin code. I’ve changed mine to 1234
One thing you could try is to manually send the request from vera’s shell. I will look it up and add a link here.
Note: I believe I entered the Path in the serial port configuration manually. I don’t think it makes any difference.
*Edit: Here are instructions on how to enter alarm panel commands from vera’s shell [url=http://forum.micasaverde.com/index.php/topic,14923.msg180234.html#msg180234]http://forum.micasaverde.com/index.php/topic,14923.msg180234.html#msg180234[/url]. I know this used to work with UI5 firmwares, because I actually used it to configure my alarm panel. This procedure will shut down Vera. You might have to change the path to the ad2usb (/dev/ttyUSB0) in step 3 to match your system. You should be then able to use 12343 to arm your system stay and 12341 to disarm. where 1234 is your PIN.
Interesting observation! Vera support replied back to me this morning thinking that there might be some network interference. My USB path doesn’t look to be filled out in my panel, but everything else is setup the same.
I think when I get home I might unplug some devices and see if that makes a difference. It might be time to add a switch!
I was able to follow those commands and log into the shell and issue the commands. The commands execute just as quick as they do when I plug the AD2USB directly into my PC. Something in the Vera interface must be interferring. I have the new switching coming in early next week. I don’t think it will fix the issue, but I did discover that I didn’t bridge my ISP’s modem to my WLAN and I probably had a double NAT situation going on. That’s been resolved, but now I’m out of ports, hence the switch.
I will likely have to wipe the vera box and then start with adding just the AD2USB plugin and go from there!
Best Home Automation shopping experience. Shop at Ezlo!
