Nut upsuser - Oct 2018 - after power outage and proper shutdown, UPS turns on before power returns

Hi,

I'm struggling with a peculiar issue with my UPS. After a power
outage, the devices powered by it properly shut down via nut.
Eventually, the UPS also goes down. Power is still out, however,
roughly 40 seconds after the UPS shut down, it turns back on and it
starts supplying power to the load, thus turning back on the devices
attached to it. This is obviously not something I want. In trying to
figure out the problem, the closest I've come was the ondelay
parameter, but that only comes in play after the power returns, so it
shouldn't apply here.

The UPS in question is a CyberPower Value600ELCD. Its USB port is
connected to my router which runs an up-to-date Debian testing with
nut-{driver,monitor,server} version 2.7.4-8 installed via apt. I'm
pasting ups.conf below and attaching output from upsc, upsrw and
/lib/nut/usbhid-ups -DD -a cyberpower.

root at e3845:/etc/nut# egrep -v -e '^$|^#' ups.conf
maxretry = 3
[cyberpower]
    driver = usbhid-ups
    port = auto
    offdelay = 20
    ondelay = 60
    default.battery.charge.low = 40
    default.battery.charge.warning = 50


Any idea what could be going on here?

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ups_driver_output.txt.gz
Type: application/gzip
Size: 5803 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20180928/be4d36fb/attachment.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upsrw.txt.gz
Type: application/gzip
Size: 265 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20180928/be4d36fb/attachment-0001.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upsc.txt.gz
Type: application/gzip
Size: 437 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20180928/be4d36fb/attachment-0002.gz>

On Sep 27, 2018, at 6:59 PM, Gabriel <jarod125 at gmail.com>
wrote:
> 
> Hi,
> 
> I'm struggling with a peculiar issue with my UPS. After a power
> outage, the devices powered by it properly shut down via nut.
> Eventually, the UPS also goes down. Power is still out, however,
> roughly 40 seconds after the UPS shut down, it turns back on and it
> starts supplying power to the load, thus turning back on the devices
> attached to it. This is obviously not something I want. In trying to
> figure out the problem, the closest I've come was the ondelay
> parameter, but that only comes in play after the power returns, so it
> shouldn't apply here.
Hi Gabriel,

sorry for the delay - I am still working through a bit of a backlog here.

We have a few other open CyberPower issues listed here:
https://github.com/networkupstools/nut/labels/CyberPower%20%28CPS%29

If you wouldn't mind checking through them to see if the Value line produces
similar debug output to the others listed there, that would be most helpful.

One theme with some of the CPS timeout issues is that the user-specified timer
values are rounded down to the nearest minute. So an offdelay of 20 is probably
a corner case. That may not be the fix for your issue, but I would recommend
using "offdelay=60" and "ondelay = 120" to attempt to
separate the issues.

Also, it would be helpful to compare the debug log for running the driver with
the "-k" option to kill power (as you did before when obtaining the
driver debug output, the rest of NUT will need to be stopped). I would recommend
doing this with the machine plugged into another power source, so that you can
keep capturing the logs without the rest of the system powering down
unexpectedly.
> 
> The UPS in question is a CyberPower Value600ELCD. Its USB port is
> connected to my router which runs an up-to-date Debian testing with
> nut-{driver,monitor,server} version 2.7.4-8 installed via apt. I'm
> pasting ups.conf below and attaching output from upsc, upsrw and
> /lib/nut/usbhid-ups -DD -a cyberpower.
Depending on the results of the shutdown debug logs, we might need to patch the
driver. Here are instructions for getting the build environment set up:
https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu

Thank you for a very detailed bug report.

[when replying, please use reply-all - the list does not munge reply-to headers]

On Tue, Oct 2, 2018 at 3:59 PM Charles Lepple <clepple at gmail.com>
wrote:
>
> On Sep 27, 2018, at 6:59 PM, Gabriel <jarod125 at gmail.com> wrote:
> >
> > Hi,
> >
> > I'm struggling with a peculiar issue with my UPS. After a power
> > outage, the devices powered by it properly shut down via nut.
> > Eventually, the UPS also goes down. Power is still out, however,
> > roughly 40 seconds after the UPS shut down, it turns back on and it
> > starts supplying power to the load, thus turning back on the devices
> > attached to it. This is obviously not something I want. In trying to
> > figure out the problem, the closest I've come was the ondelay
> > parameter, but that only comes in play after the power returns, so it
> > shouldn't apply here.
>
> Hi Gabriel,
>
> sorry for the delay - I am still working through a bit of a backlog here.
>
> We have a few other open CyberPower issues listed here:
https://github.com/networkupstools/nut/labels/CyberPower%20%28CPS%29
>
> If you wouldn't mind checking through them to see if the Value line
produces similar debug output to the others listed there, that would be most
helpful.
To be honest, I'm not really able to read the debug output, so I
wouldn't know what to look for (looks like a foreign language to me).
When I sent the report, I've just attached what was mentioned in the
"Request help" paragraph from the Support instructions page[1].
> One theme with some of the CPS timeout issues is that the user-specified
timer values are rounded down to the nearest minute. So an offdelay of 20 is
probably a corner case. That may not be the fix for your issue, but I would
recommend using "offdelay=60" and "ondelay = 120" to attempt
to separate the issues.
After sending the email, I revisited the usbhid-ups driver man page
and found the part that specified that ondelay=-1 can be used in the
scenario I am facing (for some reason, I haven't noticed this when
initially reading the docs). And sure enough, this works, but the side
effect is that the UPS won't come back when power returns. I've also
tried with higher values (300) and it's still the same. UPS will power
up even if there's no mains power. After looking at the github issues
at the link you specified, I've found this[2] post which describes
pretty much the exact behaviour I'm seeing. I haven't tried with
ondelay=0, but I'm sure it'll behave like that guy says (I'll
confirm
and report back). So, at the moment, between: i) set the ondelay to a
(very) large value and hope that power returns before the UPS turns
back on or ii) set ondelay=-1 and manually turn on the UPS after power
returns, setting ondelay=0 looks like the only half-decent option, but
still leaves you vulnerable in case the power comes back and goes out
again before the battery is charged to a comfortable level.

While we're at this, what's the difference between
ups.delay.{start,shutdown} and ups.timer.{start,shutdown}? The first
pair seems to be user-configurable via upsrw (and overriden via
ondelay and offdelay in ups.conf), but the latter appear to be
non-configurable.
> Also, it would be helpful to compare the debug log for running the driver
with the "-k" option to kill power (as you did before when obtaining
the driver debug output, the rest of NUT will need to be stopped). I would
recommend doing this with the machine plugged into another power source, so that
you can keep capturing the logs without the rest of the system powering down
unexpectedly.
This I can do (hopefully this week). I'll get back with the output.

[1] https://networkupstools.org/support.html
[2] https://github.com/networkupstools/nut/issues/432#issuecomment-405371395