Discussion:
[Nut-upsuser] The dreaded Tripp Lite SMART500RT1U and NUT
Steve Ballantyne
2014-06-26 18:31:05 UTC
Permalink
<nut-upsuser at lists.alioth.debian.org>
I am doing my best to avoid have to spend $280 for a network monitoring
card to put into a $190 UPS just to have some good remote monitoring
capabilities. Rather, I would like to monitor my many 1U Tripp Lite's on
my network using a Raspberry Pi running Raspian and using NUT.

However, I cannot seem to get it working. And I while the hardware
compatibility list says that it is supported - I certainly have my doubts.

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.

pi at raspberrypi ~ $ sudo /lib/nut/usbhid-ups -DDD -u root -a SMART500RT1U
Network UPS Tools - Generic HID driver 0.37 (2.6.4)
USB communication driver 0.32
0.000000 debug level is '3'
0.007268 upsdrv_initups...
0.011293 Checking device (09AE/0001) (001/009)
0.015827 - VendorID: 09ae
0.017073 - ProductID: 0001
0.018406 - Manufacturer: TRIPP LITE
0.019801 - Product: TRIPP LITE SMART500RT1U
0.021422 - Serial Number: unknown
0.022460 - Bus: 001
0.022639 Trying to match device
0.023645 This Tripp Lite device (09ae/0001) is not supported by
usbhid-ups.
Please use the tripplite_usb driver instead.
8< SNIP!

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 '........'
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"
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)
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)
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"
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
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"
9.991607 send_to_all: SETINFO battery.voltage.nominal "0"
9.992388 send_to_all: SETINFO ups.debug.load_banks "0"
9.993437 send_to_all: SETINFO ups.delay.shutdown "64"
9.993654 send_to_all: SETFLAGS ups.delay.shutdown RW STRING
9.994438 send_to_all: SETAUX ups.delay.shutdown 3
9.994961 send_to_all: ADDCMD shutdown.return
Unknown protocol (3005)Attached to Tripp Lite SMART500RT1U
9.995802 send_cmd(msg_len=2, type='S')
9.996015 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
10.097779 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
10.098216 send_to_all: SETINFO ups.debug.S "01 04 00 00 64 00 0d
'....d..'"
10.099156 Unknown value for s[1]: 0x01
10.099388 send_to_all: SETINFO ups.status ""
10.099568 send_cmd(msg_len=2, type='L')
10.100346 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
10.202393 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
10.202731 send_to_all: SETINFO ups.debug.L "00 00 00 07 58 58 0d
'....XX.'"
10.202923 send_cmd(msg_len=2, type='D')
10.203115 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
10.304883 send_cmd: received 44 00 79 00 86 0d 00 00 'D.y.....' (OK)
10.305216 send_to_all: SETINFO ups.debug.D "00 79 00 86 0d 00 00
'.y.....'"
10.305412 send_cmd(msg_len=2, type='V')
10.306322 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
10.408136 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
10.408437 send_cmd(msg_len=2, type='M')
10.408636 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
10.510511 send_cmd: received 4d 00 75 00 7c 0d 00 00 'M.u.....' (OK)
10.510851 send_to_all: SETINFO ups.debug.M "00 75 00 7c 0d 00 00
'.u.....'"
10.511656 send_cmd(msg_len=2, type='T')
10.512689 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
10.614504 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
10.614835 send_to_all: SETINFO ups.debug.T "21 00 02 58 01 58 0d
'...X.X.'"
10.615028 send_cmd(msg_len=2, type='P')
10.615820 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
10.717503 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
10.717838 send_to_all: SETINFO ups.debug.P "30 30 35 30 30 58 0d
'00500X.'"
10.718023 send_to_all: DATAOK
10.718606 dstate_init: sock /var/run/nut/tripplite_usb-SMART500RT1U
open on fd 5
10.719616 send_to_all: SETINFO driver.parameter.pollinterval "2"
10.720403 send_to_all: SETINFO device.mfr "Tripp Lite"
10.721489 send_to_all: SETINFO device.model "SMART500RT1U"
10.721708 send_cmd(msg_len=2, type='S')
10.722544 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
10.824514 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
10.824815 Unknown value for s[1]: 0x01
10.824999 send_to_all: DATASTALE
10.825812 send_cmd(msg_len=2, type='L')
10.826909 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
10.928616 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
10.928996 send_cmd(msg_len=2, type='D')
10.929205 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
11.031612 send_cmd: received 44 00 79 00 86 0d 00 00 'D.y.....' (OK)
11.031919 send_cmd(msg_len=2, type='V')
11.032120 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
11.133853 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
11.134151 send_cmd(msg_len=2, type='M')
11.134349 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
11.236481 send_cmd: received 4d 00 75 00 7c 0d 00 00 'M.u.....' (OK)
11.236790 send_cmd(msg_len=2, type='T')
11.236988 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
11.338728 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
11.339094 send_cmd(msg_len=2, type='P')
11.339295 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
11.441597 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
11.441902 send_to_all: DATAOK
12.723124 send_cmd(msg_len=2, type='S')
12.723419 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
13.490411 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
13.491763 Unknown value for s[1]: 0x01
13.493169 send_to_all: DATASTALE
13.494659 send_cmd(msg_len=2, type='L')
13.495869 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
13.598529 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
13.599934 send_cmd(msg_len=2, type='D')
13.600988 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
13.702775 send_cmd: received 44 00 79 00 86 0d 00 00 'D.y.....' (OK)
13.703086 send_cmd(msg_len=2, type='V')
13.703284 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
13.805384 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
13.806270 send_cmd(msg_len=2, type='M')
13.806489 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
13.908517 send_cmd: received 4d 00 75 00 7c 0d 00 00 'M.u.....' (OK)
13.908944 send_cmd(msg_len=2, type='T')
13.910002 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
14.012381 send_cmd: received 54 21 00 02 57 01 58 0d 'T...W.X.' (OK)
14.012708 send_to_all: SETINFO ups.debug.T "21 00 02 57 01 58 0d
'...W.X.'"
14.012902 send_cmd(msg_len=2, type='P')
14.013099 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
14.115379 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
14.115681 send_to_all: DATAOK

8< SNIP!

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.

I should also mention that I have tried both a serial and a USB connection
for this. But using a device with no actual serial port, the serial is
actually a Prolific pl2303 converter.

