[Nut-upsuser] TrippLite 1500XL problems, continued.

Arjen de Korte arjen at de-korte.org
Fri Sep 21 20:42:47 UTC 2007


> So a month or more ago, I posted about continual disconnect messages from
> this UPS (roughly 2/hour), using nut 2.2.0 on debian etch. Now, I've
> finally gotten around to running tripplite_usb in debug mode, and these
> are the results:
>
> ...
> send_cmd(msg_len=2, type='L')
> send_cmd(msg_len=2, type='S')
> send_cmd(msg_len=2, type='B')
> send_cmd(msg_len=2, type='L')
> send_cmd(msg_len=2, type='S')
> send_cmd(msg_len=2, type='B')
> send_cmd: send_try = 3, recv_try = 10
>
> Error reading B value: Device detached? (error 0: error sending control
> message: Operation not permitted)
> Closing device
> Reconnect attempt #1
> ==================================================
> = device has been disconnected, try to reconnect =
> ==================================================
> Reopening device
> Checking device (0000/0000) (002/001)
> - VendorID: 0000
> - ProductID: 0000
> - Manufacturer: unknown
> - Product: unknown
> - Serial Number: unknown
> - Bus: 002
> Trying to match device
> Device does not match - skipping
> Checking device (09AE/0001) (001/003)
> - VendorID: 09ae
> - ProductID: 0001
> - Manufacturer: TRIPP LITE
> - Product: TRIPP LITE UPS
> - Serial Number: unknown
> - Bus: 001
> Trying to match device
> Device matches
> Device reopened successfully
> Successfully reconnected
> send_cmd(msg_len=3, type='W')
> send_cmd(msg_len=2, type='
> Using OMNIVS 2001 protocol (2001)
> send_cmd(msg_len=2, type='S')
> send_cmd(msg_len=2, type='P')
> send_cmd(msg_len=2, type='F')
> send_cmd(msg_len=2, type='V')
> send_cmd(msg_len=2, type='V')
> send_cmd(msg_len=2, type='U')
> send_cmd: send_try = 3, recv_try = 10
>
> Unit ID not retrieved (not available on all models)
> send_cmd(msg_len=2, type='S')
> send_cmd(msg_len=2, type='B')
> send_cmd(msg_len=2, type='L')
> ...
>
> Any help would rock.

This seems to happen with other NUT drivers for USB devices as well.
Personally, I think the best course of action would be *not* to complain
about spurious reconnects in the logs. Only if the device isn't available
after (say) three consecutive tries, assume it is disconnected.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57




More information about the Nut-upsuser mailing list