Nut upsdev - Mar 2014 - Developing the UPS side of the UPS-NUT equation (via usbhid)

Hmm...well, after it gets the report descriptor, NUT then gets each of the
reports defined in there, so that's good.  But after that, there are no more
messages (no more reports being requested...the NUT debug info just shows
"libusb_get_interrupt: Connection timed out" repeatedly).  I put in
some enticing values into the report descriptor, like shutdownimminent and
discharging and charging, hoping that would get NUT interested enough to ask for
those status, but not so far.  I'm missing something obvious.  I'm going
to dig into NUT to see if I can find where it decides what reports to get during
the "Quick update".

-----Original Message-----
From: Nut-upsdev [mailto:nut-upsdev-bounces+rgroner=rtd.com at
lists.alioth.debian.org] On Behalf Of Charles Lepple
Sent: Wednesday, March 12, 2014 8:24 PM
To: nut-upsdev at lists.alioth.debian.org Developers
Subject: Re: [Nut-upsdev] Developing the UPS side of the UPS-NUT equation (via
usbhid)

On Mar 12, 2014, at 5:18 PM, Rob Groner wrote:
> Is there some minimum amount of functionality I need to provide in this
report descriptor in order for NUT to work correctly?  I assume it's not
requesting reports because there is nothing it wants to know about.
That sounds vaguely familiar, but I think NUT will still poll the interrupt pipe
if present. The requests over EP0 are probably only made if there are HID usage
paths mapped to NUT variable names.

-- 
Charles Lepple
clepple at gmail




_______________________________________________
Nut-upsdev mailing list
Nut-upsdev at lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Success!  Turns out NUT was looking for some pretty specific paths, which I
printed out to the screen as it looked for them.  Once I added some bits in
UPS.PowerSummary.PresentStatus.*, then it started checking for those and getting
reports.

I think I'm finally starting to get it....If I want this UPS to use just the
generic usbhid-ups driver, then I'm going to have to structure my reports
descriptor to match what it's looking for.  Otherwise, I can go off on my
own and structure my reports any way I want...but then I'll have to write my
own NUT driver to look for those specific values (paths).  I may end up having
to do that anyway depending on what else we want our UPS to be able to do, but
at this point I don't see why I shouldn't just write our firmware to
work with the usbhid-ups directly.

-----Original Message-----
From: Nut-upsdev [mailto:nut-upsdev-bounces+rgroner=rtd.com at
lists.alioth.debian.org] On Behalf Of Rob Groner
Sent: Thursday, March 13, 2014 9:44 AM
To: nut-upsdev at lists.alioth.debian.org Developers
Subject: Re: [Nut-upsdev] Developing the UPS side of the UPS-NUT equation (via
usbhid)

Hmm...well, after it gets the report descriptor, NUT then gets each of the
reports defined in there, so that's good.  But after that, there are no more
messages (no more reports being requested...the NUT debug info just shows
"libusb_get_interrupt: Connection timed out" repeatedly).  I put in
some enticing values into the report descriptor, like shutdownimminent and
discharging and charging, hoping that would get NUT interested enough to ask for
those status, but not so far.  I'm missing something obvious.  I'm going
to dig into NUT to see if I can find where it decides what reports to get during
the "Quick update".

On Mar 13, 2014, at 10:27 AM, Rob Groner wrote:
> I think I'm finally starting to get it....If I want this UPS to use
just the generic usbhid-ups driver, then I'm going to have to structure my
reports descriptor to match what it's looking for.  Otherwise, I can go off
on my own and structure my reports any way I want...but then I'll have to
write my own NUT driver to look for those specific values (paths).  I may end up
having to do that anyway depending on what else we want our UPS to be able to
do, but at this point I don't see why I shouldn't just write our
firmware to work with the usbhid-ups directly.
Well... unfortunately, the difference between "ideal HID PDC UPS
implementation" and the products on the market is wide enough that there is
currently no "generic usbhid-ups driver": it's more of a generic
core, configurable at compile time, with the driver/*-hid.c files defining the
special-case mappings between HID path and NUT variables. (In some cases, the
mappings even include scale factors to account for misplaced decimal points and
other inaccurate values.)

From earlier in the thread:
>> To make this UPS as easy to use as possible for the end-user who
chooses Linux, I figured I would just completely implement the official USB HID
UPS spec.  That way no subdriver would be needed, or at least very little.
> 
> At the moment, we use USB VID and PID to select which HID-to-NUT tables to
consult (since some vendors have "custom" (incorrect) interpretations
of standard HID PDC Usages. So at the very least, you would need a skeleton
usbhid-ups subdriver which matches your VID:PID combination.
> 
> From there, though, if you follow the standard HID PDC Usage IDs, you
should be able to just map the "HID path" (see below) to the
corresponding NUT name.
Put another way, unless you want to make your UPS bug-compatible with an
existing UPS, and "borrow" their USB VID:PID combinations (something I
wouldn't recommend, since UPS vendors pay for their USB vendor ID), we would
need to add a driver/rtd-hid.c file (or similar) to NUT. It should be very
simple, but otherwise the UPS wouldn't work out-of-the-box (until the new
subdriver is merged into NUT, and propagates to the Linux distributions).

The bright side is that it wouldn't be too hard for you to provide your
users patched versions of the NUT source in the mean time. This is something
that network card vendors have been doing for years while their drivers get
merged into the kernel. I'd like to think we are a bit more friendly and
accommodating than most Linux kernel subsystem maintainers :-)

At one point, I was thinking the solution should be to make the usbhid-ups core
truly generic, and for all but the most difficult cases, patch the HID
descriptor before it is parsed. But that would require a lot of regression
testing for not a lot of gain (given the difference in frequency of arrival of
new UPS models from existing vendors, versus new UPS vendors).

-- 
Charles Lepple
clepple at gmail