thr3ads.net - Nut upsuser - [Nut-upsuser] finding a common abstraction for reporting [Mar 2022]

If this information is useful, please help other people find it:
Share via:

Greg Troxel

2022-Mar-17 23:26 UTC

[Nut-upsuser] finding a common abstraction for reporting

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

-------------- 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/20220317/ab8d7f92/attachment.sig>

Jim Klimov

2022-Mar-18 11:04 UTC

head link

[Nut-upsuser] finding a common abstraction for reporting

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>

Charles Lepple

2022-Mar-21 03:01 UTC

head link

[Nut-upsuser] finding a common abstraction for reporting

On Mar 17, 2022, at 7:26 PM, Greg Troxel <gdt at lexort.com>
wrote:> 
> 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 am not necessarily recommending that you should use apcupsd-ups (it's
monitor-only and won't send the shutdown command[*], for one thing);
however, it's worth pointing out that a few of the conversion factors are
documented in that driver's source:

https://github.com/networkupstools/nut/blob/v2.7.4/drivers/apcupsd-ups.h#L66

[*] https://networkupstools.org/docs/man/apcupsd-ups.html#_limitations
> 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.
What Jim said about this is technically correct, but I would look at it another
way:

NUT defines standard units for variables (as long as the variables are not
marked as "opaque"), and the drivers map device-specific readings to
those standard units. (USB HID PDC tends to use seconds, as do most SNMP MIBs,
if I am not mistaken.)

Units are in parentheses in the Description column:
https://networkupstools.org/docs/user-manual.chunked/apcs02.html

-- 
Charles Lepple
clepple at gmail

Nut upsuser - Mar 2022 - finding a common abstraction for reporting

[Nut-upsuser] finding a common abstraction for reporting

[Nut-upsuser] finding a common abstraction for reporting

[Nut-upsuser] finding a common abstraction for reporting