[Nut-upsuser] Tripplite OMNIVS1500 Woes

Wed Aug 13 14:14:36 UTC 2008

Charles,
I'm sorry for the comment about aggravation, this is a learning experience
for me & I whole-heartedly honor and appreciate the extremely tough work you
put into developing this driver for all of us to use. Thank you!

I have poked around a little bit more:
(The following is one debug output - the driver is running solo (no
upsd/mon) The second error is the one that actually caused the driver to
exit)

tripplite_usb -DDDDD -a hub_ups

send_cmd(msg_len=2, type='L')
send_cmd: sending  3a 4c b3 0d 00 00 00 00 '.L......'
send_cmd: received 4c 30 30 45 44 58 58 0d 'L00EDXX.' (OK)
send_cmd(msg_len=2, type='S')
send_cmd: sending  3a 53 ac 0d 00 00 00 00 '.S......'
send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (OK)
send_cmd(msg_len=2, type='B')
send_cmd: sending  3a 42 bd 0d 00 00 00 00 '.B......'
send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (bad)
send_cmd: send_try = 3, recv_try = 10

Error reading B value: Device detached? (error 0: No error)
Reconnect attempt #1
==================================================
= device has been disconnected, try to reconnect =
==================================================
Checking device (09AE/0001) (003/010)
- VendorID: 09ae
- ProductID: 0001
- Manufacturer: TRIPP LITE
- Product: TRIPP LITE UPS
- Serial Number: unknown
- Bus: 003
Trying to match device
Device matches
failed to claim USB device, trying 2 more time(s)...
detaching kernel driver from USB device...
trying again to claim USB device...
Successfully reconnected
send_cmd(msg_len=3, type='W')
send_cmd: sending  3a 57 00 a8 0d 00 00 00 '.W......'
send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (bad)
send_cmd: send_try = 3, recv_try = 10

