[Nut-upsuser] finding a common abstraction for reporting

[Jim Klimov]

As for "how much NUT" is doing, it depends :)

For many of the values where mapping tables are involved, it just reads
some number or string from the protocol encapsulation (usb-hid, snmp,
netxml...) and passes it on. However, that entry's mapping may also involve
scaling (multiply by a factor) or arbitrary subdriver-defined mapping
functions (name phases from a number, print ISO date from country-preferred
input, etc.) as the most common conversions.

On Fri, Mar 18, 2022, 00:26 Greg Troxel <gdt at lexort.com> wrote:

>
> I have been using NUT for a long time, but my UPS farm is very old and
> homogenous: I have 3 "Best Power Fortress" from about 1995, and there's
> one at someone else's.  (Yes, these really are 27 years old, and yes I
> have changed the batteries.)  They report a bunch of variables, and I
> have written a python program to report the interesting data over MQTT
> for use in Home Assistant or whatever.  I mumbled earlier that I will
> release that as open source and I mumble that again.
>
> Nothing super interesting here:
>
>   battery.runtime: 5940
>   battery.runtime.low:
>   battery.voltage: 27.5
>   battery.voltage.nominal: 24
>   device.mfr: Best Power
>   device.model: Fortress
>   device.type: ups
>   driver.name: bestfortress
>   driver.parameter.baudrate: 9600
>   driver.parameter.max_load: 660
>   driver.parameter.pollinterval: 2
>   driver.parameter.port: /dev/tty.ups
>   driver.parameter.synchronous: no
>   driver.version: 2.7.4
>   driver.version.internal: 0.05
>   input.frequency: 60.0
>   input.transfer.high:
>   input.transfer.low:
>   input.voltage: 124
>   output.current: 0.3
>   output.voltage: 123
>   output.voltamps: 37
>   ups.delay.shutdown: 10
>   ups.load: 5
>   ups.mfr: Best Power
>   ups.model: Fortress
>   ups.status: OL
>   ups.temperature: 18
>
> and it is turned into json (omitting much) as an MQTT payload:
>
> {"tst":"2022-03-17T19:15:15.641791-0400","topic":"sensor/foo/bar-ups/json","qos":2,"retain":0,"payloadlen":233,"mid":27,"payload":{"time":
> 1647558915.5165293, "runtime": 5940.0, "battery": 27.5, "frequency": 60.0,
> "line_v": 124.0, "output_v": 123.0, "output_a": 0.3, "output_va": 37.0,
> "output_percent": 5.0, "status": "OL ", "utility": "ON", "temperature":
> 18.0}}
>
> I know from past discussion that reporting "status" this way is
> nonportable/awkward, and I probably should omit it and just use
> "utility" which maybe should be "utility_inuse".  My point is that what
> the monitoring system cares about is "Is the UPS using utility power or
> not" as a running on battery even if input voltage is non-zero is still
> cause for concern.
>
> And maybe I should drop output_percent and have rated_va configured (660
> in this case) because it doesn't seem to be in the NUT output.
>
> My script is in the process of being extended to also deal with apcupsd
> and that seems to have different variables, like timeleft in minutes
> instead of runtime in seconds.  It seems obvious to me that I should
> bring things into a common schema, because the monitoring system doesn't
> care about UPS brand; it wants to know is utility power good enough, how
> many seconds left, etc.
>
> I wonder how much NUT does that by itself, or if it's more doing format
> translation of the individual units.  And I would appreciate comments on
> the wisdom/necessity of this approach.
>
> Thanks,
> Greg
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220318/8d9ef096/attachment.htm>