Nut upsuser - Jun 2018 - manual transfer switch to make UPS testing easier

Thanks, Charles.  I pulled your change and it fixed my segmentation
fault.

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

In case this is helpful to anyone, here's what I did to make it easier
to test NUT and my UPS.  My problem is that for testing I don't want my
system plugged into my UPS, so I can test UPS operations without
shutting down my system.  But the rest of the time, I want to be
protected against power problems.  My solution was to build a transfer
switch (just a DPDT switch in a box) that enables me to switch my system
between wall power and UPS power.  Thus I can connect the system to the
wall, shut down the UPS for testing, and connect my system back to the
UPS when I'm done, all without any system shutdowns.

                                        Ken

On Fri, 1 Jun 2018, Ken Olum wrote:
> In case this is helpful to anyone, here's what I did to make it easier
> to test NUT and my UPS.  My problem is that for testing I don't want my
> system plugged into my UPS, so I can test UPS operations without
> shutting down my system.  But the rest of the time, I want to be
> protected against power problems.  My solution was to build a transfer
> switch (just a DPDT switch in a box) that enables me to switch my system
> between wall power and UPS power.  Thus I can connect the system to the
> wall, shut down the UPS for testing, and connect my system back to the
> UPS when I'm done, all without any system shutdowns.
I have a dual PS server, with one PS plugged into the wall (surge
protector) and one into the UPS.  And the UPS is plugged into a wall
outlet controlled by the light switch (intended for floor lamps).

So I just turn off the light switch to test the UPS.

I highly recommend dual PS servers/desktops - it gives you a lot of
flexibility and some additional reliability for not much more additional
cost.

-- 
 	      Stuart D. Gathman <stuart at gathman.org>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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