Nut upsuser - Mar 2022 - 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

[I was going to rely privately to reduce list traffic, but the list
instructed me not to do that :-( ]

Charles Lepple <clepple at gmail.com> writes:
> 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
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.
-------------- 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/20220321/96498b42/attachment.sig>