On Mar 8, 2021, at 5:38 PM, Lee Damon via Nut-upsuser <nut-upsuser@alioth-lists.debian.net> wrote: > > On 3/8/21 2:05 PM, Manuel Wolfshant wrote: >> calibrating should not trigger nut > > I agree, it shouldn't. > The behavior is going to depend slightly on which version of NUT you are running.
v2.7.4: https://github.com/networkupstools/nut/blob/v2.7.4/clients/upsmon.c#L701 There's a later commit to specifically ignore calibration-induced "OB LB": https://github.com/networkupstools/nut/commit/13b26974b4b22e629ecb13c2ce501aba8fdd6aad > The only thing I can think of that may explain what happened was > UPS1 - ONBATT (calibrating) > UPS2 - ONLINE + LOWBATT (because of a bad battery) > UPS3 - ONLINE > > it saw the ONBATT for 1 and the LOWBATT from 2 and triggered. For the state described above, you should have a "power value" of 2 (OB but not LB still contributes 1 to the power value): * https://github.com/networkupstools/nut/blob/v2.7.4/clients/upsmon.c#L679 (loop over all UPSes, check each independently as to whether they are critical) * https://networkupstools.org/docs/man/upsmon.html#_power_values What is your MINSUPPLIES in upsmon.conf? > If that's the case, how do I prevent it from happening again? I think the key is going to be figuring out the exact state that triggered it. You can increase log levels to see state changes in the drivers. If these are CyberPower UPSes doing OB+LB+CAL, that commit mentioned above is probably the simplest fix. Another option is to do some sort of "debouncing" with upssched, but that assumes that your batteries will last longer in an actual power failure than the duration of the test. Debouncing is also harder to configure correctly. In any case, it might be good to use VMs with dummy-ups drivers to test some of these potential solutions. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
