[Nut-upsuser] Tripplite SMX1500XLRT2U through serial

Tue Sep 30 04:41:02 UTC 2008

On Mon, Sep 22, 2008 at 5:49 PM, Charles Lepple <clepple at gmail.com> wrote:
> On Mon, Sep 22, 2008 at 3:08 AM, Roman Serbski <mefystofel at gmail.com> wrote:
>> On Fri, Sep 19, 2008 at 12:11 AM, Charles Lepple <clepple at gmail.com> wrote:
>>>>>> On Wed, Sep 10, 2008 at 9:05 AM, Charles Lepple <clepple at gmail.com> wrote:
>>>>>>> If that doesn't work, you can try echoing an identification command to the
>>>>>>> serial port, and see what it returns (untested):
>>>>>>>
>>>>>>> $ stty -f /dev/cuad0 raw
>>>>>>> $ echo -ne ':\000\377\015' > /dev/cuad0
>>>>>>> $ hd < /dev/cuad0
>>> [...]
>>>> Ok, here is the ouput of "hd < /dev/cuad0":
>>>>
>>>> 00000000  52 01 ff 0d 53 31 34 30  00 64 31 0d 54 36 46 31  |R...S140.d1.T6F1|
>>>> 00000010  46 33 30 0d 44 37 44 38  38 0d 4c 31 46 30 44 00  |F30.D7D88.L1F0D.|
>>>> 00000020  58 0d 4d 36 34 38 43 0d  52 01 ff 0d 53 31 34 30  |X.M648C.R...S140|
>>>> 00000030  00 64 31 0d 54 36 46 31  46 34 30 0d 44 37 44 38  |.d1.T6F1F40.D7D8|
>>>> 00000040  37 0d 4c 31 46 30 44 00  58 0d 4d 36 34 38 43 0d  |7.L1F0D.X.M648C.|
>>>
>>> Odd... is something else monitoring this UPS? I figured we might get a
>>> couple bytes back from 'hd', but it looks like this was being output
>>> continuously?
>>>
>>> The really interesting part is that I do not see a result of the
>>> protocol request command.
>>
>> Yes, it's being output continuously. The only thing that is changing
>> is L1F0D part. We also monitor this UPS through USB cable, but it
>> connected to Windows 2003 server and according to SMX1500XLRT2U specs
>> it: "Supports simultaneous remote monitoring of UPS and site power
>> conditions via built-in USB and DB9 monitoring ports.".
>
> Interesting. I forget the exact symptoms, but previous units would not
> even respond to the other port if, for instance, you first used the
> serial port, then tried to connect via USB.
>
> I can't promise that we will be able to support the remote monitoring
> thing, but one thing that should capture the protocol number is the
> following procedure:
>
> 1) Temporarily stop the Windows-based monitoring software
> 2) Re-run the hd command
> 3) Let hd run while you restart the monitoring software
> 4) Stop hd after the monitoring software has retrieved the device
> status (online, voltages, etc.)

Greetings Charles-

I followed your advise and with stopped windows-based monitoring
software I don't get any results from hd at all... So I gave up with
the serial connection and connected through USB. Looks like my UPS was
recognized (using tripplite_usb driver), but there is something
strange going on. When I run '/usr/local/libexec/nut/tripplite_usb -a
tripplite -DDDDD -u root' I got the following information:

%/usr/local/libexec/nut/tripplite_usb -a tripplite -DDDDD -u root

Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.11 (2.2.2)
Warning: This is an experimental driver.
Some features may not function correctly.

