[Nut-upsdev] Proposed discussion: standardization of Status Flags and Instant Commands for ECO mode
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 . 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
> Instead, the motivation of using the keyword "ECO" is to maintain the
> existing behavior - I looked around the codebase and found some drivers
>  already use the flags "OL" & "ECO", so I thought it was a good idea
> to simply make it a documented and standard behavior.
>  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.
>  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...
Size: 194 bytes
Desc: not available
More information about the Nut-upsdev