Steve Ballantyne
Network Engineer
MCSE/MCDST; Novell CLA; LPIC-1; CTT+; A+; Network+; Linux+; Server+;
I-Net+; Security+; SonicWALL CSSA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140626/1dd6882f/attachment-0001.html>
Charles Lepple
2014-06-26 20:12:16 UTC
Permalink
On Thu, Jun 26, 2014 at 2:31 PM, Steve Ballantyne
Post by Steve Ballantyne
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.
Post by Steve Ballantyne
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?
Post by Steve Ballantyne
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.
Post by Steve Ballantyne
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.
Post by Steve Ballantyne
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.
Post by Steve Ballantyne
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.
Post by Steve Ballantyne
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)
Post by Steve Ballantyne
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.
Post by Steve Ballantyne
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
Steve Ballantyne
2014-06-27 02:20:47 UTC
Permalink
Hello Charles,
Post by Charles Lepple
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.
Post by Charles Lepple
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!
Post by Charles Lepple
Post by Steve Ballantyne
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!
Post by Charles Lepple
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.
Post by Charles Lepple
Post by Steve Ballantyne
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.
Post by Steve Ballantyne
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.
Post by Steve Ballantyne
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".
Post by Charles Lepple
Ah, what we should be seeing here is that "01 04" status in ASCII. I
think the 3004 protocol also encodes it in binary.
Post by Steve Ballantyne
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.
Post by Charles Lepple
Post by Steve Ballantyne
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?
Post by Charles Lepple
Post by Steve Ballantyne
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.
Post by Steve Ballantyne
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
Charles Lepple
2014-06-28 04:13:44 UTC
Permalink
On Thu, Jun 26, 2014 at 10:20 PM, Steve Ballantyne
Post by Steve Ballantyne
Post by Charles Lepple
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? :-)
Definitely.
Post by Steve Ballantyne
Post by Charles Lepple
Post by Steve Ballantyne
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?
Well, that number scales some of the voltages. Not much we can do
until we find out more about the other values.
Post by Steve Ballantyne
I can most definitely connect this to a Windows PC. Just let me know
what I can provide you.
The ideal situation is a trace of all the USB commands that the
Windows software sends. However, I think this is just a binary version
of the 3003 protocol, so experimenting might be easier.

Most important are the "OB" and "LB" status bits. Unfortunately, there
is no good way to generate the LB signal besides running the battery
down. You might need more than a Raspberry Pi to do this in short
order. I like to use incandescent lights instead of computers for test
loads, because if the UPS pulls power at an inopportune time, you
won't have nearly as much filesystem damage on a light bulb.

I think the 'M' command shows the min and max voltages - see if there
is something similar in the Windows display.

Also, any load values would be helpful.

For a 500W UPS, I assume it's one 12V (or 2x 6V) battery pack?

Attached is a patch to try to map some of the 3005 differences into
the driver. It should apply to the NUT 2.7.2 tarball, but it was
generated from the Git master branch. If you do check out from Github,
you'll need to install autoconf, automake and libtool. AsciiDoc is
pretty slow, so you can pass "--without-doc" to the ./configure
script. You may also want to add "--with-drivers=tripplite_usb" so
that it doesn't try to compile everything.
--
- Charles Lepple
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tripplite_3005.patch
Type: text/x-patch
Size: 3847 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140628/a7e23666/attachment.bin>
Steve Ballantyne
2014-06-29 02:05:00 UTC
Permalink
Hello Charles,

I think we are making progress! I grabbed nut using git, and applied
your patch without any problems. Getting to the point that I could
run a configure on my RPi - was something else. I found this blog
post, which was very helpful (for anyone else that may try it):
http://atelier-orchard.blogspot.com/2013/11/raspberry-pixf86-video-fbdev.html
It's not in English, but you get can get the general idea of how to
move along.

Also, tripplite_usb failed to build for me with a bunch of undefined
errors. I was able to fix it by editing the Makefile and adding -lusb
to the LD_FLAGS.

So - here I am starting up nut in debugging level 5, and it looks
"promising"? :-)

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2014.06.28 21:54:46 =~=~=~=~=~=~=~=~=~=~=~=

]0;pi at raspberrypi: ~/nutpi at raspberrypi ~/nut
$ sudo ./drivers/tripplite_usb -u root -a SMART500RT1U -DDDDD
Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.24
(2.7.2-signed-19-g90e2790)
Warning: This is an experimental driver.
Some features may not function correctly.

