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 _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
