Nut upsdev - May 2016 - Tripp-Lite SMART1500LCDT

I bought this UPS to use with NUT.  I've used Belkin, APC, CyberPower,
Best, Powerware upses with NUT on dozens of servers beginning with RHEL3.

http://www.amazon.com/Tripp-Lite-Display-Protection-SMART1500LCDT/dp/B009TZTGWK

Since this was advertised as USB HID, I didn't expect any problems.  Bad
idea (should have gotten the Cyberware with somewhat less runtime).

Initially, it seems to work with the NUT usbhid-ups driver.  Here is the
output of upsc:

battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 30
battery.runtime: 4718
battery.type: PbAC
battery.voltage: 0.0
battery.voltage.nominal: 24.0
device.mfr: Tripp Lite
device.model: TRIPP LITE UPS
device.serial: 2546DVLSM871900329
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 3016
driver.parameter.vendorid: 09ae
driver.version: 2.7.2
driver.version.data: TrippLite HID 0.81
driver.version.internal: 0.38
input.frequency: 6020.0
input.transfer.high: 150.0
input.transfer.low: 92.0
input.voltage: 0.0
input.voltage.nominal: 120
output.current: 130.00
output.frequency: 6020.0
output.frequency.nominal: 60
output.voltage: 0.0
output.voltage.nominal: 120
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 10
ups.mfr: Tripp Lite
ups.model: TRIPP LITE UPS
ups.power: 90.0
ups.power.nominal: 1500
ups.productid: 3016
ups.serial: 2546DVLSM871900329
ups.status: OL
ups.timer.reboot: 65535
ups.timer.shutdown: 65535
ups.timer.start: 65535
ups.vendorid: 09ae
ups.watchdog.status: 0

On RHEL6 with nut-2.6.5, it runs for 1 or 2 days, then gets

Plugging in new USB cable:
May 16 21:01:07 fairfax kernel: usb 4-2: new low speed USB device number 17
using uhci_hcd
May 16 21:01:07 fairfax kernel: usb 4-2: New USB device found, idVendor=09ae,
idProduct=3016
May 16 21:01:07 fairfax kernel: usb 4-2: New USB device strings:
Mfr=3,Product=1, SerialNumber=May 16 21:01:07 fairfax kernel: usb 4-2: Product:
TRIPP LITE UPS
May 16 21:01:07 fairfax kernel: usb 4-2: Manufacturer: Tripp Lite
May 16 21:01:07 fairfax kernel: usb 4-2: SerialNumber: 2546DVLSM871900329
May 16 21:01:07 fairfax kernel: usb 4-2: configuration #1 chosen from 1choice
May 16 21:01:07 fairfax kernel: generic-usb 0003:09AE:3016.0008:
hiddev96,hidraw0: USB HID v1.11 Device [Tripp Lite TRIPP LITE UPS] on
usb-0000:00:1d.2-2/input0
May 16 21:01:08 fairfax upsmon[10255]: Poll UPS [trippups at localhost] failed -
Data stale
May 16 21:01:08 fairfax upsd[10250]: UPS [trippups] data is no longer stale ....
May 18 14:53:34 fairfax kernel: hub 4-0:1.0: port 2 disabled by hub (EMI?),
re-enabling...
May 18 14:53:34 fairfax kernel: usb 4-2: USB disconnect, device number 17
May 18 14:53:34 fairfax kernel: usb 4-2: new low speed USB device number 18
using uhci_hcd
May 18 14:53:35 fairfax kernel: usb 4-2: new low speed USB device number 19
using uhci_hcd
May 18 14:53:35 fairfax kernel: usb 4-2: new low speed USB device number 20
using uhci_hcd
May 18 14:53:35 fairfax kernel: usb 4-2: device not accepting address 20, error
-71
May 18 14:53:35 fairfax kernel: usb 4-2: new full speed USB device number 21
using uhci_hcd
May 18 14:53:36 fairfax kernel: usb 4-2: device not accepting address 21, error
-71
May 18 14:53:36 fairfax kernel: hub 4-0:1.0: unable to enumerate USB device on
port 2

The UPS "falls off" the USB bus? and only physically replugging the
USB
cable seems to reset it.  (I tried different cables and different ports,
and even some hubs).  So I plugged the cable into an old laptop with
Fedora 19, and mocked up nut-2.7.2 from f23 for f19.  That also runs
initially, but in less than a minute gets an I/O error:

upsdrvctl[3729]: Can't open /var/run/nut/usbhid-ups-auto.pid: No such file
or di
systemd[1]: nut-driver.service: main process exited, code=exited, status=1/FAILU
upsd[3726]: Can't connect to UPS [trippups] (usbhid-ups-trippups): No such
file
upsd[3726]: Can't connect to UPS [trippups] (usbhid-ups-trippups): No such
file
usbhid-ups[3725]: Can't claim USB device [09ae:3016]: No such file or
directory
usbhid-ups[3725]: libusb_get_report: Input/output error
upsd[3726]: Connected to UPS [trippups]: usbhid-ups-trippups
upsd[3726]: listening on 127.0.0.1 port 3493
upsd[3726]: Connected to UPS [trippups]: usbhid-ups-trippups
upsd[3726]: listening on 127.0.0.1 port 3493
upsd[3726]: listening on ::1 port 3493
upsd[3726]: listening on ::1 port 3493
upsd[3726]: listening on 2001:470:8:xxxx::xxxx port 3493
upsd[3726]: listening on 2001:470:8:xxxx::xxxx port 3493
upsd[3726]: fopen /var/run/nut/upsd.pid: No such file or directory 
usbhid-ups[3725]: Startup successful
systemd[1]: Started Network UPS Tools - power devices information server.
systemd[1]: Starting Network UPS Tools - power devices information server...

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).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20160522/80abb734/attachment.sig>

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 at gmail

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.)
>