0.000000 debug level is '5'
0.009251 Checking device (067B/2303) (001/010)
0.012869 - VendorID: 067b
0.014340 - ProductID: 2303
0.015978 - Manufacturer: Prolific Technology Inc.
0.017231 - Product: USB-Serial Controller D
0.018168 - Serial Number: unknown
0.018857 - Bus: 001
0.019029 Trying to match device
0.019201 Device does not match - skipping
0.020250 Checking device (09AE/0001) (001/009)
0.023743 - VendorID: 09ae
0.023986 - ProductID: 0001
0.024141 - Manufacturer: TRIPP LITE
0.024868 - Product: TRIPP LITE SMART500RT1U
0.025049 - Serial Number: unknown
0.025207 - Bus: 001
0.025357 Trying to match device
0.026318 Device matches
0.027669 Detected a UPS: TRIPP LITE/TRIPP LITE SMART500RT1U
0.028001 send_to_all: SETINFO ups.vendorid "09ae"
0.028254 send_to_all: SETINFO ups.productid "0001"
0.028468 send_to_all: SETINFO device.type "ups"
0.029259 send_to_all: SETINFO driver.version "2.7.2-signed-19-g90e2790"
0.030842 send_to_all: SETINFO driver.version.internal "0.24"
0.031065 send_to_all: SETINFO driver.name "tripplite_usb"
0.031266 send_cmd(msg_len=2, type='
0.031536 send_cmd: sending 3a 00 ff 0d 00 00 00 00 '........'
1.134977 libusb_get_interrupt: Connection timed out
1.136412 libusb_get_interrupt() returned 0 instead of 8 while
sending 3a 00 ff 0d 00 00 00 00 '........'
2.138238 libusb_get_interrupt: Connection timed out
2.139578 libusb_get_interrupt() returned 0 instead of 8 while
sending 3a 00 ff 0d 00 00 00 00 '........'
3.141962 libusb_get_interrupt: Connection timed out
3.143315 libusb_get_interrupt() returned 0 instead of 8 while
sending 3a 00 ff 0d 00 00 00 00 '........'
4.145557 libusb_get_interrupt: Connection timed out
4.146884 libusb_get_interrupt() returned 0 instead of 8 while
sending 3a 00 ff 0d 00 00 00 00 '........'
5.148790 libusb_get_interrupt: Connection timed out
5.150121 libusb_get_interrupt() returned 0 instead of 8 while
sending 3a 00 ff 0d 00 00 00 00 '........'
6.152078 libusb_get_interrupt: Connection timed out
6.153425 libusb_get_interrupt() returned 0 instead of 8 while
sending 3a 00 ff 0d 00 00 00 00 '........'
7.155406 libusb_get_interrupt: Connection timed out
7.156855 libusb_get_interrupt() returned 0 instead of 8 while
sending 3a 00 ff 0d 00 00 00 00 '........'
8.158953 libusb_get_interrupt: Connection timed out
8.160283 libusb_get_interrupt() returned 0 instead of 8 while
sending 3a 00 ff 0d 00 00 00 00 '........'
9.162442 libusb_get_interrupt: Connection timed out
9.163820 libusb_get_interrupt() returned 0 instead of 8 while
sending 3a 00 ff 0d 00 00 00 00 '........'
9.266486 send_cmd: received 00 30 05 58 58 58 58 0d '.0.XXXX.' (OK)
9.267788 Using binary SMART protocol (3005)
9.269255 send_to_all: SETINFO ups.firmware.aux "protocol 3005"
9.270696 send_cmd(msg_len=3, type='W')
9.271796 send_cmd: sending 3a 57 00 a8 0d 00 00 00 '.W......'
9.373487 send_cmd: received 57 00 0d 00 00 00 00 00 'W.......' (OK)
9.373744 send_cmd(msg_len=2, type='S')
9.374505 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
9.476233 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
9.476533 send_to_all: SETINFO ups.mfr "Tripp Lite"
9.476718 send_cmd(msg_len=2, type='P')
9.477542 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
9.579226 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
9.579630 send_to_all: SETINFO ups.model "SMART500RT1U"
9.580498 send_to_all: SETINFO ups.power.nominal "500"
9.580690 send_cmd(msg_len=2, type='F')
9.580881 send_cmd: sending 3a 46 b9 0d 00 00 00 00 '.F......'
9.682969 send_cmd: received 46 33 33 34 34 30 31 0d 'F334401.' (OK)
9.683895 send_to_all: SETINFO ups.firmware "F334401"
9.684100 send_cmd(msg_len=2, type='V')
9.684297 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
9.786346 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
9.786612 Unknown number of switchable load banks: 0x01
9.786779 Switchable load banks: 1
9.786948 send_cmd(msg_len=2, type='V')
9.787138 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
9.889087 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
9.889423 send_to_all: SETINFO ups.debug.V "02 00 0c 01 58 58 0d '....XX.'"
9.889634 send_to_all: SETINFO outlet.1.id "1"
9.890441 send_to_all: SETINFO outlet.1.desc "Load 1"
9.890702 send_to_all: SETINFO outlet.1.switchable "1"
9.890907 send_to_all: SETINFO outlet.1.switch "1"
9.891096 send_to_all: SETFLAGS outlet.1.switch RW STRING
9.892121 send_to_all: SETAUX outlet.1.switch 3
9.892951 send_to_all: SETINFO outlet.2.id "2"
9.893179 send_to_all: SETINFO outlet.2.desc "Load 2"
9.894177 send_to_all: SETINFO outlet.2.switchable "0"
9.894970 send_to_all: ADDCMD load.on
9.895171 send_to_all: ADDCMD load.off
9.895337 send_cmd(msg_len=2, type='U')
9.895731 send_cmd: sending 3a 55 aa 0d 00 00 00 00 '.U......'
9.997588 send_cmd: received 55 00 00 0d 00 00 00 00 'U.......' (OK)
9.998444 send_to_all: SETINFO ups.id "0"
9.999497 send_to_all: SETFLAGS ups.id RW STRING
9.999749 send_to_all: SETAUX ups.id 5
9.999919 Unit ID: 0
10.000672 send_to_all: SETINFO input.voltage.nominal "120"
10.000895 send_to_all: SETINFO battery.voltage.nominal "12"
10.001097 send_to_all: SETINFO ups.debug.load_banks "1"
10.002045 send_to_all: SETINFO ups.delay.shutdown "64"
10.002259 send_to_all: SETFLAGS ups.delay.shutdown RW STRING
10.002448 send_to_all: SETAUX ups.delay.shutdown 3
10.002633 send_to_all: ADDCMD shutdown.return
Attached to Tripp Lite SMART500RT1U
10.003768 send_cmd(msg_len=2, type='S')
10.004587 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
10.106335 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
10.106677 send_to_all: SETINFO ups.debug.S "01 04 00 00 64 00 0d '....d..'"
10.107513 send_to_all: SETINFO ups.status "OL"
10.107814 send_cmd(msg_len=2, type='L')
10.108823 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
10.211079 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
10.211427 send_to_all: SETINFO ups.debug.L "00 00 00 07 58 58 0d '....XX.'"
10.211709 send_cmd(msg_len=2, type='D')
10.212540 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
10.314200 send_cmd: received 44 00 7b 00 8b 0d 00 00 'D.......' (OK)
10.314545 send_to_all: SETINFO ups.debug.D "00 7b 00 8b 0d 00 00 '.......'"
10.314742 send_cmd(msg_len=2, type='V')
10.315785 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
10.417567 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
10.417872 send_cmd(msg_len=2, type='M')
10.418080 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
10.520316 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
10.520657 send_to_all: SETINFO ups.debug.M "00 75 00 7f 0d 00 00 '.u.....'"
10.520853 send_cmd(msg_len=2, type='T')
10.521641 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
10.623318 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
10.623659 send_to_all: SETINFO ups.debug.T "21 00 02 58 01 58 0d '...X.X.'"
10.623852 send_cmd(msg_len=2, type='P')
10.624634 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
10.726438 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
10.726781 send_to_all: SETINFO ups.debug.P "30 30 35 30 30 58 0d '00500X.'"
10.726971 send_to_all: DATAOK
10.727871 dstate_init: sock
/var/state/ups/tripplite_usb-SMART500RT1U open on fd 5
10.729279 send_to_all: SETINFO driver.parameter.pollinterval "2"
10.730340 send_to_all: SETINFO device.mfr "Tripp Lite"
10.730565 send_to_all: SETINFO device.model "SMART500RT1U"
10.730760 send_cmd(msg_len=2, type='S')
10.731809 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
10.834055 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
10.834373 send_cmd(msg_len=2, type='L')
10.834584 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
10.937047 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
10.937362 send_cmd(msg_len=2, type='D')
10.937572 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
11.039299 send_cmd: received 44 00 7b 00 8b 0d 00 00 'D.......' (OK)
11.039609 send_cmd(msg_len=2, type='V')
11.039819 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
11.141543 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
11.141856 send_cmd(msg_len=2, type='M')
11.142633 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
11.244423 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
11.244740 send_cmd(msg_len=2, type='T')
11.244945 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
11.346902 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
11.347209 send_cmd(msg_len=2, type='P')
11.347416 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
11.450029 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
12.732166 send_cmd(msg_len=2, type='S')
12.732472 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
13.498966 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
13.500378 send_cmd(msg_len=2, type='L')
13.501956 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
13.604452 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
13.605955 send_cmd(msg_len=2, type='D')
13.607466 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
13.709952 send_cmd: received 44 00 7c 00 8b 0d 00 00 'D.......' (OK)
13.710289 send_to_all: SETINFO ups.debug.D "00 7c 00 8b 0d 00 00 '.......'"
13.710488 send_cmd(msg_len=2, type='V')
13.711316 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
13.812948 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
13.813265 send_cmd(msg_len=2, type='M')
13.813469 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
13.915820 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
13.916146 send_cmd(msg_len=2, type='T')
13.916351 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
14.018069 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
14.018384 send_cmd(msg_len=2, type='P')
14.018590 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
14.121062 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
14.733109 send_cmd(msg_len=2, type='S')
14.735078 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
14.837041 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
14.837368 send_cmd(msg_len=2, type='L')
14.837575 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
14.939282 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
14.939678 send_cmd(msg_len=2, type='D')
14.940503 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
15.042159 send_cmd: received 44 00 7b 00 8b 0d 00 00 'D.......' (OK)
15.042502 send_to_all: SETINFO ups.debug.D "00 7b 00 8b 0d 00 00 '.......'"
15.043276 send_cmd(msg_len=2, type='V')
15.043631 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
15.145271 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
15.145657 send_cmd(msg_len=2, type='M')
15.146481 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
15.248151 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
15.248466 send_cmd(msg_len=2, type='T')
15.248680 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
15.350894 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
15.351210 send_cmd(msg_len=2, type='P')
15.351418 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
15.453137 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
16.734021 send_cmd(msg_len=2, type='S')
16.734325 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
17.501817 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
17.503193 send_cmd(msg_len=2, type='L')
17.505396 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
17.607935 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
17.609518 send_cmd(msg_len=2, type='D')
17.610533 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
17.712807 send_cmd: received 44 00 7c 00 8b 0d 00 00 'D.......' (OK)
17.713145 send_to_all: SETINFO ups.debug.D "00 7c 00 8b 0d 00 00 '.......'"
17.713950 send_cmd(msg_len=2, type='V')
17.714182 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
17.815823 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
17.816145 send_cmd(msg_len=2, type='M')
17.816957 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
17.918798 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
17.919115 send_cmd(msg_len=2, type='T')
17.919319 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
18.021673 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
18.021992 send_cmd(msg_len=2, type='P')
18.022200 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
18.123915 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
18.734697 send_cmd(msg_len=2, type='S')
18.734994 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
18.836767 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
18.837096 send_cmd(msg_len=2, type='L')
18.837302 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
18.939418 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
18.940313 send_cmd(msg_len=2, type='D')
18.940544 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
19.042634 send_cmd: received 44 00 7c 00 8b 0d 00 00 'D.......' (OK)
19.043585 send_cmd(msg_len=2, type='V')
19.043805 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
19.145770 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
19.146653 send_cmd(msg_len=2, type='M')
19.146883 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
19.248878 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
19.249767 send_cmd(msg_len=2, type='T')
19.249991 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
19.351995 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
19.352888 send_cmd(msg_len=2, type='P')
19.353119 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
19.455629 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
20.736059 send_cmd(msg_len=2, type='S')
20.736356 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
21.504675 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
21.506853 send_cmd(msg_len=2, type='L')
21.508402 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
21.611195 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
21.612791 send_cmd(msg_len=2, type='D')
21.613067 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
21.714789 send_cmd: received 44 00 7b 00 8b 0d 00 00 'D.......' (OK)
21.715168 send_to_all: SETINFO ups.debug.D "00 7b 00 8b 0d 00 00 '.......'"
21.716130 send_cmd(msg_len=2, type='V')
21.716358 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
21.818034 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
21.818349 send_cmd(msg_len=2, type='M')
21.818557 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
21.920908 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
21.921229 send_cmd(msg_len=2, type='T')
21.921431 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
22.023152 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
22.023465 send_cmd(msg_len=2, type='P')
22.024245 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
22.126141 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
22.736742 send_cmd(msg_len=2, type='S')
22.737034 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
22.838748 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
22.839115 send_cmd(msg_len=2, type='L')
22.839382 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
22.941110 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
22.941432 send_cmd(msg_len=2, type='D')
22.941643 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
23.043611 send_cmd: received 44 00 7c 00 8b 0d 00 00 'D.......' (OK)
23.044771 send_to_all: SETINFO ups.debug.D "00 7c 00 8b 0d 00 00 '.......'"
23.045669 send_cmd(msg_len=2, type='V')
23.045908 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
23.148484 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
23.148795 send_cmd(msg_len=2, type='M')
23.149004 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
23.250732 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
23.251046 send_cmd(msg_len=2, type='T')
23.251353 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
23.353102 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
23.353413 send_cmd(msg_len=2, type='P')
23.354181 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
23.456221 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)

