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

[Charles Lepple]

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.