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

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>

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.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
>> 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/e89df715/attachment.html>

2018-02-28 21:11 GMT+01:00 Jairo Rotava <jairo.rotava at
gmail.com>:
> 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).
> 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).
>
> Jairo