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

Hello,

I own an older Tripp Lite SMART3000RM2U (protocol 3003).  It does not
work with usbhid-ups but it mostly works with the tripplite_usb driver
(nut 2.7.1, the latest in the Gentoo tree), in the sense that the
status (on line, on battery, etc.) is detected correctly, the machine
is shut down on critical battery, and I can even get some information
from the UPS.  This is how it all looks:

    < post:/etc/nut > upsc post
    battery.charge: 40
    battery.test.status: Battery OK
    battery.voltage: 52.00
    battery.voltage.nominal: 48
    device.mfr: Tripp Lite
    device.model: SMART3000RM2U
    device.type: ups
    driver.name: tripplite_usb
    driver.parameter.pollinterval: 2
    driver.parameter.port: auto
    driver.version: 2.7.1
    driver.version.internal: 0.20
    input.frequency: 59.9
    input.frequency.nominal: 60
    input.voltage: 123
    input.voltage.maximum: 125
    input.voltage.minimum: 119
    input.voltage.nominal: 120
    outlet.1.desc: Load 1
    outlet.1.id: 1
    outlet.1.switch: 1
    outlet.1.switchable: 1
    outlet.2.desc: Load 2
    outlet.2.id: 2
    outlet.2.switch: 1
    outlet.2.switchable: 1
    outlet.3.desc: Load 3
    outlet.3.id: 3
    outlet.3.switch: 1
    outlet.3.switchable: 1
    outlet.4.desc: Load 4
    outlet.4.id: 4
    outlet.4.switchable: 0
    ups.debug.D: 37 42 38 32 0d 00 00 '7B82...'
    ups.debug.load_banks: 3
    ups.debug.S: 31 30 30 00 28 30 0d '100..0.'
    ups.debug.T: 39 37 32 35 37 31 0d '972571.'
    ups.debug.V: 31 30 38 33 58 58 0d '1083XX.'
    ups.delay.shutdown: 64
    ups.firmware: F1115.B
    ups.firmware.aux: protocol 3003
    ups.id: 65535
    ups.load: 9
    ups.mfr: Tripp Lite
    ups.model: SMART3000RM2U
    ups.power.nominal: 3000
    ups.productid: 0001
    ups.status: OL
    ups.temperature: 33.9
    ups.vendorid: 09ae

What bugs be though is that I cannot seem to be able to read the
remaining run time on battery.  The battery charge is also widely
inaccurate (it drops to zero really fast and stays there).  I read
somewhere that the usb.debug numbers may hold the key to this (at
least to the running time that is), but I don't know what to do with
them (and I can no longer find that piece of information...).

Is there any way I can contribute to finding a way to get this
information out of the UPS?  I will gladly perform any necessary
investigations (but please note that I am completely unfamiliar with
the NUT code base).

Many thanks in advance!

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 15, 2014, at 9:39 PM, Stefan Bruda wrote:
> What bugs be though is that I cannot seem to be able to read the
> remaining run time on battery.  The battery charge is also widely
> inaccurate (it drops to zero really fast and stays there).  I read
> somewhere that the usb.debug numbers may hold the key to this (at
> least to the running time that is), but I don't know what to do with
> them (and I can no longer find that piece of information...).
Here's where the battery.charge variable is calculated:

  
https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1099

   battery_charge = (unsigned)(s_value[5]);

(In that file, the 3003 protocol is denoted by "tl_model ==
TRIPP_LITE_SMARTPRO".)

Due to the command prefix characters in the protocol, the ups.debug.S hex values
are actually indexed from 1 as follows:

              1  2  3  4  5  6  7

ups.debug.S: 31 30 30 00 28 30 0d '100..0.'

Hence, your s_value[5] yields 0x28 == 40%.

That said, a lot of information was either observed empirically, or taken from
this email:

  
http://lists.alioth.debian.org/pipermail/nut-upsuser/2005-September/000218.html

You will note that neither battery charge nor runtime is listed there.

It is possible that a better value for the state-of-chage could be calculated,
similar to the other protocols:

  
https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1129

However, calculating runtime usually requires the UPS to do a battery test, and
observe the voltage while under load. This unit might not be capable of doing
that.

-- 
Charles Lepple
clepple at gmail

Hello,

First of all thank you so much for the information.

At 22:43 -0400 on 2014-5-15 Charles Lepple wrote:
 >
 > On May 15, 2014, at 9:39 PM, Stefan Bruda wrote:
 > 
 > > What bugs be though is that I cannot seem to be able to read the
 > > remaining run time on battery.  The battery charge is also widely
 > > inaccurate (it drops to zero really fast and stays there).  I read
 > > somewhere that the usb.debug numbers may hold the key to this (at
 > > least to the running time that is), but I don't know what to do
with
 > > them (and I can no longer find that piece of information...).
 > 
 > Here's where the battery.charge variable is calculated:
 > 
 >   
https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1099
 > 
 >    battery_charge = (unsigned)(s_value[5]);
 > 
 > (In that file, the 3003 protocol is denoted by "tl_model ==
TRIPP_LITE_SMARTPRO".)
 >
 > Due to the command prefix characters in the protocol, the
 > ups.debug.S hex values are actually indexed from 1 as follows:
 > 
 >               1  2  3  4  5  6  7
 > 
 > ups.debug.S: 31 30 30 00 28 30 0d '100..0.'
 > 
 > Hence, your s_value[5] yields 0x28 == 40%.

Thank you.  I do not remember the exact number but the battery level
was nowhere near 40% at the time (more like 80%).  Furthermore the
above line was obtained while charging; when on battery s_value[5]
falls to 0 almost immediately and stays there.

Therefore as far as my UPS is concerned s_value[5] is wildly
incorrect.
 
 > That said, a lot of information was either observed empirically, or
 > taken from this email:
 > 
 >   
http://lists.alioth.debian.org/pipermail/nut-upsuser/2005-September/000218.html
 > 
 > You will note that neither battery charge nor runtime is listed
 > there.
 > 
 > It is possible that a better value for the state-of-chage could be
 > calculated, similar to the other protocols:
 > 
 >   
https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1129

Many thanks for the pointer.  I tried something like the above but the
"B" message is not answered (errors are spit by libusb too).  However,
I did notice that the battery voltage is available in the 3003
protocol (as a response to the "D" message), so I computed the battery
charge percentage starting from that, along the following line:

------ 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 ;
-
+               // 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...).

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.

1. The nominal voltage of the battery pack is 48V rather than 12V
(hence the division of bv to 4), but I am assuming that the
relationship between the voltage and the charge still holds (since
these are the same batteries, just that they are connected in series).

2. The UPS I am experimenting on has an external battery pack
connected to it (BP48V24-2U, which contains no less than 8 batteries!) 
so overall I seem to have three parallel packs each consisting in four
batteries in series.  This may (or may not) be the reason of the
calculations being off.

3. In any case the calculations are nonetheless a way better estimate
than s_value[5].

Please let me know if more information is needed.

I know that everything is largely a guess, but if anybody has any
better idea on how to calculate the remaining capacity I would be more
than happy to hear it and try it out.  Any pointer is much
appreciated.  

 > However, calculating runtime usually requires the UPS to do a
 > battery test, and observe the voltage while under load. This unit
 > might not be capable of doing that.

Understood.  Many thanks.

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>