On Oct 3, 2018, at 8:13 PM, Gabriel <[email protected]> wrote: > > On Tue, Oct 2, 2018 at 3:59 PM Charles Lepple <[email protected]> wrote: >> >> On Sep 27, 2018, at 6:59 PM, Gabriel <[email protected]> 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 _______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
