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>