battery.charge.low ignored (when set in ups.conf but OK with upsrw)

[MrM40]

Driver: usbhid-ups, version 0.47 (2.8.0) (from Debian package)
OS: Debian 12 (bookworm)
UPS: Eaton S3 700 Gen. 1
MOBO: SuperMicro X11

Problem:
When I set battery.charge.low = 83 in the driver-config file, like below, the monitor doesn't respect this, i.e. when battery.charge <= battery.charge.low the shutdown procedure isn't triggered. But it worke find if I set battery.charge.low using upsrw !

[eaton]
  driver = usbhid-ups
  port = auto
  desc = "eaton S3 ups"
  offdelay = 120
  ondelay = 125
  override.battery.charge.low = 83

Aso tried default.battery.charge.low = 83

These are are the UPS variables after I set battery.charge.low (either in driver-config or with upsrw):

battery.charge: 83
battery.charge.low: 83
battery.runtime: 2520
driver.parameter.offdelay: 120
driver.parameter.ondelay: 125
outlet.1.status: off
ups.delay.shutdown: 120
ups.delay.start: 125
ups.load: 0
ups.status: OB

I assume the monitor is looking at these variables and I assume it compare battery.charge and battery.charge.low

The problem using upsrw is it isn't persistent and have to be set every time the server boots.

I use this command to set it with upsrw:

upsrw -s battery.charge.low=83 -u nut -p xxxx eaton@localhost 

[jimklimov]

Well, as docs/nut-names.txt says, battery.charge.low : Remaining battery level when UPS switches to LB (percent) so indeed it is a setting for the UPS so it would actively raise the LB flag in reports. The upsmon client does not look into ups.conf (may be even running on a different system), but it should interact with what the driver says (e.g. if it raises/passes the LB flag). I've just checked, the clients/upsmon.c does not seem to directly care about battery.charge.low variable even if reported in UPS status.

I see that the ups.conf man page suggests setting override.battery.charge.low and/or override.battery.runtime.low so this is (was?) expected to work, but will have a meeting soon so can't currently trace through code where it is handled (is it a setting sent to device during driver start-up? is it a value consulted in the processing loop to "compare battery.charge and battery.charge.low"? is it only recognized by a driver after an upsrw passes through it? is it reported back by the device?) so you are welcome to beat me to it and investigate this codepath, and possibly pinpoint the bug :)

As for "the setting does not persist", that does sound strange. Until proven otherwise, I think it is posted to the device (so it would yell LB) and remembered in its chips.

In your practice, in which exact cases is it "forgotten":

• server reboot (UPS keeps running);
• whole reboot including the UPS (e.g. outage);
• NUT driver restart (with or without the override lines)?

If you comment away the override lines and restart the NUT driver, does upsc report the battery.charge.low value? (Is it queried and read from the device?) If not, does it only "appear" after you upsrw?

Maybe for certain overrides/defaults the general driver framework should do the equivalent of upsrw when it starts (as a workaround on existing packaged deployments, systemd site-local drop-in for nut-driver(@UPSNAME).service could add an ExecStartPost to sleep a sufficient bit and run upsrw)... @aquette - WDYT?

[MrM40]

In regards to the setting is not saved in the UPS persistently (after UPS is turned off) I'll say it's very likely the UPS missing this feature. It's a cheap consumer-model and I'm sure Eaton saved on both components and R&D resources on this model.

But I now tried to use two PCs, changing settings on one and reading on the other using upsc eaton, to completely rule out any driver- and server-cached data.

Setting the battery.charge.low in the driver-config-file, as below example, is useless! The value you set will show up fine in upsc but the variable it not saved to the UPS and will not have any influence on when an LB event will kick in (at least not on this UPS).

[eaton]
	driver = usbhid-ups
	port = auto
	desc = "eaton S3 ups"
	override.battery.charge.low = 85

So there are two problems with this:.
1: the variable is not saved to the UPS
2: upsc doesn't show the real value. The server or driver seem to provide a fake value, a value from it's on buffer/cache.

