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 )
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
