Error enumerating AD2USB devices

[rothm41]

I am using a Raspberry Pi Model B with the AD2USB to communicate with an Ademco Vista-20P, and I am using the official alarmdecoder-raspbian-2014-11-06.img image from the alarmdecoder website. I called and had my alarm monitoring company add the device at address 19 for me. I can use minicom to talk to the AD2USB on /dev/ttyUSB0 and see alarm events, but when I use the alarmdecoder Python libraries, I get

Exception: ('Error enumerating AD2USB devices: [Errno None] error sending control message: Operation not permitted', USBError(None, 'error sending control message: Operation not permitted'))

when it gets to the

Code: Select all

device = AlarmDecoder(USBDevice.find ())

line. I also get

Error opening device on /dev/ttyUSB0.: Permission denied

when I tried to configure the device initially from the alarmdecoder-webapp. The pi user is a member of the dialout group and I even tried adding www-data to the dialout group, since that appears to be the user running Nginx, but that didn't help. This was resolved, albeit not a permanent solution, with a

Code: Select all

chmod 777 /dev/ttyUSB0

, but of course the permission will revert when the pi reboots and this is probably not the most secure solution. While a permissions change did appear to make the webapp work, I am still getting the same error from the Python code when executing the examples from alarmdecoder.

When I run run the example code using strace, I got the following:

Code: Select all

...
open("/dev/bus/usb/001/005", O_RDWR)    = -1 EACCES (Permission denied)
open("/dev/bus/usb/001/005", O_RDONLY)  = 3
ioctl(3, USBDEVFS_CONTROL or USBDEVFS_CONTROL32, 0xbeb51938) = -1 EPERM (Operation not permitted)
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fcf000
write(1, "Exception: ('Error enumerating A"..., 191Exception: ('Error enumerating AD2USB devices: [Errno None] error sending control message: Operation not permitted', USBError(None, 'error sending control message: Operation not permitted'))
) = 191
rt_sigaction(SIGINT, {SIG_DFL, [], 0x4000000 /* SA_??? */}, {0x2cf88, [], 0x4000000 /* SA_??? */}, 8) = 0
exit_group(0)   = ?


So I tried opening permissions on /dev/bus/usb:

Code: Select all

sudo chmod -R 777 /dev/bus/usb

Which yielded a different error message in strace:

Code: Select all

...
open("/dev/bus/usb/001/005", O_RDWR)    = 3
ioctl(3, USBDEVFS_IOCTL or USBDEVFS_IOCTL32, 0xbef89b48) = -1 ENOTTY (Inappropriate ioctl for device)
close(3)                                = 0
open("/dev/bus/usb/001/004", O_RDWR)    = 3
ioctl(3, USBDEVFS_IOCTL or USBDEVFS_IOCTL32, 0xbef89b48) = -1 ENOTTY (Inappropriate ioctl for device)
close(3)                                = 0
open("/dev/bus/usb/001/003", O_RDWR)    = 3
ioctl(3, USBDEVFS_IOCTL or USBDEVFS_IOCTL32, 0xbef89b48) = -1 ENOTTY (Inappropriate ioctl for device)
close(3)                                = 0
open("/dev/bus/usb/001/002", O_RDWR)    = 3
ioctl(3, USBDEVFS_IOCTL or USBDEVFS_IOCTL32, 0xbef89b48) = 6
close(3)                                = 0
open("/dev/bus/usb/001/001", O_RDWR)    = 3
ioctl(3, USBDEVFS_IOCTL or USBDEVFS_IOCTL32, 0xbef89b48) = 2
close(3)                                = 0
open("/dev/bus/usb/001/005", O_RDWR)    = 3
ioctl(3, USBDEVFS_CONTROL or USBDEVFS_CONTROL32, 0xbef89938) = -1 EPIPE (Broken pipe)
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fef000
write(1, "Exception: ('Error enumerating A"..., 167Exception: ('Error enumerating AD2USB devices: [Errno None] error sending control message: Broken pipe', USBError(None, 'error sending control message: Broken pipe'))
) = 167
rt_sigaction(SIGINT, {SIG_DFL, [], 0x4000000 /* SA_??? */}, {0x2cf88, [], 0x4000000 /* SA_??? */}, 8) = 0
exit_group(0)                           = ?


The AD2USB appears to have the latest stable version of the firmware installer:

Code: Select all

!VER:ffffffff,V2.2a.6,TX;RX;SM;VZ;RF;ZX;RE;AU;3X;CG;DD;MF;LR;KE;MK;CB

Any help would be appreciated. I am out of ideas.

[Scott]

Howdy,

Okay, I'm just going to start from the top.

The USBDevice in the API all runs through libusb, which does require root. I haven't found a good way around that. If you sudo the script you'll notice that /dev/ttyUSB0 disappears because it's been taken over by libusb. The workaround for this is to use a SerialDevice instead and just point it at /dev/ttyUSB0. This is how we do it internally in the webapp, if not 'sharing' in the setup. If it's shared it uses a SocketDevice to connect to the local ser2sock instance. 'Shared' is the default.

You shouldn't need www-data in the group. Nginx just forwards the requests to gunicorn which runs under the pi user.

So, first thing I would check is to make sure that ser2sock and the webapp (gunicorn) aren't running. They could be taking over the port and giving you the permission denied. At that point you should be able to connect to the ttyUSB device from the pi account with screen or minicom or whatever.

It's definitely odd that it started working after you 777'd it. If for some reason you still can't open it from the pi account after making sure everything is stopped, you could add a udev rule to automatically set the mode. I've confirmed this one works:

Code: Select all