24.738110 send_cmd(msg_len=2, type='S')
24.738414 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'

M 25.504530 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
25.506212 send_cmd(msg_len=2, type='L')
25.507751 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
25.610516 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
25.612137 send_cmd(msg_len=2, type='D')
25.612415 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
25.714768 send_cmd: received 44 00 7b 00 8b 0d 00 00 'D.......' (OK)
25.715196 send_to_all: SETINFO ups.debug.D "00 7b 00 8b 0d 00 00 '.......'"
25.715411 send_cmd(msg_len=2, type='V')
25.716276 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
25.818389 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
25.818702 send_cmd(msg_len=2, type='M')
25.818911 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
25.921012 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
25.921908 send_cmd(msg_len=2, type='T')
25.922133 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'

26.024131 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
26.024440 send_cmd(msg_len=2, type='P')
26.024644 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
26.126499 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
26.738798 send_cmd(msg_len=2, type='S')
26.739205 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
26.840964 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
26.841278 send_cmd(msg_len=2, type='L')
26.841482 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
26.943342 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
26.943664 send_cmd(msg_len=2, type='D')
26.943878 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
27.045860 send_cmd: received 44 00 7b 00 8b 0d 00 00 'D.......' (OK)
27.046746 send_cmd(msg_len=2, type='V')
27.047811 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
27.149468 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
27.149778 send_cmd(msg_len=2, type='M')
27.150550 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
27.252339 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
27.252654 send_cmd(msg_len=2, type='T')
27.252863 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
27.355117 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
27.355441 send_cmd(msg_len=2, type='P')
27.355804 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
27.457570 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
28.740148 send_cmd(msg_len=2, type='S')
28.740435 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
29.506383 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
29.507771 send_cmd(msg_len=2, type='L')
29.509988 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
29.612497 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
29.613828 send_cmd(msg_len=2, type='D')
29.615070 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
29.717374 send_cmd: received 44 00 7c 00 8b 0d 00 00 'D.......' (OK)
29.717720 send_to_all: SETINFO ups.debug.D "00 7c 00 8b 0d 00 00 '.......'"
29.717915 send_cmd(msg_len=2, type='V')
29.718114 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
29.820365 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
29.820680 send_cmd(msg_len=2, type='M')
29.820889 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
29.922615 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
29.923014 send_cmd(msg_len=2, type='T')
29.923229 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
30.025616 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
30.025918 send_cmd(msg_len=2, type='P')
30.026125 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
30.128359 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
30.740839 send_cmd(msg_len=2, type='S')
30.741135 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
30.842861 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
30.843227 send_cmd(msg_len=2, type='L')
30.843435 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
30.945447 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
30.946484 send_cmd(msg_len=2, type='D')
30.946717 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
31.048828 send_cmd: received 44 00 7b 00 8b 0d 00 00 'D.......' (OK)
31.049747 send_to_all: SETINFO ups.debug.D "00 7b 00 8b 0d 00 00 '.......'"
31.050467 send_cmd(msg_len=2, type='V')
31.050737 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
31.152695 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
31.153004 send_cmd(msg_len=2, type='M')
31.153213 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
31.255700 send_cmd: received 4d 00 75 00 7f 0d 00 00 'M.u.....' (OK)
31.256017 send_cmd(msg_len=2, type='T')
31.256214 send_cmd: sending 3a 54 ab 0d 00 00 00 00 '.T......'
31.357942 send_cmd: received 54 21 00 02 58 01 58 0d 'T...X.X.' (OK)
31.358258 send_cmd(msg_len=2, type='P')
31.358466 send_cmd: sending 3a 50 af 0d 00 00 00 00 '.P......'
31.460306 send_cmd: received 50 30 30 35 30 30 58 0d 'P00500X.' (OK)
32.742203 send_cmd(msg_len=2, type='S')
32.742512 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......'
33.509240 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK)
33.510607 send_cmd(msg_len=2, type='L')
33.512818 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......'
33.615361 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK)
33.617516 send_cmd(msg_len=2, type='D')
33.617785 send_cmd: sending 3a 44 bb 0d 00 00 00 00 '.D......'
33.719724 send_cmd: received 44 00 7c 00 8b 0d 00 00 'D.......' (OK)
33.720061 send_to_all: SETINFO ups.debug.D "00 7c 00 8b 0d 00 00 '.......'"
33.720256 send_cmd(msg_len=2, type='V')
33.721037 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
33.823099 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
33.823415 send_cmd(msg_len=2, type='M')
33.823621 send_cmd: sending 3a 4d b2 0d 00 00 00 00 '.M......'
^C]0;pi at raspberrypi: ~/nutpi at raspberrypi ~/nut $

