<div dir="ltr"><div>Kicking the old tyre a bit once more:</div><div><br></div><div>  In my recent reading I saw "float charge", "float mode", "float voltage" etc. Maybe that is what I meant in the earlier discussion - similar concept, similar word.</div><div><br></div><div>  In case of PbAc per <a href="https://chargetek.com/basic-information.html">https://chargetek.com/basic-information.html</a> : "Float mode is where the voltage on the battery is maintained at 
approximately 2.25 volts per cell, or 13.5 volts for a 12V battery. This
 voltage will maintain the full charge condition in the battery without 
boiling our electrolyte or overcharging the battery."</div><div><br></div><div>  Likewise, <a href="https://en.wikipedia.org/wiki/Float_voltage">https://en.wikipedia.org/wiki/Float_voltage</a> and <a href="https://en.wikipedia.org/wiki/Trickle_charging">https://en.wikipedia.org/wiki/Trickle_charging</a> articles stress that "A battery under continuous float voltage charging is said to be float-charging<sup id="gmail-cite_ref-Inc.1989_3-0" class="gmail-reference"><a href="https://en.wikipedia.org/wiki/Trickle_charging#cite_note-Inc.1989-3"><span class="gmail-cite-bracket"></span></a></sup>", which is a wee bit different from what I saw in discussions about devices that "normally only charge up to a 100% level and then let their battery seep 
away until it hits a threshold (90-95%) so it is boosted back to 100% 
again".</div><div><br></div><div>  Also, for monitoring generally, there is a case of devices (especially lithium-based batteries, as I hear) that are intentionally charged to some 90-95% and avoid going to 100% due to whatever FUD or true dangers or wear-out. Windows power manager has settings/modes for that on laptops.</div><div><br></div><div>  So... I think there is a common ground of possibly different concepts here, and we somehow want to handle it, and it needs a name. So far the term used in code and variables ended up being "hover", as in e.g. `onlinedischarge_log_throttle_hovercharge` setting added to `usbhid-ups`.</div><div><br></div><div>  Is there a better (industry-standard) name that does reflect such behaviors, notably - those that we see with NUT as "DISCHRG that we should not worry about (until some point)"?</div><div>  Is "float" or "trickle" it? It's never too late to deprecate one alias in favor of another, if need be...</div><div><br></div><div>Jim</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, May 19, 2024 at 9:24 PM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</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 <<a href="mailto:jimklimov%2Bnut@gmail.com" target="_blank">jimklimov+nut@gmail.com</a>> writes:<br>
<br>
>> "battery voltage is unreasonably high" is a reasonable concept. <...> I<br>
>> would not call it HB, though because that makes it sound parallel to LB,<br>
>> which is about believed remaining capacity, not detection of overcharging<br>
>> failure.<br>
><br>
> Well, given that a "battery.charge.high" is not a name yet defined or used,<br>
> hands are untied - and it does seem like a sufficiently high-level concept<br>
> to me even if no devices would emit that information and only some users<br>
> set it for synthetic logic. Namely, I'm thinking about hover-charging which<br>
> some devices do - as noted earlier. This may become more popular with LiIon<br>
> batteries hitting the UPS market (laptops and phones already do often<br>
> hover).<br>
<br>
I would suggest deferring until there is a need and an articulated use.<br>
<br>
Hover charging is a new word for me, but I understand it to mean<br>
declining to charge a battery which is mostly charged.<br>
<br>
Part of the difficulty is this is about "state of charge" which has a<br>
messy relationship to "battery voltage".<br>
<br>
> Currently the concept in NUT was somewhat addressed by a<br>
> `onlinedischarge_log_throttle_hovercharge` setting introduced (in<br>
> <a href="https://github.com/networkupstools/nut/pull/2216" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/2216</a> and being revised now in<br>
> <a href="https://github.com/networkupstools/nut/pull/2428" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/2428</a>) with the intention to<br>
> hush log messages to the tune of "we are both online and discharging, what<br>
> is happening?"<br>
<br>
well, if that's how it is, I don't think it should be suppressed.  I<br>
find it odd though, to be discharging, vs simply saying "battery at 93%<br>
- good enough - don't fully charge it -- because it's better long term<br>
to be nice to it compared to the value of the 7% if the power fails in<br>
an hour".  But maybe I'm confused.<br>
<br>
> Telling users to configure something like a "default.battery.charge.high"<br>
> instead of that contrived name seems better streamlined and can eventually<br>
> make way into other drivers (or `main.c` core) where applicable.<br>
<br>
Configuring what, for what purpose?  If this is about setting charge<br>
thresholds, we should have a few models' interface on the table to see<br>
what's common.<br>
<br>
> It seems that we still do not fully know what a "HB High Battery" NUT flag<br>
> can mean physically, and if the few existing drivers that use it do so<br>
> consistently with *some* single definition; I looked at precedents of `git<br>
> grep -w HB` in the codebase, there are a few `setval()` hits, namely:<br>
><br>
> * adelsystem_cbi.c: "BVAL_HIALRM_I",<br>
> * al175.c: "BATTERY VOLTAGE STATUS",<br>
> * asem.c: "charge_percentage >= hb_threshold (default 75)",<br>
> * generic_modbus.c: "usually ... charging state > 85%",<br>
> * pijuice.c: "battery_charge_level > HIGH_BATTERY_THRESHOLD (macro 75)"<br>
> * similarly in hwmon_ina219.c added by PR<br>
> <a href="https://github.com/networkupstools/nut/pull/2430" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/2430</a> that started this<br>
> discussion<br>
><br>
> The first one seems to be about an alarm, the second - not sure, and the<br>
> rest are about passing a threshold with no apparent implications of what<br>
> that means and why we care. MAYBE there are further NUT clients that would<br>
> react to the flag somehow, but they are not in the core codebase.<br>
<br>
And that is two different things.  There is "battery adequately<br>
charged", where that might mean 75% or 85%.  there is an alarm condition<br>
of excess voltage which indicates a charging circuit failure.    I would<br>
not in English call a battery which is "mostly charged"  as "high".<br>
<br>
> So maybe it is better to leave "HB" be, and define another `ups.status`<br>
> flag - e.g. for this particular situation a new "HOVER" state makes sense<br>
> and is unambiguous, and easier to set/check in driver code too. If we find<br>
> ways how devices report the state directly or just as the numeric threshold<br>
> (e.g. some new USB HID or SNMP OID endpoint(s)) - pass the direct flag<br>
> value through if available; otherwise synthesize it if the device or user<br>
> provided a setting and it is under 100% -- either way, we<br>
> `getval(somename)` and go from there if not NULL.<br>
<br>
I would view HB as a bug to be fixed unless we can find that a lot of<br>
devices define that (the devices, not our drivers!).<br>
<br>
As for HOVER, not sure what that means either.  There's a binary flag<br>
"this device is known to not charge fully, and it is configured to do<br>
so".  After that, there is just<br>
<br>
   LOW BATTERY: it's so low that the UPS will not power a load for very<br>
   long (longstanding)<br>
