Sorry, on the road now, so will be short. Quite a few drivers do convert data to the common denominator.
The mapping tables usually have a place for pointers to conversion methods (to read and to write). Values like current battery.charge are often calculated from some reported voltage and known/assumed min/max voltage and a not-always-linear function for in-between values (see e.g. recent PRs for blazer and nutdrv_qx). Jim On Wed, Nov 15, 2023, 17:52 Kelly Byrd <[email protected]> wrote: > 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 >
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
