Nut upsuser - May 2014 - Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?

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>

On May 22, 2014, at 10:03 AM, Stefan Bruda wrote:
>> 
>> 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.
Good.
> 
>> 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).
Sorry, I wasn't clear. I meant to say that the voltage value read from the
UPS is a voltage scaled to match a single 12V battery, and that there is a
multiplier in the "V" response which determines the
battery_voltage_nominal value.

See attached. Still doesn't have the writable V_interval values, but I
probably won't have time to test that until later.

Don't worry about the battery physical properties for now - the problem
there is that we don't have enough information from the UPS to do a proper
calculation. With the V_interval[] settings, you can tweak the new
state-of-charge calculation to match what you see via upsc when the battery is
fully charged, so that's better than nothing.
> 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).
I think we can strike a balance between trying to improve the
TRIPP_LITE_SMARTPRO case, without intentionally breaking TRIPP_LITE_SMART_0004.
If someone with a Protocol 0004 unit steps up to help with testing, we can try
and fix that case then.

Here, s_value[5] seems to be an ASCII digit:
   http://lists.alioth.debian.org/pipermail/nut-upsuser/2009-June/005154.html
>> 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.
Yes, the latter case: although fully draining a lead-acid battery isn't
recommended too often, one could conceivably log the battery.voltage values
while the UPS drains the battery to the LB threshold (we'll call that 10%),
then get the fully-charged voltage, and use those for the V_interval settings.

Re-reading the comments, the "Tripp Lite source" refers to an old
open-source package from Tripp Lite which decodes the values from their serial
UPSes. It had a table of voltage-to-charge values, and the dv/dq calculation was
an interpolation of those values.
>> 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).
The granularity of having an "experimental" flag for the entire driver
isn't optimal, but maintaining even more detailed information is tough, as
well. Hence, the recommendation to test everything.
>  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.
Same here: as far as Tripp Lite hardware, I only have an old OMNIVS1000, which
is apparently different than an OmniVS1000 (!) that has a different USB
ProductID, and talks to usbhid-ups. This is where the "no warranty"
clause of the GPL kicks in :-)
>> 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?
I think so. I'll try to add a fall-back option to re-enable that if
necessary, but I believe the OS X kernel is already setting this, and the UPS
does not react well to setting it a second time.
> 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.

Thanks, that is a useful data point. Does Gentoo have an easy way (short of
installing the whole OS) to see what those patches are? I assume they are kept
in a version control repository, but I don't know enough of the
portage-related vocabulary to quickly search for that.

Gentoo would be a good addition to the NUT Buildbot, but the build farm hardware
is somewhat memory-constrained at the moment.

-- 
Charles Lepple
clepple at gmail


-------------- next part --------------
A non-text attachment was scrubbed...
Name: tripplite_usb_battery_charge.patch
Type: application/octet-stream
Size: 3200 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140523/0252c8e7/attachment.obj>

Hello,

At 09:24 -0400 on 2014-5-23 Charles Lepple wrote:
 >
 > See attached. Still doesn't have the writable V_interval values,
 > but I probably won't have time to test that until later.

Thank you for the patch.

 > Don't worry about the battery physical properties for now - the
 > problem there is that we don't have enough information from the UPS
 > to do a proper calculation. With the V_interval[] settings, you can
 > tweak the new state-of-charge calculation to match what you see via
 > upsc when the battery is fully charged, so that's better than
 > nothing.

Yes, the V_interval[] being exposed is a very good idea and does seem
the only sensible workaround.

 > > 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.
 > 
 > Thanks, that is a useful data point. Does Gentoo have an easy way
 > (short of installing the whole OS) to see what those patches are?

Sure.  Gentoo is a port-based, source distribution, so the patches are
in the local Portage tree (code word for the collection of ports, or
ebuilds as they are actually called in Gentoo;-) ).  I am attaching
the complete ebuild to this message (I am sure that the files are also
available somewhere on the Web but I never looked since I already have
them locally so I don't know where).  Note that I renamed the
directory from nut to nut-gentoo to eliminate any possible confusion.

I am using nut-2.7.1.ebuild (latest available).  Most of the content
is irrelevant to you -- in fact I believe that the only useful
information would be the Gentoo patches which for 2.7.1 appear to be:

    files/nut-2.4.1-no-libdummy.patch
    files/nut-2.6.2-lowspeed-buffer-size.patch
    files/nut-2.7.1-fix-scanning.patch
    files/nut-2.7.1-snmpusb-order.patch

(they are all applied to 2.7.1 despite their names).

 > Gentoo would be a good addition to the NUT Buildbot, but the build
 > farm hardware is somewhat memory-constrained at the moment.

No worries, there is nothing to build for Gentoo...

In any event, thank you very much for the assistance.  The current
incarnation of nut works substantially better on my system.  I would
also be more than happy to help in the future so drop me a line as
needed.

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>

[ATTACHMENT ~/nut-gentoo.tar, application/x-tar]