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

[Gene Heskett]

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>