Re: [Nut-upsuser] finding a common abstraction for reporting
Regarding VA/W conversion, keep in mind the power crest factor, and that it is not always sqrt(2)/2 =~0.7 Some devices actually report theirs and I've seen the likes of 0.9 for example. On Mon, Mar 21, 2022, 14:36 Greg Troxel wrote: > > [I was going to rely privately to reduce list traffic, but the list > instructed me not to do that :-( ] > > Charles Lepple writes: > > > On Mar 17, 2022, at 7:26 PM, Greg Troxel 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 > > Thanks, that was useful. The case that prompted me to ask was a UPS run > by someone else that I think is using apcupsd and not nut. I'm not > responsible for the UPS; I just want to get power status. > > >> 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 > > Thanks. So most of what I was asking about is defined: there are a list > of NUT variables, defined semantics, and units. > > The thing that's messy is power vs realpower (which is a bit funny > because they are "apparent power" and "power"). It seems old Best units > report in VA and some APC in W. Whether to map them both into > "power-ish" for the mqtt protocol is an interesting question, especially > since I don't really believe either measurement without confirming it. > > > To the extent my script supports apcupsd, it would make sense to do the > same normalization. > ___ > Nut-upsuser mailing list > Nut-upsuser@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] finding a common abstraction for reporting
[I was going to rely privately to reduce list traffic, but the list instructed me not to do that :-( ] Charles Lepple writes: > On Mar 17, 2022, at 7:26 PM, Greg Troxel 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 Thanks, that was useful. The case that prompted me to ask was a UPS run by someone else that I think is using apcupsd and not nut. I'm not responsible for the UPS; I just want to get power status. >> 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 Thanks. So most of what I was asking about is defined: there are a list of NUT variables, defined semantics, and units. The thing that's messy is power vs realpower (which is a bit funny because they are "apparent power" and "power"). It seems old Best units report in VA and some APC in W. Whether to map them both into "power-ish" for the mqtt protocol is an interesting question, especially since I don't really believe either measurement without confirming it. To the extent my script supports apcupsd, it would make sense to do the same normalization. signature.asc Description: PGP signature ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] finding a common abstraction for reporting
On Mar 17, 2022, at 7:26 PM, Greg Troxel 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@gmail ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] finding a common abstraction for reporting
On 3/21/22 01:44, Greg Troxel wrote: Jim Klimov 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.) You are far from being the only one :) I have multiple UPSes on 3 continents (4 or 5 models of APC UPSs, one Ablerex, some Eaton and some obscure brands no one has heard of but). Thing is that in some places it's quite difficult to find the model or even brand you'd like to use. Especially outside EU and most specially in African countries :( ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] finding a common abstraction for reporting
Jim Klimov 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. signature.asc Description: PGP signature ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [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 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@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
[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
signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
