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

Gene Heskett gheskett at shentel.net
Sat Jan 11 20:50:10 GMT 2020

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>

More information about the Nut-upsuser mailing list