[Nut-upsuser] Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?

Thu May 22 14:03:07 UTC 2014

Hello,

At 22:19 -0400 on 2014-5-19 Charles Lepple wrote:
 >
 > On May 19, 2014, at 7:12 PM, Stefan Bruda wrote:
 > 
 > > Therefore as far as my UPS is concerned s_value[5] is wildly
 > > incorrect.
 > 
 > So it turns out that the RM15002U also does not report anything useful for s_value[5]:
 > 
 > http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-January/002076.html
 > 
 > We really should ask the author of tripplite_usb what he was thinking :-)

Well, it does produce a number between 0 and 100, which might even
mean the battery charge for some UPSes...

 > > ------ begin patch ------
 > > --- tripplite_usb.c.original    2014-05-19 16:20:58.251634449 -0400
 > > +++ tripplite_usb.c     2014-05-19 16:53:54.806609602 -0400
 > > @@ -1098,8 +1098,8 @@
 > > 
 > > -               /* This may not be right... */
 > > -               if(tl_model == TRIPP_LITE_SMARTPRO) {
 > > -                       battery_charge = (unsigned)(s_value[5]);
 > > -                       dstate_setinfo("battery.charge",  "%u", battery_charge);
 > > -               }
 > >        }
 > > 
 > > @@ -1167,9 +1167,22 @@
 > >                                hex2d(d_value+1, 2) * input_voltage_scaled / 120);
 > > 
 > >                bv = hex2d(d_value+3, 2) * battery_voltage_nominal / 120.0 ;
 > 
 > Does battery_voltage_nominal get set correctly? Theoretically, it
 > should be 48, since the 2nd and 3rd digits of ups.debug.V are 08,
 > and that gets multiplied by 6.

Yes, as it appear as 48V in the output of upsc.

 > Might be useful to have an intermediate value that doesn't scale to
 > actual battery voltage for the charge calculation, since bv seems
 > to be some sort of ratio relative to a 12V battery.

I am game, but what would a more appropriate value be?  I am new to
the intricacies of reverse engineering Tripp Lite UPSes so I don't
really know how to proceed... ;-)  I am not even terribly familiar
with the properties of lead-acid batteries (such as the variance of
the internal resistance and the such).

 > > -
 > > +               // bv is 48V nominal rather than 12V
 > > +
 > >                dstate_setinfo("battery.voltage", "%.2f", bv);
 > > 
 > > +               if(tl_model == TRIPP_LITE_SMARTPRO) {
 > > +                       if (bv / 4 >= V_interval[1])
 > > +                               bp = 100;
 > > +                       else if (bv / 4 <= V_interval[0])
 > > +                               bp = 10;
 > > +                       else
 > > +                               bp = (int)(100*sqrt((bv / 4 - V_interval[0])
 > > +                                                           / (V_interval[1] - V_interval[0])));
 > > +                       dstate_setinfo("battery.charge",  "%3d", bp);
 > > +               }
 > > +
 > >                /* - * - * - * - * - * - * - * - * - * - * - * - * - * - * - */
 > > 
 > >                ret = send_cmd(m_msg, sizeof(m_msg), m_value, sizeof(m_value));
 > > ------ end patch ------
 > > 
 > > This is against NUT 2.7.1 and so will probably not apply cleanly on
 > > the current latest and greatest.  I would not apply it as is anyway
 > > since it is quick and dirty and I am sure that it may be simplified
 > > (the conditional in particular is probably not needed...).
 > 
 > Not much has changed between 2.7.1 and 2.7.2+git, so it might not
 > be that bad.

It should apply, but somebody more familiar with the thing should
verify the code.  For instance is this only applicable to tl_model ==
TRIPP_LITE_SMARTPRO (as in my code)?  How about tl_model ==
TRIPP_LITE_SMART_0004?  This one supposedly also responds to a "D"
message with (again supposedly) the same kind of response, but maybe
s_value[5] is better in this case.  In my patch I simply did not care
about it and I would not know whether to care or not since I don't
have access to this kind of UPS.  Any modification would be a matter
of wild guesses for me (though I am not sure whether others have better
foundations for their guesses either ;-) ).

I believe that the other type is left in the dark anyway when it comes
to the battery charge (so this code will at least not do any harm for
TRIPP_LITE_SMART_0004), but I might be wrong (I did not cover more
than 10% of the code really).

 > > The result seems to be quite a bit off compared with the output of
 > > Poweralert, as follows: 90% Poweralert = 50V = 79% as reported by the
 > > modified NUT.  A bit afterward the voltage falls to 49.2V (= 73% in
 > > the modified NUT) but Poweralert still reports 90%.  Later still (but
 > > not much later) Poweralert gets down to 80% = 48.4V = 67% as per the
 > > modified NUT.  I have not tested anything lower than this.
 > > 
 > > In related matter:
 > > 
 > > 1. The voltage as read by NUT is precisely the voltage read by
 > > Poweralert.  So if the voltage is in direct relationship with the
 > > remaining charge (which it should, however roughly) then all is needed
 > > is some computation to figure it out.
 > 
 > It's going to be a rough estimate for sure, since it depends on the
 > load, plus whatever internal resistance the battery has built up
 > over time.

Agreed.  Moreover a precise value seems to be available from the UPS
which is tantalizing (this, or Poweralert performs the same kind of
calculations, but in a smarter way).  Problem is, I have no idea where
to get it from...

 > Maybe what we do is expose the V_interval[] entries as options in
 > ups.conf (or even upsrw variables), and use those in lieu of
 > s_value[5] if they are set.

>From what I see in the code V_interval[] is hard coded rather than
being read from the UPS.  Oh, I see, you mean that various users will
set this to whatever works for their UPS, right?  Yes, I believe this
to be a very good idea, so that people can effectively modify the
parameters without recompiling the code.

 > Given how long this code has been this way, either nobody else has
 > run into this (and s_value[5] has a different meaning) or nobody
 > trusts battery.charge, and your code will be an improvement.

Well, I seem to recall that it is mentioned in the documentation that
the value is not to be trusted (I am not sure whether it is this value
or overall the output of the driver which is labelled as
experimental).  I have been running NUT for several years with this
UPS without caring about that value -- as long as a battery critical
event turned my machines off I was happy. :-) The reason I started
investigating this is that I wanted to see whether the mentioned
external battery pack is taken into consideration by the UPS and I
discovered that I have no means of seeing if it is so.

This all being said, I cannot vouch whether my code is useful or not
-- please keep in mind that I only have one UPS to play with so the
result is not necessarily portable.

 > While you're in there, can you check to see if everything still
 > works if you comment out the "usb_set_altinterface(udev, 0)" line
 > from drivers/libusb.c? (You might need to unplug and re-plug the
 > UPS to be certain.) 

I have commented out the line and upsc seems to behave as before.  I
have not performed any other test but this should be enough to show
that the line is not useful, right?

In case it matters by the way this is all happening on a box running
kernel version 3.12.13 with Gentoo patches.  The NUT I am playing with
is the stock Gentoo unstable variety, meaning version 2.7.1 with some
Gentoo patching on top.

Best regards,
Stefan

-- 
If it was so, it might be; and if it were so, it would be; but as it 
isn't, it ain't.  That's logic.  --Lewis Carroll, Through the Looking-Glass

No HTML emails and proprietary attachments please <http://bruda.ca/ascii>