[Nut-upsdev] RunTimeToEmpty is in minutes or seconds?

[Kelly Byrd]

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:
  { "battery.runtime", 0, 0, "UPS.PowerSummary.RunTimeToEmpty", NULL,
"%.0f", 0, NULL }

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.




On Tue, Jan 2, 2024 at 11:10 AM Greg Troxel <gdt at lexort.com> wrote:

> Kelly Byrd <kbyrd at memcpy.com> writes:
>
> > Looking through a bunch of the code for drivers using HID, It looks like
> > everyone is using "ups.powersummary.runtimetoempty" to map to NUT's
> > "battery.runtime" variable.
> >
> > My question for you all is what units ups.powersummary.runtimetoempty is
> > supposed to be in? This doc from USB.org:
> > https://www.usb.org/sites/default/files/hut1_4.pdf (Section 31.2) says
> > minutes, but the NUT developer docs:
> > https://networkupstools.org/docs/developer-guide.chunked/apas02.html
> > (Section A.3) says battery.runtime is in seconds.
>
> In my experience, the Best Fortress driver does translate the front
> panel display in minutes and seconds to seconds in battery.runtime.
> That is not a USB device.
>
> I htink it's very important that the NUT variables have the same
> semantics regardless of driver so that programs/humans that use the data
> can just use it without knowing how the device misrepresents it.
>
> To me the big question is
>
>   Given that the standard says minutes, what do actual UPS devices do?
>   Do they follow the standard, or do they stick seconds in that field?
>   Do the values in the field, interpreted as minutes, make sense
>   physically?  Do they match the display?
>
> and that once that is answered, we can decide what to do, which might be
> "have a quirk table for buggy devices that put minutes in the seconds
> field", or an anti-quirk table for the one known device that gets it
> right.
>
> > Is this just a case where real world UPS' are using seconds so we're
> stuck
> > with it now? I guess it's being pedantic, but IMO trying to measure a UPS
> > remaining runtime with accuracy is sort of silly.
>
> I agree that believing seconds accuracy is a bit silly but that's a
> somewhat different question from "should the units for this variable
> (which we express as a an integer with no fractions) be seconds or
> minutes"/?  Arguing for seconds is that it's the SI base unit, and that
> if somehow does know seconds, it's useful.  I can see a UPS with a
> lithium ion battery at high loads validly having a runtime of "30s" at
> some point.  No, I wouldn't believe 29s vs 30s.
>
>
> > I noticed this because I'm cobbling together a personal project that
> > has absurd capacity for the load, somewhere around 2-3 days from a
> > fully charged battery and I'm using NUT's Arduino driver to report
> > things. It's not critical that I be able to communicate that much
> > remaining time, but I wanted to ask here about the difference.
>
> There's no theoretical problem expressing 3 days in seconds, so I'm
> guessing this is field size?  Are you running into battery.runtime being
> expressed as a uint16_t?
>
> I get your point that if runtime is 3 days and it is represented as
> 65535s, that "there is a lot of battery left and nothing to do for low
> battery now".
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20240102/cc38b74a/attachment.htm>