Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jimklimov opened this issue Jun 27, 2024 · 32 comments
Open

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

jimklimov opened this issue Jun 27, 2024 · 32 comments
Assignees
Labels
documentation Eaton ECO mode impacts-release-2.8.2 Issues reported against NUT release 2.8.2 (maybe vanilla or with minor packaging tweaks) Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) NUT protocols
Milestone

Comments

@jimklimov
Copy link
Member

jimklimov commented Jun 27, 2024

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).

@jimklimov jimklimov added impacts-release-2.8.2 Issues reported against NUT release 2.8.2 (maybe vanilla or with minor packaging tweaks) ECO mode labels Jun 27, 2024
@jimklimov jimklimov added this to the 2.8.4 milestone Jun 27, 2024
@jimklimov jimklimov added documentation Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) labels Jun 27, 2024
@masterwishx
Copy link
Contributor

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

Eaton 9E 2000 model :

image
image
image

Eaton 9SX 2000 model :

image
image

@masterwishx
Copy link
Contributor

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

@gdt
Copy link
Contributor

gdt commented Jun 28, 2024

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
Copy link
Member Author

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
Copy link
Contributor

gdt commented Jun 28, 2024

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
Copy link
Contributor

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 :

image

@masterwishx
Copy link
Contributor

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
Copy link
Contributor

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

@jimklimov
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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

@masterwishx
Copy link
Contributor

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
Copy link
Contributor

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

@masterwishx
Copy link
Contributor

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
Copy link
Contributor

masterwishx commented Sep 20, 2024

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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

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

@masterwishx
Copy link
Contributor

but there should be enough comments for you to take over

Thanks a lot for help ,will try ...

@masterwishx
Copy link
Contributor

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

@arnaudquette-eaton
Copy link
Contributor

arnaudquette-eaton commented Sep 24, 2024

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
Copy link
Contributor

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 :

image
image
image

@arnaudquette-eaton
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

  • 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 ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Eaton ECO mode impacts-release-2.8.2 Issues reported against NUT release 2.8.2 (maybe vanilla or with minor packaging tweaks) Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) NUT protocols
Projects
None yet
Development

No branches or pull requests

4 participants