Nut upsdev - May 2024 - Question about "HB" flag and a "battery.charge.high" name

Hello all,

  During discussion at
https://github.com/networkupstools/nut/pull/2430#discussion_r1592317940 I
found that while `nut-names.txt` documents the `battery.charge.low` as the
"Remaining battery level when UPS switches to LB (percent)", there is
no
counterpart as `battery.charge.high`. First I thought one could be just
added... but for that matter, what could one logically mean - an overcharge
(as in, "possibly harmful to the chemistry of the cells")? Or an
euphemism(*) for being "well charged" (maybe not 100% if the device
hovers
at some 85%-95% to extend battery life)?

  (*) Recent work in usbhid-ups dealt with optional "OL+DISCHRG"
warning
throttling for known-hovering devices using a custom option; if the
"euphemism" above is ratified - it could be a more systemic setting
for
that concept and behavior.

  In the same discussion, there is a mention of the "HB" flag
(apparently
"High battery" per e.g. docs/new-drivers.txt), but there are too few
hits
in the code base to make up an opinion about its physical meaning. Does
anyone here remember the history or intent behind it?

Thanks in advance,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20240507/725bc21a/attachment.htm>

Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:
>   During discussion at
> https://github.com/networkupstools/nut/pull/2430#discussion_r1592317940 I
> found that while `nut-names.txt` documents the `battery.charge.low` as the
> "Remaining battery level when UPS switches to LB (percent)",
there is no
> counterpart as `battery.charge.high`. First I thought one could be just
> added... but for that matter, what could one logically mean - an overcharge
> (as in, "possibly harmful to the chemistry of the cells")? Or an
> euphemism(*) for being "well charged" (maybe not 100% if the
device hovers
> at some 85%-95% to extend battery life)?
I don't think we should use .high, unless a significant number of
units/protoocls issue a "battery charge is high" state with a
consistent
meaning.  So no.

If this is about having variables with thresholds that control devices
or cause synthetic setting of some variable (like turning on LB if
charge% is < battery.charge.low), then it makes sense.   If there is no
such 'binary sensor' to use HA language, then it doesn't make sense.

I personally have set up a threshold sensor in HA, intended to be
  >= 27.2 is ok, <=26.4 is alarm
so that it goes into alarm at 26.4 and recovers at 27.2.  The point is
to switch to alarm state when the UPS transfers to battery and not
return until the battery is recharged and it has been stable, to reduce
falsing.  But I don't think this concept exists within nut.
>   In the same discussion, there is a mention of the "HB" flag
(apparently
> "High battery" per e.g. docs/new-drivers.txt), but there are too
few hits
> in the code base to make up an opinion about its physical meaning. Does
> anyone here remember the history or intent behind it?
I do not, but "battery voltage is unreasonably high" is a reasonable
concept.  I would say that > 14V for a 12V system is probably fair,
although it really needs to be temperature compensated.  That's an alert
for charging system failure, though.

I would not call it HB, though because that makes it sound parallel to
LB, which is about believed remaining capacity, not detection of
overcharging failure.  It is not parallel.

the long name is

  charging system failure - overcharging

and I am reluctant to abbreviate it.