[Nut-upsdev] no serial number for Tripp-Lite SMART3000RM2U?

[Charles Lepple]

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 at 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 at gmail