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.

[masterwishx]

UPS.OutletSystem.Outlet.[1].ConfigApparentPower

in vars have only :

outlet.1.status: on
outlet.desc: Main Outlet
outlet.id: 0
outlet.switchable: no

cant find it for Eaton 9E in log :

[masterwishx]

but found next :

 hid_lookup_path: 00840004 -> UPS
Sep  7 11:34:09 myserver rc.nut:    4.071424#011[D5:3982] hid_lookup_path: 00840018 -> OutletSystem
Sep  7 11:34:09 myserver rc.nut:    4.071431#011[D5:3982] hid_lookup_path: 00840020 -> Outlet
Sep  7 11:34:09 myserver rc.nut:    4.071438#011[D5:3982] hid_lookup_path: 00ff0001 -> not found in lookup table
Sep  7 11:34:09 myserver rc.nut:    4.071446#011[D5:3982] hid_lookup_path: ffff00ba -> not found in lookup table
Sep  7 11:34:09 myserver rc.nut:    4.071457#011[D1:3982] Path: UPS.OutletSystem.Outlet.[1].ffff00ba, Type: Feature, ReportID: 0x15, Offset: 0, Size: 8, Value: 16
Sep  7 11:34:09 myserver rc.nut:    4.071466#011[D3:3982] Report[buf]: (4 bytes) => 80 04 00 00
Sep  7 11:34:09 myserver rc.nut:    4.071473#011[D5:3982] PhyMax = 0, PhyMin = 0, LogMax = 255, LogMin = 0
Sep  7 11:34:09 myserver rc.nut:    4.071479#011[D5:3982] Unit = 00000000, UnitExp = 0
Sep  7 11:34:09 myserver rc.nut:    4.071485#011[D5:3982] Exponent = 0

[arnaudquette-eaton]

I'll try to look for the missing proprietary Usage IDs (like ffff00ba)

[jimklimov]

Well, FWIW - my "Eaton Ellipse ECO 650" does not seem to report the data points added with PR #2620 :

--- /var/tmp/eco650-2.8.2.txt   2024-09-13 09:05:07.038442487 +0200
+++ /var/tmp/eco650-2.8.2.1064-1064-g501bbdc62.txt      2024-09-13 08:58:16.404844100 +0200
@@ -19,10 +19,10 @@
 driver.parameter.synchronous: auto
 driver.parameter.vendor: EATON
 driver.parameter.vendorid: 0463
-driver.state: dumping
-driver.version: 2.8.2
-driver.version.data: MGE HID 1.46
-driver.version.internal: 0.53
+driver.state: quiet
+driver.version: 2.8.2.1064-1064-g501bbdc62
+driver.version.data: MGE HID 1.49
+driver.version.internal: 0.57
 driver.version.usb: libusb-1.0.24 (API: 0x1000108)
 input.transfer.high: 264
 input.transfer.low: 161

...so unless it hides the capability behind some other Usage IDs, I can't directly participate in testing of these ECO features :\

[masterwishx]

I'll try to look for the missing proprietary Usage IDs (like ffff00ba)

in case you need, posting debug nut log ...
nut debug log.txt

[arnaudquette-eaton]

hey there, finally got the info:

• ffff00ba = iDesignator (to be added in mge-hid)
• Path: UPS.OutletSystem.Outlet.[x].iDesignator:
  ** Labelling of the load segment that is shown on the mechanic of the UPS
  ** RO, String

side note: any HID Usage that starts with "i" (like iModel, iDesignator, ...) is the index of a string in the string descriptor

hope it helps

[masterwishx]

hey there, finally got the info:

• ffff00ba = iDesignator (to be added in mge-hid)
• Path: UPS.OutletSystem.Outlet.[x].iDesignator:
  ** Labelling of the load segment that is shown on the mechanic of the UPS
  ** RO, String

side note: any HID Usage that starts with "i" (like iModel, iDesignator, ...) is the index of a string in the string descriptor

hope it helps

Cool, Thanks a lot.
The bad thing I have more unknown hex id's.
You can find in log I posted above and more interesting if you can check:

What hex id should be present in ups log for enable/disable the ECO/Bypass mode for Eaton?

[arnaudquette-eaton]

if you can extract and highlight these, that would save me some precious time.

[masterwishx]

if you can extract and highlight these, that would save me some precious time.

Do you need only hex number or path or the whole block where unknown?

[arnaudquette-eaton]

the full HID path with the unknown hex Usage ID, similar to UPS.OutletSystem.Outlet.[x].ffff00ba
thx

[masterwishx]

the full HID path with the unknown hex Usage ID, similar to UPS.OutletSystem.Outlet.[x].ffff00ba thx

just to be sure : this case is ok becouse its found by another id ?

hid_lookup_path: 00ff0004 -> not found in lookup table
hid_lookup_path: 00840044 -> ConfigActivePower
Path: UPS.Flow.[4].ConfigActivePower, Type: Feature, ReportID: 0x74, Offset: 0, Size: 16, Value: 1600

[masterwishx]

the full HID path with the unknown hex Usage ID, similar to UPS.OutletSystem.Outlet.[x].ffff00ba thx

