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

Greg Troxel gdt at lexort.com
Wed Dec 1 14:49:47 GMT 2021

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",
> 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>

More information about the Nut-upsdev mailing list