[Nut-upsdev] Question about "HB" flag and a "battery.charge.high" name

Greg Troxel gdt at lexort.com
Tue May 7 13:46:01 BST 2024


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.




More information about the Nut-upsdev mailing list