[Nut-upsdev] Re: [nut-Patches][303751] Checking UPS Temperature

[Arjen de Korte]

Peter Selinger wrote:

> One disadvantage of handling it through a script is that is will not
> be done by default. Most users probably don't know about the problem
> of burning batteries, as it is not very common. 

Whatever we do, that isn't going to change (sadly). Since we're adding a
new function (with possibly bad side effects), the default should be
'off'. Selecting the maximum temperature should be done in 'ups.conf',
since it very much depends on the environment in which the UPS is used,
there is no default. Setting it too low and you risk nuisance tripping
it (and shutting down a system, which isn't going to boot up
automatically). On the other hand, too high and you risk burning your
UPS without notification (while expecting to be warned for that). Either
way, we (as the developers) should *not* take the responsibility. It's
probably OK to nag the system administrator if the value is not set, but
that's all we can/should do.

> A potential problem with Eric Wilde's patch is that it is not general
> enough; some UPS models have an boolean OVERHEAT flag although they
> don't report the actual temperature.

Where is this flag defined? While looking for it, I found quite a number
of other flags that are not documented in 'docs/new-drivers.txt':

ACFAIL
AWAITINGPOWER
BY
CHRG (mentioned in 'docs/acpi.txt')
COMMFAULT
DEPLETED
DISCHRG (mentioned in 'docs/acpi.txt')
FAILED
HB
NOT_APPLICABLE
OVERHEAT (mentioned in 'docs/new-names.txt')
SD
TEST
TIP
UNKNOWN...
VRANGE

At the very least, flags should be documented in 'docs/new-drivers.txt',
in order to maintain consistency throughout the drivers.

[...]

> A few drivers already support the OVERHEAT flag in ups.status. (None
> seem to support ups.alarm, although this was perhaps originally
> intended for this purpose). I wonder if it would make sense to allow
> upsmon to react to the OVERHEAT flag.

Not at the moment, since that would also require a different flag to
indicate that the UPS should 'shutdown.stayoff', rather than
'shutdown.return' or 'shutdown.reboot'. This is not what we want,
because the error condition is not going to improve without manual
intervention (taking the UPS offline, replacing the batteries).

Best regards, Arjen