[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