On Oct 31, 2020, at 8:30 PM, Gene Heskett <gheskett at shentel.net> wrote:> >> battery.voltage: 16.0 > At that voltage, 5 of the 12 cells are shorted >> battery.voltage.nominal: 24The 16.0 is a scaled version of the fixed (bogus) 24.0 V reading, similar to this unit: https://networkupstools.org/ddl/Cyber_Power_Systems/CP1500PFCLCD.html I think we even "fixed" that after NUT 2.7.2, before I realized that many units are providing a bogus value: https://github.com/networkupstools/nut/commit/c8950dee9c91ce45d05d8f220ea26891fb92329e>> output.voltage: 138.0 > too high by about 15 volts >From the other CPS UPS thread on Monday:> This is another known CyberPower issue, and fixing it properly requires making some changes deep in the core USB HID code (that would require a lot of testing on other vendors' equipment) for what is basically a cosmetic issue: > > https://github.com/networkupstools/nut/issues/439https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-October/012126.html
On Oct 31, 2020, at 10:53 PM, Charles Lepple <clepple at gmail.com> wrote:> > On Oct 31, 2020, at 8:30 PM, Gene Heskett <gheskett at shentel.net> wrote: >> >>> battery.voltage: 16.0 >> At that voltage, 5 of the 12 cells are shorted >>> battery.voltage.nominal: 24 > > The 16.0 is a scaled version of the fixed (bogus) 24.0 V reading, similar to this unit: > > https://networkupstools.org/ddl/Cyber_Power_Systems/CP1500PFCLCD.htmlGene, you might have missed this email, and I admit I wasn't very precise with my wording. This particular UPS model is returning a fixed (in the sense of "constant") integer "24" (not 24.0) for both battery voltage and nominal battery voltage, likely because according to the vendor, some models do not have a battery voltage sensor (or, I suspect, it isn't accessible to the microprocessor that sends stats back over USB). Given the broken HID report descriptor that the UPS provides, NUT 2.7.2 scales "24" to "16.0". NUT 2.7.4 uses a heuristic to "fix" that value back to 24.0, but "garbage in, garbage out". Another way to look at it: if you had two 12V lead-acid batteries in series, and someone gave you many readings of 27.0V, 26.0V, 25.0V, and 24.0V over time, would you be suspicious that you weren't seeing, say, 26.5V at some point? Rick's batteries may be low, but I would be surprised if he actually saw 16.0V on a multimeter. I wish we had a better way to flag these bogus values in NUT, but we're still collecting the data in order to programmatically figure out which models really do have a voltage sensor hooked up to USB, and which ones don't. For now, the next best thing is annotating the DDL entries from user-submitted data, like the link above. See also the output.voltage discussion below. The scaling issue isn't as bad, but it's rooted in the same USB HID descriptor (the decoder ring for the values the UPS sends back).> > I think we even "fixed" that after NUT 2.7.2, before I realized that many units are providing a bogus value: > > https://github.com/networkupstools/nut/commit/c8950dee9c91ce45d05d8f220ea26891fb92329e > >>> output.voltage: 138.0 >> too high by about 15 volts >> > > From the other CPS UPS thread on Monday: > >> This is another known CyberPower issue, and fixing it properly requires making some changes deep in the core USB HID code (that would require a lot of testing on other vendors' equipment) for what is basically a cosmetic issue: >> >> https://github.com/networkupstools/nut/issues/439 > > https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-October/012126.html >
On Sun, Nov 1, 2020 at 9:03 AM Charles Lepple <clepple at gmail.com> wrote:> This particular UPS model is returning a fixed (in the sense of > "constant") integer "24" (not 24.0) for both battery voltage and nominal > battery voltage, likely because according to the vendor, some models do not > have a battery voltage sensor (or, I suspect, it isn't accessible to the > microprocessor that sends stats back over USB). Given the broken HID report > descriptor that the UPS provides, NUT 2.7.2 scales "24" to "16.0". NUT > 2.7.4 uses a heuristic to "fix" that value back to 24.0, but "garbage in, > garbage out". >I thank you all for your insights, I learned new things! Here are some anecdotes from my other Cyberpower UPSs: or1500lcdrm1u at str002 Ubuntu 16.04 LTS battery.voltage: 10.1 battery.voltage.nominal: 24 device.model: OR1500LCDRM1U driver.version: 2.7.2 driver.version.data: CyberPower HID 0.3 driver.version.internal: 0.38 ups.model: OR1500LCDRM1U ups.test.result: Done and passed cp1350 at str003 Ubuntu 16.04 LTS battery.voltage: 16.0 battery.voltage.nominal: 24 device.model: CRCA102\#BJ1 driver.version: 2.7.2 driver.version.data: CyberPower HID 0.3 driver.version.internal: 0.38 ups.model: CRCA102#BJ1 ups.test.result: Done and warning cp1500 at ap-001 Slackware 14.2 (nut 2.7.4 compiled locally) battery.voltage: 27.2 battery.voltage.nominal: 24 device.model: CP1500AVRLCDa driver.version: 2.7.4 driver.version.data: CyberPower HID 0.4 driver.version.internal: 0.41 ups.model: CP1500AVRLCDa ups.test.result: Done and passed cp1500 at dns1 Slackware 14.2 (nut 2.7.4 compiled locally) battery.voltage: 27.1 battery.voltage.nominal: 24 device.model: CP1500AVRLCDa driver.version: 2.7.4 driver.version.data: CyberPower HID 0.4 driver.version.internal: 0.41 ups.model: CP1500AVRLCDa ups.test.result: Done and passed cp1500 at thinkpad Ubuntu 18.04 LTS battery.voltage: 27.0 battery.voltage.nominal: 24 device.model: CP1500AVRLCDa driver.version: 2.7.4 driver.version.data: CyberPower HID 0.4 driver.version.internal: 0.41 ups.model: CP1500AVRLCDa ups.test.result: Done and passed -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20201101/c70d8ada/attachment.html>
On Sunday 01 November 2020 09:02:56 Charles Lepple wrote:> Gene, > > you might have missed this email, and I admit I wasn't very precise > with my wording.Yes, or at least I don't recall it, which at my age IS a possibility. More below as needed.> This particular UPS model is returning a fixed (in the sense of > "constant") integer "24" (not 24.0) for both battery voltage and > nominal battery voltage, likely because according to the vendor, some > models do not have a battery voltage sensor (or, I suspect, it isn't > accessible to the microprocessor that sends stats back over USB). > Given the broken HID report descriptor that the UPS provides, NUT > 2.7.2 scales "24" to "16.0". NUT 2.7.4 uses a heuristic to "fix" that > value back to 24.0, but "garbage in, garbage out". > > Another way to look at it: if you had two 12V lead-acid batteries in > series, and someone gave you many readings of 27.0V, 26.0V, 25.0V, and > 24.0V over time, would you be suspicious that you weren't seeing, say, > 26.5V at some point?A bit odd, yes. Particularly since a 20 cent comparator and a kilobyte of machine code for a successive approximation routine is essentially public domain, published for a Z80 in about 1981, so such ability is essentially free. All they have to do is make room on the pcb, and port that code to whatever micro they are using. I used it for quite a few readings in a transmitter controller in the 1981-1982 time frame that was essentially an ATS system without the label as that changed the Friendly Candy Commissions rules back then. It kept the logs on paper tape at the studio, adjusted the transmitter if it was not within tolerance, reporting the adjustment on the log printer, even started the air conditioner that fed the bottom of an early solid state Sparta FM transmitter as its finals weren't overly stable in a high altitude Cali summer in the high sierra's. All without any operator action. That was now almost 40 years ago, and most of that code I wrote by looking up the next z-80 commands machine code in the programmers manual from Zilog. In that time frame an assembler wasn't affordable and needed more resources than a micro-professor kit board supplied. I even made my own 2716 programmer, eraseing them in the sunlight when I needed to reprogram them again. Now its part of linux and free for the downloading. And uv erasers are gone, replaced by better tech in the memory chips. There was no internet then.> Rick's batteries may be low, but I would be surprised if he actually > saw 16.0V on a multimeter. > > I wish we had a better way to flag these bogus values in NUT, but > we're still collecting the data in order to programmatically figure > out which models really do have a voltage sensor hooked up to USB, and > which ones don't. For now, the next best thing is annotating the DDL > entries from user-submitted data, like the link above. > > See also the output.voltage discussion below. The scaling issue isn't > as bad, but it's rooted in the same USB HID descriptor (the decoder > ring for the values the UPS sends back). > > > I think we even "fixed" that after NUT 2.7.2, before I realized that > > many units are providing a bogus value: > > > > https://github.com/networkupstools/nut/commit/c8950dee9c91ce45d05d8f > >220ea26891fb92329e > > > >>> output.voltage: 138.0 > >> > >> too high by about 15 volts > > > > From the other CPS UPS thread on Monday: > >> This is another known CyberPower issue, and fixing it properly > >> requires making some changes deep in the core USB HID code (that > >> would require a lot of testing on other vendors' equipment) for > >> what is basically a cosmetic issue: > >> > >> https://github.com/networkupstools/nut/issues/439 > > > > https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-October/0 > >12126.htmlThanks for a cogent explanation Charles. Sitting in your chair, the temptation to point those errors out in the logs, potentially giving the vendor an elbow in the ribs to fix their liars would be hard to resist. But thats just me being me. :) Take care now. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>