[Nut-upsuser] The dreaded Tripp Lite SMART500RT1U and NUT

[Steve Ballantyne]

Hello Charles,

Thanks for the feedback.  I will try to answer some of these questions:

> 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.)

Ah, that makes sense.  I can see why this would simplify the
engineering and production of the unit.

> However, we don't have all of the 09AE/0001 protocols decoded in the
> tripplite_usb driver.

I can try to help out on this front?  :-)

SNIP!
> >    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 '........'
SNIP!

> Hmm, this shouldn't take that long. Does it do that every time you
> start the tripplite_usb driver, or only the first time?

Only when I first start the driver.  It tries about once a second, and
then after a few failures, it connects and takes off.

> >    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)

That would make sense to what I am seeing.  If I leave this to run, it
will keep looping, stopping for a split second on "DATAOK".

> 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.

Yes!  It is a 500W, for sure.

> >    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)

Nope, this is a standard 120V, for a standard grounded outlet.
Although I suppose perhaps they could have shared some of the guts of
this from larger units that are 220/230v?

> >    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.

I can most definitely connect this to a Windows PC.  Just let me know
what I can provide you.  For that matter, I could grant you a remote
shell to this Raspberry Pi and let you take a look.  Let me know if
that would be beneficial and I will send the connection info and
credentials directly to your gmail address.

Thanks,
Steve Ballantyne
Network Engineer
MCSE/MCDST; Novell CLA; LPIC-1; CTT+; A+; Network+; Linux+; Server+;
I-Net+; Security+; SonicWALL CSSA