On Oct 17, 2017, at 8:48 AM, LLSJ Krüger <[email protected]> wrote:
> Results of 'lsusb -vvv -d 3344:'
[...]
> wDescriptorLength 136
> Report Descriptors:
> ** UNAVAILABLE **
>
Can you please re-run lsusb, possibly as root, to grab the contents of the
"Report Descriptors" section?
(Running "usbhid-ups" should have detached the kernel driver already, which
should allow lsusb to retrieve that descriptor -- but if you have
disconnected+reconnected the USB cable since testing, you will need to re-run
"usbhid-ups" before "lsusb".)
> ran usbhid-ups -DDDD -u root -x explore -x vendorid=3344 -x port=auto -a
> myups >& /tmp/junda-tech.txt
>
> and then
>
> gen-usbhid-subdriver.sh < /tmp/junda-tech.txt' :
>
[...]
> /* --------------------------------------------------------------- */
> /* HID2NUT lookup table */
> /* --------------------------------------------------------------- */
>
> static hid_info_t jundatech_hid2nut[] = {
>
> { "unmapped.ups.powersummary.capacitymode", 0, 0,
> "UPS.PowerSummary.CapacityMode", NULL, "%.0f", 0, NULL },
> { "unmapped.ups.powersummary.designcapacity", 0, 0,
> "UPS.PowerSummary.DesignCapacity", NULL, "%.0f", 0, NULL },
> { "unmapped.ups.powersummary.fullchargecapacity", 0, 0,
> "UPS.PowerSummary.FullChargeCapacity", NULL, "%.0f", 0, NULL },
> { "unmapped.ups.powersummary.presentstatus.acpresent", 0, 0,
> "UPS.PowerSummary.PresentStatus.ACPresent", NULL, "%.0f", 0, NULL },
> { "unmapped.ups.powersummary.presentstatus.charging", 0, 0,
> "UPS.PowerSummary.PresentStatus.Charging", NULL, "%.0f", 0, NULL },
> { "unmapped.ups.powersummary.presentstatus.discharging", 0, 0,
> "UPS.PowerSummary.PresentStatus.Discharging", NULL, "%.0f", 0, NULL },
> { "unmapped.ups.powersummary.rechargeable", 0, 0,
> "UPS.PowerSummary.Rechargeable", NULL, "%.0f", 0, NULL },
> { "unmapped.ups.powersummary.remainingcapacity", 0, 0,
> "UPS.PowerSummary.RemainingCapacity", NULL, "%.0f", 0, NULL },
> { "unmapped.ups.powersummary.imanufacturer", 0, 0,
> "UPS.PowerSummary.iManufacturer", NULL, "%.0f", 0, NULL },
> { "unmapped.ups.powersummary.iproduct", 0, 0,
> "UPS.PowerSummary.iProduct", NULL, "%.0f", 0, NULL },
> { "unmapped.ups.powersummary.iserialnumber", 0, 0,
> "UPS.PowerSummary.iSerialNumber", NULL, "%.0f", 0, NULL },
This part looks promising - the UPS appears to implement a portion of the HID
Power Device Class specification, rather than just being a HID-enabled
USB-to-serial adapter.
In the generated code, the capitalized names are HID PDC names, which you can
search for in the nut/drivers/ directory to see how other vendors use them. The
script just maps them to generic numbers, but the values are most useful if
mapped to proper types. For instance:
$ git grep UPS.PowerSummary.PresentStatus.ACPresent
drivers/apc-hid.c: { "BOOL", 0, 0, "UPS.PowerSummary.PresentStatus.ACPresent",
NULL, NULL, HU_FLAG_QUICK_POLL, online_info },
drivers/belkin-hid.c: { "BOOL", 0, 0,
"UPS.PowerSummary.PresentStatus.ACPresent", NULL, NULL, HU_FLAG_QUICK_POLL,
liebert_online_info },
...
This indicates that the APC models tend to follow the spec, but that we had to
add a custom mapping function for Belkin/Liebert since their boolean True value
is often 1e-7 instead of 1.
I would recommend checking the values to make sure that they match the labels,
but static attributes such as CapacityMode, DesignCapacity, FullChargeCapacity
and Rechargeable can get a HU_FLAG_STATIC or HU_FLAG_SEMI_STATIC flag (see
drivers/usbhid-ups.h) so that the driver does not waste time polling them. Some
values like iManufacturer, iProduct and iSerialNumber are likely duplicates of
the values in the USB device descriptor, and do not need to be included.
>>>
>> Which part of the website?
> As below except with some minor changes, like -a instead of -s
Ah, right - I will add a note to the text that `-s` might not be available yet.
_______________________________________________
Nut-upsuser mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
