[Nut-upsdev] Work around for power recycling after shutdown.return - TSSHARA UPS - nutdrv_qx driver - megatec protocol
jairo.rotava at gmail.com
Wed Feb 28 20:11:01 UTC 2018
I think that on this file nutdrv_qx_megatec.c the definition for
shutdown.stayoff may be wrong. In the file the definition is "S%sR0000\r"m
while on the megatec protocol description (
http://networkupstools.org/protocols/megatec.html) the command is just
When I changed it my system was abe to at least stay off, and stopped
making an instant power recycling.
2018-02-28 15:40 GMT-03:00 Jairo Rotava <jairo.rotava at gmail.com>:
> 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
>> > ups would do another shutdown.return during the boot, and kept this
>> > After some investigation I found the problem is a bug on the ups -
>> > model, driver nutdrv_qx: every time I shutdown with return, and
>> > the usb after the power is back it would start another shudown.return
>> > 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
> 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
>> > after the shutdown.return it would not show the problem. My guess is
>> > 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
>> > 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
>> > 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
>> > recycle in the middle of the boot.
>> > I would like to know how can I contribute to get solve this issue with
>> > 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...
More information about the Nut-upsdev