[Nut-upsuser] after power outage and proper shutdown, UPS turns on before power returns

[Charles Lepple]

On Oct 3, 2018, at 8:13 PM, Gabriel <jarod125 at gmail.com> wrote:
> 
> 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].

My mistake, I was interested in the debug output just for the shutdown case (mentioned below). I meant to ask you about comparing the output of "upsc" to that of the other CPS models:

https://networkupstools.org/ddl/Cyber_Power_Systems/

or slightly more recent (and a little less reliable):

http://new.networkupstools.org/ddl/Cyber_Power_Systems/

> 
>> 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.

Thanks for pointing out that difference. I think the reboot-without-power case warrants a new issue:

https://github.com/networkupstools/nut/issues/625
> 
> 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.

The ups.timer.start and ups.timer.shutdown variables are read back from the UPS, and IIRC they should count down from ups.delay.start and ups.delay.shutdown, respectively.

> 
>> 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