[Nut-upsuser] Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?
clepple at gmail.com
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.
>> 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 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 seems to be an ASCII digit:
>> 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 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 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
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.
clepple at gmail
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3200 bytes
Desc: not available
More information about the Nut-upsuser