Path: UPS.BatterySystem.Charger.ffff00e9, Type: Feature, ReportID: 0x26, Offset: 8, Size: 8, Value: 2
Path: UPS.OutletSystem.Outlet.[1].ffff00ba, Type: Feature, ReportID: 0x15, Offset: 0, Size: 8, Value: 16
Path: UPS.OutletSystem.Outlet.[1].ffff00e9, Type: Feature, ReportID: 0x83, Offset: 0, Size: 8, Value: 2
Path: UPS.PowerSummary.ffff00e9, Type: Feature, ReportID: 0x07, Offset: 32, Size: 8, Value: 2
Path: UPS.ffff00e5.ffff00e1.PowerRate, Type: Feature, ReportID: 0x20, Offset: 24, Size: 8, Value: 1
Path: UPS.ffff00e5.ffff0005.iVersion, Type: Feature, ReportID: 0x10, Offset: 72, Size: 8, Value: 11
Path: UPS.ffff00e5.ffff0005.Mode, Type: Feature, ReportID: 0xfd, Offset: 0, Size: 8, Value: 41

[arnaudquette-eaton]

the full HID path with the unknown hex Usage ID, similar to UPS.OutletSystem.Outlet.[x].ffff00ba thx

just to be sure : this case is ok becouse its found by another id ?

hid_lookup_path: 00ff0004 -> not found in lookup table
hid_lookup_path: 00840044 -> ConfigActivePower
Path: UPS.Flow.[4].ConfigActivePower, Type: Feature, ReportID: 0x74, Offset: 0, Size: 16, Value: 1600

right, the Usages like 00ff0004 encodes an ID. Here, 4 for the 4th index which ends up as [4].

[masterwishx]

the full HID path with the unknown hex Usage ID, similar to UPS.OutletSystem.Outlet.[x].ffff00ba thx

just to be sure : this case is ok becouse its found by another id ?

hid_lookup_path: 00ff0004 -> not found in lookup table
hid_lookup_path: 00840044 -> ConfigActivePower
Path: UPS.Flow.[4].ConfigActivePower, Type: Feature, ReportID: 0x74, Offset: 0, Size: 16, Value: 1600

right, the Usages like 00ff0004 encodes an ID. Here, 4 for the 4th index which ends up as [4].

Thanks, posted above the missed values #2495 (comment)
Also had you chance to check about ECO ?

[arnaudquette-eaton]

right, just need to find enough spare minutes to process this thing that is not related at all with my work :D
note that I'm preparing a PR...

[arnaudquette-eaton]

ok, skipped a coffee break to make something you can play with.
Beware, not so much to expect, and you'll have to complete. but there should be enough comments for you to take over.
enjoy

[masterwishx]

ok, skipped a coffee break to make something you can play with.

Oh , sorry for it , i was thinking you are retired...

[masterwishx]

but there should be enough comments for you to take over

Thanks a lot for help ,will try ...

[masterwishx]

Cant find in nut log "ECOControl" or 0xffff0085 , is that mean ECO Control not available in Eaton 9E by USB ?

[arnaudquette-eaton]

retired from opensource, to restore a crazy personal life :D
though still helping a bit here and there...

E series, like 9E, are Entry level units, cheaper, but less features.

[masterwishx]

retired from opensource, to restore a crazy personal life :D

Oh got it , sorry

E series, like 9E, are _E_ntry level units, cheaper, but less features.

Yes i know , wanted 9SX but no luck :(

from docs it still have ECO :

Bypass/ECO Mode from docs:

Eaton 9E 2000 model :

[arnaudquette-eaton]

it seems that HE - High Efficiency is the new name of ECO mode.
You may dig around UPS.PowerConverter.Input[5].Switchable (RW), and play with LCD too:

ECO mode :
0: Not enabled
1: High Efficiency mode enabled, equivalent to legacy term ECO mode.
2: ESS mode enabled (makes sense for UPS that implements this mode)

[masterwishx]

it seems that HE - High Efficiency is the new name of ECO mode. You may dig around UPS.PowerConverter.Input[5].Switchable (RW), and play with LCD too:

ECO mode :
0: Not enabled
1: High Efficiency mode enabled, equivalent to legacy term ECO mode.
2: ESS mode enabled (makes sense for UPS that implements this mode)

9E has only two buttons and The problem I don't have buttons combination on ups to enable eco by Eaton documents, will try to check.. Input[5]...

[masterwishx]

UPS.PowerConverter.Input[5].Switchable

yes found in nut log:
UPS.PowerConverter.Input.[5].Switchable, Type: Feature, ReportID: 0x3f, Offset: 0, Size: 8, Value: 0

[masterwishx]

it seems that HE - High Efficiency is the new name of ECO mode. You may dig around UPS.PowerConverter.Input[5].Switchable (RW), and play with LCD too:

ECO mode :
0: Not enabled
1: High Efficiency mode enabled, equivalent to legacy term ECO mode.
2: ESS mode enabled (makes sense for UPS that implements this mode)

What the real difference about Input.[1] - [5] ?

[arnaudquette-eaton]

these indexed collections are connected to the HW design, and link with the SW features.
Input[1] is tied the to main AC... Input[5] hooks the converter...

[masterwishx]

• 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?)

it seems some work made here for ECO Mode ...