[Nut-upsdev] Tripp-Lite SMART1500LCDT

[Marco Walther]

On 08/03/2016 05:25 AM, Stuart Gathman wrote:
> 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.
Finally an idea;-) I had the same problem for a couple of years but 
since I use a [1st gen] appleTV as the server, I thought it might be 
it's USB port.

I bought a `plugable USB2-HUB-AG7' and experimented a bit. So far, I did 
not get it to turn the power to devices completely off:-( But the 
unbind/bind seems affect the devices somehow. I tried it with a little 
Sparkfun RedBoard (Arduino clone) and when I [re]bind, the RX/TX LEDs 
flash shortly, so it seems to reinitialize it's USB-Serial chip. Maybe 
that's enough?

The same TX/RX LED flashing happens with the hub-ctrl power off->on;-)

OK, the USB hub is now installed between the aTV & USP ;-) Let's see 
what happens next.

-- Marco

>
> 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 at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev