I've made some progress getting this Tripplite to work: http://gathman.org/2016/07/30/Standard_Schmandard/
Basically, plug it into a USB hub that actually implements USB2.0, then power cycle the port when it hangs. It does seem to be a hardware problem with the USB controller. On 05/24/2016 09:06 AM, Charles Lepple wrote: > On May 22, 2016, at 10:18 AM, Stuart Gathman wrote: >> I have a ticket open with TrippLite, but at this point it seems to be a >> software, rather than hardware problem, since with the newer kernel and >> usbhid-ups, the ups stays on the bus, and I could kludge around the >> problem by making systemd keep restarting nut-driver. They seem to be >> interested in actually resolving the issue. If necessary, I am willing >> to donate the TrippLite and just buy a Cyberware (the last cyberware I >> bought works - hopefully they haven't broken their USB code). What >> should I do next to diagnose this problem? I don't know enough about >> USB protocol to determine which side is broken (I can only point to all >> the other brands of USB UPC that work). > I have that same model UPS, and the same general set of symptoms. Although I > can't argue with the software dependency, I think it might be related to the > USB controller hardware as well. > > > http://lists.alioth.debian.org/pipermail/nut-upsuser/2015-October/009967.html > > With a Raspberry Pi, the UPS seemed to run much longer between disconnects. I > would have to dig up the old logs to see which kernels were in use. > > I was hoping to have more time to test this UPS, but a lot of other projects > got in the way, and I ended up just switching to an older Tripp-Lite > OMNIVS1000. > > Another option is to build the code from this pull request, which reorganizes > the way the device is polled: https://github.com/networkupstools/nut/pull/122 > > I don't have a lot of experience with that branch, but it sounds promising. > (I would prefer to identify the underlying problem rather than work around it > by closing and reopening the USB device more frequently, though, especially > given the testing needed for other UPSes.) > _______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