<br>
   FULL BATTERY: the battery is either fully charged, in all senses, or<br>
   is charged enough that the hover rules say don't charge any more.<br>
<br>
and perhap FULL is split into FULL and MOSTLYFULL.<br>
<br>
> For that matter, a  name like `battery.charge.hover` might also be "less<br>
> ambiguous" than `battery.charge.high` but I'm not sure if some better<br>
> wording than just `...hover` is possible (suggestions welcome):<br>
<br>
I still find hover unclear.  We have to start with an unambiguous<br>
description of the semantics, and not hope that people will infer the<br>
same semantics from a word.<br>
<br>
> * not too long and cumbersome<br>
> * reflect that it is a lower limit/threshold/watermark of the battery<br>
> charge level, which the UPS would deflate to before it begins charging<br>
> again to reach some high watermark (maybe not 100% - and this is in fact<br>
> what `battery.charge.high` might mean more reasonably)<br>
<br>
Is that what things really do?   I have seen devices simply decline to<br>
charge above about 90%, but not discharge and recharge.<br>
<br>
I typed in hover charging to DDG and got lots of information about how<br>
to charge my hoverboard.  Then I got results about vacuums, and about EV<br>
charging in the Birmingham-Hoover metro area.<br>
<br>
So I submit that "hover charging" is not a thing worthy of us using the<br>
name.<br>
<br>
</blockquote></div>