[Nut-upsuser] nut on armhf, r-pi4b IOW

[Charles Lepple]

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 )