usb/serial dongle - pinning it to always be /dev/vpro
Graham Eddy
that means it is possible, as reported in this forum previously, for the device file to change according to what is presently plugged into the usb ports.
hasn't been a problem for me, as for others, but i had to do some fiddling to handle some usb devices, so decided to finish this off as well i.e. always have a serial device file /dev/vpro that corresponds to the dongle no matter what else is plugged in (unless, of course, you plug in another identical dongle, then we can't pick which is which...)
i'm on ubuntu 9.10 (karmic).
i just used udev rules to ensure that /dev/vpro is always symlinked to whatever actual serial device file that the dongle is connected to.
my dongle identifies itself to the computer as ID_VENDOR_ID=050d and ID_MODEL_ID=0109 so we just look for a udev add event from TTY subsystem corresponding to this, and add the symlink to the indicated device.
copy of my file is below - just drop a copy into /etc/udev/rules.d/
(and you might need to run "# udevadm control --reload_rules")
ahah! the observant say. what if i don't have a Belkin F5U109 dongle? what are the ID_VENDOR_ID and ID_MODEL_ID now? just run "# udevadm monitor --property" then unplug your dongle, wait a mo, then plug it back in again. the output will show you those values, go change them in your udev rules file
and don't forget to change wview config to use /dev/vpro as the device file, then restart wview
Graham Eddy
-----------------usb_serial_vpro.rules---------------------
# automap usb/serial dongle for Davis VantagePro2
# (assumes a Belkin F5U109/F5U409 PDA Adapter is for the vpro)
# creates symlink /dev/vpro
# install file in /etc/udev/rules.d/
ACTION!="add|remove", OPTIONS="last_rule"
SUBSYSTEM!="tty", OPTIONS="last_rule"
ENV{ID_BUS}!="usb", OPTIONS="last_rule"
ENV{ID_VENDOR_ID}!="050d", OPTIONS="last_rule"
ENV{ID_MODEL_ID}!="0109", OPTIONS="last_rule"
ACTION=="add", SYMLINK+="vpro"
--------------------------------------------------------
Graham Eddy
ACTION=="add", SUBSYSTEM=="tty", ENV{ID_BUS}=="usb", ENV{ID_VENDOR_ID}=="050d", ENV{ID_MODEL_ID}=="0109", SYMLINK+="vpro"
but i have structured it for better flexibility
Graham Eddy
Owen
11.1
Unfortunately, I have an old USB printer attached to the linux box,
and every time it's powered on/off, the VP2 suffers EMI
(electromagnetic interference) which makes it hop around USB ports,
which sucks. I have previously used another method to fix the wview
problem (updating the device in the wview database with sql commands),
but Graham's post made me get off my arse to try and do it properly
(thanks Graham). Unfortunately it doesn't fix the EMI problem - more
on that later.
Anyway, the syntax of "udevadm" here is not the same as Ubuntu and
doesn't return a "ID_VENDOR_ID" amongst other things, so different
steps are required; This is how I did it.
Step 1. Identify the relevent USB device your VP2 is using.
[beast]:/# cat /proc/tty/driver/usbserial
usbserinfo:1.0 driver:2.0
0: module:ftdi_sio name:"FTDI USB Serial Device" vendor:0403
product:f850 num_ports:1 port:1 path:usb-0000:00:1a.1-1
2: module:cp2101 name:"cp2101" vendor:10c4 product:ea60 num_ports:1
port:1 path:usb-0000:00:1a.2-1
Now, I know my weather station device is the "cp2101", and the first
number corresponds to the ttyUSB device it uses, in this case "2", so
I know my device is /dev/ttyUSB2
Step 2. I need further "udev" info to create the rule, so I run:
[beast]:/# udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB2)
| less
looking at device '/devices/pci0000:00/0000:00:1a.2/usb3/3-1/3-1:1.0/
ttyUSB1/tty/ttyUSB1':
KERNEL=="ttyUSB1"
SUBSYSTEM=="tty"
DRIVER==""
looking at parent device '/devices/pci0000:00/0000:00:1a.2/
usb3/3-1/3-1:1.0/ttyUSB1':
KERNELS=="ttyUSB1"
SUBSYSTEMS=="usb-serial"
DRIVERS=="cp2101"
ATTRS{port_number}=="0"
looking at parent device '/devices/pci0000:00/0000:00:1a.2/
usb3/3-1/3-1:1.0':
KERNELS=="3-1:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="cp2101"
ATTRS{bInterfaceNumber}=="00"
ATTRS{bAlternateSetting}==" 0"
...snip, snip...a whole lot more superfluous rubbish...
Step 3. I look for the entry at the top that has the matching
"DRIVERS" entry to the one I had earlier, and also relates to the
correct ttyUSB device.
Step 4. Again, because "udev" works differently, the approach of
Graham's config file won't work, so I take the shortcut that does, and
my config file looks thus:
# automap usb/serial dongle for Davis VantagePro2
# creates symlink /dev/vpro
# create in a file in /etc/udev/rules.d
# and run "udevadm control --reload-rules" to reload the rule base
KERNELS=="ttyUSB*", SUBSYSTEMS=="usb-serial", DRIVERS=="cp2101",
ACTION=="add", SYMLINK+="vpro"
Step 5. The reload command is also slightly different. Run:
[beast]:/# udevadm control --reload-rules (Note, no underscore)
Step 6. Unplug/re-plug your VangatePro2 console and check that /dev/
vpro is created correctly.
Step 7. Change your wview config to point at "/dev/vpro" and restart
wview.
Step 8. Good stuff, it works! Drink a beer (or 10)
______________________________
The bad stuff - EMI
Unfortunately, the EMI problem still exists, and even though the VP2
config points at /dev/vpro, it's not a dynamically updateable thing
just to re-write /dev/vpro to point to a new tty device when it
changes. Wview still tries to talk to the old tty device, so when EMI
occurs, I have to do somthing about it - ie. restart wview.
To do this, I use software called "logfmon" to monitor for certain
phrases in syslog (which happen when the tty disconnect/reconnects
happen), and then logfmon will restart wview for me. It's a bit of a
pain, but at least it works. If you need any help with this, let me
know and I'll see what I can do.
Graham Eddy
re-created (by various re-plugging of USB devices) so does not pick up
the new config automatically.
the only way at present for wview to pick up the new /dev/vpro is to
restart wview.
one *could* add a rule ACTION="add",RUN+="/etc/init.d/wview restart",
but this would be very messy after a reboot (too early)
maybe we could ask for a wview enhancement to accept a gentle poke to
re-open the device file?
then have a rule like ACTION="add",RUN+="/usr/local/bin/wview_reopen_port"
where the client can just die quietly if wview not running or not yet
opened the device file on startup
------------------------------------------------------------------------
*Graham Eddy*