You have the device side right. Devices have "UPS.PowerSummary.CapacityMode" (are the next three in %, mAh, or mWh? "UPS.PowerSummary.FullChargeCapacity" "UPS.PowerSummary.RemainingCapacity" "UPS.PowerSummary.RemainingCapacityLimit" "UPS.PowerSummary.WarningCapacityLimit"
According to nut-names.txt, NUT has: battery.charge | Battery charge (percent) | 100.0 battery.charge.low | Remaining battery level when UPS switches to LB (percent) battery.charge.restart | Minimum battery level for UPS restart after power-off battery.charge.warning | Battery level when UPS switches and also battery.capacity | Battery capacity (Ah) | 7.2 battery.capacity.nominal | Nominal battery capacity (Ah) So, it feels to me like this is the right logic: if CapacityMode == 2 (capacity units are percent) then battery.charge = RemainingCapacity battery.charge.low, restart = RemainingCapacityLimit battery.charge.warning = WarningCapacityLimit if CapacityMode == 0 (units are in mAh) then battery.capacity = RemainingCapacity battery.capacity.nominal = FullChargeCapacity (or DesignCapacity) Note that in each case some things are left out. I didn't see a battery.capacity.low or warning, which is probably ok because the time remaining HID objects should give a similar set of behavior? Looking at the existing drivers, it feels like most people use capacity as a percent. It makes me wonder if either Windows or MacOS expects percent so vendors just had to do that. I didn't find variables currently in NUT for milliwatt-hours. I still have my original question, what is the right way to check this CapacityMode while parsing RemainingCapacity and its friends? Although the more I look into this, the more I think I won't bother and submit the PR with comments that CapacityMode is assumed to be 2 and maybe a log message if it isn't? On Wed, Nov 15, 2023 at 7:50 AM Greg Troxel <[email protected]> wrote: > Kelly Byrd <[email protected]> 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! > >
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
