Introduce NUT handling for "ECO Mode" (status, commands)

[jimklimov]

At the moment we do not even have a name for "ECO Mode" (as in "economic" or "ecological"; allegedly aka "High Efficiency"/"HE" or "eConversion") status in https://networkupstools.org/docs/developer-guide.chunked/new-drivers.html#_status_data while it apparently becomes a common feature (and reported state) on current devices.

Quite probably, every vendor or model series has their own definition.

By some accounts, the description of this ECO mode seems to be what was called "line-interactive" in the early days of UPSes (as opposed to "online", which kept wall and load on physically separate circuits with a battery and inverter in the middle), so powering load from the wall and switching over to battery when it goes out of range - maybe except the smart part of also waiting for 5 minutes on battery after a hiccup before switching back to wall. (Per #2254 (comment) for Riello at least)

For Eaton devices, per #430 (comment), the ECO range provides the ECO mode, which cut power on slaves outlets if power consumption on the master outlet goes below a certain threshold. This is usable in NUT, but I think I missed to document it. See

nut/drivers/mge-hid.c

Lines 1326 to 1329 in b7f7043

	/* On Protection Station, the line below is the power consumption threshold
	* on the master outlet used to automatically power off the slave outlets.
	* Values: 10, 25 (default) or 60 VA. */
	{ "outlet.power", ST_FLAG_RW | ST_FLAG_STRING, 6, "UPS.OutletSystem.Outlet.[1].ConfigApparentPower", NULL, "%s", HU_FLAG_SEMI_STATIC | HU_FLAG_ENUM, pegasus_threshold_info },

- supported values can be seen using upsrw on outlet.power.

There are few hits to git grep -wi eco drivers already, which suggest that:

• huawei-ups2000.c, apc-mib.c and huawei-mib.c have mappings for "OL ECO" or "OB ECO"
• delta_ups-hid.c has a hit for "on eco" (lower-cased)
• mge-hid.c seems to have many comments about it, and "pegasus" mappings for some model series
• socomec_jbus.c has an upsdebugx() message about it but no formal status_set()
• tripplitesu.c has a #define ECONOMIC_MODE "ECO" macro which is not further referenced
• nutdrv_qx_voltronic.c inconveniently handles it as an alarm (suppress alarm = "UPS is in ECO Mode." #2494); also of note there is a "Converter Mode" alarm that has no name either... maybe (is it boost/trim or something else?)

Another aspect raised in ML and tickets earlier is that there seems to be no way currently to manage such UPS mode through NUT. Per git grep dstate_addcmd, quite a few drivers seem to support bypass.(start|stop) commands, one for calibrate.(start|stop), and a few wordings like test.battery.(start|stop|quick...) and test.panel.* -- so there's ample similar precedent for some eco{mode?}.(start|stop) to become a thing syntax-wise.

Alternatively, as per Eaton example noted above, this might be a setting (perhaps per-outlet) rather than a device-wide command (although the comment said "seen" not "set" albeit via upsrw).

UPDATE: The coded notion of ECO concept as such (in headers, upsmon notifications, docs, C++ bindings, augeas...) is getting added by PR #2637

[masterwishx]

just for the info, Bypass/ECO Mode from docs:

Eaton 9E 2000 model :

Eaton 9SX 2000 model :

[masterwishx]

it seems we can set some voltage range for both modes like posted in #2492 (comment)

[gdt]

I think this should be a detail of OL. OL should mean: input ok, UPS is supplying the load using input power. As to whether it is charging/inverting or not, that's a secondary thing. perfectly ok to have an "OL_MODE" variable. But as someone getting alerts, I care about are things ok or are they not, and I don't care that much about the green claims. (Those may or may not be important at purchase time, but we're not talking about that here.)

Again, I want to organize the thinking by asking how it is used in monitoring/alerting.

[jimklimov]

Well, depending on the load (is it a computer whose PSU is protected by capacitors or something else) it may be important to know in advance whether you expect a 5-10ms gap without power during the switch-over. Or if a lightning would strike directly your PC through a prepared circuit. Or conversely if you waste power on double-conversion when all seems good...

[gdt]

Sure, you might care about that, but those are properties of the setup, more than that they are about what is happening now. I think it's fine to represent them. I just don't think we should blur them into a big-picture OL vs OB, fracturing OL into 3 and then needing a macro that says "is one of these true, so that regardless of technology, the system is in normal operation, with utility input power."

If we care about the gap, then let's have a "switching time" variable that is in s (but will be ms) that is the time from loss of power on the output socket until it is good again.