Original Message>I have 2 SmartUOS1050SLT's that apparently protocol 3004, has there >been >any progress on getting these units supported under nut? I am running >version 2.4.1, and get the following output when starting the driver.>#lsusb >Bus 005 Device 002: ID 09ae:0001 Tripp Lite># upsdrvctl -DDDD start >Network UPS Tools - UPS driver controller 2.4.1 >Starting UPS: tripplite >exec: /lib/nut/tripplite_usb -a tripplite >Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.20 (2.4.1) >Warning: This is an experimental driver. >Some features may not function correctly.>Detected a UPS: TRIPP LITE/TRIPP LITE SMART1050SLT >Unknown input voltage range: 0x02 >Unknown number of switchable load banks: 0x00 >Unit ID: 0 >Unknown protocol (3004)Attached to Tripp Lite SMART1050SLT >Unknown value for s[1]: 0x01Reply:from clepple>No progress - we have not received enough information from owners of >Protocol 3004 units to proceed. From what little I can tell, 3004 uses >binary values instead of ASCII (e.g. 0x01 instead of 0x31 to represent >the number 1). Also, there seem to be other minor differences.>The procedure for adding support for a new UPS protocol involves a lot >of testing, and is best done without any critical loads attached (e.g. >servers that you were trying to protect with the UPS in the first >place). If you can take one unit offline for testing, we can work with >you to add support, but there is always the danger that a wrong >command will shut down the UPS before the attached computers are >expecting it.Moving this to the dev list so that people can benefit from the discussion. Thanks,
On Sun, 2010-01-31 at 14:38 -0500, Charles Lepple wrote:> On Jan 31, 2010, at 1:44 PM, chance fulton wrote: > > > Original Message > >> I have 2 SmartUOS1050SLT's that apparently protocol 3004, has there > >> been > >> any progress on getting these units supported under nut? I am running > >> version 2.4.1, and get the following output when starting the driver. > > > >> #lsusb > >> Bus 005 Device 002: ID 09ae:0001 Tripp Lite > > > >> # upsdrvctl -DDDD start > >> Network UPS Tools - UPS driver controller 2.4.1 > >> Starting UPS: tripplite > >> exec: /lib/nut/tripplite_usb -a tripplite > >> Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.20 (2.4.1) > >> Warning: This is an experimental driver. > >> Some features may not function correctly. > > > >> Detected a UPS: TRIPP LITE/TRIPP LITE SMART1050SLT > >> Unknown input voltage range: 0x02 > >> Unknown number of switchable load banks: 0x00 > >> Unit ID: 0 > >> Unknown protocol (3004)Attached to Tripp Lite SMART1050SLT > >> Unknown value for s[1]: 0x01 > > > > Reply:from clepple > > > >> No progress - we have not received enough information from owners of > >> Protocol 3004 units to proceed. From what little I can tell, 3004 > >> uses > >> binary values instead of ASCII (e.g. 0x01 instead of 0x31 to > >> represent > >> the number 1). Also, there seem to be other minor differences. > > > >> The procedure for adding support for a new UPS protocol involves a > >> lot > >> of testing, and is best done without any critical loads attached > >> (e.g. > >> servers that you were trying to protect with the UPS in the first > >> place). If you can take one unit offline for testing, we can work > >> with > >> you to add support, but there is always the danger that a wrong > >> command will shut down the UPS before the attached computers are > >> expecting it. > > > > > > Moving this to the dev list so that people can benefit from the > > discussion. > > The first thing to do is build the latest version to make sure that > you have everything set up correctly. (I don't recall whether you were > using NUT 2.4.1 from packages or from source - if it's the latter, you > may be all set.) > > If you have SVN, autoconf and automake installed, you can do a SVN > checkout: > > http://www.networkupstools.org/source.html ("Development tree" section) > > If not, we generate tarballs from Buildbot. You can download from here: > > http://buildbot.ghz.cc/public/nut/waterfall?branch=trunk&builder=Debian-etch-x86 > > You will want the first "tarball" link, currently http://ocelot.ghz.cc/~buildbot/nut-2.4.1-r2286.tar.gz > > Please post a few details about your OS distribution and version. >I have Ubuntu server 9.10 Kernel 2.6.31-17-generic-pae I have just installed Network UPS Tools - UPS driver controller 2.4.1-r2286 And still have the same issue. Let me know what I need to do next. Thanks,
On Jan 31, 2010, at 5:04 PM, chance fulton wrote:> How long does it run for? Seems to be taking forever printing this > stuff > > 146.157601 send_cmd(msg_len=2, type='S') > 146.326082 Unknown value for s[1]: 0x01 > 146.326107 send_cmd(msg_len=2, type='L') > 146.454070 send_cmd(msg_len=2, type='D') > 146.582070 send_cmd(msg_len=2, type='V') > 146.710056 send_cmd(msg_len=2, type='M') > 146.838041 send_cmd(msg_len=2, type='T') > 146.966031 send_cmd(msg_len=2, type='P') > 148.158677 send_cmd(msg_len=2, type='S')I forgot to mention that you can kill it after a few minutes. Can you just try it briefly with five "-D" options?
On Feb 1, 2010, at 4:16 PM, chance fulton wrote:> 117 off mains > then I added some more load around 350 > I let it run till it shut itself off.Here's the status from around when the power was cut: 116.394032 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK) 118.313822 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK) 120.361600 send_cmd: received 53 01 04 00 01 58 00 0d 'S....X..' (OK) 122.408599 send_cmd: received 53 01 04 00 01 4c 00 0d 'S....L..' (OK) 124.329167 send_cmd: received 53 01 04 00 01 40 00 0d 'S.......' (OK) 126.376596 send_cmd: received 53 01 04 00 01 3c 00 0d 'S.......' (OK) 128.296736 send_cmd: received 53 01 04 00 01 36 00 0d 'S.... 6..' (OK) (I removed a bunch of intermediate lines, but the driver did transition from "OL" to "OB" as it should.) What's disturbing is that towards the end, the "LB" indicator is flickering: 1809.265763 send_cmd: received 53 01 04 00 01 1f 00 0d 'S.......' (OK) 1811.185555 send_cmd: received 53 00 04 00 01 00 00 0d 'S.......' (OK) 1813.233333 send_cmd: received 53 01 04 00 01 1f 00 0d 'S.......' (OK) 1815.281109 send_cmd: received 53 01 04 00 01 1f 00 0d 'S.......' (OK) 1817.200900 send_cmd: received 53 01 04 00 01 1f 00 0d 'S.......' (OK) 1819.248680 send_cmd: received 53 01 04 00 01 1f 00 0d 'S.......' (OK) 1821.296454 send_cmd: received 53 00 04 00 01 00 00 0d 'S.......' (OK) 1823.216246 send_cmd: received 53 01 04 00 01 1e 00 0d 'S.......' (OK) 1825.264023 send_cmd: received 53 01 04 00 01 1e 00 0d 'S.......' (OK) 1827.183813 send_cmd: received 53 00 04 00 01 00 00 0d 'S.......' (OK) 1829.231590 send_cmd: received 53 00 04 00 01 00 00 0d 'S.......' (OK) Hopefully, NUT will catch the first "LB" indicator, and shut down at that point. I added a couple more things to SVN (voltage, temperature, etc.) One thing you might want to try is pulling the power, and running the driver with "-k" to shut it down. There is a 64-second "offdelay", but you could try setting it lower, e.g. "-x offdelay=5". -- Charles Lepple