<div dir="ltr"><div>Thanks for the insights, especially these:<br></div><div><br></div><div>>
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.</div><div><br></div><div>>
"battery voltage is unreasonably high" is a reasonable concept. <...> 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.
</div><div><br></div><div>Well, given that a "battery.charge.high" is not a name yet defined or used, hands are untied - and it does seem like a sufficiently high-level concept to me even if no devices would emit that information and only some users set it for synthetic logic. Namely, I'm thinking about hover-charging which some devices do - as noted earlier. This may become more popular with LiIon batteries hitting the UPS market (laptops and phones already do often hover).</div><div><br></div><div>Currently the concept in NUT was somewhat addressed by a `onlinedischarge_log_throttle_hovercharge` setting introduced (in <a href="https://github.com/networkupstools/nut/pull/2216">https://github.com/networkupstools/nut/pull/2216</a> and being revised now in <a href="https://github.com/networkupstools/nut/pull/2428">https://github.com/networkupstools/nut/pull/2428</a>) with the intention to hush log messages to the tune of "we are both online and discharging, what is happening?"</div><div><br></div><div>Telling users to configure something like a "default.battery.charge.high" instead of that contrived name seems better streamlined and can eventually make way into other drivers (or `main.c` core) where applicable.</div><div><br></div><div>It seems that we still do not fully know what a "HB High Battery" NUT flag can mean physically, and if the few existing drivers that use it do so consistently with *some* single definition; I looked at precedents of `git grep -w HB` in the codebase, there are a few `setval()` hits, namely:<br><br>* adelsystem_cbi.c: "BVAL_HIALRM_I",</div><div>* al175.c: "BATTERY VOLTAGE STATUS",</div><div>* asem.c: "charge_percentage >= hb_threshold (default 75)",</div><div>* generic_modbus.c: "usually ... charging state > 85%",</div><div>* pijuice.c: "battery_charge_level > HIGH_BATTERY_THRESHOLD
(macro 75)" <br></div><div>* similarly in hwmon_ina219.c added by PR <a href="https://github.com/networkupstools/nut/pull/2430">https://github.com/networkupstools/nut/pull/2430</a> that started this discussion<br></div><div><br></div><div>The first one seems to be about an alarm, the second - not sure, and the rest are about passing a threshold with no apparent implications of what that means and why we care. MAYBE there are further NUT clients that would react to the flag somehow, but they are not in the core codebase.<br></div><div><br></div><div>
So maybe it is better to leave "HB" be, and define another `ups.status`
flag - e.g. for this particular situation a new "HOVER" state makes
sense and is unambiguous, and easier to set/check in driver code too. If we find ways how devices report the state directly or just as the numeric threshold (e.g. some new USB HID or SNMP OID endpoint(s)) - pass the direct flag value through if available; otherwise synthesize it if the device or user provided a setting and it is under 100% -- either way, we `getval(somename)` and go from there if not NULL.<br></div><div><br></div><div>For that matter, a name like `battery.charge.hover` might also be "less ambiguous" than
`battery.charge.high`
but I'm not sure if some better wording than just `...hover` is possible (suggestions welcome):</div><div><br></div><div>* not too long and cumbersome</div><div>* reflect that it is a lower limit/threshold/watermark
of the battery charge level, which the UPS would deflate to before it begins charging again to reach some high watermark (maybe not 100% - and this is in fact what
`battery.charge.high`
might mean more reasonably)<br></div><div><br></div><div>I guess I'll hold off on any decisions and activity here until summer, to allow some time for community discussion and decision :)<br></div><div><br></div><div>Further insights welcome,<br></div><div>Jim Klimov</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 7, 2024 at 2:46 PM Greg Troxel via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net">nut-upsdev@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jim Klimov via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net" target="_blank">nut-upsdev@alioth-lists.debian.net</a>> writes:<br>
<br>
> During discussion at<br>
> <a href="https://github.com/networkupstools/nut/pull/2430#discussion_r1592317940" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/2430#discussion_r1592317940</a> I<br>
> found that while `nut-names.txt` documents the `battery.charge.low` as the<br>
> "Remaining battery level when UPS switches to LB (percent)", there is no<br>
> counterpart as `battery.charge.high`. First I thought one could be just<br>
> added... but for that matter, what could one logically mean - an overcharge<br>
> (as in, "possibly harmful to the chemistry of the cells")? Or an<br>
> euphemism(*) for being "well charged" (maybe not 100% if the device hovers<br>
> at some 85%-95% to extend battery life)?<br>
<br>
I don't think we should use .high, unless a significant number of<br>
units/protoocls issue a "battery charge is high" state with a consistent<br>
meaning. So no.<br>
<br>
If this is about having variables with thresholds that control devices<br>
or cause synthetic setting of some variable (like turning on LB if<br>
charge% is < battery.charge.low), then it makes sense. If there is no<br>
such 'binary sensor' to use HA language, then it doesn't make sense.<br>
<br>
I personally have set up a threshold sensor in HA, intended to be<br>
>= 27.2 is ok, <=26.4 is alarm<br>
so that it goes into alarm at 26.4 and recovers at 27.2. The point is<br>
to switch to alarm state when the UPS transfers to battery and not<br>
return until the battery is recharged and it has been stable, to reduce<br>
falsing. But I don't think this concept exists within nut.<br>
<br>
> In the same discussion, there is a mention of the "HB" flag (apparently<br>
> "High battery" per e.g. docs/new-drivers.txt), but there are too few hits<br>
> in the code base to make up an opinion about its physical meaning. Does<br>
> anyone here remember the history or intent behind it?<br>
<br>
I do not, but "battery voltage is unreasonably high" is a reasonable<br>
concept. I would say that > 14V for a 12V system is probably fair,<br>
although it really needs to be temperature compensated. That's an alert<br>
for charging system failure, though.<br>
<br>
I would not call it HB, though because that makes it sound parallel to<br>
LB, which is about believed remaining capacity, not detection of<br>
overcharging failure. It is not parallel.<br>
<br>
the long name is<br>
<br>
charging system failure - overcharging<br>
<br>
and I am reluctant to abbreviate it.<br>
<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>