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

[Seth Galitzer]

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 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.
>

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
sgsax at ksu.edu
785-532-7790