Discussion:
[Nut-upsdev] Work around for power recycling after shutdown.return - TSSHARA UPS - nutdrv_qx driver - megatec protocol
Jairo Rotava
2018-02-27 13:51:13 UTC
Permalink
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
Daniele Pezzini
2018-02-28 04:41:03 UTC
Permalink
Post by Jairo Rotava
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?
Post by Jairo Rotava
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?
Post by Jairo Rotava
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.
Post by Jairo Rotava
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
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Jairo Rotava
2018-02-28 18:40:21 UTC
Permalink
Answers bellow.
Post by Jairo Rotava
Post by Jairo Rotava
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.
Post by Jairo Rotava
After some investigation I found the problem is a bug on the ups -
TSSHARA
Post by Jairo Rotava
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.
Post by Jairo Rotava
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
Post by Jairo Rotava
Version of NUT/nutdrv_qx?
NUT: 2.7.4
nutdrv_qx:0.28
megatec 0.06
Post by Jairo Rotava
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
Post by Jairo Rotava
Does this odd behaviour happen even if the 'stayoff' flag is used?
Even worst, the ups just cycle the power and turn on again.
Post by Jairo Rotava
Post by Jairo Rotava
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
Post by Jairo Rotava
Post by Jairo Rotava
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
Post by Jairo Rotava
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.
Post by Jairo Rotava
Post by Jairo Rotava
I end up using the original nutrv_qx file and modified the shutdown
script
Post by Jairo Rotava
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
Post by Jairo Rotava
recycle in the middle of the boot.
I would like to know how can I contribute to get solve this issue with
the
Post by Jairo Rotava
tsshara ups.
Regards
Jairo
_______________________________________________
Nut-upsdev mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Jairo Rotava
2018-02-28 20:11:01 UTC
Permalink
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
Post by Jairo Rotava
Answers bellow.
Post by Jairo Rotava
Post by Jairo Rotava
Hi,
I had an issue where after returning the power from a shutdown.return
the
Post by Jairo Rotava
ups would do another shutdown.return during the boot, and kept this
forever.
Post by Jairo Rotava
After some investigation I found the problem is a bug on the ups -
TSSHARA
Post by Jairo Rotava
model, driver nutdrv_qx: every time I shutdown with return, and
reconnect
Post by Jairo Rotava
the usb after the power is back it would start another shudown.return
cycle.
Post by Jairo Rotava
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
Post by Jairo Rotava
Version of NUT/nutdrv_qx?
NUT: 2.7.4
nutdrv_qx:0.28
megatec 0.06
Post by Jairo Rotava
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
Post by Jairo Rotava
Does this odd behaviour happen even if the 'stayoff' flag is used?
Even worst, the ups just cycle the power and turn on again.
Post by Jairo Rotava
Post by Jairo Rotava
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
Post by Jairo Rotava
after the shutdown.return it would not show the problem. My guess is
that
Post by Jairo Rotava
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
Post by Jairo Rotava
Post by Jairo Rotava
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
Post by Jairo Rotava
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.
Post by Jairo Rotava
Post by Jairo Rotava
I end up using the original nutrv_qx file and modified the shutdown
script
Post by Jairo Rotava
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
Post by Jairo Rotava
recycle in the middle of the boot.
I would like to know how can I contribute to get solve this issue with
the
Post by Jairo Rotava
tsshara ups.
Regards
Jairo
_______________________________________________
Nut-upsdev mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
Daniele Pezzini
2018-03-02 04:34:16 UTC
Permalink
Post by Jairo Rotava
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".
hmm.. no.
In plain megatec protocol there's no such a thing as 'shutdown and
stay off' -- the closest thing you can do is call 'SnRm' with an
incredibly high value for the time to wait before turning on the
device (i.e. 'SnR9999', using the allowed maximum), while the 'Sn'
command is meant to tell the device to immediately turn on the load
when power returns.
Only some devices support the non-standard 'SnR0000' command and hold
off the load indefinitely (and it's also stated in nutdrv_qx's
manpage, 'Known problems' section).
Post by Jairo Rotava
When I changed it my system was abe to at least stay off, and stopped making
an instant power recycling.
Try the following things and let's see what happens:
- 'offdelay=30', 'ondelay=0' (the driver will send 'S.5' to the device),
- 'offdelay=120', 'ondelay=0' (the driver will send 'S02' to the device),
- 'offdelay=30', 'ondelay=180' (the driver will send 'S.5R0003' to the device),
- 'offdelay=120', 'ondelay=180' (the driver will send 'S02R0003' to the device),
- 'offdelay=30', 'stayoff' flag (the driver will send 'S.5R0000' to the device),
- 'offdelay=120', 'stayoff' flag (the driver will send 'S02R0000' to
the device).
Post by Jairo Rotava
Jairo
Jairo Rotava
2018-03-02 12:14:48 UTC
Permalink
yes, you are right. I tried the what you asked and got it working.

I overlooked the "know problems" section, but I think it is not clear
enough. I would never realize from the manual that to keep my ups from
waking up without mains I should use ondelay=0, and stayoff would make it
recycle the power.

If there were a section on the manual with something like this: if you are
having problem when restarting the UPS try to change ondelay = 0,or test
the stayoff flag.

I can write something for the special case of using a TS Shara nobreak, if
you wish.

Thanks
Post by Jairo Rotava
Post by Jairo Rotava
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
Post by Jairo Rotava
while on the megatec protocol description (
http://networkupstools.org/protocols/megatec.html) the command is just
"S%s\r".
hmm.. no.
In plain megatec protocol there's no such a thing as 'shutdown and
stay off' -- the closest thing you can do is call 'SnRm' with an
incredibly high value for the time to wait before turning on the
device (i.e. 'SnR9999', using the allowed maximum), while the 'Sn'
command is meant to tell the device to immediately turn on the load
when power returns.
Only some devices support the non-standard 'SnR0000' command and hold
off the load indefinitely (and it's also stated in nutdrv_qx's
manpage, 'Known problems' section).
Post by Jairo Rotava
When I changed it my system was abe to at least stay off, and stopped
making
Post by Jairo Rotava
an instant power recycling.
- 'offdelay=30', 'ondelay=0' (the driver will send 'S.5' to the device),
- 'offdelay=120', 'ondelay=0' (the driver will send 'S02' to the device),
- 'offdelay=30', 'ondelay=180' (the driver will send 'S.5R0003' to the device),
- 'offdelay=120', 'ondelay=180' (the driver will send 'S02R0003' to the device),
- 'offdelay=30', 'stayoff' flag (the driver will send 'S.5R0000' to the device),
- 'offdelay=120', 'stayoff' flag (the driver will send 'S02R0000' to
the device).
Post by Jairo Rotava
Jairo
Loading...