[Nut-upsdev] Dynamic HID driver mappings, Tripplite-hid.c

[Arnaud Quette]

Hey Thomas,

First, Arjen de Korte and Peter Selinger are retired from the project.
So please, don't bother them by cc'ing mails to this list ;-)

2011/10/7 Thomas Charron <twaffle at gmail.com>:
>  I think I'm going to have the slightly rejigger the tripplite-hid.c
> driver to 'properly' support all of the data I know about it's
> outlets.
>
>  A given UPS may have 'n' output loads.  I could have 5, I could have
> 10, I won't know until I actually ask the UPS.  But in order to use
> the hid to nut struct, I'm actually going to have to modify that
> struct dynamically, or in actuality, create a new struct, copy the old
> struct, add stuff to the end, then change the struct in
> tripplite_subdriver to point to the new, 'for this particular UPS' hid
> to nut table.
>
>  This is due to Tripplite's HID use of a bitmask to provide some of
> this information.  For example, on our units, we have 3 switchable
> outlets.  This should map to outlet.1, outlet.2, and outlet.3.
> However, they could have another UPS with outlets 1-8.
>
>  Suggestions?  Better ways to do this?    Anyone who is more familiar
> with the code want to do the logical changes, and I can help with the
> hid entries that matter and how they work.

this is essentially what I've solved in snmp-ups, since this was the
only one (until now) that had devices with more than 2 outlets.
Take a look at:
- drivers/eaton-mib.c (2nd and 3rd mib2nut)
- drivers/snmp-ups.c (instantiate_info(), and related calls)

the idea is to have "outlet.count" declared first, and then outlet templates.
once the driver walks the mib2nut for checkings available data, it
uses this templates, and instantiate new entries upon need.
I was thinking about making this code more generic, and putting it
into "nut-outlets.ch" for wider use... once there is a need.

I have to see how it fits into usbhid-ups...

cheers,
Arnaud