[Nut-upsdev] [nut-commits] svn commit r1043 - in trunk: . docs

[Peter Selinger]

Arjen de Korte wrote:
> 
> > FullyCharged is not precisely an "alarm", as it is not a condition to
> > be worried about. It is a kind of status. The standard actually
> > defines four related codes defined: "Charging", "Discharging",
> > "FullyCharged", and "FullyDischarged". Although some UPS simply
> > pretend to be "charging" all the time, this is often confusing to
> > users, who expect that their battery must be full at some point.
> 
> *sigh!*
> 
> People who have no clue about how batteries work, should not worry about
> this. Unfortunately, that's not under our control, so I agree we'd better
> work around these 'bugs'. :-)

Most people are not electrical engineers, but to be fair, most people
have a lot of experience using batteries. When I charge my laptop or
cell phone, then after some finite amount of time, the battery is
full, it stops charging, and I am informed of this fact. As a matter
of fact, my laptop refuses to charge if it is over 95% full, to
prevent the constant top-offs that presumably can destroy battery
life.

It is not totally unreasonable for UPS users to be concerned if their
battery shows it is "charging" throughout the lifetime of the UPS.
 
> > It would make sense to me to map all four related codes to status
> > flags. In fact, precisely one of the four should be true at any given
> > time for any given connected battery, although the standard does not
> > specify this.
> 
> I'm very reluctant to add all sorts of status flags to 'ups.status' (in
> fact, I still doubt if we should have CHRG and DISCHRG in there). Where
> would we stop? 

I think a useful condition for inclusion in ups.status is that it is a
status, and that it is somewhat standardized across UPS. I think
every UPS has some sort of indicator of whether the battery is
charging. It may or may not be used by clients. Whether the
FullyCharged and FullyDischarged flags should be included (e.g. as
FULL and EMPTY) depends on whether there are any meaningful UPS out
there who actually use these flags.

> I propose that we map 'FullyCharged=1' to '!chrg' and
> 'FullyDischarged=1' to '!dischrg'. By putting these at the end of the list
> of 'ups.status' info elements, they would clear the Charging and
> Discharging status, without setting these. So 'FullyCharged=0' would not
> mean the UPS is charging, nor would 'FullyDischarged=0' mean that it is
> discharging.

This is a possibility, and probably a good one. But the logic must go in
ups_status_set(), and not in the ups.status info elements in the
subdrivers. This is because the order of the ups.status elements does
not determine the order in which bits in the ups_status variable are
set and cleared. Information may arrive asynchronously (during an
interrupt transfer) or in random order, depending on what's included
in a long walk, quick walk, or whatever. 

This is the reason for the separation of "driver-internal" status bits
(defined in status_bit_t), vs. "NUT" status (defined in
docs/new-drivers.txt). The former should record strictly what the UPS
reports, without any interpretation. In the latter, several flags
might be combined into one. So the existing internal FULLYCHARGED and
CHRG bits should be retained with their present meaning, and should be
mapped to the NUT status CHRG. 

In addition, this allows subdrivers to collect all available
information, without worrying whether this should go in ups.status,
ups.alarm, or simply be ignored. Unknown stuff doesn't need to be
commented out. All decisions about what actually to report can be done
in ups_status_set() in a non-subdriver-specific manner. 

-- Peter