Nut upsdev - Jan 2022 - NUT I-D: Minimum command and variable set for conformance

I received a comment calling for a minimum command and variable set to be 
supported for conformance.

The proposal assumes that in the future there will be UPS units which natively 
include an Attachment Daemon and which support direct internet access from a 
Management Daemon.  Something like figure 3 in section 3 of the I-D: 
https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-05.html#name-ups-and-attachment-daemon-i
Such a UPS could claim to be RFC compliant, a marketing advantage, and the 
comment is that such a claim should require that at least a useful subset of the
commands be implemented.

The comment proposes as the minimum set: ? Battery state (charging/charged), UPS
on main power/UPS on inverter, battery percentage of charge left, and killpower 
(commanding the UPS to turn itself off) at the least. ??

The idea of a minimum command and variable set seems to me to be an interesting 
idea, but we need to look closely as what is involved.

1. An Informational RFC cannot lay down conformance standards, but can discuss 
a "Recommended minimum support for commands and variables"

2. The minimum set is for a consumer grade appliance.  Professional use requires
much more to manage for example unattended servers.

To encourage discussion, I propose the following new subsection 9.4 Recommended 
Minimum Support:

  9.4 Recommended Minimum Support

  The features provided by current UPS units vary widely.  However experience
  shows that a minimum feature set is needed for satisfactory use of the NUT
  Project software.  For a full list of variables see the Recording Document
  (7.1).

  9.4.1 Desktop PC Variables

  The following variables form a minimum set suitable for Desktop PC.  It is
  expected that on public power supply failure, the PC will be halted.  It will
  not restart automatically when power returns.

  battery.charge
  battery.charge.low
  device.mfr
  device.model
  ups.status with statuses OL OB LB FSD

  9.4.2 Unattended servers, additional variables

  The following additional variables are needed in a minimum set suitable for an
  unattended server.  It is expected that on public power supply failure, the
  server will be halted.  It will restart automatically when power returns.

  battery.date
  device.serial
  ups.delay.shutdown
  ups.delay.start

  9.4.3 All systems

  Satisfactory use of the NUT Project software requires support for all
commands.

All comments welcome.  If the list is agreed, I will add the new subsection 9.4 
"Recommended Minimum Support" to the I-D

Roger

On 1/3/22 13:47, Roger Price wrote:
> I received a comment calling for a minimum command and variable set to 
> be supported for conformance.
>
> The proposal assumes that in the future there will be UPS units which 
> natively include an Attachment Daemon and which support direct 
> internet access from a Management Daemon.? Something like figure 3 in 
> section 3 of the I-D: 
>
https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-05.html#name-ups-and-attachment-daemon-i
> Such a UPS could claim to be RFC compliant, a marketing advantage, and 
> the comment is that such a claim should require that at least a useful 
> subset of the commands be implemented.
>
> The comment proposes as the minimum set: ? Battery state 
> (charging/charged), UPS on main power/UPS on inverter, battery 
> percentage of charge left, and killpower (commanding the UPS to turn 
> itself off) at the least. ?
>
> The idea of a minimum command and variable set seems to me to be an 
> interesting idea, but we need to look closely as what is involved.
>
> 1. An Informational RFC cannot lay down conformance standards, but can 
> discuss a "Recommended minimum support for commands and
variables"
>
> 2. The minimum set is for a consumer grade appliance. Professional use 
> requires much more to manage for example unattended servers.
>
> To encourage discussion, I propose the following new subsection 9.4 
> Recommended Minimum Support:
>
> ?9.4 Recommended Minimum Support
>
> ?The features provided by current UPS units vary widely.? However 
> experience
> ?shows that a minimum feature set is needed for satisfactory use of 
> the NUT
> ?Project software.? For a full list of variables see the Recording 
> Document
> ?(7.1).
>
> ?9.4.1 Desktop PC Variables
>
> ?The following variables form a minimum set suitable for Desktop PC.? 
> It is
> ?expected that on public power supply failure, the PC will be halted.? 
> It will
> ?not restart automatically when power returns.
>
> ?battery.charge
> ?battery.charge.low
> ?device.mfr
> ?device.model
> ?ups.status with statuses OL OB LB FSD
>
> ?9.4.2 Unattended servers, additional variables
>
> ?The following additional variables are needed in a minimum set 
> suitable for an
> ?unattended server.? It is expected that on public power supply 
> failure, the
> ?server will be halted.? It will restart automatically when power 
> returns.
>
> ?battery.date
> ?device.serial
> ?ups.delay.shutdown
> ?ups.delay.start
>
> ?9.4.3 All systems
>
> ?Satisfactory use of the NUT Project software requires support for all 
> commands.
>
> All comments welcome.? If the list is agreed, I will add the new 
> subsection 9.4 "Recommended Minimum Support" to the I-D
>
> Roger
A few comments here

- I have not seen any low- and mid-end UPS that knows about killpower so 
not including it as a requirement is a good idea

- The 3KVA Ablerex that I have handy and which powers since ... a long 
time ago ( I've replaced 3-4 times the batteries, at least ) a small 
size DC does not know about battery.date and since it is connected via a 
Serial-to-USB adapter, I am not sure that it knows about device.serial. 
It probably does, but in lsusb -v I can only see the USB adapter

wolfy