On Thu, 3 Sep 2020, [email protected] wrote:
battery.charge.low: 30
ups.delay.shutdown: 20
I am trying to understand what controls/triggers the UPS reboot signal.
1. Have had the UPS reboot while on power and 100% battery when manually
restarting M1 for updates taking down both M1 (during boot, so the
signal was delayed?) & M2 (was running). Have tried to reproduce it
while writing this with a manual reboot / suspend to no avail.
NUT is designed to
1. Power off the system attached to the UPS when some criteria is reached, eg.
status [LB]
2. Some time later, in your case ups.delay.shutdown = 20 seconds, the UPS shuts
down its power outlets.
3. When wall power returns, the UPS turns on it's power outlets and this
provokes the attached system to power up.
In your case, instead of powering off the attached system, you begin a
suspend/hibernate, but continue to take power from the UPS. But the
ups.delay.shutdown will still have an effect, and the UPS will turn off it's
outlets.
I don't see clearly how you intend to operate, but you may need to neutralize
the "delayed shutdown" order to the UPS. However if you do this, I don't see
how it will be possible to resume from suspend.
I suspect that you would be best served by a big UPS which will carry you
through most power outages, and use NUT to shutdown (not suspend) on LB, when
it's clear that wall power has gone for the day. There is no automatic suspend
in that scenario.
Roger
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
