Nut upsdev - Dec 2021 - Proposed discussion: standardization of Status Flags and Instant Commands for ECO mode

Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:
>> The basic standardization items needed are:
>
>    1. A ups.status flag for ECO mode, currently there's no standard. I
>    looked around the codebase and found many drivers already use the flag
OL
>    ECO, so I think we could settle on that.
>       - But with a caveat - the ECO status flag only appears when the UPS
>       is online, and can disappear when it's on battery. But this is
> how many UPS
>       units report the current power status - the register only has a value
for
>       "online ECO", not "battery ECO" (which is
understandable, since
> it doesn't
>       really make sense).
>    2. Instant commands for entering and exiting ECO mode. Currently NUT
>    doesn't have standardized instant commands for that.
>
>   Does the esteemed lNUT developer community have some constructive
opinions
> and ideas about this? After all, naming is one of the hardest problems in
> Computer Science ;)u
My view is that whether a device is in some true online mode or ECO mode
is a minor implementation detail.  I would not want to overload
ups.status for this, because many data consumers want to know which mode
we are in:

  utility power is ok and being used to power the load

  the battery is being used to power the load

I can imagine software out there that doesn't know about the ECO
concept, and it should continue to work.  That requires not changing
ups.status=OL.



Therefore, I suggest a new variable that describes the form of online
behavior, choosing among

  inverter
  bypass

and maybe something else, describing if the  UPS is running a full-blown
inverter, just wiring input to output, or doing something else.   (I
dimly remember BEST Ferrups which have some intermediate "line
interactive" mode with ferroresonant transformers.)    This might be
empty when offline, or it might be the same, especially for units that
only have one possibility.

Then, given a ups.mode that shows these choices, that could be set to
command which mode is chosen, when there is an ability to choose.

UPS units that only have inverter or bypass could have the variable
basically read only.


People/programs that care can look at the new variable, and those that
don't can continue as they are with no problems.


Personally I am using a Best Fortress LI660, which I think is ~always in
eco mode, as it's much quieter than when on battery and I hear a relay
when it transfers.   I don't think it has a non-eco mode.   But really
my software  wants to know if the power is ok or not to report to home
assistant, and the remaining runtime, battery voltage, etc.

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-upsdev/attachments/20211201/0c0732d2/attachment.sig>

On Wed, Dec 01, 2021 at 08:39:39AM -0500, Greg Troxel
wrote:
> My view is that whether a device is in some true online mode or ECO mode
> is a minor implementation detail.  I would not want to overload
> ups.status for this, because many data consumers want to know which mode
> we are in:
> 
> I can imagine software out there that doesn't know about the ECO
> concept, and it should continue to work.  That requires not changing
> ups.status=OL.
There seems to be a misunderstanding here. The original proposal doesn't
change ups.status=OL at all. Instead, it merely appends an additional
keyword "ECO" after "OL", i.e. ups.status="OL
ECO". Since ups.status
is already a space-separated list of keywords [1]. It doesn't involve any
breaking change, everything will continue to work as usual.

Instead, the motivation of using the keyword "ECO" is to maintain the
existing behavior - I looked around the codebase and found some drivers
[2] already use the flags "OL" & "ECO", so I thought it
was a good idea
to simply make it a documented and standard behavior.

[1] Currently we already have "OL", "OB", "LB",
"HB", "RB", "CHAG",
"DISCHRG", "BYPASS", "CAL", "OFF",
"OVER", "TRIM", "BOOST", "FSD",
and a huge number of possible combinations.
> Therefore, I suggest a new variable that describes the form of online
> behavior, choosing among
> 
>   inverter
>   bypass
> 
> and maybe something else
[2] I rechecked and found it was actually only used by a single driver, so on
second thought, maintaining the existing behavior is not really a concern, so
I agree, a new variable can be an alternative solution if there's consensus.

Cheers,
Tom Li