Hello, 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 "S%s\r". When I changed it my system was abe to at least stay off, and stopped making an instant power recycling.
Jairo 2018-02-28 15:40 GMT-03:00 Jairo Rotava <jairo.rot...@gmail.com>: > Answers bellow. > > 2018-02-28 1:41 GMT-03:00 Daniele Pezzini <hyo...@gmail.com>: > >> 2018-02-27 14:51 GMT+01:00 Jairo Rotava <jairo.rot...@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@lists.alioth.debian.org >> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev >> > >
_______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev