On Thu, Jun 26, 2014 at 2:31 PM, Steve Ballantyne <steve.ballant...@gmail.com> wrote: > According to the list, I should be using the usbhid-ups driver. But when I > do that, it fails and tells me that I should be using tripplite_usb instead.
Sigh, it sounds like a collision of "protocol" numbers. If I recall, Tripp Lite assured us that the USB Product ID (if not 0001) mapped to the "protocol", but not necessarily vice versa. So the compatibility list is referring to a device with USB IDs 09AE/3005. 09AE/0001 is essentially a USB-to-serial converter, and is not compatible with usbhid-ups. (Theoretically, we could have a companion driver that talks the same protocols over a real RS-232 port, but the hardware I used to develop the tripplite_usb driver only has a USB port.) However, we don't have all of the 09AE/0001 protocols decoded in the tripplite_usb driver. > Fine! But when I use the tripplite_usb driver, it don't work either ... > > pi@raspberrypi ~ $ sudo /lib/nut/tripplite_usb -u root -a SMART500RT1U > -DDDDD > Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.20 (2.6.4) > Warning: This is an experimental driver. > Some features may not function correctly. > > 0.000000 debug level is '5' > 0.009252 Checking device (09AE/0001) (001/009) > 0.013935 - VendorID: 09ae > 0.015179 - ProductID: 0001 > 0.016578 - Manufacturer: TRIPP LITE > 0.017984 - Product: TRIPP LITE SMART500RT1U > 0.019899 - Serial Number: unknown > 0.020123 - Bus: 001 > 0.020785 Trying to match device > 0.020974 Device matches > 0.022584 Detected a UPS: TRIPP LITE/TRIPP LITE SMART500RT1U > 0.022884 send_to_all: SETINFO ups.vendorid "09ae" > 0.023091 send_to_all: SETINFO ups.productid "0001" > 0.024146 send_to_all: SETINFO device.type "ups" > 0.024961 send_to_all: SETINFO driver.version "2.6.4" > 0.025174 send_to_all: SETINFO driver.version.internal "0.20" > 0.025897 send_to_all: SETINFO driver.name "tripplite_usb" > 0.026152 send_cmd(msg_len=2, type=' > 0.026694 send_cmd: sending 3a 00 ff 0d 00 00 00 00 '........' > 1.130244 libusb_get_interrupt: Connection timed out > 1.131657 libusb_get_interrupt() returned 0 instead of 8 while sending > 3a 00 ff 0d 00 00 00 00 '........' > 2.133695 libusb_get_interrupt: Connection timed out > 2.135035 libusb_get_interrupt() returned 0 instead of 8 while sending > 3a 00 ff 0d 00 00 00 00 '........' > 3.137419 libusb_get_interrupt: Connection timed out > 3.138950 libusb_get_interrupt() returned 0 instead of 8 while sending > 3a 00 ff 0d 00 00 00 00 '........' > 4.141155 libusb_get_interrupt: Connection timed out > 4.142488 libusb_get_interrupt() returned 0 instead of 8 while sending > 3a 00 ff 0d 00 00 00 00 '........' > 5.144640 libusb_get_interrupt: Connection timed out > 5.145957 libusb_get_interrupt() returned 0 instead of 8 while sending > 3a 00 ff 0d 00 00 00 00 '........' > 6.147561 libusb_get_interrupt: Connection timed out > 6.148989 libusb_get_interrupt() returned 0 instead of 8 while sending > 3a 00 ff 0d 00 00 00 00 '........' > 7.150974 libusb_get_interrupt: Connection timed out > 7.152289 libusb_get_interrupt() returned 0 instead of 8 while sending > 3a 00 ff 0d 00 00 00 00 '........' > 8.154643 libusb_get_interrupt: Connection timed out > 8.156024 libusb_get_interrupt() returned 0 instead of 8 while sending > 3a 00 ff 0d 00 00 00 00 '........' > 9.158554 libusb_get_interrupt: Connection timed out > 9.159965 libusb_get_interrupt() returned 0 instead of 8 while sending > 3a 00 ff 0d 00 00 00 00 '........' Hmm, this shouldn't take that long. Does it do that every time you start the tripplite_usb driver, or only the first time? > 9.262678 send_cmd: received 00 30 05 58 58 58 58 0d '.0.XXXX.' (OK) > 9.264042 send_to_all: SETINFO ups.debug.0 "30 05 58 58 58 58 0d > '0.XXXX.'" > 9.265665 send_to_all: SETINFO ups.firmware.aux "protocol 3005" Here's that 3005 protocol ID. > 9.267228 send_cmd(msg_len=3, type='W') > 9.267744 send_cmd: sending 3a 57 00 a8 0d 00 00 00 '.W......' > 9.370082 send_cmd: received 57 00 0d 00 00 00 00 00 'W.......' (OK) Your unit might support a watchdog timer. > 9.370367 send_cmd(msg_len=2, type='S') > 9.370565 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......' > 9.472418 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK) Ah, what we should be seeing here is that "01 04" status in ASCII. I think the 3004 protocol also encodes it in binary. > 9.472712 send_to_all: SETINFO ups.mfr "Tripp Lite" > 9.472899 send_cmd(msg_len=2, type='P') > 9.473087 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......' > 9.575667 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK) > 9.576026 send_to_all: SETINFO ups.model "SMART500RT1U" > 9.576848 send_to_all: SETINFO ups.power.nominal "500" 500W sounds right based on the name. > 9.577346 send_cmd(msg_len=2, type='F') > 9.578194 send_cmd: sending 3a 46 b9 0d 00 00 00 00 '.F......' > 9.679786 send_cmd: received 46 33 33 34 34 30 31 0d 'F334401.' (OK) > 9.680087 send_to_all: SETINFO ups.firmware "F334401" > 9.680278 send_cmd(msg_len=2, type='V') > 9.680463 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......' > 9.782790 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK) > 9.783126 Unknown input voltage range: 0x02 > 9.783308 Unknown number of switchable load banks: 0x01 Is this a 230V unit? Again, it's looking for the ASCII version of 0x02 (which would be 0x32) > 9.783476 send_cmd(msg_len=2, type='V') > 9.783664 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......' > 9.885906 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK) > 9.886240 send_to_all: SETINFO ups.debug.V "02 00 0c 01 58 58 0d > '....XX.'" > 9.886425 send_cmd(msg_len=2, type='U') > 9.886618 send_cmd: sending 3a 55 aa 0d 00 00 00 00 '.U......' > 9.988651 send_cmd: received 55 00 00 0d 00 00 00 00 'U.......' (OK) > 9.989595 send_to_all: SETINFO ups.id "0" > 9.990206 send_to_all: SETFLAGS ups.id RW STRING > 9.990984 send_to_all: SETAUX ups.id 5 > 9.991202 Unit ID: 0 > 9.991406 send_to_all: SETINFO input.voltage.nominal "120" ^ 120V might just be the default. > That last little bit between DATASTALE and DATAOK seems to loop on through > infinity. Has anyone actually made this model work with nut? I have dug up > some other very old threads that all seem to dead end without a solution. Don't think so, but I think we can make this work with some code changes. Do you have access to a Windows box to verify some of the readings, or does it have a readout on the front? I can also get access to a Raspberry Pi if needed to rebuild the NUT package. -- - Charles Lepple _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser