Index | Thread | Search

From:
Landry Breuil <landry@openbsd.org>
Subject:
Re: upd(4): add more sensors (load, power..)
To:
Walter Alejandro Iglesias <wai@roquesor.com>
Cc:
tech@openbsd.org, sthen@openbsd.org
Date:
Sun, 1 Dec 2024 10:26:15 +0100

Download raw body.

Thread
Le Wed, Nov 27, 2024 at 02:44:19PM +0100, Walter Alejandro Iglesias a écrit :
> On Tue, Nov 26, 2024 at 04:19:01PM +0100, Walter Alejandro Iglesias wrote:
> > On Tue, Nov 26, 2024 at 03:29:17PM +0100, Landry Breuil wrote:
> > > Le Mon, Nov 25, 2024 at 07:26:25PM +0100, Walter Alejandro Iglesias a écrit :
> > > > On Mon, Nov 25, 2024 at 05:48:14PM +0100, Landry Breuil wrote:
> > > > > here's a diff (below) that does _just_ that, for a start. gives this here:
> > > > > 
> > > > > hw.sensors.upd0.percent2=25.00% (PercentLoad), OK
> > > > > hw.sensors.upd0.timedelta0=917.352000 secs (RunTimeToEmpty), OK
> > > > 
> > > > I get this in mine:
> > > > 
> > > >   hw.sensors.upd0.percent2=24.00% (PercentLoad), OK
> > > >   hw.sensors.upd0.timedelta0=1017.806400 secs (RunTimeToEmpty), OK
> > > 
> > > and do those two values match what's reported by the UPS on its LCD, if
> > > you have one ?
> > 
> > It's an Eaton 3S 550:
> > 
> >   https://www.eaton.com/gb/en-gb/skuPage.3S550B.html
> > 
> > No LCD, :(
> > 
> > I can try installing nut.
> 
> Nut shows similar values, jus a bit higher runtime.

that's been bugging me, so i went back to the analysis of nut hid code,
and i found out that it might be a matter of report size/offset. After
comparing sthen's model debug output and mine, i concluded that the
'invalid' value we get on EATON models is because 4 bytes are read, but
afaict at the "wrong" spot. right-shifting the value (eg dividing adjust
by 256) gives me a value that matches the value reported by nut for
battery.runtime.

that feels hackish, and i dunno if it should only apply to EATON/MGE
models (in which case i'd readd the vendor matching bits) or to all
models that read the RunTimeToEmpty value on 4 bytes.

to know if a given model provides that value on 2 or 4 bytes, one can
try dumping the usb descriptor with

$ lsusb -v -d vendor:product | grep -A2 'Time To Empty' |grep Size
Item(Global): Report Size, data= [ 0x20 ] 32

new diff below, add #define UPD_DEBUG to the top of the file if you want
debug output printed every 5 second in dmesg. Applies on top of -current
where i've commited the PercentLoad bit.

reports/testing welcome on a variety of models/brands, with comparison
against values reported by nut if possible..

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	1 Dec 2024 09:11:20 -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 */
@@ -428,6 +430,11 @@
 	}
 
 	hdata = hid_get_data(buf, len, &sensor->hitem.loc);
+	switch (HID_GET_USAGE(sensor->hitem.usage)) {
+	case HUB_RUNTIMETO_EMPTY:
+		DPRINTF(("%s: read %d bytes for RunTimeToEmpty, got %lld, adjust=%lld, sensor val=%lld\n", DEVNAME(sc), len, hdata, adjust, hdata*adjust));
+		break;
+	}
 	if (sensor->ksensor.type == SENSOR_INDICATOR)
 		sensor->ksensor.value = hdata ? 1 : 0;
 	else