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

[Charles Lepple]

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/