hi,

comeback of a diff i still had around, and has been tested by various
ppl on 3 distinct models of eaton upses which report a broken (eg huge) value
for RunTimeToEmpty.

i dont remember the exact details of my reading of the spec and the
sysutils/nut code, but if we read 4 bytes for RunTimeToEmpty, then the actual
value is in the leftmost bytes, so right-shifting / dividing the adjust factor
by 256 gives me a value that matches the value reported by nut.

i pondered doing the right-shifting after reading the actual hdata to make sure
the raw value read was within 'sensible' bounds, but i wouldn't know how to
define those.. advices welcome. "If the value is above 3h then it doesnt make
sense and right-shift should apply" ?

i can also make it specific to eaton vendor, that just requires more plumbing
to propagate the hid vendor here and there..

without the diff:
hw.sensors.upd0.timedelta0=227940.000000 secs (RunTimeToEmpty), OK
(systat sensors)
upd0.timedelta0                            2.638 days    OK    RunTimeToEmpty

with the diff:
hw.sensors.upd0.timedelta0=890.390625 secs (RunTimeToEmpty), OK
(systat sensors)
upd0.timedelta0                            14.840 min    OK    RunTimeToEmpty

i'd like this diff to make 7.7, so oks are welcome. tests on non-eaton UPSses
are of course welcome, but it seems so far only some eaton reports this sensor
on 4 bytes.

Landry

Index: upd.c
===================================================================
RCS file: /cvs/src/sys/dev/usb/upd.c,v
diff -u -r1.33 upd.c
--- upd.c       1 Dec 2024 09:05:05 -0000       1.33
+++ upd.c       9 Feb 2025 08:55:10 -0000
@@ -421,6 +421,8 @@
        case HUB_RUNTIMETO_EMPTY:
                /* spec says minutes, not seconds */
                adjust = 1000000000LL;
+               if (len == 4)
+                       adjust = adjust >> 8;
                break;
        default:
                adjust = 1; /* no scale adjust */