Steve Ballantyne
Network Engineer
MCSE/MCDST; Novell CLA; LPIC-1; CTT+; A+; Network+; Linux+; Server+;
I-Net+; Security+; SonicWALL CSSA
Post by Charles Lepple
Attached is a patch to try to map some of the 3005 differences into
the driver. It should apply to the NUT 2.7.2 tarball, but it was
generated from the Git master branch. If you do check out from Github,
you'll need to install autoconf, automake and libtool. AsciiDoc is
pretty slow, so you can pass "--without-doc" to the ./configure
script. You may also want to add "--with-drivers=tripplite_usb" so
that it doesn't try to compile everything.
Charles Lepple
2014-06-29 13:08:17 UTC
Permalink
On Sat, Jun 28, 2014 at 10:05 PM, Steve Ballantyne
Post by Steve Ballantyne
Hello Charles,
I think we are making progress! I grabbed nut using git, and applied
your patch without any problems. Getting to the point that I could
run a configure on my RPi - was something else. I found this blog
http://atelier-orchard.blogspot.com/2013/11/raspberry-pixf86-video-fbdev.html
It's not in English, but you get can get the general idea of how to
move along.
At some point I should grab another SD card and do a clean install,
then write up that procedure for the NUT documentation.
Post by Steve Ballantyne
Also, tripplite_usb failed to build for me with a bunch of undefined
errors. I was able to fix it by editing the Makefile and adding -lusb
to the LD_FLAGS.
Odd, it should have picked that up. Do you have libusb*dev installed?
(Also probably the compat package, since NUT expects the libusb 0.1
API).
Post by Steve Ballantyne
So - here I am starting up nut in debugging level 5, and it looks
"promising"? :-)
At this point, I would start upsd and verify that the numbers look
good in upsc. You may want to keep the log running to check how the
unit responds to the loss of AC power (again, with the lamp, and
probably using a power strip to cut power - some APC units get weird
when they aren't grounded). Also we would want to verify the low
battery signal (I'm just guessing that it's the binary version of the
3003 protocol).

After that, there are the shutdown commands. This one is a little
tricky, since there are several timers involved.
Post by Steve Ballantyne
9.684297 send_cmd: sending 3a 56 a9 0d 00 00 00 00 '.V......'
9.786346 send_cmd: received 56 02 00 0c 01 58 58 0d 'V....XX.' (OK)
9.786612 Unknown number of switchable load banks: 0x01
Hmm, I thought I covered that case. No matter, it's just a warning.
Post by Steve Ballantyne
9.786779 Switchable load banks: 1
Does this match the vendor software?

It doesn't look like NUT is committing the rest of the values, so I
might need to look at that part again (or maybe that's a different
debug level). If upsc is missing a lot of numbers that you see in the
debug log, let me know.
Steve Ballantyne
2014-07-01 13:17:28 UTC
Permalink
Hello Charles,

Thank you for all of your help this far. I have made some great
progress. I was hung up with all sorts of USB problems which we can
chalk up to a "blonde moment" for me (or more accurately, a *bald*
moment). In all my starting over and screwing around, I had forgotten
to reinstall libusb-compat. Duh! I am now to a point that I think we
can dig a little deeper.

The patch that you provided me works fine, and allows a connection
with some basic values (see bottom of thread).
Post by Charles Lepple
The ideal situation is a trace of all the USB commands that the
Windows software sends. However, I think this is just a binary version
of the 3003 protocol, so experimenting might be easier.
SNIP, SNIP
Post by Charles Lepple
I think the 'M' command shows the min and max voltages - see if there
is something similar in the Windows display.
How would I go about providing you this stuff? Can you point me to
something that would help trace out the USB data? I can install the
software, and run it, but I would need some guidance on grabbing the
USB debug info. This UPS has produces some really helpful data if we
can manage to yank it out of there. Examples, charge remaining (in
percentage), temperature, age of the battery, date of last self test,
etc.
Post by Charles Lepple
Attached is a patch to try to map some of the 3005 differences into
the driver. It should apply to the NUT 2.7.2 tarball, but it was
generated from the Git master branch. If you do check out from Github,
you'll need to install autoconf, automake and libtool. AsciiDoc is
pretty slow, so you can pass "--without-doc" to the ./configure
script. You may also want to add "--with-drivers=tripplite_usb" so
that it doesn't try to compile everything.
Your patch, along with a lot of other Raspbian/Debian changes got me
up and running. For any other fool that would dare attempt this ... I
am providing what it took to get this up and running. Note that there
are some direct links in here to mirrors that could go belly up. And
I may not be choosing the most ideal of permissions. While you might
be able to copy and paste this into a shell script and run it ... I
would suggest stepping using these steps only as guidance.

### BEGIN SCRIPT ###

#some depencies from repo
sudo apt-get -y install m4 libtool libudev-dev automake

#fixing autoconf for later
sudo ln -s /usr/share/autoconf/Autom4te /usr/local/share/autoreconf/Autom4te
sudo ln -s /usr/bin/autom4te /usr/local/bin/autom4te
sudo ln -s /usr/bin/autoconf /usr/local/bin/autoconf
sudo ln -s /usr/bin/autoheader /usr/local/bin/autoheader

#installing nut dependencies
mkdir nut-depends
cd ./nut-depends

# acscripts from source
wget http://sourceforge.net/projects/acscripts.berlios/files/acscripts-0.0.1.13.tar.bz2
tar xf acscripts-0.0.1.13.tar.bz2
sudo mkdir /usr/lib/scripts
sudo mv acscripts-0.0.1.13 /usr/lib/scripts/acscripts

#autoreconf from source
wget http://sourceforge.net/projects/autoreconf/files/0.0.0.1/autoreconf-0.0.0.1.tar.bz2
tar xf autoreconf-0.0.0.1.tar.bz2
cd autoreconf-0.0.0.1
./configure && sudo make install
cd ..

#libusb and libusb-compat from source
wget "http://downloads.sourceforge.net/project/libusb/libusb-1.0/libusb-1.0.18/libusb-1.0.18.tar.bz2?r=http%3A%2F%2Fwww.libusb.org%2F&ts=1404210716&use_mirror=softlayer-ams"
-O libusb-1.0.18.tar.bz2
tar -xjf libusb-1.0.18.tar.bz2
cd libusb-1.0.18
./configure && sudo make install
cd ..
wget "http://downloads.sourceforge.net/project/libusb/libusb-compat-0.1/libusb-compat-0.1.4/libusb-compat-0.1.4.tar.bz2?r=http%3A%2F%2Fwww.libusb.org%2F&ts=1404210428&use_mirror=softlayer-ams"
-O libusb-compat-0.1.4.tar.bz2
tar -xjf libusb-compat-0.1.4.tar.bz2
cd libusb-compat-0.1.4
./configure && sudo make install
cd ..

#get back to home root
cd ..

#download nut from dev repo
git clone git://github.com/networkupstools/nut.git
cd nut

#patch for TrippLite SMART500RT1U
wget http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140628/a7e23666/attachment.bin
-O charles-tripplite.patch
patch -p1 < charles-tripplite.patch

echo "Running autogen ..."
./autogen.sh

#create some groups and directories and mod some persmissions
sudo groupadd nut
sudo usermod -a -G nut pi
sudo usermod -a -G nut root
sudo mkdir /var/run/nut
sudo chown root:nut /var/run/nut
sudo mkdir -p /var/state/ups
sudo chown root:nut /var/state/ups
sudo chmod 0770 /var/state/ups

#now we ./configure and make it
./configure --without-doc --with-drivers=tripplite_usb,upsdrvctl

#still tries to build docs, even though I said NO to docs
cp Makefile Makefile.orig
sed -i 's/include common clients conf data tools docs drivers/include
common clients conf data tools drivers/' Makefile

make
sudo make install

### END SCRIPT ###

### BEGIN CONFIG FILE CHANGES / STARTUP ###

sudo vi /usr/local/ups/etc/ups.conf

[SMART500RT1U]
driver = tripplite_usb
port = auto
desc = "Tripp Lite SmartUPS 500RT 1U"

sudo vi /etc/udev/rules.d/90-nut-ups.rules

# TrippLite UPS [09ae:0001]
ACTION=="add", \
SUBSYSTEM=="usb", \
ATTR{idVendor}=="09ae", ATTR{idProduct}=="0001", \
MODE="0666", GROUP="nut"

sudo vi /usr/local/ups/etc/upsd.users

[pi]
password = pi
upsmon master
MONITOR SMART500RT1U at localhost 1 pi pass master

sudo vi /usr/local/ups/etc/upsd.conf # DEFAULTS
# LISTEN ::1 3493
# LISTEN localhost 3493

sudo chown root:nut /usr/local/ups/etc/upsd.conf /usr/local/ups/etc/upsd.users
sudo chmod 0640 /usr/local/ups/etc/upsd.conf /usr/local/ups/etc/upsd.users

sudo /usr/local/ups/sbin/upsdrvctl -u pi start

sudo /usr/local/ups/sbin/upsd -u pi -4

### END CONFIG FILE CHANGES / STARTUP ###


## TESTING DUMP! ##

# Plugged into 120v outlet ...
pi at raspberrypi ~/nut $ /usr/local/ups/bin/upsc SMART500RT1U at localhost
battery.voltage.nominal: 12
device.mfr: Tripp Lite
device.model: SMART500RT1U
device.type: ups
driver.name: tripplite_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.7.2-signed-19-g90e2790
driver.version.internal: 0.24
input.voltage.nominal: 120
outlet.1.desc: Load 1
outlet.1.id: 1
outlet.1.switch: 1
outlet.1.switchable: 1
outlet.2.desc: Load 2
outlet.2.id: 2
outlet.2.switchable: 0
ups.debug.D: 00 79 00 8b 0d 00 00 '.y.....'
ups.debug.L: 00 00 00 07 58 58 0d '....XX.'
ups.debug.load_banks: 1
ups.debug.M: 00 74 00 7f 0d 00 00 '.t.....'
ups.debug.P: 30 30 35 30 30 58 0d '00500X.'
ups.debug.S: 01 04 00 00 64 00 0d '....d..'
ups.debug.T: 20 00 02 57 01 58 0d '...W.X.'
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.'
ups.delay.shutdown: 64
ups.firmware: F334401
ups.firmware.aux: protocol 3005
ups.id: 0
ups.mfr: Tripp Lite
ups.model: SMART500RT1U
ups.power.nominal: 500
ups.productid: 0001
ups.status: OL
ups.vendorid: 09ae

# UNPLUGGED!
pi at raspberrypi ~/nut $ /usr/local/ups/bin/upsc SMART500RT1U at localhost
battery.voltage.nominal: 12
device.mfr: Tripp Lite
device.model: SMART500RT1U
device.type: ups
driver.name: tripplite_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.7.2-signed-19-g90e2790
driver.version.internal: 0.24
input.voltage.nominal: 120
outlet.1.desc: Load 1
outlet.1.id: 1
outlet.1.switch: 1
outlet.1.switchable: 1
outlet.2.desc: Load 2
outlet.2.id: 2
outlet.2.switchable: 0
ups.debug.D: 00 00 00 84 0d 00 00 '.......'
ups.debug.L: 00 00 00 07 58 58 0d '....XX.'
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......'
ups.debug.P: 30 30 35 30 30 58 0d '00500X.'
ups.debug.S: 01 04 00 01 64 00 0d '....d..'
ups.debug.T: 20 00 00 00 01 58 0d '.....X.'
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.'
ups.delay.shutdown: 64
ups.firmware: F334401
ups.firmware.aux: protocol 3005
ups.id: 0
ups.mfr: Tripp Lite
ups.model: SMART500RT1U
ups.power.nominal: 500
ups.productid: 0001
ups.status: OB
ups.vendorid: 09ae

# Replugged!
pi at raspberrypi ~/nut $ /usr/local/ups/bin/upsc SMART500RT1U at localhost
battery.voltage.nominal: 12
device.mfr: Tripp Lite
device.model: SMART500RT1U
device.type: ups
driver.name: tripplite_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.7.2-signed-19-g90e2790
driver.version.internal: 0.24
input.voltage.nominal: 120
outlet.1.desc: Load 1
outlet.1.id: 1
outlet.1.switch: 1
outlet.1.switchable: 1
outlet.2.desc: Load 2
outlet.2.id: 2
outlet.2.switchable: 0
ups.debug.D: 00 79 00 81 0d 00 00 '.y.....'
ups.debug.L: 00 00 00 07 58 58 0d '....XX.'
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......'
ups.debug.P: 30 30 35 30 30 58 0d '00500X.'
ups.debug.S: 01 04 00 00 5a 00 0d '....Z..'
ups.debug.T: 20 00 02 58 01 58 0d '...X.X.'
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.'
ups.delay.shutdown: 64
ups.firmware: F334401
ups.firmware.aux: protocol 3005
ups.id: 0
ups.mfr: Tripp Lite
ups.model: SMART500RT1U
ups.power.nominal: 500
ups.productid: 0001
ups.status: OL
ups.vendorid: 09ae
pi at raspberrypi ~/nut $


Steve Ballantyne
Network Engineer
MCSE/MCDST; Novell CLA; LPIC-1; CTT+; A+; Network+; Linux+; Server+;
I-Net+; Security+; SonicWALL CSSA
Steve Ballantyne
2014-07-01 19:12:38 UTC
Permalink
On Tue, Jul 1, 2014 at 9:17 AM, Steve Ballantyne
Post by Steve Ballantyne
How would I go about providing you this stuff? Can you point me to
something that would help trace out the USB data?
I thought I would try to make sense of the ups.debug data. All I have
really figured out is that the fourth hex segment for S is a 00 for
plugged in and a 01 for on-battery. Which the driver already knows.
The rest is a mystery to me. But I played around with unplugging and
running the load down, and then recharging, etc. Here are my notes
and observations. NC = "no change". I am assuming that those fields
are the make/model/serial number, etc.

S fourth segment = 00 for on-power, 01 for on-battery

UNPLUGD a while
ups.debug.D: 00 00 00 7d 0d 00 00 '.......' <---- 4th segment = 125
ups.debug.L: 06 00 00 07 58 58 0d '....XX.' <---- 1st segment = 6
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......' NC
ups.debug.P: 30 30 35 30 30 58 0d '00500X.' NC
ups.debug.S: 01 04 00 01 4d 00 0d '....M..' <---- 5th segment = 77
ups.debug.T: 21 00 00 00 01 58 0d '.....X.' <---- 3/4/5 segments = 00 00 01
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.' NC

REPLUGd
ups.debug.D: 00 79 00 81 0d 00 00 '.y.....' <---- 4th segment = 81
ups.debug.L: 08 00 00 07 58 58 0d '....XX.' <---- 1st segment = 8
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......' NC
ups.debug.P: 30 30 35 30 30 58 0d '00500X.' NC
ups.debug.S: 01 04 00 00 5a 00 0d '....Z..' <---- 5th segment = 77
ups.debug.T: 21 00 02 57 01 58 0d '...W.X.' <---- 3/4/5 segments = 02 57 01
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.' NC

...
ups.debug.D: 00 79 00 82 0d 00 00 '.y.....' <---- 4th segment = 82
ups.debug.L: 07 00 00 07 58 58 0d '....XX.' <---- 1st segment = 7
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......' NC
ups.debug.P: 30 30 35 30 30 58 0d '00500X.' NC
ups.debug.S: 01 04 00 00 5d 00 0d '.......' <---- 5th segment = 90
ups.debug.T: 21 00 02 57 01 58 0d '...W.X.' <---- 3/4/5 segments = 02 57 01
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.' NC

...
ups.debug.D: 00 79 00 84 0d 00 00 '.y.....' <---- 4th segment = 84
ups.debug.L: 07 00 00 07 58 58 0d '....XX.' <---- 1st segment = 7
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......' NC
ups.debug.P: 30 30 35 30 30 58 0d '00500X.' NC
ups.debug.S: 01 04 00 00 64 00 0d '....d..' <---- 5th segment = 64
ups.debug.T: 21 00 02 57 01 58 0d '...W.X.' <---- 3/4/5 segments = 02 57 01
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.' NC

...
ups.debug.D: 00 79 00 85 0d 00 00 '.y.....' <---- 4th segment = 85
ups.debug.L: 07 00 00 07 58 58 0d '....XX.' <---- 1st segment = 7
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......' NC
ups.debug.P: 30 30 35 30 30 58 0d '00500X.' NC
ups.debug.S: 01 04 00 00 64 00 0d '....d..' <---- 5th segment = 64
ups.debug.T: 21 00 02 57 01 58 0d '...W.X.' <---- 3/4/5 segments = 02 57 01
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.' NC

AFTER SELF-TEST
ups.debug.D: 00 79 00 83 0d 00 00 '.y.....' <---- 4th segment = 83
ups.debug.L: 07 00 00 07 58 58 0d '....XX.' <---- 1st segment = 7
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......' NC
ups.debug.P: 30 30 35 30 30 58 0d '00500X.' NC
ups.debug.S: 01 00 00 00 60 00 0d '.......' <---- 5th segment = 60
ups.debug.T: 21 00 02 57 01 58 0d '...W.X.' <---- 3/4/5 segments = 02 57 01
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.' NC

... ...
ups.debug.D: 00 79 00 88 0d 00 00 '.y.....' <---- 4th segment = 88
ups.debug.L: 07 00 00 07 58 58 0d '....XX.' <---- 1st segment = 7
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......' NC
ups.debug.P: 30 30 35 30 30 58 0d '00500X.' NC
ups.debug.S: 01 00 00 00 64 00 0d '....d..' <---- 5th segment = 64
ups.debug.T: 21 00 02 58 01 58 0d '...X.X.' <---- 3/4/5 segments = 02 58! 01
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.' NC

...
ups.debug.D: 00 79 00 88 0d 00 00 '.y.....' <---- 4th segment = 88
ups.debug.L: 07 00 00 07 58 58 0d '....XX.' <---- 1st segment = 7
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......' NC
ups.debug.P: 30 30 35 30 30 58 0d '00500X.' NC
ups.debug.S: 01 00 00 00 64 00 0d '....d..' <---- 5th segment = 64
ups.debug.T: 21 00 02 57 01 58 0d '...W.X.' <---- 3/4/5 segments = 02 57 01
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.' NC

...
ups.debug.D: 00 79 00 88 0d 00 00 '.y.....' <---- 4th segment = 88
ups.debug.L: 07 00 00 07 58 58 0d '....XX.' <---- 1st segment = 7
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......' NC
ups.debug.P: 30 30 35 30 30 58 0d '00500X.' NC
ups.debug.S: 01 00 00 00 64 00 0d '....d..' <---- 5th segment = 64
ups.debug.T: 21 00 02 57 01 58 0d '...W.X.' <---- 3/4/5 segments = 02 57 01
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.' NC

FULLY RECHARGED
ups.debug.D: 00 79 00 89 0d 00 00 '.y.....' <---- 4th segment = 89
ups.debug.L: 07 00 00 07 58 58 0d '....XX.' <---- 1st segment = 7
ups.debug.load_banks: 1
ups.debug.M: 00 00 00 7f 0d 00 00 '.......' NC
ups.debug.P: 30 30 35 30 30 58 0d '00500X.' NC
ups.debug.S: 01 00 00 00 64 00 0d '....d..' <---- 5th segment = 64
ups.debug.T: 21 00 02 58 01 58 0d '...X.X.' <---- 3/4/5 segments = 02 58 01
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.' NC

Steve Ballantyne
Network Engineer
MCSE/MCDST; Novell CLA; LPIC-1; CTT+; A+; Network+; Linux+; Server+;
I-Net+; Security+; SonicWALL CSSA
Charles Lepple
2014-07-01 20:55:50 UTC
Permalink
On Tue, Jul 1, 2014 at 3:12 PM, Steve Ballantyne
Post by Steve Ballantyne
On Tue, Jul 1, 2014 at 9:17 AM, Steve Ballantyne
Post by Steve Ballantyne
How would I go about providing you this stuff? Can you point me to
something that would help trace out the USB data?
Tracing the data on Windows is not my speciality, but there are a few
messages in the NUT archives (can't remember whether nut-upsdev or
-upsuser, but the search form at
http://www.networkupstools.org/support.html hits both). The basic idea
is to configure the USB sniffer software to monitor your UPS, then you
would take notes on what the Windows software reports as you do a
similar test to what you posted.

A few people have done this by running Windows in a VM, and monitoring
on the Linux host side. Others have installed the sniffer software
into Windows itself. The details are going to depend on what you find
to be a more palatable challenge. The free Windows sniffer software is
mostly from the XP era, so with a newer OS, YMMV.

I don't know if the serial port will be easier or harder to deal with.
Post by Steve Ballantyne
I thought I would try to make sense of the ups.debug data. All I have
really figured out is that the fourth hex segment for S is a 00 for
plugged in and a 01 for on-battery. Which the driver already knows.
The rest is a mystery to me. But I played around with unplugging and
running the load down, and then recharging, etc. Here are my notes
and observations. NC = "no change". I am assuming that those fields
are the make/model/serial number, etc.
S fourth segment = 00 for on-power, 01 for on-battery
How far down did you let the battery go? I don't usually recommend
running it down all the way very often, but it would be good to do
that at least once to verify the LB flag. On yours, I think that would
look like "S: 00 ..."

The "01 04" seems to be the state before a self-test on yours as well
as on the ASCII version of the SMARTPRO protocol. See comments around
"switch(s_value_2) {" in the source code.
Post by Steve Ballantyne
UNPLUGD a while
ups.debug.D: 00 00 00 7d 0d 00 00 '.......' <---- 4th segment = 125
Looks like the first pairs of digits are the input voltage, and "00
7d" = 125V out.
Post by Steve Ballantyne
ups.debug.L: 06 00 00 07 58 58 0d '....XX.' <---- 1st segment = 6
Not sure, but I have a feeling that one of 06 or 07 is a percent load.

Lots of good progress here! I tried to enable a few more commands for
your model. For instance, the "M" values seem to be min/max voltage,
so there is a "reset.input.minmax" command to use with upscmd. Also,
you can trigger a battery test with "test.battery.start". I assume the
work the same way as on Protocol 3003 :-)

The attached patch is meant to be applied on top of the previous
patch. If it's easier, I can diff it against Git master.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tripplite_3005_v0.25.patch
Type: text/x-patch
Size: 5835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140701/8ef0bd26/attachment-0001.bin>
Charles Lepple
2014-07-02 00:44:24 UTC
Permalink
What the heck, here's another patch (0.26) that implements outlet
control (via upsrw) and shows the current temperature (degrees C).
Applies on top of the 0.25 patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tripplite_3005_v0.26.patch
Type: text/x-patch
Size: 2909 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140701/0bfb5def/attachment.bin>
Steve Ballantyne
2014-07-03 15:29:06 UTC
Permalink
Post by Charles Lepple
Lots of good progress here! I tried to enable a few more commands for
your model. For instance, the "M" values seem to be min/max voltage,
so there is a "reset.input.minmax" command to use with upscmd. Also,
you can trigger a battery test with "test.battery.start". I assume the
work the same way as on Protocol 3003 :-)
Hello Charles,

