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>
Greg Troxel
2022-Mar-20 23:44 UTC
[Nut-upsuser] finding a common abstraction for reporting
Jim Klimov <jimklimov+nut at gmail.com> writes:> 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.Thanks. I can see why it is that way. I was wondering essentially about having a standardized UPS mib, both names and units, and having each driver translate into that standard set of values. I'm monitoring 3, UPSes of 2 different brands, in 3 locations, heading for probably 3 types in 5 lociatons. I want a common view of how the power is, without having to think about UPS type. (I realize that I may be the only one doing that.) I will probably do a bit of this in the ups monitoring to mqtt python script I'm working on. Partly that's because some of them use apcupsd, but partly because it seems easier. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220320/3fc6678f/attachment.sig>