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.) -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
