<div dir="ltr">Charles,<br>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!<br>
<br>I have poked around a little bit more:<br>(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)<br><br>tripplite_usb -DDDDD -a hub_ups<br>
<br>send_cmd(msg_len=2, type='L')<br>send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'<br>send_cmd: received 4c 30 30 45 44 58 58 0d 'L00EDXX.' (OK)<br>send_cmd(msg_len=2, type='S')<br>
send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'<br>send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (OK)<br>send_cmd(msg_len=2, type='B')<br>send_cmd: sending 3a 42 bd 0d 00 00 00 00 '.B......'<br>
send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (bad)<br>send_cmd: send_try = 3, recv_try = 10<br><br>Error reading B value: Device detached? (error 0: No error)<br>Reconnect attempt #1<br>==================================================<br>
= device has been disconnected, try to reconnect =<br>==================================================<br>Checking device (09AE/0001) (003/010)<br>- VendorID: 09ae<br>- ProductID: 0001<br>- Manufacturer: TRIPP LITE<br>- Product: TRIPP LITE UPS <br>
- Serial Number: unknown<br>- Bus: 003<br>Trying to match device<br>Device matches<br>failed to claim USB device, trying 2 more time(s)...<br>detaching kernel driver from USB device...<br>trying again to claim USB device...<br>
Successfully reconnected<br>send_cmd(msg_len=3, type='W')<br>send_cmd: sending 3a 57 00 a8 0d 00 00 00 '.W......'<br>send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (bad)<br>send_cmd: send_try = 3, recv_try = 10<br>
<br>Could not reset watchdog. Please send model information to nut-upsdev mailing list<br>send_cmd(msg_len=2, type='<br>send_cmd: sending 3a 00 ff 0d 00 00 00 00 '........'<br>send_cmd: received 00 20 01 58 58 58 58 0d '...XXXX.' (OK)<br>
Using OMNIVS 2001 protocol (2001)<br>send_cmd(msg_len=2, type='S')<br>send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'<br>send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (OK)<br>send_cmd(msg_len=2, type='P')<br>
send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'<br>send_cmd: received 50 30 31 35 30 30 58 0d 'P01500X.' (OK)<br>send_cmd(msg_len=2, type='F')<br>send_cmd: sending 3a 46 b9 0d 00 00 00 00 '.F......'<br>
send_cmd: received 46 32 32 31 31 20 41 0d 'F2211.A.' (OK)<br>send_cmd(msg_len=2, type='V')<br>send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'<br>send_cmd: received 56 31 30 34 30 58 58 0d 'V1040XX.' (OK)<br>
send_cmd(msg_len=2, type='V')<br>send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'<br>send_cmd: received 56 31 30 34 30 58 58 0d 'V1040XX.' (OK)<br>send_cmd(msg_len=2, type='U')<br>send_cmd: sending 3a 55 aa 0d 00 00 00 00 '.U......'<br>
send_cmd: received 56 31 30 34 30 58 58 0d 'V1040XX.' (bad)<br>send_cmd: send_try = 3, recv_try = 10<br><br>Unit ID not retrieved (not available on all models)<br>Attached to Tripp Lite UPS<br>send_cmd(msg_len=2, type='S')<br>
send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'<br>send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (OK)<br>send_cmd: send_try = 1, recv_try = 8<br><br>send_cmd(msg_len=2, type='B')<br>send_cmd: sending 3a 42 bd 0d 00 00 00 00 '.B......'<br>
send_cmd: received 42 30 44 41 34 44 33 0d 'B0DA4D3.' (OK)<br>send_cmd(msg_len=2, type='L')<br>send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'<br>send_cmd: received 4c 30 30 45 44 58 58 0d 'L00EDXX.' (OK)<br>
send_cmd(msg_len=2, type='S')<br>send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'<br>send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (OK)<br>send_cmd: send_try = 3, recv_try = 1<br><br>send_cmd(msg_len=2, type='B')<br>
send_cmd: sending 3a 42 bd 0d 00 00 00 00 '.B......'<br>send_cmd: received 53 31 34 30 31 00 30 0d 'S1401.0.' (bad)<br>send_cmd: send_try = 3, recv_try = 10<br><br>Error reading B value: Device detached? (error 0: could not claim interface 0: Device or resource busy)<br>
Reconnect attempt #1<br>==================================================<br>= device has been disconnected, try to reconnect =<br>==================================================<br>Checking device (09AE/0001) (003/010)<br>
- VendorID: 09ae<br>- ProductID: 0001<br>- Manufacturer: TRIPP LITE<br>- Product: TRIPP LITE UPS <br>- Serial Number: unknown<br>- Bus: 003<br>Trying to match device<br>Device matches<br>failed to claim USB device, trying 2 more time(s)...<br>
detaching kernel driver from USB device...<br>trying again to claim USB device...<br>Successfully reconnected<br>send_cmd(msg_len=3, type='W')<br>send_cmd: sending 3a 57 00 a8 0d 00 00 00 '.W......'<br>send_cmd: received 57 00 0d 00 00 00 00 00 'W.......' (OK)<br>
send_cmd(msg_len=2, type='<br>send_cmd: sending 3a 00 ff 0d 00 00 00 00 '........'<br>send_cmd: received 00 20 01 58 58 58 58 0d '...XXXX.' (OK)<br>send_cmd: send_try = 2, recv_try = 3<br><br>Using OMNIVS 2001 protocol (2001)<br>
send_cmd(msg_len=2, type='S')<br>send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'<br>send_cmd: received 00 20 01 58 58 58 58 0d '...XXXX.' (bad)<br>send_cmd: send_try = 3, recv_try = 10<br><br>
Could not retrieve status ... is this an OMNIVS model?<br><br>**This is the point in which it Bails out**<br>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. <br>
<br>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.<br><br>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?<br>
<br>Thanks so much for the input so far!<br><br>And for future job's should I be looking for an MGE UPS?? It seems they have been highly reccomended here. <br><br><br><div class="gmail_quote">On Tue, Aug 12, 2008 at 10:34 PM, Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Mon, Aug 11, 2008 at 2:20 PM, Craig Van Degrift<br>
<<a href="mailto:craig@yosemitefoothills.com">craig@yosemitefoothills.com</a>> wrote:<br>
</div><div class="Ih2E3d">> My OmniPlus1500LCD unit has a<br>
> button to push for testing. Without a special button, using a switched power<br>
> strip can turn off power while keeping the ground connection.<br>
<br>
</div>I haven't tried this on an OmniPlus model, but most test buttons try<br>
not to trigger a low-battery condition during the test.<br>
<br>
This would be useful for testing OL/OB status, but it wouldn't help<br>
test a full OB/LB shutdown sequence.<br>
<br>
--<br>
<font color="#888888">- Charles Lepple<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@lists.alioth.debian.org">Nut-upsuser@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser" target="_blank">http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser</a><br>
</div></div></blockquote></div><br></div>