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

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

Tom Li <tomli at tomli.me> writes:
> 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.
I had no idea about the space-separated keyword list.  I wrote python
code, not yet published, that compares to "OL".  I was suggesting that
changing the contens would break code that didn't know about the new
one, and I guess that has turned into "may break code that wasn't
expecting this".
> 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.
I really should read the specs then :-)  But I suspect I'm not the only
one with code/scripts like mine.
> [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.
I don't think it's a big deal either way.  In general I prefer simpler
variables that abstract more complicated behavior so that less
sophisticated data consumers will end up doing somethin sensible.  But I
see that the existing status variable is not like that.
-------------- 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/2e72369d/attachment.sig>