Setting the variable using upsrw is saved to the UPS correctly....I can read the new value from the other PC. And it also have influence on when the LB event will occur.

[jimklimov]

Thanks for the investigation!

As for 2: upsc doesn't show the real value. The server or driver seem to provide a fake value, a value from it's on buffer/cache. - which value do you treat as "real"? The one which the UPS reports when you do not specify the override? (After all, this is what "override." settings are for: "ignore the UPS reading and plaster another one in the responses"; compare to "default." which is "initialize with this reading, replace if the device provides another").

So if I get it right, the following statements are correct:

• when override.battery.charge.low is set in ups.conf, and a driver is started, it reports this value via upsc;
• ...but an actual discharge does not raise an LB flag when the charge goes below this value (if it was not also set into the device using upsrw), by whatever software or hardware backed logic involved in this (UPS, driver, upsmon...)

[MrM40]

As for 2: upsc doesn't show the real value. The server or driver seem to provide a fake value, a value from it's on buffer/cache. - which value do you treat as "real"? The one which the UPS reports when you do not specify the override? (After all, this is what "override." settings are for: "ignore the UPS reading and plaster another one in the responses"; compare to "default." which is "initialize with this reading, replace if the device provides another").

I meant the "real" value is the one from the UPS which is the one and only that has influence on triggering a shutdown-event, since all the logic is located in the UPS (it change he value of ups.staus to LB). And is was my understanding that upsc will get the value from the UPS. But I see you point with "override". But it only have value if the monitor had some logic and would use this override value. If the override isn't use for anything why does it exist, I wonder, other than "nice to look at".
UPDATE: okay, it can have great value for other clients which might have own logic using e.g. battery.charge and battery.charge.low provided by the server, to trigger a shutdown event etc.

So if I get it right, the following statements are correct:

• when override.battery.charge.low is set in ups.conf, and a driver is started, it reports this value via upsc;

YES

• ...but an actual discharge does not raise an LB flag when the charge goes below this value (if it was not also set into the device using upsrw), by whatever software or hardware backed logic involved in this (UPS, driver, upsmon...)

YES, correct. And likely because the UPS newer get this new values specified in the ups.conf, accoding to my test using two PCs.
Version and hardware is specified in first line of the first message ;-)

[DezzardHD]

I also adjusted the value of battery.charge.low hoping to shutdown my devices at a 80% charge.
Took me way to long to find out, that the status did not change to OB LB and therefore no shutdown was triggered.
I guess the documentation could be clearer, that changing battery.charge.low in ups.conf will not affect the status.
https://networkupstools.org/docs/user-manual.chunked/ar01s06.html#UPS_shutdown

[MrM40]

My work arround:
Make a srcript which are called from a systemd-timer at boot (and every 24 hours just in case).

Systemd-timer example:

Timer-file (/etc/systemd/system/nut_properties.timer):

[Unit]
Description="Set nut startup-properties"

[Timer]
OnBootSec=1min
OnUnitActiveSec=24h

[Install]
WantedBy=timers.target 

Service-file (/etc/systemd/system/nut_properties.service)

[Unit]
Description="Set nut startup properties"

[Service]
Type=oneshot
ExecStart=/etc/nut/CustomStartupProperties.sh 

Scriptfile: /etc/nut/CustomStartupProperties.sh

upsrw -w -s battery.charge.low=50 -u nut -p MyPass eaton@localhost
upsrw -w -s ups.delay.shutdown=120 -u nut -p MyPass eaton@localhost
upsrw -w -s ups.delay.start=125 -u nut -p MyPass eaton@localhost

The -w parameter is very important when you call multiple upsrw commands

Ser permisions on the scriptfile:

chmod u=rwx,g=rwx,o=--- /etc/nut/CustomStartupProperties.sh

[jimklimov]

FYI: Summarized an earlier part of comments above in the Wiki at https://github.com/networkupstools/nut/wiki/Ensure-UPS-settings-with-volatile-device-memory