Gabriel
2018-Oct-04 00:13 UTC
[Nut-upsuser] after power outage and proper shutdown, UPS turns on before power returns
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
Charles Lepple
2018-Oct-04 12:23 UTC
[Nut-upsuser] after power outage and proper shutdown, UPS turns on before power returns
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
Gabriel
2018-Oct-18 22:35 UTC
[Nut-upsuser] after power outage and proper shutdown, UPS turns on before power returns
> > 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(Re)confirmed the behaviour: - ondelay=0, UPS powers on the load when mains return - ondelay=-1, UPS never powers on the load, even when mains return - ondelay=xx, UPS powers on the load after xx (roughly) seconds, regardless of mains status Debug logs for running the driver with -k is attached. Let me know if they help (I've run this a few times with different values for on/off delay). Tests were run with main power on (did not unplug the UPS). -------------- next part -------------- A non-text attachment was scrubbed... Name: ups_driver_output7.txt.gz Type: application/gzip Size: 3609 bytes Desc: not available URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20181019/6953fed3/attachment.gz> -------------- next part -------------- A non-text attachment was scrubbed... Name: ups_driver_output2.txt.gz Type: application/gzip Size: 1977 bytes Desc: not available URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20181019/6953fed3/attachment-0001.gz> -------------- next part -------------- A non-text attachment was scrubbed... Name: ups_driver_output3.txt.gz Type: application/gzip Size: 1981 bytes Desc: not available URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20181019/6953fed3/attachment-0002.gz> -------------- next part -------------- A non-text attachment was scrubbed... Name: ups_driver_output5.txt.gz Type: application/gzip Size: 1977 bytes Desc: not available URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20181019/6953fed3/attachment-0003.gz>
Possibly Parallel Threads
- after power outage and proper shutdown, UPS turns on before power returns
- after power outage and proper shutdown, UPS turns on before power returns
- after power outage and proper shutdown, UPS turns on before power returns
- after power outage and proper shutdown, UPS turns on before power returns
- CyberPower BR850ELCD ignores offdelay and turns itself back on while still on battery