Nut upsuser - Mar 2018 - Tripp-Lite BCPERS450 shutdown/restart problems

Hi, Charles.  Are you by any chance planning to address my problems
where NUT does not know how to schedule a shutdown of this Tripp-Lite
UPS?  If not, could you point me in the right direction?  My best
understanding of the situation of the moment is that the right control
is UPS.OutletSystem.Outlet.DelayBeforeShutdown but that NUT does not
know to use that.

Thanks.

                                        Ken

On Mar 20, 2018, at 11:53 AM, Ken Olum <kdo at cosmos.phy.tufts.edu>
wrote:
> 
> Hi, Charles.  Are you by any chance planning to address my problems
> where NUT does not know how to schedule a shutdown of this Tripp-Lite
> UPS?  If not, could you point me in the right direction?  My best
> understanding of the situation of the moment is that the right control
> is UPS.OutletSystem.Outlet.DelayBeforeShutdown but that NUT does not
> know to use that.
Ken,

I apologize for the delay - I forgot that your segfault was on the master
branch, not the libusb-1.0+0.1 branch. (There are some merge issues with the
latter, and I have been fighting a losing battle trying to find time to test the
merge with actual working hardware.)

If you pull the master branch again, you should get a tree that includes commit
e34d94a94f0: "usbhid-ups: fix instcmd logging before fallback check",
and rebuilding with that should fix the segfault.

I wouldn't read too much into the distinction between "outlet" and
"load" and the UPS itself, especially for a single ganged output
control.

Because of the way the code is written, it tries a bunch of different
combinations of commands until one works, but unless someone provides debug
logs, we don't know the exact sequence for a given UPS. That's why I am
hesitant to push a change without doing baseline testing on known working
hardware (and grabbing the logs).

I am attempting to gather the Ubuntu/Debian rebuild instructions here:
https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu

My only caution with removing the distro packages is that the init/systemd
scripts from the NUT repository may not be the best match. (Then again, there
are some open issues with Debian/Ubuntu package shutdown scripts...)

In an earlier email, you asked about matching up the NUT "usage path"
to the Report ID. In Wireshark, find the "GET DESCRIPTOR Response" for
the HID Report Descriptor (might say "Unknown type 34" if you have an
old version like on this computer). Each of the NUT 32-bit hex components of the
path are a combination of the 16-bit Usage Page and the 16-bit Usage. The dots
in the path correspond to a Collection. The Report ID is nested in among all of
the other items. Given this structure, and that Wireshark usually collapses all
of the elements of the report descriptor, it is often easier to find report IDs
in the usbhid-ups debug output.

-- 
- Charles Lepple
https://ghz.cc/charles/

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