Open jimklimov opened 4 months ago
just for the info, Bypass/ECO Mode from docs:
it seems we can set some voltage range for both modes like posted in https://github.com/networkupstools/nut/issues/2492#issuecomment-2191108335
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.
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...
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.
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 :
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
I'll try to look for the missing proprietary Usage IDs (like ffff00ba)
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 :\
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
hey there, finally got the info:
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
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?
if you can extract and highlight these, that would save me some precious time.
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?
the full HID path with the unknown hex Usage ID, similar to UPS.OutletSystem.Outlet.[x].ffff00ba thx
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
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
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].
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 https://github.com/networkupstools/nut/issues/2495#issuecomment-2363359944 Also had you chance to check about ECO ?
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...
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
ok, skipped a coffee break to make something you can play with.
Oh , sorry for it , i was thinking you are retired...
but there should be enough comments for you to take over
Thanks a lot for help ,will try ...
Cant find in nut log "ECOControl" or 0xffff0085 , is that mean ECO Control not available in Eaton 9E by USB ?
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.
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:
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)
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]...
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
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] ?
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...
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 ...
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 https://github.com/networkupstools/nut/issues/2254#issuecomment-1872498487 for Riello at least)
For Eaton devices, per https://github.com/networkupstools/nut/issues/430#issuecomment-380417164, 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 https://github.com/networkupstools/nut/blob/b7f7043c8cc6f84d801e12d3db133c7cb1ae1463/drivers/mge-hid.c#L1326-L1329 - supported values can be seen using
upsrw
onoutlet.power
.There are few hits to
git grep -wi eco drivers
already, which suggest that:huawei-ups2000.c
,apc-mib.c
andhuawei-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 seriessocomec_jbus.c
has anupsdebugx()
message about it but no formalstatus_set()
tripplitesu.c
has a#define ECONOMIC_MODE "ECO"
macro which is not further referencednutdrv_qx_voltronic.c
inconveniently handles it as an alarm (#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 supportbypass.(start|stop)
commands, one forcalibrate.(start|stop)
, and a few wordings liketest.battery.(start|stop|quick...)
andtest.panel.*
-- so there's ample similar precedent for someeco{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
).