[Nut-upsuser] empty ups.status on TrippLite SMART1500RMXL2U

Charles Lepple clepple at gmail.com
Thu Jan 24 19:22:44 UTC 2008

On Jan 24, 2008 11:31 AM, Justin Ellison <justin at techadvise.com> wrote:
> Hi Charles,
> On Wed, 2008-01-23 at 07:31 -0500, Charles Lepple wrote:
> > ups.power.nominal seems like it should be 1500 instead of 150. Is the
> > input voltage actually 120 VAC? How are the outlets grouped? (That is,
> > how many are switchable, and how many are on all the time?) Also, what
> > are the USB product and vendor IDs (available from lsusb)?
> The Windows software also reports protocol 0004.  This is an old unit,
> probably 5 years old or so.  I looked, but didn't see any way to update
> firmware on this UPS.

Ah, OK. Well, since it's a unique protocol ID, we can add that to the code.

> It's a 1500VA, so yeah, no idea why it reads 150.  Input is 120V.

Good. I'll see about adding a x10 scale factor in there.

> There are two load groups, load 1 is switchable, and has two outlets on
> it.  load group 2 is not switchable, and contains the other six outlets.
> I'm running Nut in an embedded environment, and don't have lsusb
> available.  I can setup Nut on my laptop for testing if need be, but
> here's the relevant section of /proc/bus/usb/devices:
> T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=1.5 MxCh= 0
> D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=09ae ProdID=0001 Rev= 0.01
> S:  Manufacturer=TRIPP LITE
> S:  Product=  Tripp Lite SMART1500RMXL2U
> C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 60mA
> I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=00 Driver=(none)
> E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=200ms

Works for me. The important parts here are the vendor/product IDs, and
the Ivl=200ms (the polling interval).

> > If you are mainly concerned with on-battery/on-line and low battery
> > indications, just hook up the unit with a dummy load (so as not to
> > crash the computer when the batteries die) and run the batteries down
> > while monitoring the "ups.debug.S" line.
> >
> > Even better would be to compare values directly with what the Tripp
> > Lite software returns, if you have a Windows system available. If you
> > go that route, we could also look at a USB protocol dump.
> My primary concern is battery status, but it would be nice to have all
> the other features too.  I can hijack my wife's laptop for awhile to do
> the dump, but I'm unfamiliar with the internals of the PowerAlert
> software.  What do I need to do to get you the data you need?

It's been a while since I last used PowerAlert, as well.

Does this UPS have two USB ports?

Basically, the ups.debug.* lines are the hex results from sending
commands to the UPS. All of the commands have the same general form
(so far, anyway), which is good because it means they all respond to
the protocol query command the same way.

The difference is in how they report values. Some protocol numbers use
hex digits, and some send straight binary. We can stare at the
ups.debug.* lines all day, but we can make more educated guesses if we
look at PowerAlert at the same time as the output of upsc (if you have
two USB ports, anyway).

The next best way would be to get a bunch of readings from the
PowerAlert software, then plug back into NUT and see what the
ups.debug.* lines say. It won't be an exact match, but we can probably
tell where the voltages and load values are returned.

For status, the main things you want to get are OL (online), OB (on
battery), LB (low battery), etc. Of course, testing LB can be even
more risky, which is why we recommend plugging in a dummy load to the
UPS during testing (a few light bulbs will drain the UPS, but they
don't have buffers to flush when the power goes out). Also, I believe
the status is at "14..." because you are online, but have not done a
battery test recently. For completeness, you may want to throw in a
battery test (probably just with NUT connected, since the test event
will probably not last too long).

If you want to do this incrementally (first sort out status, then get
values for voltages, etc.), then you may be interested in checking out
a copy of the NUT trunk via SVN. There are a few extra tools
(autoconf, automake, libtool, ...) that you'd need to install, so it
may be a hassle if you don't do much development there. In that case,
you can stick to the snapshots on Buildbot (from the first column),
but you'll have to rebuild everything each time (whereas SVN updates
only the code that has changed). Instructions here:


- Charles Lepple

More information about the Nut-upsuser mailing list