Stefan Bruda
2014-May-22 14:03 UTC
[Nut-upsuser] 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 thanbeing 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>
Charles Lepple
2014-May-23 13:24 UTC
[Nut-upsuser] Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?
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>
Stefan Bruda
2014-May-24 21:49 UTC
[Nut-upsuser] Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?
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]
Maybe Matching Threads
- Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?
- Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?
- Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?
- Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?
- Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?