FYI… Got this response from Tech Support…
DEC 18, 2014 | 02:08PM UTC
XXXXX replied:
Hi XXX,
Currently there is an issue that prevents our customers to use USB devices with Vera Edge, but this should be resolved in our next software release, by the end of this week.
Please let me know if you have other questions and I?ll get back to you afterwards.
Downloading Vera Edge firmware update as we speak… v 1.7.906… Will report results shortly
Ok… Followed the instructions and still not working… here are the results…
ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
kmod: Usage:
rmmod module
Failed to find vendor=0x0403. Maybe it is a built in module ?
type: echo “ftdi_sio vendor=0x403 product=0x6015” > /etc/modules.d/65-usb-serial-ftdi
type: echo “vendor:0403 product:6015” > /etc/cmh/serproxy.ports
reboot
There’s something amiss with the ftdi driver in that release then…
I was able to get the module to load with slightly different syntax from above. At this point, dmesg would indicate that the FTDI SIO compatible converter was attached to ttyUSB0. From here, I could successfully issue the required ser2net command manually and then telnet to the ad2usb where I could confirm i was getting data from the alarm panel. However, the GUI would not indicate the detection of a serial port. Further investigation of /var/log/cmh/serproxy.log showed no indication that the usb-serial adapter was being automatically connected via ser2net and /proc/tty was strangely missing. I was trying to compare what happens on my vera2 versus the veraedge as I moved the ad2usb between the two units to troubleshoot. I can go no further at this point without guidance and assume there must be some issue with usbserial or the kernel particularly in light of the missing /proc/tty.
Instructions I used on the veraedge to get the serial port to connect:
ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
type: rmmod ftdi_sio
The version of rmmod on the veraedge will not accept any options so the -f will generate an error if included. This command isn’t really necessary anyway as the ftdi_sio module doesn’t appear to load by default on the veraedge. In fact, there are no modules at all attached to usbserial according to lsmod in the default configuration.
type: insmod ftdi_sio vendor=0x0403 product=0x6015
You must specify the module name here or an error is generated.
Getting the module to load automatically on boot is also not the same. There is now a /etc/modules-boot.d/ directory with soft links to the modules.d directory. I suspect you might have to create / modify the module call there to get the module to load automatically but I didn’t tinker with this.
I also must admit that I am a bit out of my wheelhouse here …
Are we stuck until MCV addresses?
-Tim
Unfortunately yes, this is out of anybody’s control but theirs unless you know a way of pushing new MCV Firmware to people from 3rd parties
Really disappointed in the new Edge thus far…so many issues. I don’t know how you tout yourself as being compatible with so much stuff, yet not even supporting items your older systems supported. Seems like they may have pushed this one to market far too quickly.
Update: this and the following two posts do result in the Vera successfully communicating with the alarm panel so read on!
It has been a while since I’ve had to delve into this plugin but I guess my luck ran out when I upgraded to UI 7. A few days later my Veralite turned into a brick. But I digress…I now have a Veraedge and I’m rebuilding my automation network.
What follows is a brain dump from working with v1.7.906 so excuse the brevity/grammar/spelling/etc - I’ll probably post a script later after I reboot and have to do all of this again:
Posts above regarding the removal of the module are correct.
Insertion of the module is product-ID specific. Use lsusb to find the product ID. It is in the form of 0403:6001. The first 4 are the vendor ID which will be the same for all of us. The second four digits after the colon are the product ID> It looks like the product ID might vary, so find yours and use that in insmod. I haven’t tested it, but it might work without a product ID, but I’m not sure.
3 After that, unplug and reinsert the USB cable.
At this point you should see the serial port listed in Apps->Develop->Serial Port Config. At least I think this is the first step that I saw the serial port, but I wasn’t watching that closely.
The seg fault described above appears to be a result of serproxy not handling missing command-line args in clean way (read->sloppy programming and QA). It prints usage information if you’re running it with < 3 arguments, when it really needs 4. Interestingly, the native startup script also calls serproxy without the necessary arguments, so it goes into a endless seg fault loop, /mios/usr/bin/Start_serproxy.s:
“/usr/bin/serproxy 127.0.0.1 127.0.0.1 $InstID”
It is missing the trailing arg of the serial device.
/usr/bin/serproxy 127.0.0.1 127.0.0.1 /dev/ttyUSB0
So, run the serproxy command above. You don’t have to run ser2net manually, serproxy starts it with the appropriate options. You can run ‘ps ax|grep ser2net’ if you’re interested in what options are used. You can run it in the background by adding an ampersand to the end of the command or by pressing ctrl-z then typing bg %% if you already started it.
It spits out some errors regarding downloads, but based on the logs, a number of downloads work, and they all seem to be pulling device configuration info from the Lua engine. The ones that fail don’t seem to be causing problems as it looks like it falls back to sane defaults but I could be wrong.
Warning: this may completely hose your Vera, I am not responsible for anything that results from using the stuff below. If you don’t understand what I have below, you probably shouldn’t try to use it.
OK this is what I’m using to automate the steps above, getting you to the point that the tty device is up, the daemons are running, and the serial port shows up in the UI:
#!/bin/sh
# SVN : $Id: Start_serproxy.sh 8764 2013-07-31 12:58:27Z florin $
#Copyright (C) 2008 Mi Casa Verde, Inc., a Nevada Corporation
# www.micasaverde.com
# 1 - 702 - 4879770 / 866 - 966 - casa
#This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License.
#This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
#without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
InstID=$(cat /etc/cmh/PK_AccessPoint)
while [[ ! -f /var/run/cmh.stop ]]; do
# Intentionally done in-loop b/c the device might
# not be inserted at boot, and this will pick it up on Lua reload
ProdID=$(lsusb|awk -F '[: ]' '/0403/ { print $8; }')
rmmod ftdi_sio
insmod ftdi_sio vendor=0x0403 product=$ProdID
TTYNode=$(dmesg|awk '/ now attached to/ { print $NF; }'|tail -n 1)
kill $(ps ax|awk "/serproxy/ /!$$/ { print $1; } " 2>/dev/null) 2>/dev/null
kill $(ps ax|awk '/ser2net/ { print $1; }' 2>/dev/null) 2>/dev/null
sleep 5 # Give LuaUPnP some time to startup
echo "Running serproxy: /usr/bin/serproxy 127.0.0.1 127.0.0.1 $InstID /dev/${TTYNode}"
/usr/bin/serproxy 127.0.0.1 127.0.0.1 $InstID /dev/${TTYNode}
sleep 1
doneI replaced the /usr/bin/Start_serproxy.sh with that code because it is run on boot and, well, that is where it should be done based on the code that was already in there. I replaced it by:
cd /usr/bin
rm Start_serproxy.sh
vi Start_serproxy.sh
<paste script above>
<save + exit (esc :wq enter)
chmod +x Start_serproxy.sh
rebootTo put the original back in-place:
rm /usr/bin/Start_serproxy.sh
ln -s /mios/usr/bin/Start_serproxy.sh /usr/bin
rebootIt works!!!
With the script I posted above I can interact with the alarm panel in UI 7 v1.7.906 
If you replace the Start_serproxy.sh script as described above, things should start working… mostly. I’ve found the “cheat sheet” is acting wonky. The entries don’t appear immediately. They appear eventually in the cheat sheet list. I think refreshing the page and going back in the cheat list helps The devices that the cheat sheet creates do not appear until a reboot, AFAICT.
Hope all that helps.
Update: after a cold boot w/ removing power, the serial port settings in the UI appear to have been lost. It was back to 9600 baud and no device was associated with it. This caused a connection error like before. But once I fixed the settings via the UI, and restarted Luup, things are working again. I’ll look into this more .
I’ve been reserved but at this point I’m going to have to throw a “WTF?” at the Vera team. Spending a day fixing their problems, which has happened before, wears on one. The problems described in the first post are a simple programming mistake that never should have made it past QA (argc < 4, ttydev = argv[3]… segfault). The issues in this post just add to problem together illustrating the poor quality of the software product. The only plus side here is that the platform is configurable to the point where we can fix their problems ourselves. In essence, we are the Vera QA team.
Sound - I will try to confirm your findings later today…
FYI - The reponse I received from Vera…
We?ve discovered an incompatibility in the usb drivers on the OpenWrt platform that is used by the Vera Edge.
Our colleagues from development are working on it right now and should release a patch and in the first weeks of January to fix this.
[quote=“Vandamme23, post:871, topic:168766”]FYI - The reponse I received from Vera…
We?ve discovered an incompatibility in the usb drivers on the OpenWrt platform that is used by the Vera Edge.
Our colleagues from development are working on it right now and should release a patch and in the first weeks of January to fix this.[/quote]
It isn’t really an incompatibility, at least anymore. I think they just need to add a few module alias lines for this product ID. I can’t speak to older versions of the firmware, but based on info above from other posters, and Vera’s response regarding a release with a fix in December, a missing or otherwise incompatible module is probably already fixed.
Let us know how this work-around does on your device Vandamme23.
Update: Oh, and they need to pass in the correct command-line arguments to their serproxy binary, else do something similar. They should probably fix the segfault but strictly speaking that isn’t necessary as long as they pass in the right args.
Sound… Using your post, I am able to see my serial port in the UI now… I can configure it and assign it to partition 1… But when trying to do anything using the device, it states the device is not responding… I will try removing the app and reloading it…
Did you set the serial port baud rate to 115200 in the UI? Also make sure you list every keypad address in-use. If either of those aren’t correct it won’t respond. That was what was giving me the same error.
http://code.mios.com/trac/mios_vista-alarm-panel-ad2usb/wiki/UI5
I am experiencing the following when I was testing my new vista 20p and AD2USB: I had my alarm system set “Away”. When I entered I wanted to test my siren so I waited for the siren to go off before I entered my code. I then entered my code. The display said “Canceled Alarm” and the defaulted zone. I made sure the zone was closed and entered my code and off a few more times, but the “Canceled Alarm” message wouldn’t go away. After 15 minutes it was still there so I using vera I pressed the Disarm button. That cleared the “Canceled Alarm” message. Is there a way to fix this?
When you have a faulted zone, does the backlight on the keypad displays stay on constantly, or does it turn off?
The back light stays on and the it keeps flashing between the faulted zone & the “Alarm Canceled” message. I punch my code in and the off button multiple times, but
it doesn’t do anything. Then when I use vera U15 on my computer and click on the “DisArm” button it clears it.
Is the AD2USB now compatible with UI7? Some of us couldn’t get it working in UI7 - even by SSHing into the Vera. There was something in UI7 that prevented the port from showing up in the GUI. Unfortunately, can’t stay at UI5 forever so I was hoping to attempt UI7 again, but only if I can control my alarm system.
Thx
[quote=“helraiser, post:878, topic:168766”]Is the AD2USB now compatible with UI7? Some of us couldn’t get it working in UI7 - even by SSHing into the Vera. There was something in UI7 that prevented the port from showing up in the GUI. Unfortunately, can’t stay at UI5 forever so I was hoping to attempt UI7 again, but only if I can control my alarm system.
Thx[/quote]
Read up a few posts…
[quote=“MikeH, post:877, topic:168766”]The back light stays on and the it keeps flashing between the faulted zone & the “Alarm Canceled” message. I punch my code in and the off button multiple times, but
it doesn’t do anything. Then when I use vera U15 on my computer and click on the “DisArm” button it clears it.[/quote]
That sounds like the problem I had ages ago.The wiki for the plugin states these panels don’t send a message when faulted zones are cleared. So the plugin sends a “" to get the faulted zone list to determine when it is cleared. The problem I was seeing was that it sent the "” about once a second. I set the debug variable to 1 in the plugin settings and watched the log output via SSH to confirm.
IIRC I patched the plugin by hand, but eventually an updated plugin fixed it without a patch, but that was 18 months ago so you should have the fixed plugin.
I would try the debug flag to confirm that is the problem, check all keypad addresses, then resort to modifying the plugin source code.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules