On Mar 20, 2018, at 11:53 AM, Ken Olum <k...@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.


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: 

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

Nut-upsuser mailing list

Reply via email to