Nut upsdev - Feb 2018 - Work around for power recycling after shutdown.return - TSSHARA UPS - nutdrv_qx driver - megatec protocol

Hi,

I had an issue where after returning the power from a shutdown.return the
ups would do another shutdown.return during the boot, and kept this
forever. After some investigation I found the problem is a bug on the ups -
TSSHARA model, driver nutdrv_qx: every time I shutdown with return, and
reconnect the usb after the power is back it would start another
shudown.return cycle. When I used my rapsberry pi on it they would cycle
forever.

I tested the shutdown.return using the upscmd and I didn't see this
behavior, so I finally find out that is I sent a dummy command to the USP
after the shutdown.return it would not show the problem. My guess is that
the UPS firmware keeps the last command on memory and when the USB is
reconnected it runs it.

I changed the nutdrv-qx driver (megatec protocol) and added a dummy info
read after the shutdown command and the system is working fine. But I don't
think this is the best way to fix this patch. What should be the best
solution for this?

I end up using the original nutrv_qx file and modified the shutdown script
to something like this
/lib/nut/nutdrv_qx -a tsshara -k; /lib/nut/nutdrv_qx -a tsshara

The last call is just to send some different cmds to the UPS so is does not
recycle in the middle of the boot.

I would like to know how can I contribute to get solve this issue with the
tsshara ups.

Regards
Jairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20180227/6b13e186/attachment.html>

2018-02-27 14:51 GMT+01:00 Jairo Rotava <jairo.rotava at
gmail.com>:
> Hi,
>
> I had an issue where after returning the power from a shutdown.return the
> ups would do another shutdown.return during the boot, and kept this
forever.
> After some investigation I found the problem is a bug on the ups - TSSHARA
> model, driver nutdrv_qx: every time I shutdown with return, and reconnect
> the usb after the power is back it would start another shudown.return
cycle.
> When I used my rapsberry pi on it they would cycle forever.
Jairo, what's the exact model of the UPS?
Version of NUT/nutdrv_qx?

Is the monitoring system (the one running nutdrv_qx) turned off by the
shutdown process?
Does this odd behaviour happen even if the 'stayoff' flag is used?
>
> I tested the shutdown.return using the upscmd and I didn't see this
> behavior, so I finally find out that is I sent a dummy command to the USP
> after the shutdown.return it would not show the problem. My guess is that
> the UPS firmware keeps the last command on memory and when the USB is
> reconnected it runs it.
When you experience this problem, does the UPS completely turn off
itself before restarting?
>
> I changed the nutdrv-qx driver (megatec protocol) and added a dummy info
> read after the shutdown command and the system is working fine. But I
don't
> think this is the best way to fix this patch. What should be the best
> solution for this?
If possible, having TS Shara fix their firmware, if it's really broken.
>
> I end up using the original nutrv_qx file and modified the shutdown script
> to something like this
> /lib/nut/nutdrv_qx -a tsshara -k; /lib/nut/nutdrv_qx -a tsshara
>
> The last call is just to send some different cmds to the UPS so is does not
> recycle in the middle of the boot.
>
> I would like to know how can I contribute to get solve this issue with the
> tsshara ups.
>
> Regards
> Jairo
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Answers bellow.

2018-02-28 1:41 GMT-03:00 Daniele Pezzini <hyouko at gmail.com>:
> 2018-02-27 14:51 GMT+01:00 Jairo Rotava <jairo.rotava at gmail.com>:
> > Hi,
> >
> > I had an issue where after returning the power from a shutdown.return
the
> > ups would do another shutdown.return during the boot, and kept this
> forever.
> > After some investigation I found the problem is a bug on the ups -
> TSSHARA
> > model, driver nutdrv_qx: every time I shutdown with return, and
reconnect
> > the usb after the power is back it would start another shudown.return
> cycle.
> > When I used my rapsberry pi on it they would cycle forever.
>
> Jairo, what's the exact model of the UPS?
>
TS Shara Soho II

> Version of NUT/nutdrv_qx?
>
NUT: 2.7.4
nutdrv_qx:0.28
megatec 0.06
>
> Is the monitoring system (the one running nutdrv_qx) turned off by the
> shutdown process?
>
Yes. Same behavior when I kill all service and use just nutdrv_qx -k
> Does this odd behaviour happen even if the 'stayoff' flag is used?
Even worst, the ups just cycle the power and turn on again.
>
> >
> > I tested the shutdown.return using the upscmd and I didn't see
this
> > behavior, so I finally find out that is I sent a dummy command to the
USP
> > after the shutdown.return it would not show the problem. My guess is
that
> > the UPS firmware keeps the last command on memory and when the USB is
> > reconnected it runs it.
>
> When you experience this problem, does the UPS completely turn off
> itself before restarting?
>
Yes
>
> >
> > I changed the nutdrv-qx driver (megatec protocol) and added a dummy
info
> > read after the shutdown command and the system is working fine. But I
> don't
> > think this is the best way to fix this patch. What should be the best
> > solution for this?
>
> If possible, having TS Shara fix their firmware, if it's really broken.
>
I agree. I'll contact the manufacturer. Too many bugs to make a work around
with software.

I don't see how I can get it working if it doesn't stay off when I need.
It
does not stay off with shutdown.stayoff. It also come
back on after shutdown.return even if there is no AC power.
>
> >
> > I end up using the original nutrv_qx file and modified the shutdown
> script
> > to something like this
> > /lib/nut/nutdrv_qx -a tsshara -k; /lib/nut/nutdrv_qx -a tsshara
> >
> > The last call is just to send some different cmds to the UPS so is
does
> not
> > recycle in the middle of the boot.
> >
> > I would like to know how can I contribute to get solve this issue with
> the
> > tsshara ups.
> >
> > Regards
> > Jairo
> >
> > _______________________________________________
> > Nut-upsdev mailing list
> > Nut-upsdev at lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20180228/3630bb6b/attachment.html>