[Nut-upsuser] Tripplite SMART2200VS with tripplite_usb: UPS doesn't shut down

[Larry Fahnoe]

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