[Nut-upsdev] What is the arduino sub-driver intended to be used for?

[Greg Troxel]

Kelly Byrd <kbyrd at memcpy.com> writes:

> Making progress on this PR. I have question about storing and checking
> state in a subdriver
> HID Power Devices can a "UPS.PowerSummary.CapacityMode" value. According to
> the spec, the values are:
> 0: maH
> 1: mwH
> 2: percent (%)
> 3: Boolean support only (OK or failed)
>
> Grep'ing the source, nothing makes use of this now (some subdrivers have it
> mapped to unmapped.ups.powersummary.capacitymode or something similar) and
> many of the HID UPS drivers assume CapacityMode 2 (they interpret
> RemainingCapacity, WarningCapacityLimit, RemainingCapacityLimit as
> percent). My application (and the original sample sketch for the Arduino
> project also does this, so I'm fine with that.
>
> But, I was wondering if anyone could point out the right way in a NUT
> subdriver to have a function that handles RemainingCapacity do different
> things based on CapacityMode. I think I understand how to write my own
> function to handle values in arduino-hid.c, but I don't know how to check
> the state of a previously parsed value, especially one that doesn't have a
> place to be stored in the normal nut names variable hierarchy.
>
> Or maybe this is too much trouble and I'll just assume CapacityMode = 2.

I am really unclear on all of this, but it sounds like the USB interface
has the device define CapacityMode and then provide a value.   So some
devices might report in mWh and some in %.  I guess some might even be
switchable but I would expect each one is how it is.

When mapping to nut, my view is that the point is to provide a common
abstraction while at the same time providing full access -- and these
two goals are not entirely compatible.

I would say that nut probably should have different variables  for the
different modes, and read the mode field, and then write the content of
RemainingCapacity into RemainingCapacityPercent if mode is 2.

Just writing without checking risks some other UPS having its mAh
remaining value put in a field that data consumers think is %.

I could be way off, but if so hopefully that's obvious!