[Nut-upsuser] The dreaded Tripp Lite SMART500RT1U and NUT
Charles Lepple
clepple at gmail.com
Thu Jun 26 20:12:16 UTC 2014
On Thu, Jun 26, 2014 at 2:31 PM, Steve Ballantyne
<steve.ballantyne at 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 at 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
More information about the Nut-upsuser
mailing list