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.

-- 
Charles Lepple
clepple@gmail




_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Reply via email to