[Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

Ken Olum kdo at cosmos.phy.tufts.edu
Tue Dec 28 16:33:17 GMT 2021


Recent discussion reminds me that I had a problem with my BCPERS450
about 4 years ago.  I developed a workaround which I've been using
successfully ever since.  It would be nice if some change were
incorporated into the system to help other people who have this unit or
ones with the same issue.  From my message of 23 Mar 2018:

I discovered the following code at line 571 in usbhid-ups.c.  This is
part of the "checking for alternatives" code:

		if (!strcasecmp(cmdname, "shutdown.return")) {
			int	ret;

			/* Ensure "ups.start.auto" is set to "yes", if supported */
			if (dstate_getinfo("ups.start.auto")) {
				setvar("ups.start.auto", "yes");
			}

			ret = instcmd("load.on.delay", dstate_getinfo("ups.delay.start"));
			if (ret != STAT_INSTCMD_HANDLED) {
				return ret;
			}

			return instcmd("load.off.delay", dstate_getinfo("ups.delay.shutdown"));
		}

My understanding of this code is that it attempts to set the
load.on.delay control.  If that works, it then uses load.off.delay to
schedule a shutdown.  My unit has nothing that maps into load.on.delay,
so that command fails, and then it does not use load.off.delay.  Instead
it fails, and the calling code goes on to try shutdown.reboot, which in
my case has the completely wrong functionality.

However, load.off.delay seems to be the right thing to use for me.
Without any other setting, it shuts off the UPS after the delay and
reboots it when the power returns.  I don't know what functionality
load.on.delay is supposed to represent.  Is it trying to avoid the race
where the power comes on before the load.off.delay command has reached
the UPS, which then never restarts the load?

Since this race seems fairly unlikely to cause trouble and with the code
above my UPS is unusable, I modified my copy of the code to remove the
check for the return value from load.on.delay.  This indeed causes it to
shut down the UPS as it should.

I'm sure this is not the right fix in general, but I don't understand
the situation well enough to know what would be better.  Among other
things I don't know is whether my real problem is with this logic or
whether it is with the mapping of things like
UPS.OutletSystem.Outlet.DelayBeforeShutdown to things like
load.off.delay.

                                        Ken



More information about the Nut-upsuser mailing list