Citeren Michal Soltys <sol...@ziu.info>:
Then, the other options, that is if:
- additional LB checks are to remain in main.c
- new apcsmart's "ignorelb" option to have the desired effect
- the checks are to use well known battery.{runtime,charge}.low, and
be universal at the same time
the likely options are:
- handle this at driver level - e.g. preserve the immutable flag if
already set without setting rw (if necessary, e.g. in apcsmart if
ignorelb is set), ignore polling, adjust the code so it works fine,
etc.
- go back to minbatt/mintime
- add e.g. ST_FLAG_USER_OVERRIDE which would be used for any (and
only for) override.* in ups.conf (instead of
ST_FLAG_USER_IMMUTABLE), while not being encumbered by "must not be
rw" constraint
The 1st option looks good ?
Yes. You really must handle this situation at driver level. We don't
want to get into a situation where a variable is R/W (through upsrw),
but any changes send to the UPS will not be visible because there is
an override set in ups.conf. Whether or not it is possible to grant an
override in ups.conf also depends on the UPS and therefor must be
handled by the driver. For instance, if you want to override
battery.charge.low, you must be able to ignore the low battery charge
warning from the UPS. Many models (not necessarily APC) will shut down
automatically after a low battery condition is detected, so this may
not be possible.
In the vast majority of cases, if a UPS reports either
battery.charge.low or battery.runtime.low, these will be usable for
determining when it is time to shutdown the load. If this doesn't work
reliably, chances are that the underlying mechanism of calculating
charge or runtime left is broken. There is nothing we can possibly do
with that. Also consider the possibility that problems you might be
seeing are due to glitches in the status bits. If that is the case, it
might help to only set the LB flag if it is reported three times in a
row (note that this flag will be latched immediately if the UPS is on
battery).
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
_______________________________________________
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