pi@alarmdecoder-demo ~ $ cat /etc/udev/rules.d/50-ad2usb.rules
ATTRS{idVendor}=="0403", SUBSYSTEMS=="usb", ACTION=="add", MODE="0777"


So, all of that being said, if you plan on running the webapp in addition to a script of your own I highly recommend using ser2sock and a SocketDevice.

Hopefully that gives you a few ideas of where it's breaking.

[rothm41]

Howdy,

Okay, I'm just going to start from the top.

The USBDevice in the API all runs through libusb, which does require root. I haven't found a good way around that. If you sudo the script you'll notice that /dev/ttyUSB0 disappears because it's been taken over by libusb. The workaround for this is to use a SerialDevice instead and just point it at /dev/ttyUSB0. This is how we do it internally in the webapp, if not 'sharing' in the setup. If it's shared it uses a SocketDevice to connect to the local ser2sock instance. 'Shared' is the default.

You shouldn't need www-data in the group. Nginx just forwards the requests to gunicorn which runs under the pi user.

So, first thing I would check is to make sure that ser2sock and the webapp (gunicorn) aren't running. They could be taking over the port and giving you the permission denied. At that point you should be able to connect to the ttyUSB device from the pi account with screen or minicom or whatever.

It's definitely odd that it started working after you 777'd it. If for some reason you still can't open it from the pi account after making sure everything is stopped, you could add a udev rule to automatically set the mode. I've confirmed this one works:

Code: Select all

pi@alarmdecoder-demo ~ $ cat /etc/udev/rules.d/50-ad2usb.rules
ATTRS{idVendor}=="0403", SUBSYSTEMS=="usb", ACTION=="add", MODE="0777"


So, all of that being said, if you plan on running the webapp in addition to a script of your own I highly recommend using ser2sock and a SocketDevice.

Hopefully that gives you a few ideas of where it's breaking.

Hi Scott,

I disabled gunicorn and ser2sock and restarted the Pi.

Code: Select all

sudo update-rc.d gunicorn disable
sudo update-rc.d nginx disable
sudo update-rc.d ser2sock disable
sudo reboot


When the system booted, I ran ps -ef to reassure myself that ser2sock and gunicorn were not running, and tried to run the example.py script again with no success. I did add the /etc/udev/rules.d/50-ad2usb.rules code (nice little trick), which worked to open up the /dev/ttyUSB0 permissions at boot, but that didn't seem to help with the python libraries either.

Code: Select all

pi@alarmdecoder ~ $ ./example.py
Exception: ('Error enumerating AD2USB devices: [Errno None] error sending control message: Operation not permitted', USBError(None, 'error sending control message: Operation not permitted'))
pi@alarmdecoder ~ $ sudo !!
sudo ./example.py
Exception: ('Error enumerating AD2USB devices: [Errno None] error sending control message: Broken pipe', USBError(None, 'error sending control message: Broken pipe'))


Interestingly, when running as root, the "Operation not permitted" does not occur, but I get a "Broken pipe" error.

Next, I tried to use ser2sock and SocketDevice to connect.

Code: Select all

sudo service ser2sock start
python ./socket_example.py


Unfortunately, nothing happens. It does not print events from the alarm system. Running it with sudo yields the same result.

When running it with strace, it appears that the handle_message is never triggering.

...
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
...

I exit out of the socket_example loop and run minicom, and I prove that I can see door faults and other events; so I'm still not sure what is going on here:-( I would think maybe something is wrong with my AD2USB device, but then I am not sure why I would be able to see the raw serial communications.

Right now, about the only thing I can think to do is to capture ttyUSB0 to a file and write my own code to parse the messages, but I would rather not do that if I can use libraries that alarmdecoder has already built.

Code: Select all

stty -F /dev/ttyUSB0 115200 cs8 -parenb
nohup cat /dev/ttyUSB0 > ttyUSB0.log &


[rothm41]

Update: My stty and cat on /dev/ttyUSB0 seems to be problematic. It ends up setting the AD2USB device address to 00 and stops working until I change the address back to the 19 I have assigned to it.

[Scott]

Well, good news, sorta!

I've confirmed it's not just you. Tried a fresh copy of the newest image and got the 'Broken pipe' to show up. I'll do some investigating and update with my findings.

Thanks,
Scott

[Scott]

Alrighty, I think I got a set of steps that will get you moving with USB.

It turned out to be a combination of issues: ancient version of libusb 1.0 in the raspbian repo, and outdated versions of pyusb/pyftdi. There was also some issue with claiming the interface that an upgrade to the lastest distribution fixes.

I do still highly recommend sticking to SerialDevice or SocketDevice, though. They're 99% functionally the same and a lot less painful to get up and running. The next version of the image likely won't have support for the USBDevice class by default. The AD2USB will still be supported on it obviously, but just through SerialDevice/SocketDevice.

Steps to get running on the image from 2014-11-06:

• sudo raspi-config
• - Choose Expand Filesystem
• - Select Finish, Reboot
• sudo pip uninstall pyftdi
• sudo pip install pyusb --upgrade
• cd /opt && sudo git clone https://github.com/eblot/pyftdi.git && cd pyftdi && sudo python setup.py develop
• sudo apt-get remove -y libusb-1.0-0
• sudo apt-get install -y libudev-dev
• cd /tmp && wget -qO - http://downloads.sourceforge.net/projec ... 19.tar.bz2 |bzcat |tar xvf - && cd libusb-1.0.19 && ./configure && make && sudo make install
• sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y
• sudo sync && sudo reboot && exit

The other potential issue you might face if using the AD2USB directly (without ser2sock/"Shared"-mode on the webapp) is a permission denied error. This can be fixed by changing /etc/gunicorn.d/alarmdecoder to use the 'dialout' group instead of 'pi'.

Hope all that helps!

Scott