The patch that you provided appears to have worked. The first patch
probably worked too ... but I left the driver running throughout the
rebuilding process (woops).

Some new commands being demonstrated ...
pi at raspberrypi ~/nut $ /usr/local/ups/bin/upscmd -u pi -p pi -l
SMART500RT1U at localhost
Instant commands supported on UPS [SMART500RT1U]:

load.off - Turn off the load immediately
load.on - Turn on the load immediately
reset.input.minmax - Reset minimum and maximum input voltage status
shutdown.return - Turn off the load and return when power is back
test.battery.start - Start a battery test

Doing a test.battery.start definitely works. CLICK! BUZZ! BEEP! Done!

The others give me back an "OK" but do not seem to be doing anything.
Should load.off be shutting down supplied power? I have a lamp
plugged into the UPS that I have moved around to different ports. I
have one surge only, one switchable, and then four standard
battery/surge ports. It doesn't seem to do anything on any of those
ports that I can tell. If I run it twice, or try to go back and forth
between load.off and load.on, I start generating errors.

pi at raspberrypi ~/nut $ /usr/local/ups/bin/upscmd -u pi -p pi
SMART500RT1U at localhost load.off
Unexpected response from upsd: ERR DATA-STALE
pi at raspberrypi ~/nut $ /usr/local/ups/bin/upscmd -u pi -p pi
SMART500RT1U at localhost load.on
Unexpected response from upsd: ERR DATA-STALE

