Hi Charles, all: On Tue, Oct 06, 2015 at 08:45:40AM -0400, Charles Lepple wrote: > On Oct 6, 2015, at 5:40 AM, Steffen Grunewald <steffen.grunew...@aei.mpg.de> > wrote: > > > > What I currently tried: > > - I found a longish discussion on this list, dating back to six years > > ago: > > http://lists.alioth.debian.org/pipermail/nut-upsuser/2009-February/004772.html > > In particular, Marco's requirements look quite similar to ours, but > > there was apparently no solution (back then). I mayhave missed a later > > continuation though. > > Right, I don't think the "ignorelb" flag was added to drivers until 2011.
And somehow this option is named in a way that made my input filter drop it quite early. Yes, indeed, this one does the trick. I still don't understand where exactly it happens :/ (but I don't care much) > > - Use multiple drivers, with override.battery.charge.low set to various > > levels - or "dummy-ups" repeaters with the same modification > > - Let client groups upsmon-read one of those "virtual" UPSes > > > > What I found: > > - upsd obviously doesn't calculate LB itself (even if charge.low is set > > to 105.00 for testing purposes). Does this only happen on OB, or does > > upsd do no calculations at all? > > Apparently, ordered handling of multiple shutdown conditions cannot be > > done this way? > > Also correct that upsd does not calculate LB, but the drivers can do what you > are describing if the "ignorelb" flag is set. Using dummy-ups in repeater > mode does sound like a good option. It is ;) What I am doing now: - have a (primary) snmp-ups driver with override.battery.charge.low = 50 *and* ignorelb = true (is this correct syntax?), as 50% is the critical capacity where I cannot trust the UPS anymore (for more than a few minutes). battery.runtime returns random numbers, batttery.runtime.low is 0, and I don't have a better guess either :/ - a bunch of dummy-ups drivers, each with a different charge.low setting (55, 60, 70, 85, 105 [!]), and ignorelb set. > Another potential hitch: while you can override LB, I haven't looked into > overriding OB. So for testing, it might be necessary to have a copy of dummy > ups reading from a file, in place of the actual snmp-ups driver. This is easy: just insert a "override.battery.charge = 66.66" into the primary driver definition while testing - which can be done with upsc -l | xargs -t -i% upsc %$localhost ups.status When done with testing, "upsdrvctl stop primary", remove the override from ups.conf and "upsdrvctl start primary". Yes, you'll get "OL LB" reports. Don't know what an upsmon would do with that :) (Workaround: Next to override.battery.charge, define override.ups.status?) There's only one drawback caused by the repeater logic set up this way: - upsdrvctl will start the primary (real) driver since it can connect via snmp - upsdrvctl fails (Connection refused) connecting to the repeaters since upsd isn't running yet - upsd will only see the primary driver (can't connect to ... dummy-ups) but then provide a path for the repeaters which will be started by a second invocation of "upsdrvctl start" - everything is fine after that Just using "/etc/init.d/nut-server start" will fail: it will fire up the primary driver and upsd, but not the repeaters. I presume a "upsdrvctl start" (in /etc/rc.local?) will handle this. (OS is Debian Wheezy.) This is fine with me as "repeaters" were probably invented to be run on a machine different from the one running the primary driver(s), and therefore connecting to an already running upsd is the "typical use case". Thanks a lot, Charles, you saved my week! Steffen -- Steffen Grunewald, Cluster Administrator Max Planck Institute for Gravitational Physics (Albert Einstein Institute) Am Mühlenberg 1 D-14476 Potsdam-Golm Germany ~~~ Fon: +49-331-567 7274 Fax: +49-331-567 7298 Mail: steffen.grunewald(at)aei.mpg.de ~~~ _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
