Ken Olum
2018-Mar-20 15:53 UTC
[Nut-upsuser] 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
Charles Lepple
2018-Mar-22 00:33 UTC
[Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems
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/
Ken Olum
2018-Mar-23 20:37 UTC
[Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems
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