<div dir="ltr">Good news, with the UPS on battery power, /lib/nut/tripplite_usb -a tripplite -k -DDD *does* shut the UPS down:<br><br># /lib/nut/tripplite_usb -a tripplite -k -DDD<br>Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.20 (2.7.2)<br>Warning: This is an experimental driver.<br>Some features may not function correctly.<br><br><div>   0.000000 debug level is '3'<br>   0.003081 Checking device (09AE/0001) (001/004)<br>   0.014348 - VendorID: 09ae<br>   0.014421 - ProductID: 0001<br>   0.014466 - Manufacturer: TRIPP LITE<br>   0.014511 - Product: TRIPP LITE SMART2200VS      <br>   0.014554 - Serial Number: unknown<br>   0.014597 - Bus: 001<br>   0.014640 Trying to match device<br>   0.015020 Device matches<br>   0.015844 Detected a UPS: TRIPP LITE/TRIPP LITE SMART2200VS      <br>   0.015926 Initiating UPS shutdown<br>   0.015975 soft_shutdown(offdelay=64): N<br>   0.016021 send_cmd(msg_len=4, type='N')<br>   2.117236 send_cmd(msg_len=2, type='G')<br><br>Driver exited and UPS shut down a little after 64 seconds.  Will continue with additional testing to make sure all the components work together.</div><div><br></div><div>As background, the intended application is to use the Raspberry Pi as the NUT master controlling the UPS while the NUT slave is running on an ESXi host.</div><div><br></div><div>Thanks for the help!</div><div><br></div><div>--Larry<br><br>On Wed, May 25, 2016 at 10:07 PM, Charles Lepple <<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>> wrote:<br>><br>> On May 25, 2016, at 9:42 PM, Larry Fahnoe <<a href="mailto:fahnoe@fahnoetech.com">fahnoe@fahnoetech.com</a>> wrote:<br>> ><br>> > So the current NUT can't cause this UPS to power off the load while it is on line power, correct?  I will update the nut-server init script with the sleep/reboot logic per FAQ #51.<br>><br>> Correct.<br>><br>> > My larger concern is testing the UPS to ensure it shuts down correctly and comes back up correctly as well.  My concern is driven by my observation that with older versions of NUT using the tripplite_usb driver, this UPS has *not* correctly shut down while on battery, thus the batteries drained and the UPS never supplied load power once line power had been restored.<br>><br>> To be honest, most of my testing with Raspbian has been just debugging drivers during normal operation, not with the shutdown scripts. I also haven't had much of a chance to test with systemd.<br>><br>> Even stranger, someone else saw the opposite problem with the same .deb version in Debian/x86: <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799849">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799849</a><br>><br>> >  I assume the next logical test would be to do the same test (/lib/nut/tripplite_usb -a tripplite -k -DDD) while the UPS is on battery?<br>><br>> Yes.<br>><br>> > Are the serial drivers any better at this sort of thing than the USB driver for these older Tripplite UPS systems?<br>><br>> Not sure - the OMNIVS1000 that I used to test tripplite_usb does not have a serial port.<br>><br>> There seem to be some options to force the UPS to reboot, but it is unclear which protocol number the serial driver was written for.<br>><br>> --<br>> Charles Lepple<br>> clepple@gmail<br>><br>><br>><br><br><br><br>--<br>Larry Fahnoe, Fahnoe Technology Consulting, fahnoe@FahnoeTech.com<br>           Minneapolis, Minnesota       <a href="http://www.FahnoeTech.com">www.FahnoeTech.com</a><br><div class="gmail_extra">
</div></div></div>