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.
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/infoInstant return, logging this: 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 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>
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.33This 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>