<div dir="ltr">Thanks for the reply, it looks to me (based on various existing  HID-based drivers in the NUT source tree) that everyone is just mapping it directly with a line like this in a hid_info_t:<br>  { "battery.runtime", 0, 0, "UPS.PowerSummary.RunTimeToEmpty", NULL, "%.0f", 0, NULL }<br><br>I found that in belkin-hid, apc-hid, cps-hid, tripplite-hid, and a bunch of others. This seems like evidence that real world UPS devices are using seconds. <div><br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 2, 2024 at 11:10 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>
> Looking through a bunch of the code for drivers using HID, It looks like<br>
> everyone is using "ups.powersummary.runtimetoempty" to map to NUT's<br>
> "battery.runtime" variable.<br>
><br>
> My question for you all is what units ups.powersummary.runtimetoempty is<br>
> supposed to be in? This doc from USB.org:<br>
> <a href="https://www.usb.org/sites/default/files/hut1_4.pdf" rel="noreferrer" target="_blank">https://www.usb.org/sites/default/files/hut1_4.pdf</a> (Section 31.2) says<br>
> minutes, but the NUT developer docs:<br>
> <a href="https://networkupstools.org/docs/developer-guide.chunked/apas02.html" rel="noreferrer" target="_blank">https://networkupstools.org/docs/developer-guide.chunked/apas02.html</a><br>
> (Section A.3) says battery.runtime is in seconds.<br>
<br>
In my experience, the Best Fortress driver does translate the front<br>
panel display in minutes and seconds to seconds in battery.runtime.<br>
That is not a USB device.<br>
<br>
I htink it's very important that the NUT variables have the same<br>
semantics regardless of driver so that programs/humans that use the data<br>
can just use it without knowing how the device misrepresents it.<br>
<br>
To me the big question is<br>
<br>
  Given that the standard says minutes, what do actual UPS devices do?<br>
  Do they follow the standard, or do they stick seconds in that field?<br>
  Do the values in the field, interpreted as minutes, make sense<br>
  physically?  Do they match the display?<br>
<br>
and that once that is answered, we can decide what to do, which might be<br>
"have a quirk table for buggy devices that put minutes in the seconds<br>
field", or an anti-quirk table for the one known device that gets it<br>
right.<br>
<br>
> Is this just a case where real world UPS' are using seconds so we're stuck<br>
> with it now? I guess it's being pedantic, but IMO trying to measure a UPS<br>
> remaining runtime with accuracy is sort of silly.<br>
<br>
I agree that believing seconds accuracy is a bit silly but that's a<br>
somewhat different question from "should the units for this variable<br>
(which we express as a an integer with no fractions) be seconds or<br>
minutes"/?  Arguing for seconds is that it's the SI base unit, and that<br>
if somehow does know seconds, it's useful.  I can see a UPS with a<br>
lithium ion battery at high loads validly having a runtime of "30s" at<br>
some point.  No, I wouldn't believe 29s vs 30s.<br>
<br>
<br>
> I noticed this because I'm cobbling together a personal project that<br>
> has absurd capacity for the load, somewhere around 2-3 days from a<br>
> fully charged battery and I'm using NUT's Arduino driver to report<br>
> things. It's not critical that I be able to communicate that much<br>
> remaining time, but I wanted to ask here about the difference.<br>
<br>
There's no theoretical problem expressing 3 days in seconds, so I'm<br>
guessing this is field size?  Are you running into battery.runtime being<br>
expressed as a uint16_t?<br>
<br>
I get your point that if runtime is 3 days and it is represented as<br>
65535s, that "there is a lot of battery left and nothing to do for low<br>
battery now".<br>
</blockquote></div>