And then I can't pull down a status ... (at least for a couple of
minutes, and then it will start working again).

pi at raspberrypi ~/nut $ /usr/local/ups/bin/upsc SMART500RT1U at localhost
Error: Data stale

This is what my status dump looks like ...

pi at raspberrypi ~/nut $ /usr/local/ups/bin/upsc SMART500RT1U at localhost
battery.test.status: Battery OK
battery.voltage: 334.10
battery.voltage.nominal: 12
device.mfr: Tripp Lite
device.model: SMART500RT1U
device.type: ups
driver.name: tripplite_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.7.2-signed-19-g90e2790
driver.version.internal: 0.26
input.voltage: 0
input.voltage.maximum: 3341
input.voltage.minimum: 0
input.voltage.nominal: 120
outlet.1.desc: Load 1
outlet.1.id: 1
outlet.1.switch: 1
outlet.1.switchable: 1
outlet.2.desc: Load 2
outlet.2.id: 2
outlet.2.switchable: 0
ups.debug.D: 00 7b 00 8b 0d 00 00 '.......'
ups.debug.L: 07 00 00 07 58 58 0d '....XX.'
ups.debug.load_banks: 1
ups.debug.M: 00 74 00 7e 0d 00 00 '.t.....'
ups.debug.P: 30 30 35 30 30 58 0d '00500X.'
ups.debug.S: 01 00 00 00 64 00 0d '....d..'
ups.debug.T: 21 00 02 57 01 58 0d '...W.X.'
ups.debug.V: 02 00 0c 01 58 58 0d '....XX.'
ups.delay.shutdown: 64
ups.firmware: F334401
ups.firmware.aux: protocol 3005
ups.id: 0
ups.mfr: Tripp Lite
ups.model: SMART500RT1U
ups.power.nominal: 500
ups.productid: 0001
ups.status: OL
ups.temperature: 0
ups.vendorid: 09ae

