Nut upsuser - May 2016 - Tripplite SMART2200VS with tripplite_usb: UPS doesn't shut down

>
> >    2.117586     send_cmd(msg_len=2, type='G')
> >    3.219418     libusb_get_interrupt: Connection timed out
> >    3.219474     libusb_get_interrupt() returned 0 instead of 8 while
> sending 3a 47 b8 0d 00 00 00 00 '.G......'
> >    4.219593     libusb_get_interrupt: Connection timed out
> >    4.219661     libusb_get_interrupt() returned 0 instead of 8 while
> sending 3a 47 b8 0d 00 00 00 00 '.G......'
> Is the unit on line power at this point?

Yes, the UPS is on line power and the NUT master is not powered by the UPS
for the test. The libusb_get_interrupt() messages continued well past the
64 second timeout.

I don't think we know the command needed to power off the UPS when it
is
> not running on battery (the 'G' command seems to be "wait for
power to
> return"). I suspect we could emulate it with the watchdog, but that
will
> require a fair amount of testing to make sure we understand the timer.

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.

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.  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?

Are the serial drivers any better at this sort of thing than the USB driver
for these older Tripplite UPS systems?
--Larry

On Wed, May 25, 2016 at 7:20 PM, Charles Lepple <clepple at gmail.com>
wrote:
> On May 25, 2016, at 3:43 PM, Larry Fahnoe wrote:
> >
> >    0.016075     Initiating UPS shutdown
> >    0.016117     soft_shutdown(offdelay=64): N
> >    0.016137     send_cmd(msg_len=4, type='N')
>
> The delay command ('N') was sent successfully, so the UPS is
receiving
> commands.
>
> >    2.117586     send_cmd(msg_len=2, type='G')
> >    3.219418     libusb_get_interrupt: Connection timed out
> >    3.219474     libusb_get_interrupt() returned 0 instead of 8 while
> sending 3a 47 b8 0d 00 00 00 00 '.G......'
> >    4.219593     libusb_get_interrupt: Connection timed out
> >    4.219661     libusb_get_interrupt() returned 0 instead of 8 while
> sending 3a 47 b8 0d 00 00 00 00 '.G......'
>
> Is the unit on line power at this point? I don't think we know the
command
> needed to power off the UPS when it is not running on battery (the
'G'
> command seems to be "wait for power to return"). I suspect we
could emulate
> it with the watchdog, but that will require a fair amount of testing to
> make sure we understand the timer.
>
>
>
https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L675
>
> As a result, the last entry in the FAQ will apply:
> http://networkupstools.org/docs/FAQ.html
>
> --
> Charles Lepple
> clepple at gmail
>
>
>
>

-- 
Larry Fahnoe, Fahnoe Technology Consulting, fahnoe at FahnoeTech.com
           Minneapolis, Minnesota       www.FahnoeTech.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20160525/9001e311/attachment.html>

On May 25, 2016, at 9:42 PM, Larry Fahnoe <fahnoe at fahnoetech.com>
wrote:
> 
> 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.
Correct.
> 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.
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.

Even stranger, someone else saw the opposite problem with the same .deb version
in Debian/x86: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799849
>  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?
Yes.
> Are the serial drivers any better at this sort of thing than the USB driver
for these older Tripplite UPS systems?
Not sure - the OMNIVS1000 that I used to test tripplite_usb does not have a
serial port.

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.

-- 
Charles Lepple
clepple at gmail

Good news, with the UPS on battery power, /lib/nut/tripplite_usb -a
tripplite -k -DDD *does* shut the UPS down:

# /lib/nut/tripplite_usb -a tripplite -k -DDD
Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.20 (2.7.2)
Warning: This is an experimental driver.
Some features may not function correctly.

   0.000000 debug level is '3'
   0.003081 Checking device (09AE/0001) (001/004)
   0.014348 - VendorID: 09ae
   0.014421 - ProductID: 0001
   0.014466 - Manufacturer: TRIPP LITE
   0.014511 - Product: TRIPP LITE SMART2200VS
   0.014554 - Serial Number: unknown
   0.014597 - Bus: 001
   0.014640 Trying to match device
   0.015020 Device matches
   0.015844 Detected a UPS: TRIPP LITE/TRIPP LITE SMART2200VS
   0.015926 Initiating UPS shutdown
   0.015975 soft_shutdown(offdelay=64): N
   0.016021 send_cmd(msg_len=4, type='N')
   2.117236 send_cmd(msg_len=2, type='G')

Driver exited and UPS shut down a little after 64 seconds.  Will continue
with additional testing to make sure all the components work together.

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.

Thanks for the help!

--Larry

On Wed, May 25, 2016 at 10:07 PM, Charles Lepple <clepple at gmail.com>
wrote:
>
> On May 25, 2016, at 9:42 PM, Larry Fahnoe <fahnoe at fahnoetech.com>
wrote:
> >
> > 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.
>
> Correct.
>
> > 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.
>
> 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.
>
> Even stranger, someone else saw the opposite problem with the same .deb
version in Debian/x86:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799849
>
> >  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?
>
> Yes.
>
> > Are the serial drivers any better at this sort of thing than the USB
driver for these older Tripplite UPS systems?
>
> Not sure - the OMNIVS1000 that I used to test tripplite_usb does not have
a serial port.
>
> 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.
>
> --
> Charles Lepple
> clepple at gmail
>
>
>


--
Larry Fahnoe, Fahnoe Technology Consulting, fahnoe at FahnoeTech.com
           Minneapolis, Minnesota       www.FahnoeTech.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20160526/92c08256/attachment.html>