The first thing I discovered is that the te923con application has a bug in decoding UV index data from the station. The index jumps from .9 to 10.0. A simple patch to te923_com.h is required. This diff output actually is a change to a single line that I split up for clarity here:
@@ -138,7 +138,7 @@
}
else {
- data->uv = bcd2int( buf[18] & 0x0F ) / 10.0 +
bcd2int( buf[18] & 0xF0 ) +
bcd2int( buf[19] & 0x0F ) * 10.0;
+ data->uv = bcd2int( buf[18] & 0x0F ) / 10.0 +
bcd2int( ( buf[18] & 0xF0 ) >> 4 ) +
bcd2int( buf[19] & 0x0F ) * 10.0;
data->_uv = 0;
}The next thing to address is the permissions problem. To this point, the only way to get data from the station was to be root. Otherwise, you get this error:
[mcp:…/te923/te923] te923con -D
Error while setting configuration (-1).This is a generic issue with USB devices, and I found an item on a wiki (http://wiki.openstreetmap.org/wiki/USB_Garmin_on_GNU/Linux#Fixing_Device_Permissions) about GPS units that got me going.
That page discusses how to set the group ownership on the device, as well as the permissions on the device. Long story short, I created the device rule set /etc/udev/rules.d/99-te923.rules (all on one line):
ATTRS{idVendor}=="1130", ATTRS{idProduct}=="6801",
MODE="0660", GROUP="plugdev"idVendor and idProduct identify the TE923 weather station, mode tells the USB driver to give read/write permissions to the user and group that owns the device, and group tells the driver to assign group ownership to “plugdev”. My user on the machine is a member of that group so I should be OK.
Ask the system to reload the USB rulesets:
[mcp:.../te923/te923] sudo udevadm control --reload_rulesAnd now I can get valid data back from the unit without being root:
[mcp:.../cwanek/cronjobs] te923con
1273414489::::59:::::::::1003.1:5.0:3:0:9:0.4:0.0:11.7:215Unfortunately, though, some readings (specifically current temp readings) are empty. Even wide-open permissions on the device don’t help. This doesn’t make sense to me, and I have not yet solved this issue, so I’m still stuck with being root to run te923con. I’d love to know why it would work only partially.
Still, I don’t really want to have root’s crontab running the script, so I configured sudo to skip the password prompt for the group plugdev for the te928con application. With visudo, add:
%plugdev ALL=NOPASSWD: /usr/local/bin/te923conMoving on, the I was still not able to run te923con without removing the USB human interface device module (sudo rmmod usbhid). While removing it allows access to the te923 station, it would also cause any other HID like a mouse or keyboard to stop functioning. So the trick is to get the usbhid module to release just the weather station.
There are many sites that document how to get usbhid to unbind a device. I found http://lwn.net/Articles/143397/, which gave me the following command:
sudo bash -c "echo -n 2-1:1.0 > /sys/bus/usb/drivers/usbhid/unbind"bash -c is required so the shell redirection to unbind will succeed.
Digging deeper, I learned (http://reactivated.net/writing_udev_rules.html) that you can configure the unbind to happen immediately after the device is connected, by using the “RUN=” option in the device rules file (this is all on one line in /etc/udev/rules.d/99-te923.rules):
ATTRS{idVendor}=="1130", ATTRS{idProduct}=="6801",
MODE="0660", GROUP="plugdev",
RUN="/bin/sh -c 'echo -n $id:1.0 > /sys/bus/usb/drivers/usbhid/unbind'"So now, apart from the missing data when running as a non-privileged user, the te923 weather station is coexisting with other USB devices, and I am able to schedule the upload script in my own user crontab.
There’s one last thing…
Interesting stuff. How do you find the reliability of the RF link between sensors and base on your station?
In terms of USB on Linux (Debian in my case), I find that I only get incomplete data if there is a HID device attached. Unplug the keyboard/mouse and I get the full data set, though running as root. Not sure why that’s the case.
Does your rain data make sense to you? I’m currently looking at what may be a bug in the 0.4 code that misses the last byte off the values read for rc. Good luck!
I have had what seem to be issues with the RF between the anemometer and UV sensor, but they are on a pole on the roof, and the controller is two floors below. Back in the spring, it seemed like snow would lock up the vane and cups on the anemometer also.
I’ve had no issues with the reliability of the rain and temp/humidity sensors. They’re closer and only have one wall between them and the controller. When I was first setting the station up I did run across this thread about modifying the antenna: http://www.weather-watch.com/smf/index.php?topic=29813.0
That’s interesting about incomplete data with kbd/mouse. Mine is a headless server, so I haven’t got any experience with that. I should give it a try sometime (I also am using Debian).
By missing the last byte, do you mean the high-order or low-order byte? The rain data makes sense to me so far, but in Colorado we don’t get all that much rain (my RC is only up to 466).
When setting the station up, and messing around with my PHP code, I counted clicks of the counter while pouring a glass of water through the rain gauge. The counter data matched my counts, and I used the rain display to come up with the counter -> accumulation scale. The scale was very close to the published resolution of the station, so I thought I was OK as far as the RC goes.
Reading through the source some more, I *think* that the author of that code believes that byte of data is meant to be an indicator of valid values (i.e. a good sensor link), rather than part of the actual rain counter value. His decoding of other sensor values seems to follow that pattern.
The RC is laid into bytes 30 and 31 little-endian, so I don’t think it makes sense for byte 29 to be part of the counter on either end.
With my RC at 466, I have obviously rolled over the capacity of a single byte, but have quite a way to go to roll over the capacity of two bytes. Here are the current values in the RC data:
[DEBUG] RAINC BUF[29]=e0 BUF[30]=d2 BUF[31]=01
A counter of 466 is a sane value for my station, and adding e0 either as a high-order or low-order byte of the RC value just doesn’t seem right. I seem to recall seeing that byte flip between e0 and 00, but can’t swear to it.
So given my interpretation of the source code and values I see now, I think byte 29 is not important to the RC value, though I can’t guess what it does mean.
I tried the te923con with a mouse plugged in and had no problems. I got complete data every time. My server has many banks of USB ports, and everything worked regardless of the which one I plugged the mouse into.
First, here’s without the mouse:
[hal:/home/mrbalky] ll /sys/bus/usb/drivers/usbhid
total 0
–w——- 1 root root 4096 2010-08-23 18:51 unbind
–w——- 1 root root 4096 2010-08-25 18:07 uevent
–w——- 1 root root 4096 2010-08-25 18:07 new_id
lrwxrwxrwx 1 root root 0 2010-08-25 18:07 module -> ../../../../module/usbhid/
–w——- 1 root root 4096 2010-08-25 18:07 bind
[hal:/home/mrbalky] sudo bin/te923con -i-
1282781540:23.50:47:27.10:31:-:-:-:-:-:-:-:-:1011.1:3.4:4:0:10:1.1:0.6:32.8:466
And here’s with:
[hal:/home/mrbalky] ll /sys/bus/usb/drivers/usbhid
total 0
–w——- 1 root root 4096 2010-08-23 18:51 unbind
–w——- 1 root root 4096 2010-08-25 18:07 uevent
–w——- 1 root root 4096 2010-08-25 18:07 new_id
lrwxrwxrwx 1 root root 0 2010-08-25 18:07 module -> ../../../../module/usbhid/
–w——- 1 root root 4096 2010-08-25 18:07 bind
lrwxrwxrwx 1 root root 0 2010-08-25 18:14 1-2:1.0 -> ../../../../devices/pci0000:00/0000:00:1d.0/usb1/1-2/1-2:1.0/
[hal:/home/mrbalky] sudo bin/te923con -i-
1282781688:23.50:47:27.00:30:-:-:-:-:-:-:-:-:1011.1:3.4:4:0:9:1.1:1.0:32.7:466
Hi
well done for all your work.
I have one of these stations, and I modified a number of other peoples code to run a data collector/database storer on OSX, using java/c++/jndi/jna. Yes got all the HID problems as well, but under OSX its easier (no kext required)
I have embedded your UV fix into my code, my other query is wind gusts, they seem a bit low, I read the data in using Hideki’s software under windows to verify it, but still not totally convinced.
A word of caution regarding the UV detector, they are not waterproof!! and water ingress will either give stupid reading or cause it to fail.