-
-
Notifications
You must be signed in to change notification settings - Fork 350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nutdrv_qx: init battery info always if it is known [issue #1279] #1652
Conversation
….XXX") for troubleshooting [networkupstools#1279]
…attery.voltage.low/high/nom if known always (not just if battery.charge or battery.runtime are not served) [networkupstools#1279]
…er of battery packs [networkupstools#1279]
… when guessing battery.packs count [networkupstools#1279]
…range when guessing battery.packs count [networkupstools#1279]
…t() to remain specific about the code source
…or the driver option flag [networkupstools#1279]
…(so if sscanf() somehow fails/skips, we have a non-toxic outcome)
…y.voltage" right away, if we know the batt.packs and that battery_voltage_reports_one_pack [networkupstools#1279]
In fact, the "Voltronic" driver reports |
…s_one_pack_considered every loop?
…" with qx_multiply_battvolt()
…ons since master versions moved while the PR networkupstools#1652 was queued Signed-off-by: Jim Klimov <[email protected]>
After giving it some thought, for the strange charge values like 67%-70% seen in reports for this PR and issue #1279, I think the formula in analysis above is a bit wrong, maybe:
Why should it care about On the other hand, this formula seems to be the only use of the "high" values beside setting them and checking if they are set. And a freshly charged battery that is kept freshly charged (not in ONBATT mode) quite correctly hovers at that higher voltage?.. And perhaps boosting it in this PR from 130/120th to 150/120th to match some physical meaning was a bit too naive? To reiterate, as far as the current formula in several drivers and methods goes, the reported current voltage equal to or greater than the "high" (a common occurrence per DDL dumps) means a ratio over |
…to 130/120 of the nominal (back from experimental 150/120) [networkupstools#1652] Signed-off-by: Jim Klimov <[email protected]>
Update from mailing list request for community to test this PR:
|
Signed-off-by: Jim Klimov <[email protected]>
…to 130/120 of the nominal (back from experimental 150/120) [networkupstools#1652] Signed-off-by: Jim Klimov <[email protected]> Signed-off-by: Alex W Baulé <[email protected]>
Set C variables from dstate entries separately from "guesstimating" them.
May be the answer to issue #1279
if
clause for guesstimation should move lower. Note that for battery packs guesswork, it further queriesqx_battery()
to set more voltage-related variables, so I am not sure this is okay to do in all situations (even with devices that do serve data charge/runtime properly) or if those values would confuse something. However, the blazer driver seems to not ponder about this and "just works", which is a bit encouraging... CC @aquette @clepple @zykhAlso adds some troubleshooting aid for future similar reports.