On Jul 10, 2014, at 1:00 PM, Steve Ballantyne <[email protected]> 
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@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@gmail




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

Reply via email to