debug level is '5'
Checking device (09AE/0001) (/dev/usb3//dev/ugen0)
- VendorID: 09ae
- ProductID: 0001
- Manufacturer: TRIPP LITE
- Product: TRIPP LITE SMX1500XLRT2U
- Serial Number: unknown
- Bus: /dev/usb3
Trying to match device
Device matches
Detected a UPS: TRIPP LITE/TRIPP LITE SMX1500XLRT2U
send_cmd(msg_len=3, type='W')
send_cmd: sending  3a 57 00 a8 0d 00 00 00 '.W......'
send_cmd: received 57 00 0d 00 00 00 00 00 'W.......' (OK)
send_cmd(msg_len=2, type='
send_cmd: sending  3a 00 ff 0d 00 00 00 00 '........'
send_cmd: received 00 30 03 58 58 58 58 0d '.0.XXXX.' (OK)
Using SMARTPRO protocol (3003)
send_cmd(msg_len=2, type='S')
send_cmd: sending  3a 53 ac 0d 00 00 00 00 '.S......'
send_cmd: received 53 31 34 30 00 64 31 0d 'S140.d1.' (OK)
send_cmd(msg_len=2, type='P')
send_cmd: sending  3a 50 af 0d 00 00 00 00 '.P......'
send_cmd: received 50 30 31 35 30 30 58 0d 'P01500X.' (OK)
send_cmd(msg_len=2, type='F')
send_cmd: sending  3a 46 b9 0d 00 00 00 00 '.F......'
send_cmd: received 46 31 30 39 31 20 41 0d 'F1091.A.' (OK)
send_cmd(msg_len=2, type='V')
send_cmd: sending  3a 56 a9 0d 00 00 00 00 '.V......'
send_cmd: received 56 32 30 36 33 58 58 0d 'V2063XX.' (OK)
send_cmd(msg_len=2, type='V')
send_cmd: sending  3a 56 a9 0d 00 00 00 00 '.V......'
send_cmd: received 56 32 30 36 33 58 58 0d 'V2063XX.' (OK)
send_cmd(msg_len=2, type='U')
send_cmd: sending  3a 55 aa 0d 00 00 00 00 '.U......'
send_cmd: received 55 ff ff 0d 00 00 00 00 'U.......' (OK)
Unit ID: 65535
Attached to Tripp Lite SMX1500XLRT2U
send_cmd(msg_len=2, type='S')
send_cmd: sending  3a 53 ac 0d 00 00 00 00 '.S......'
send_cmd: received 53 31 34 30 00 5a 31 0d 'S140.Z1.' (OK)
send_cmd(msg_len=2, type='D')
send_cmd: sending  3a 44 bb 0d 00 00 00 00 '.D......'
send_cmd: received 44 37 46 38 38 0d 00 00 'D7F88...' (OK)
send_cmd(msg_len=2, type='M')
send_cmd: sending  3a 4d b2 0d 00 00 00 00 '.M......'
send_cmd: received 4d 37 39 38 31 0d 00 00 'M7981...' (OK)
send_cmd(msg_len=2, type='T')
send_cmd: sending  3a 54 ab 0d 00 00 00 00 '.T......'
send_cmd: received 54 37 30 31 46 33 30 0d 'T701F30.' (OK)
send_cmd(msg_len=2, type='L')
send_cmd: sending  3a 4c b3 0d 00 00 00 00 '.L......'
send_cmd: received 4c 32 34 30 44 00 58 0d 'L240D.X.' (OK)
send_cmd(msg_len=2, type='D')
send_cmd: sending  3a 44 bb 0d 00 00 00 00 '.D......'
send_cmd: received 44 37 46 38 38 0d 00 00 'D7F88...' (OK)
dstate_init: sock /var/db/nut/tripplite_usb-tripplite open on fd 6
send_cmd(msg_len=2, type='S')
send_cmd: sending  3a 53 ac 0d 00 00 00 00 '.S......'
send_cmd: received 53 31 34 30 00 5a 31 0d 'S140.Z1.' (OK)
send_cmd(msg_len=2, type='D')
send_cmd: sending  3a 44 bb 0d 00 00 00 00 '.D......'
send_cmd: received 44 37 46 38 37 0d 00 00 'D7F87...' (OK)
send_cmd(msg_len=2, type='M')
send_cmd: sending  3a 4d b2 0d 00 00 00 00 '.M......'
send_cmd: received 4d 37 39 38 31 0d 00 00 'M7981...' (OK)
send_cmd(msg_len=2, type='T')
send_cmd: sending  3a 54 ab 0d 00 00 00 00 '.T......'
send_cmd: received 54 37 30 31 46 34 30 0d 'T701F40.' (OK)
send_cmd(msg_len=2, type='L')
send_cmd: sending  3a 4c b3 0d 00 00 00 00 '.L......'
send_cmd: received 4c 32 33 30 44 00 58 0d 'L230D.X.' (OK)
send_cmd(msg_len=2, type='D')
send_cmd: sending  3a 44 bb 0d 00 00 00 00 '.D......'
send_cmd: received 44 37 46 38 39 0d 00 00 'D7F89...' (OK)

As soon as I run it without '-u root' I have an error (same valid when
I start nut):

%/usr/local/libexec/nut/tripplite_usb -a tripplite -DDDDD

Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.11 (2.2.2)
Warning: This is an experimental driver.
Some features may not function correctly.

debug level is '5'
Checking device (09AE/0001) (/dev/usb3//dev/ugen0)
- VendorID: 09ae
- ProductID: 0001
- Manufacturer: unknown
- Product: unknown
- Serial Number: unknown
- Bus: /dev/usb3
Trying to match device
Device matches
Detected a UPS: unknown/unknown
send_cmd(msg_len=3, type='W')
send_cmd: sending  3a 57 00 a8 0d 00 00 00 '.W......'
libusb_set_report() returned -1 instead of 8
Could not reset watchdog. Please send model information to nut-upsdev
mailing list
send_cmd(msg_len=2, type='
send_cmd: sending  3a 00 ff 0d 00 00 00 00 '........'
libusb_set_report() returned -1 instead of 8
Error reading protocol

I double checked permissions (according to
http://people.freebsd.org/~thierry/nut_FreeBSD_HowTo.txt), but it
didn't help. Does it look like a permission problem?

Many thanks!