Repository navigation
Plan does not charge battery as much as expected during cheap period, but in reality battery does fully charge #1889
Description
Describe the bug
Battery plans to charge to ~30-40% in cheap overnight period when it should be able to fully charge. Despite the plan the battery does fully charge, but it will avoid exporting any excess at the end of the day when it otherwise should.
Expected behaviour
Battery would plan to fully charge during cheap period overnight (on IOG).
Predbat version
8.11.2 (but been happening at least a week or two on different versions, since at least 8.10.2)
Environment details
GivEnergy AC coupled, 9.5kWh + 5.2kWh batteries, HomeAssistant OS on a Pi
Screenshots
If applicable, add screenshots to help explain your problem. The most useful ones can be your battery chart, the Predbat HTML plan and your current settings in HA.
Log file
predbat.log.txt
Predbat debug yaml file
predbat_debug_09_00_00.yaml.txt
Activity
ablack89 commentedon Jan 21, 2025
Issue appears to be resolved in 8.11.3
ablack89 commentedon Jan 31, 2025
Issue seems to have returned for me without having changed any configuration (now running on 8.13.1)
gcoan commentedon Jan 31, 2025
can you post your plan and debug file please to aid investigation
ablack89 commentedon Feb 1, 2025
Hi, I've attached the debug and a screenshot of the plan for tonight where it says it'll charge to 43% ( I'd expect it to be able to reach 100% in the tone it says it'll be charging).
predbat_debug_09_45_00.txt
chalfontchubby commentedon Sep 26, 2026
(Written by Claude, posted by @chalfontchubby.)
I replayed your 1 February debug file against current Predbat and found why the plan only charges to ~43%.
Cause: you have
battery_charge_power_curve: auto, and the curve Predbat learned from your history says the battery charges at only 0.34× its maximum rate at every SoC from 1% to 85% (0.25× in your 21 January file). So the plan believes your 3 kW inverter adds only about 1 kW, and can only reach ~43% in the 23:30–05:30 window, even though its target is 100%. Your real battery charges at full rate, which is why it fills up anyway, and why the plan doesn't expect the spare energy to export later.None of your other settings cause this. Predbat does want to charge fully once the curve is right.
What to do:
battery_charge_power_curve: autofromapps.yaml(or replace it with a curve you've checked) and restart Predbat.auto, check the log after a restart for the linecurve automatically computed as. A healthy curve is 1.0 (or absent) below ~85% and only tapers near full.This was filed against v8.13, and the curve learning has changed since. If you still see the plan under-charging on a current version, please attach a fresh debug file. Otherwise this can be closed.
Why the curve could have been learned wrong
The learner only looks for full-rate charging between 86% and 99% (
find_charge_curve()ininverter.py). From each starting point it walks back through history until the SoC drops below that point, then writes the measured value to every SoC in between. A missing SoC reading counts as 0%. So a single dropout or spurious 0% reading in the SoC history during a full-rate charge (GivTCP can report 0 on a failed read) writes one low value across 1–86%, which is exactly the flat block in both of your files. I can't confirm that from the debug files alone, as they don't include the raw SoC history. In v8.13 the walk also checked charge rate and battery power only at its starting minute, which made it easier to trip. Current code checks them at every minute, and averages power across each SoC step (#4552).chalfontchubby commentedon Sep 26, 2026
(Written by Claude, posted by @chalfontchubby.)
Closing this in favour of #5259, which tracks the underlying problem: a single bad SoC reading can make the auto-learned charge curve flat and low below 85%. The workaround above still applies: remove
battery_charge_power_curve: autofromapps.yaml, or restart Predbat once the bad reading has aged out of history. If the under-charging comes back on a current version, please reopen with a fresh debug file.