Could not reset watchdog. Please send model information to nut-upsdev
mailing list
send_cmd(msg_len=2, type='
send_cmd: sending  3a 00 ff 0d 00 00 00 00 '........'
send_cmd: received 00 20 01 58 58 58 58 0d '...XXXX.' (OK)
Using OMNIVS 2001 protocol (2001)
send_cmd(msg_len=2, type='S')
send_cmd: sending  3a 53 ac 0d 00 00 00 00 '.S......'
send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (OK)
send_cmd(msg_len=2, type='P')
send_cmd: sending  3a 50 af 0d 00 00 00 00 '.P......'
send_cmd: received 50 30 31 35 30 30 58 0d 'P01500X.' (OK)
send_cmd(msg_len=2, type='F')
send_cmd: sending  3a 46 b9 0d 00 00 00 00 '.F......'
send_cmd: received 46 32 32 31 31 20 41 0d 'F2211.A.' (OK)
send_cmd(msg_len=2, type='V')
send_cmd: sending  3a 56 a9 0d 00 00 00 00 '.V......'
send_cmd: received 56 31 30 34 30 58 58 0d 'V1040XX.' (OK)
send_cmd(msg_len=2, type='V')
send_cmd: sending  3a 56 a9 0d 00 00 00 00 '.V......'
send_cmd: received 56 31 30 34 30 58 58 0d 'V1040XX.' (OK)
send_cmd(msg_len=2, type='U')
send_cmd: sending  3a 55 aa 0d 00 00 00 00 '.U......'
send_cmd: received 56 31 30 34 30 58 58 0d 'V1040XX.' (bad)
send_cmd: send_try = 3, recv_try = 10

Unit ID not retrieved (not available on all models)
Attached to Tripp Lite UPS
send_cmd(msg_len=2, type='S')
send_cmd: sending  3a 53 ac 0d 00 00 00 00 '.S......'
send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (OK)
send_cmd: send_try = 1, recv_try = 8

send_cmd(msg_len=2, type='B')
send_cmd: sending  3a 42 bd 0d 00 00 00 00 '.B......'
send_cmd: received 42 30 44 41 34 44 33 0d 'B0DA4D3.' (OK)
send_cmd(msg_len=2, type='L')
send_cmd: sending  3a 4c b3 0d 00 00 00 00 '.L......'
send_cmd: received 4c 30 30 45 44 58 58 0d 'L00EDXX.' (OK)
send_cmd(msg_len=2, type='S')
send_cmd: sending  3a 53 ac 0d 00 00 00 00 '.S......'
send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (OK)
send_cmd: send_try = 3, recv_try = 1

send_cmd(msg_len=2, type='B')
send_cmd: sending  3a 42 bd 0d 00 00 00 00 '.B......'
send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (bad)
send_cmd: send_try = 3, recv_try = 10

Error reading B value: Device detached? (error 0: could not claim interface
0: Device or resource busy)
Reconnect attempt #1
==================================================
= device has been disconnected, try to reconnect =
==================================================
Checking device (09AE/0001) (003/010)
- VendorID: 09ae
- ProductID: 0001
- Manufacturer: TRIPP LITE
- Product: TRIPP LITE UPS
- Serial Number: unknown
- Bus: 003
Trying to match device
Device matches
failed to claim USB device, trying 2 more time(s)...
detaching kernel driver from USB device...
trying again to claim USB device...
Successfully reconnected
send_cmd(msg_len=3, type='W')
send_cmd: sending  3a 57 00 a8 0d 00 00 00 '.W......'
send_cmd: received 57 00 0d 00 00 00 00 00 'W.......' (OK)
send_cmd(msg_len=2, type='
send_cmd: sending  3a 00 ff 0d 00 00 00 00 '........'
send_cmd: received 00 20 01 58 58 58 58 0d '...XXXX.' (OK)
send_cmd: send_try = 2, recv_try = 3

Using OMNIVS 2001 protocol (2001)
send_cmd(msg_len=2, type='S')
send_cmd: sending  3a 53 ac 0d 00 00 00 00 '.S......'
send_cmd: received 00 20 01 58 58 58 58 0d '...XXXX.' (bad)
send_cmd: send_try = 3, recv_try = 10

Could not retrieve status ... is this an OMNIVS model?

**This is the point in which it Bails out**
It's strange that it had two disconnect errors - but recovered from the
first. I observed this behavior other times as well - sometimes the
reconnect would work and other it would fail.

When I used to let the service run for a long period of time I would see a
lot of "Error reading X value" messages in the logfile & these would cause
reconnects as well.

I'm just now starting to learn how Linux handles USB devices & I had another
question regarding this. Is this Tripplite model supposed to be a hiddev
device? From what I recall reading it seemed that it needed the
tripplite_usb driver because it is NOT a hiddev device, it uses a serial
over usb connection...? When I plug the device in I get a /dev/hiddev0 file
- and yet the usbhid-ups driver will not work with this protocol. It may be
a missinformed shot in the dark - but is hiddev claiming the device when it
shouldn't be?

Thanks so much for the input so far!

And for future job's should I be looking for an MGE UPS?? It seems they have
been highly reccomended here.

On Tue, Aug 12, 2008 at 10:34 PM, Charles Lepple <clepple at gmail.com> wrote:

> On Mon, Aug 11, 2008 at 2:20 PM, Craig Van Degrift
> <craig at yosemitefoothills.com> wrote:
> > My OmniPlus1500LCD unit has a
> > button to push for testing.  Without a special button, using a switched
> power
> > strip can turn off power while keeping the ground connection.
>
> I haven't tried this on an OmniPlus model, but most test buttons try
> not to trigger a low-battery condition during the test.
>
> This would be useful for testing OL/OB status, but it wouldn't help
> test a full OB/LB shutdown sequence.
>
> --
> - Charles Lepple
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20080813/a89f6bf9/attachment.htm 