[Nut-upsuser] Multiple instances of the same model, with same ID and no serial number!

[Charles Lepple]

On Jul 10, 2014, at 1:00 PM, Steve Ballantyne <steve.ballantyne at gmail.com> wrote:

> How is this for a conundrum?
> 
> I have three Tripp-Lite SMART5001U's running in the same one rack,
> attached to the same host running NUT.  I am running the tripplite_usb
> driver thanks to some crafty hacking of Charles (thank you sir!).

Sounds like we can merge that branch into master?

> Now you may ask, "hey dip****, why have THREE 1U UPS's stacked up, when
> you can have a single larger one with the capacity of three?".  Don't
> ask.  I didn't build this stack of stupidity.  I only have to support
> it!
> 
> But being that all of these buggers are identical ... I cannot get nut
> to tell them apart and so I can only monitor one of them at a time!
> Before I go writing a script that bounces between the three of them,
> is there a way I can get all three to work?

Short answer: not well. If you can tolerate the potential for changes in bus assignments (tends to happen occasionally with kernel upgrades) and the UPSes are indeed on different bus numbers, you can use the bus parameter.

Plugging into the same hub usually assigns them the same bus. To kludge around this, add a hub in front of one UPS, and plug the other UPS directly into the host. Beware that you are adding an additional point of failure, and will need probably to power this hub if it is not bus-powered.

> It seems that I can use 'sudo /usr/local/ups/bin/upsrw -u pi -p pi -s
> ups.id=1 SMART500RT1U-1 at localhost' to change the id (from the default
> of zero).  But then when I load up the next one, nut says "oh, I
> remember this one ... it has an id of 1!".  So it assigns '1' as the
> id of the second UPS, then dropping the first.  UGH.

Something like that... The ups.id value should stay stored on the actual UPS, but I admit that I did not test swapping the UPSes while the driver is running (I had enough problems just reconnecting to a single UPS). The reconnection code would usually match the same serial number, but if there is no serial number present, that's a wildcard.

This is the problem described in the last paragraph under "Known Issues and Bugs" in the man page. The only way to read the ID is to open the device, which means detaching the kernel HID driver, and that's somewhat invasive.

> Then I was looking at using the driver to try and change the serial
> number at load time, like this 'sudo /usr/local/ups/bin/tripplite_usb
> -u pi -a SMART500RT1U-2 -x serial=1' but I get an error, "No matching
> USB/HID UPS found".  That tells me that the -x options are to help
> match a unit.  Not to go changing the properties on the fly.

Right. With libusb, you enumerate all of the USB devices on the system, and the only identifiers are the things you would get back from "lsusb -v": the bus number, the numeric VID and PID, the vendor string, the product string, and the serial number. (The device number isn't stable, in that it can change every time you plug the UPS in, even to the same port.)

The first driver claims the first UPS in the enumeration process, but currently, the second driver can't tell that the first UPS has been claimed until after it tries to open it. It would be possible to rewrite that loop to open the first unclaimed UPS, but I'll be honest: I don't want to debug that. Then there is still a chance that they are enumerated in the wrong order.

> Can anyone think of a clever way to make this work?  The only thing
> that really defines these as different is the /dev/bus/usb value.  So
> I would need some way of telling NUT to "fake it".  :-)

The bus value should work to distinguish the UPSes, although it isn't set in stone, and as I mentioned, a new kernel might number the buses differently. If you were, for instance, just totaling up the power consumed (bearing in mind that an UPS is not really a measurement device), it would work, assuming no gaps in the bus numbers. But if somehow UPS #1 got assigned the bus that was formerly for UPS #2, then you might end up shutting down the wrong system.

I guess I assumed you had a 1:1 mapping between the UPS and Raspberry Pi boards.

The hack I used with two Tripp Lite UPSes in a portable rack was that we had two different models (something like a 1500VA and a 2200VA; don't quote me on that), and we matched on the model name.

-- 
Charles Lepple
clepple at gmail