On Jan 11, 2020, at 1:58 AM, Gene Heskett wrote:> > On Friday 10 January 2020 20:43:55 Gene Heskett wrote: > >> On Friday 10 January 2020 19:04:11 Charles Lepple wrote: >>> On Jan 10, 2020, at 5:29 PM, Gene Heskett wrote: >>>> input.transfer.high: 0 ???? Shouldn't these two be something real >>>> ???? input.transfer.low: 0 ???? ditto >>> >>> Known issue, but only cosmetic: >>> https://github.com/networkupstools/nut/issues/482 >> >> I wonder if the same basic problem is causeing the zero loading to be >> reported at my place???Possible, but it is not unusual for a load reading to be off at the low end of the scale. (They need to subtract out any load caused by the internal UPS electronics, which is also pretty far down in the noise compared to a 625 VA design rating, and then it probably gets clamped to zero if it's close enough.) If you stop all of the NUT components, and run the driver manually in debug mode ("/lib/nut/usbhid-ups -a myups -DDD" as root), the raw values before and after scaling are printed. For instance, on issue #482 (attached file "sx650g.txt"), this is what gets mapped to "ups.load": 0.070141 Report[get]: (3 bytes) => 13 14 00 0.070177 Path: UPS.Output.PercentLoad, Type: Feature, ReportID: 0x13, Offset: 0, Size: 8, Value: 20 There are instructions in docs/hid-subdrivers.txt about capturing the debug output to a file. The gen-subdriver script only needs '-DD', but to see the raw values, I think we want '-DDD'. Since we aren't talking about watching values change over time, 45-60 seconds is all you need before hitting Ctrl-C. Please gzip the result, as it is quite repetitive.>> >> Cheers, Gene Heskett > > Looking at drivers/ for HID versions of cps, I don't see anything that > addresses that. Nor do I see an ID string match for the 625 variation. > vendor_id 764 says cps-hid.c.Right, it's an open issue, so no fix in the code yet. (There might be enough examples in GitHub to come up with a general solution now, but at the time, there wasn't a clear path forward to identify when to apply scale factors, and where.) That said, per the "driver.version.data: CyberPower HID 0.4" line in upsc, it looks like your UPS is matching the vendor ID for cps-hid.c.> > In the header of cps-hid.c, I see this comment: > * Note: this subdriver was initially generated as a "stub" by the > * gen-usbhid-subdriver script. It must be customized. > > Then I found docs/hid-subdrivers.txt, but while it looks like it may be > possible to autogen something once we are actually talking to it, no > hints on how to proceed are obvious. Any clues?That "stub" message should have been removed, since the file has since been converted to NUT names. (The output of gen-usbhid-subdriver contains generic names based on the HID names.) The problem is further downstream. Even after you map HID names to NUT names, then you run into the fact that CPS and NUT are interpreting the HID Report Descriptor differently. (Some details here: https://github.com/networkupstools/nut/issues/439 )
On Saturday 11 January 2020 15:12:17 Charles Lepple wrote:> On Jan 11, 2020, at 1:58 AM, Gene Heskett wrote: > > On Friday 10 January 2020 20:43:55 Gene Heskett wrote: > >> On Friday 10 January 2020 19:04:11 Charles Lepple wrote: > >>> On Jan 10, 2020, at 5:29 PM, Gene Heskett wrote: > >>>> input.transfer.high: 0 ???? Shouldn't these two be something real > >>>> ???? input.transfer.low: 0 ???? ditto > >>> > >>> Known issue, but only cosmetic: > >>> https://github.com/networkupstools/nut/issues/482 > >> > >> I wonder if the same basic problem is causeing the zero loading to > >> be reported at my place??? > > Possible, but it is not unusual for a load reading to be off at the > low end of the scale. (They need to subtract out any load caused by > the internal UPS electronics, which is also pretty far down in the > noise compared to a 625 VA design rating, and then it probably gets > clamped to zero if it's close enough.) > > If you stop all of the NUT components, and run the driver manually in > debug mode ("/lib/nut/usbhid-ups -a myups -DDD" as root), the raw > values before and after scaling are printed. For instance, on issue > #482 (attached file "sx650g.txt"), this is what gets mapped to > "ups.load": > > 0.070141 Report[get]: (3 bytes) => 13 14 00 > 0.070177 Path: UPS.Output.PercentLoad, Type: Feature, ReportID: > 0x13, Offset: 0, Size: 8, Value: 20 > > There are instructions in docs/hid-subdrivers.txt about capturing the > debug output to a file. The gen-subdriver script only needs '-DD', but > to see the raw values, I think we want '-DDD'. Since we aren't talking > about watching values change over time, 45-60 seconds is all you need > before hitting Ctrl-C. Please gzip the result, as it is quite > repetitive. > > >> Cheers, Gene Heskett > > > > Looking at drivers/ for HID versions of cps, I don't see anything > > that addresses that. Nor do I see an ID string match for the 625 > > variation. vendor_id 764 says cps-hid.c. > > Right, it's an open issue, so no fix in the code yet. (There might be > enough examples in GitHub to come up with a general solution now, but > at the time, there wasn't a clear path forward to identify when to > apply scale factors, and where.) > > That said, per the "driver.version.data: CyberPower HID 0.4" line in > upsc, it looks like your UPS is matching the vendor ID for cps-hid.c. > > > In the header of cps-hid.c, I see this comment: > > * Note: this subdriver was initially generated as a "stub" by the > > * gen-usbhid-subdriver script. It must be customized. > > > > Then I found docs/hid-subdrivers.txt, but while it looks like it may > > be possible to autogen something once we are actually talking to it, > > no hints on how to proceed are obvious. Any clues? > > That "stub" message should have been removed, since the file has since > been converted to NUT names. (The output of gen-usbhid-subdriver > contains generic names based on the HID names.) > > The problem is further downstream. Even after you map HID names to NUT > names, then you run into the fact that CPS and NUT are interpreting > the HID Report Descriptor differently. (Some details here: > https://github.com/networkupstools/nut/issues/439 )Thats asking quite a bit of you. IMO TANSTAAFL applies here, just like anyplace else. Perhaps a confirmation of the clamp to zero for low loads might be this snippet from "strace upsc myups": newselect(4, [3], NULL, NULL, {tv_sec=5, tv_usec=0}) = 1 (in [3], left {tv_sec=4, tv_usec=999990}) read(3, "s ups.load \"0\"\nVAR myups ups.mfr"..., 64) = 64 write(1, "ups.load: 0\n", 12ups.load: 0 ) = 12 where it apparently reads 64, but reports an 0, which is probably pretty miniscule in the grand scheme of things if that is a 3 byte value that it reads. I'd plug in a 100 watt lamp, but none have survived the mass conversion, first to ccfl's, and now to led's at this camp site. Thanks guys. 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>
On Jan 11, 2020, at 3:50 PM, Gene Heskett wrote:> >> The problem is further downstream. Even after you map HID names to NUT >> names, then you run into the fact that CPS and NUT are interpreting >> the HID Report Descriptor differently. (Some details here: >> https://github.com/networkupstools/nut/issues/439 ) > > Thats asking quite a bit of you. IMO TANSTAAFL applies here, just like > anyplace else.To be fair, glancing at one specific debug log is a lot easier than fixing code that has to run on equipment that I've never seen before :-)> Perhaps a confirmation of the clamp to zero for low loads might be this > snippet from "strace upsc myups": > > newselect(4, [3], NULL, NULL, {tv_sec=5, tv_usec=0}) = 1 (in [3], left > {tv_sec=4, tv_usec=999990}) > read(3, "s ups.load \"0\"\nVAR myups ups.mfr"..., 64) = 64 > write(1, "ups.load: 0\n", 12ups.load: 0 > ) = 12 > > where it apparently reads 64, but reports an 0, which is probably pretty > miniscule in the grand scheme of things if that is a 3 byte value that > it reads.The parameters to read() are the file descriptor, a buffer, and a length, so the "3" is the file descriptor (comes from the read set in newselect(): [3]), and 64 is the length of the string that includes "VAR". However, cps-hid.c is in the usbhid-ups driver, which is sending the VAR data to upsd. I was recommending that you grab the debug log from the driver, before it has had a chance to convert any of the raw HID bytes to numbers.