Can anyone help me, I have a Vera plus and an envisalink connected to a vista 20p panel and I have a zwave fire and carbon detector. I want the smoke detector to trigger the 20p fire alarm in the event of a fire but I can’t figure out how to trigger the letter key that I have programmed.
I know this isn’t a PLEG thread but my issue seems tied to this plugin and I didn’t know if anyone might have a better way to handle my problem.
I have a lock that I want to lock when the alarm is armed. For some reason if I set the alarm with the door unlocked it will go through the motion and seem like it’s arming. Once it gets to the end it arms, immediately disarms, and then locks the door. If I arm with the door locked to begin with everything is fine.
Does anyone know what might be causing this issue? At first I though it was because I was locking the door immediately but even placing it on a 20 second delay still keeps the alarm from setting with the door unlocked. It’s almost like the presence of the PLEG condition is preventing the alarm from arming.
For what it’s worth, here is my PLEG condition:
tSecurityArmed and tGarageDoorUnlocked and (tGarageDoorUnlocked; tSecurityArmed)
I guess I’m hoping there is an advanced setting in the Ademco Plugin that will help solve my problem. If not, I’ll retreat to the PLEG forum to see if they have any tips over there.
Thanks in advance for any help.
For what it’s worth, I got this working. Just in case anyone else has a similar issue I tied to the door locking to the exit delay (instead of arming) with a 30 second action delay. It seems to work well now. Apparently it’s been this way for some time and I never realized it. My phone would always say it was armed, which it was but for only a second. :-*
I had all of this working well on a Vera Lite for years. I recently upgraded to a Vera Plus and had to relocate the Vera so I implemented a Raspberry Pi based on this thread.
http://forum.micasaverde.com/index.php/topic,26672.0.html
The Pi side of things works well. Additionally I can trigger and get a response (chime from keypads on panel) for arming/disarming. However, I get no status indication in the Partition widget. Usually the status is indicated and the corresponding button is highlighted. Not really sure where to look to resolve this issue.
I think I’ve identified a bug of some form. Running Firmware 1.7.2414 on a Vera Edge.
Loading the AD2USB Plugin from the App store always results in an error
failed to load /D_Codeset_1086.xml.lz - the device number is whatever device was created for the panel.
If I go to apps the plugin doesn’t show installed. However, installing a second time it will install and increment the device number by 1 for the new device and the plug-in will show as installed but the error for the previous device continues. I can manually delete the device with:
http://:3480/data_request?id=device&action=delete&device=
This eliminates the error and things appear to progress properly (except for the issue in my previous post that I’m still investigating)
VeraLite.
I am getting a Comm Failure as well. Ver 2.2a.6
Hi All,
I am trying to control my Vista 20p through the Vera Mobile app but am having trouble.
I can control the arming/disarming from the PC just fine, but when I open the app the plugin doesn’t have any options.
I attached a screenshot where you can see that my thermostat has the options button, but the Vista Partition does not.
Short of using the “My Modes” is there a way to access the desktop style of control from the app?
Thanks
I’ve been running the AD2USB for years on U15 and Vera 3 with no issues other than the occasional port reset. I recently “upgraded” to a Vera Plus with U17, and I’m about to go back to my old Vera 3 since I can’t get the alarm sensors to work properly. MCV support seems perplexed by the whole issue…
Besides listing all my door and window sensors as motion sensors, they respond very inconsistently. In all cases, the alarm partition will register “not ready” almost immediately after any sensor is tripped, but the sensors themselves have literally taken HOURS to update their status in Vera as tripped after they are physically tripped. But other sensors will respond immediately. It’s also very inconsistent…some sensors seem to usually respond immediately while others might do it once or twice in a row but then not again for hours. It’s almost as if the sensor information flow is getting “clogged up” somehow. The “clogging” pattern goes like this…I can reboot the Vera or reset the port, and then the front door will respond perfectly. Then I try the kitchen door, and it also works immediately. Then back to the front door, and it won’t detect changes to the sensor. Then back to the kitchen door and that won’t work either. Then the tripped messages will show up 5, 20 or even 120 minutes later. Yet the alarm partition gets the “not ready” message immediately in all cases! Very strange…
I’ve made no hardware changes to the alarm, sensors, or AD2USB module. The port is set to the right baud rate (115200), etc. I’ve reinstalled the entire plug in, alarm devices, and manually added all the sensors again a few times and always get the same results. I’ve tried changing the TTL to lower values like 15 seconds, and set the IgnoreTripTime value to 0 for all the sensors to see if the issue had something to do with the fact that these are now being treated as motion sensors and that parameter might have been causing tripped messages to be ignored as nuisance motion detection, etc. Nothing has changed the behavior.
I’m using version 3.12 of the plug in…one other issue I can’t seem to fix is that the alarm panel device lists the plug-in version as 2.45. I’ve tried changing that setting in the Device to match the actual plugin version, but it always reverts back to 2.45. If I knew how to go back to that actual version of the plugin, I’d like to try that as it might help, but I’m not sure if that’s possible. There’s also the “Can’t Detect Device” message on the Alarm Panel Device that I can eventually clear using the advice above, but things stay the same even with that message cleared and having the message doesn’t seem to affect the other basic functions of the alarm (arming, disarming, etc.).
The only other odd thing after my latest reinstallation of everything, and again this hasn’t changed the issue at all, is that there are two Zone fields in the Alarm Device. One only has one of my zones in it, and the other field has my entire list of (32) zones. I don’t think this would solve the issue as previous attempts didn’t have these two fields and the problems were the same, but I’d like to know how to remove a duplicate field (it won’t let me have nothing in the field).
Thanks in advance…I’m hoping someone has solved this before or can offer some more tips…not being able to use the door sensors is a big deal and I might actually just go back to my older but very stable Vera 3 if I can’t solve this soon…
Olivier
If you haven’t done this yet upload hugheaves’ version of the plugin which is not the one in the plugin store. Just go to apps tab, click develop apps, then the upload files section.
Download the zip using the link at the bottom of this page:
http://code.mios.com/trac/mios_vista-alarm-panel-ad2usb/browser/trunk
Extract the zip, and upload the files within that directory.
Mine shows 2.45 as well, but it is the latest version.
I hope it helps if at least tell you how your system compares to mine. I have a vera edge running ui7. My system also shows the 3.12 version and the 2.45 version, so that is probably not your problem. I also get the ‘can’t detect device’ message on the panel but it doesn’t seem to impact anything. I tried the changes above but was not successful in removing the message. My ttl is set at 20. NumPartitions is 1. I hadn’t noticed but all of my sensors are showing as motion as well. I am not certain this impacts anything for me. I may not be looking in the right place, but I only see one zone field and the information inside it pretty much mirrors my cheat sheet. In my cheat sheet, I only list the zone number and the name. Sound-mind probably has your solution and doing that and basically starting over will probably fix you. Write back if I can confirm any settings with my system, and especially if you find the issue.
Thanks sound-mind and pentium…I did download the other version of the plugin…never thought to look outside of the plugin store! Are there other ways to find out-of-store plugins like that? I’m now on version 3.89 of the plugin with no warning messages. I’m still doing my testing, but things seem a little better at least. I’ve still had some moments when it seemed that the door sensors would stop responding again, especially when I was testing them a lot over a short period of time, but I’m still checking things to see if that was my imagination or the new version “breaking in” somehow…
Has anyone solved the issue of door/window sensors being shown as motion sensors?
[quote=“ohecht, post:991, topic:168766”]Thanks sound-mind and pentium…I did download the other version of the plugin…never thought to look outside of the plugin store! Are there other ways to find out-of-store plugins like that? I’m now on version 3.89 of the plugin with no warning messages. I’m still doing my testing, but things seem a little better at least. I’ve still had some moments when it seemed that the door sensors would stop responding again, especially when I was testing them a lot over a short period of time, but I’m still checking things to see if that was my imagination or the new version “breaking in” somehow…
Has anyone solved the issue of door/window sensors being shown as motion sensors?[/quote]
I doubt that the door/window sensor v. motion sensors is a bug in the plugin. Are you sure the zone type is set correctly in the panel itself? Some zone types can behave the exact same depending on your configuration, though they are actually different types of zones.
Would your testing have abused the set TTL?
http://code.mios.com/trac/mios_vista-alarm-panel-ad2usb
I.e., if you manually faulted a zone, then cleared it by closing the door (etc) before the TTL had expired, then faulted it again, it would never appear as cleared, rather it would always remain in the faulted state. This TTL thing is not ideal but it isn’t a terrible thing. It assumes a fault is still occurring until it queries the sensor, which is better than assuming something is cleared, but not as good as an actual cleared message being sent.
Those files are just updated versions that have never been formally released into the plugin store. They actually reside in the same source code repository that the 2.45 plugin is stored in. A folder or two up in that site in tags/ probably contains the 2.45 version that is in the plugin store. Vera/MiOS provides a way to upload plugin files manually. The same files are those packed into a plugin. What you did was just upload those files manually that were more recent than those in the store itself. I assume the same process is how plugin developers work - they write the lua/xml/json files and upload them manually to test them.
I have TTL set at 15 now, and I have 32 zones total…not sure if that’s a reasonable number given the number of zones. The system is working a lot better, but there have been a few times when a sensor wouldn’t register tripped or un-tripped…I’m still checking them regularly to try to find the specific pattern. Is there any setting you can think of that would interrupt the process of scanning zones to see if they are cleared? I have CheckConnectionTimer set to 180, in case that could be related.
I also have the IgnoreTripTime variable set to 2 for each sensor. I assume that’s a value to minimize false alarms for motion sensors based on smaller, transient movement that might be detected. I wonder if setting that to 1 or 0 would make my door sensors more responsive at least in terms of tripping.
@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:
[10000001000000003A--],008,[f70000051008001c08020000000000],"****DISARMED**** Ready to Arm "Old regex in trunk rev 83:
local sections = {data:match('^%[([%d%-]+)%],(%x+),%[(%x+)%],"(.+)"$')}Updated regex:
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.
The door sensors are still just completely inconsistent…I’m seriously considering just going back to my nice and stable Vera 3 that just worked…I can’t really use this system if I can’t trust the alarm sensors as reliable triggers. And it looks like I have until tomorrow to return the VeraPlus for a refund…
I hate to throw more time and money at what’s felt like a downgrade so far, but has anyone had better luck the the Envisalink ethernet adapter and plugin for these alarm panels?
I have read every single page of this thread because I just bought a new house in Texas that came with a Honeywell Vista 15PSIA alarm panel, and I needed to get this working with a Vera Plus on UI7.
I put a Visonic PowerMax+ in my old house in Hawaii, and the Vera plugin has been solid for that one for years. Right when I closed on the house, I found out that one of the main Vista/Vera plugin authors pulled the rug out from everyone by leaving and taking all his toys with him.
It was down to this plugin, and things were not looking good. From reading the thread which as not had a whole lot of activity lately, I thought I was screwed on the Vera Plus front, and that is what I bought for my new house.
What I can say know is… Vera Plus people on UI7, take heart, because it appears that it can be made to work well (hopefully it will stay that way).
It appears the newest Ad2USB interfaces has a uart that is supported by the built in Vera UI7 drivers, as the one I just bought along with a new Vera Plus on Amazon shows up when plugged in. It also appears the regular Ad2USB plugin app in the Vera App store works just fine too, as I’m not using an alternate fork published elsewhere. The sensors for doors, windows, and motion all seem to work well, are responsive when tripped, and clear responsively and consistently when I set the TTL to 10 in the Alarm Panel device in Advanced>Variables.
My main struggles where from not doing the following stuff right away (1st one was found per advice deep in this thread):
-
My Partitions variable was set to the correct 1 in the Alarm Panel device, but I did not have the KeypadAddresses variable in the Alarm Partition device set to “16, 18” like I should have. This caused all sorts of device not found problems until that was set.
-
I neglected to set up the cheat-sheet with all my zones set up. Not sure what problems that caused, but I should have done that right away. I set them all up with noting but zone numbers, names, and let the other fields (loop, serial) blank.
-
(Too long so hare are some Cliff Notes: I had to repeat the setup for an additional panel at device 18 in the Vista panel, using SSH into vera, using vera as a terminal into the alarm) Although as a first step, I did go into the alarm panel programming and enable the additional keypad at address 18 for the AD2USB interface, I still had comm problems where it would pull data into the Vera and update the armed status etc. in vera, but it would not push commands to the alarm panel, so I could not arm, disarm, or do anything that pushed date to the alarm.
I did all sorts of troubleshooting to reduce the potential variables and ultimately set the Ad2USB as the only panel, using address 16, and it all communications started working in both directions. I could arm, disarm, and everything worked well, but I needed to get my actual hardware keypad working, especially as provided wireless connectivity for added sensors.
During that troubleshooting, I set the hardware keypad to address 18 to see how it would behave (I hit 1 +3 together when powering and set the address, etc.), and it was also having communication issues at keypad address 18, just like AD2USB/Vera was. I then used SSH to get into Vera (since it was now working with Ad2USB interface at address 16), wrote a script with vi to shut down luup, and telnet into the Ad2USB. I did this so I could use telnet to program the alarm panel like I would with the alarm keypad. I just did not want to go readdress that keypad to get it working again for programming, and issue all of the commands while standing there because its more comfortable doing that sitting at a computer. I just did the same steps I previously did at the keypad to enable a keypad at address 18 (field *191), and I heard the keypad in the hallway beep (a sign of life at address 18!).
Now, everything worked together, the hardware keypad (now at keypad address 18), and the vera/AD2USB (at keypad address 16).
I will at some point, go and get that keypad back to default keypad address of 16, and the AD2USB2 to keypad address 18, as that is how it should be, but for tonight and the next week, I’m going to enjoy the fact that this is all working. If for some reason, things don’t work well when I switch the addresses back, I will post back here about it, but there is no technical reason it should not. These addresses just ended up this way through my strange convoluted path of trying to get this all working, haha.
I know this is all just a jumbled mess to read, and I will likely put up an actual comprehensive A-Z guide on getting this all working once I get all the keypad address back to normal, etc., but that will be a couple of weekends from now.
For tonight, I want to just relay my particular experience, and give some other (Vera Plus with UI7) people some hope that this can all be made to work. If it all falls apart, I’ll come back and admit that as well, but right now it’s working a treat.
sorry for the messy read.
I struggled with the AD2USB for over a year. The unreliability of communications was constant. I bought an EVL4, and instantly regretted not doing so a year earlier. The plug-in’s been absolutely stable on my Vera Edge running UI7, and I’ve never had any issues with it whatsoever.
I struggled with the AD2USB for over a year. The unreliability of communications was constant. I bought an EVL4, and instantly regretted not doing so a year earlier. The plug-in’s been absolutely stable on my Vera Edge running UI7, and I’ve never had any issues with it whatsoever.[/quote]
What plugin are you using, the AD2USB one, or the defunct one made for the EVL4? I wanted to use that one, but the author pulled the rug out from everybody by leaving and taking all of his plugin toys with him. I cannot even get access to the old plugin at this point. I guess the AD2USB plugin can be made to work with it, but have you tried that yet? Perhaps that’s how you’re running right now, and I sure like that device and the flexibility/stability may offer. I’d like to use it, and just might give it a go, even if I end up using it at another panel interface address as a second way into the alarm panel.
It’s odd that none of difficulties involved the actual Ad2USB interface or the serial drivers in my Vera Plus. I did notice however, that when I set the TTL variable to an aggressive 5 seconds, the serial driver/interface went down like a sack of potatoes within a minute, haha. I cannot speak for the long term reliability of interfacing with the Ad2USB, but I’ll see where it goes.
I am installing ad2pi network appliance and I am getting “Error:Device not ready” when trying to arm on Vera Edge UI7? Keypad on web browser and regular 6160 keypad works. Anybody have any idea how to fix.
Has anyone figured out the issue with all devices showing as motions, I don?t see how the cheat sheet can see what zone type is in panel programming. It does not ask a zone type. I have tried to change all parameters in the advanced settings of a contact to be a contact device, but as soon as I reload the layup, all my setup changes revert back to motion again. I absolutely have the zone types in the 20p set correctly.