Still have a couple of zeroes in there ... but this is better. :-)

Steve Ballantyne
Network Engineer
MCSE/MCDST; Novell CLA; LPIC-1; CTT+; A+; Network+; Linux+; Server+;
I-Net+; Security+; SonicWALL CSSA
Charles Lepple
2014-07-04 04:49:43 UTC
Permalink
Post by Steve Ballantyne
input.voltage.maximum: 3341
This number is coincidentally what you would get by reading 0d 0d. I'll have to check the offsets.
Post by Steve Ballantyne
input.voltage.minimum: 0
This one might actually be zero, before running the reset minmax command (which also takes a few seconds to be processed). The min/max values seem to be stored in some sort of nonvolatile memory.

Not sure why the load.* commands aren't working. Those should turn on and off the main load relay, and the outlet variable should control the switchable outlet. We might need to look at a USB trace of the Windows software to see what is going on.
Charles Lepple
2014-07-05 14:24:20 UTC
Permalink
Post by Charles Lepple
Post by Steve Ballantyne
input.voltage.maximum: 3341
This number is coincidentally what you would get by reading 0d 0d. I'll have to check the offsets.
I know how to write a "for" loop and switch/case statement, really I do :-)

See attached (version 0.27). I also pushed this to Github as the branch tripplite_3005.
--
Charles Lepple
clepple at gmail


-------------- next part --------------
A non-text attachment was scrubbed...
Name: tripplite_3005-v0.27.patch
Type: application/octet-stream
Size: 1360 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140705/5873bfe9/attachment.obj>
Loading...