<div dir="ltr">You have the device side right. Devices have<br>"UPS.PowerSummary.CapacityMode" (are the next three in %, mAh, or mWh?<div>"UPS.PowerSummary.FullChargeCapacity"<br>"UPS.PowerSummary.RemainingCapacity"<br>"UPS.PowerSummary.RemainingCapacityLimit"<br>"UPS.PowerSummary.WarningCapacityLimit"<div><br><br>According to nut-names.txt, NUT has:<br>battery.charge             | Battery charge (percent)            | 100.0<br>battery.charge.low       | Remaining battery level when  UPS switches to LB (percent)<br>battery.charge.restart    | Minimum battery level for UPS restart after power-off<br>battery.charge.warning    | Battery level when UPS switches<br><br>and also<br><br><div>battery.capacity          | Battery capacity (Ah)               | 7.2<br>battery.capacity.nominal    | Nominal battery capacity (Ah)  <br><br>So, it feels to me like this is the right logic:<br>if CapacityMode == 2 (capacity units are percent) then<br>  battery.charge = RemainingCapacity<br>  battery.charge.low, restart =  RemainingCapacityLimit<br>  battery.charge.warning =  WarningCapacityLimit<br><br>if CapacityMode == 0 (units are in mAh) then</div><div>  battery.capacity = RemainingCapacity</div><div>  battery.capacity.nominal = FullChargeCapacity (or DesignCapacity)<br></div><div>  <br>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?<br><br>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. </div><div>  <br>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? </div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 15, 2023 at 7:50 AM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Kelly Byrd <<a href="mailto:kbyrd@memcpy.com" target="_blank">kbyrd@memcpy.com</a>> writes:<br>
<br>
> Making progress on this PR. I have question about storing and checking<br>
> state in a subdriver<br>
> HID Power Devices can a "UPS.PowerSummary.CapacityMode" value. According to<br>
> the spec, the values are:<br>
> 0: maH<br>
> 1: mwH<br>
> 2: percent (%)<br>
> 3: Boolean support only (OK or failed)<br>
><br>
> Grep'ing the source, nothing makes use of this now (some subdrivers have it<br>
> mapped to unmapped.ups.powersummary.capacitymode or something similar) and<br>
> many of the HID UPS drivers assume CapacityMode 2 (they interpret<br>
> RemainingCapacity, WarningCapacityLimit, RemainingCapacityLimit as<br>
> percent). My application (and the original sample sketch for the Arduino<br>
> project also does this, so I'm fine with that.<br>
><br>
> But, I was wondering if anyone could point out the right way in a NUT<br>
> subdriver to have a function that handles RemainingCapacity do different<br>
> things based on CapacityMode. I think I understand how to write my own<br>
> function to handle values in arduino-hid.c, but I don't know how to check<br>
> the state of a previously parsed value, especially one that doesn't have a<br>
> place to be stored in the normal nut names variable hierarchy.<br>
><br>
> Or maybe this is too much trouble and I'll just assume CapacityMode = 2.<br>
<br>
I am really unclear on all of this, but it sounds like the USB interface<br>
has the device define CapacityMode and then provide a value.   So some<br>
devices might report in mWh and some in %.  I guess some might even be<br>
switchable but I would expect each one is how it is.<br>
<br>
When mapping to nut, my view is that the point is to provide a common<br>
abstraction while at the same time providing full access -- and these<br>
two goals are not entirely compatible.<br>
<br>
I would say that nut probably should have different variables  for the<br>
different modes, and read the mode field, and then write the content of<br>
RemainingCapacity into RemainingCapacityPercent if mode is 2.<br>
<br>
Just writing without checking risks some other UPS having its mAh<br>
remaining value put in a field that data consumers think is %.<br>
<br>
I could be way off, but if so hopefully that's obvious!<br>
<br>
</blockquote></div>