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

Gene Heskett gheskett at shentel.net
Sun Jan 12 14:56:39 GMT 2020


On Saturday 11 January 2020 18:43:23 Gene Heskett wrote:

> On Saturday 11 January 2020 17:00:19 Charles Lepple wrote:
> > 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.
>
> The command line in that file is duff. Quote:
> In preparation for writing a subdriver for a device that is currently
> unsupported, run usbhid-ups with the following command line:
>
>  drivers/usbhid-ups -DD -u root -x explore -x vendorid=XXXX auto
>
> (substitute your device's 4-digit VendorID instead of "XXXX").
> I tried 0501 and 0764, same return.
>
> drivers/usbhid-ups -DDD -u root -x explore -x vendorid=0501 auto
>
> >& /tmp/info
>
>  Instant return, logging this:
in /tmp/info

>    0.000000     Error: too many non-option arguments. Try -h for help.
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33

This I assumed was with nut-server and nut-client, both stopped, which 
they had been. Was that incorrect?

Thanks.

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