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

[Peter Selinger]

Arjen de Korte wrote:
> 
> 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.

Point taken. 
 
> > 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.

I agree. However, as far as I can see, currently *none* of the status
flags are documented, not even LB or OB.
 
> [...]
> 
> > 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).

Point taken. It would require a lot of driver support, since they may
not all implement 'shutdown.stayoff'. I am not volunteering!

-- Peter