On 06/06/2012 06:29 PM, Charles Lepple wrote:
On Jun 6, 2012, at 6:46 PM, Seth Galitzer wrote:
I'm trying to set up a single host to monitor the state of several UPS in my data center. I have a
mix of several APC and Tripp-Lite in production. The former are great, the latter are not so much.
With the APCs (using usbhid-ups), I can set up configs for each based on the value they report
from ups.serial. With the Tripp-Lites (using tripplite_usb), there is no value returned for
ups.serial (serial=12345 in ups.conf), and debug output says the serial is "unknown".
The driver does read a "Unit ID" value, but this appears to be the same for all devices
and I have not yet found a way to configure this in the device firmware manually.
Are there any plans to support this in the near future? Is there anything I
can do to help support this? I would like to be able to check all of the UPS
from a single host, but without a way to differentiate them, I'm out of luck.
The "ups.serial" value is easy to read during a USB bus scan - since it is in
the USB device descriptor, it is possible to read without exclusively opening the device.
Tripp-Lite's "Unit ID" is buried deep in their serial-over-USB protocol, and I
don't know of a good way to read it until after the device has been matched (skipping
over devices which are being handled by other driver instances).
(Actually, you should be able to set the Unit ID manually - it is an unsigned 16-bit number,
and you would use something like "upsrw -s ups.id=<value> tl1@localhost". You
will be prompted for a username and password that can be specfied in upsd.users. But it isn't
as useful due to the problem of matching against it.)
Long term, we might be able to restructure the USB bus scan code to handle
this, but I don't think we have plans for that. (In particular, libusb doesn't
provide a clean way to figure out whether we are attempting to detach a kernel
driver from an UPS, or whether it is detaching another userspace process such
as a NUT driver.)
In your case, you can work around the problem by specifying the USB bus number
(which is subject to change as kernels are upgraded, or if intermediate USB
hubs are added) in ups.conf.
upsrw reports ups.id is a string, which could be useful if I could match
against it, but if I read your statement correctly, I cannot.
Matching on USB bus number would not be optimal, since this changes even
when a device is unplugged and replugged along with in between system
boots. So I'd have to look them all up and reconfigure ups.conf with
every reboot. Doable, but a royal pain to maintain.
I didn't realize nut was using some kernel drivers. I just assumed
everything was all local to the app. I'm eventually getting rid of all
of these and switching to a larger room-size UPS instead. That won't be
for several months yet, but it will greatly simplify my monitoring needs.
Thanks.
Seth
--
Seth Galitzer
Systems Coordinator
Computing and Information Sciences
Kansas State University
http://www.cis.ksu.edu/~sgsax
[email protected]
785-532-7790
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
