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

Fri May 23 13:24:30 UTC 2014

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>