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

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!).  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?

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.

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.

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".  :-)

Steve Ballantyne
Network Engineer
MCSE/MCDST; Novell CLA; LPIC-1; CTT+; A+; Network+; Linux+; Server+;
I-Net+; Security+; SonicWALL CSSA

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

On Thu, Jul 10, 2014 at 10:33 PM, Charles Lepple <clepple at gmail.com>
wrote:
> Sounds like we can merge that branch into master?
I thought I had discovered a firmware difference (or something)
because I couldn't get the battery tests to run.  But then I realized
that I wasn't running the actual test under the right user, with the
right permissions.  Duh.  So I then went back and tested it against
three other Rpi/Tripp-Lite SMARTUPS500RT1U units and had success with
every one of them.  I am not sure how variant the firmware is, but I
can tell you that some of these units were purchased almost a full
year ahead of one of the others and they all work the same.  So I
would say that you are fine to commit your changes!
> Plugging into the same hub usually assigns them the same bus.
:-(  Yep, it did.
> To kludge around this, add a hub in front of one UPS, and plug the other
UPS directly into the host.
I hadn't thought of that.  I am actually using a "2 port hub", or
a
non-powered splitter so that I can attach three UPS's to a two USB
port RPi.  But I hadn't thought about trying to identify the UPS by
the hub it's plugged into?  Perhaps I will play with that.  I could
chain two splitters together, use a native port, and make all three
work!  Hah!  Kidding of course.  This may be a multiple RPi job.
> I guess I assumed you had a 1:1 mapping between the UPS and Raspberry Pi
boards.
Yep, there is only this one rack in my environment with multiple
Tripp-Lites in it.  Kind of peed' me off when a vendor came in and
dropped all this crap into my rack.  I had purchased a Liebert 2500
watt UPS just for their stuff, and now all that is plugged into it is
one of my small switches.  When the batteries go in them, I will
probably yank them out and get everyone onto the one monitored
Liebert.

Thanks again for your help Charles.  I have written some shell scripts
to do some testing for me which I can share to the community if you
think it might be helpful.  My environment is probably far different
than the common user.  I don't care to run shutdown scripts, because
instead of servers I have a single Cisco switch plugged into most of
mine.  Since the switch is running off of flash, and has no "safe
shutdown routine", with the power is gone, it's gone!  But I still
need to know about it.  So my shutdown routine is more of an alert
routine.

Anyhow, let me know if you think that would be useful.  Otherwise, I
will keep it under my hat.  I'm not out to de-rail or confuse people
who are using the product as it was intended.  ;-)

Steve Ballantyne
Network Engineer
MCSE/MCDST; Novell CLA; LPIC-1; CTT+; A+; Network+; Linux+; Server+;
I-Net+; Security+; SonicWALL CSSA