evcc-io
Battery Boost Limit
Describe the bug
When Battery Boost is enabled (to allow fast charging from the home battery), the system does not respect the configured minimum battery SoC limit.
I also had “Prevent discharge in fast mode and planned charging” toggled ON — but the EV continued charging from the battery even after it dropped below the configured threshold (e.g., 85%).
This appears to contradict the in-app documentation and user expectations — that SoC protection would remain active, even during fast charging.
Attached screenshots:
- Home Battery screen showing:
- Battery SoC at 58%
- Limit configured at 85%
- “Prevent discharge in fast mode…” toggle ON
- Charger Settings screen showing:
- Battery Boost enabled
Steps to reproduce
- Set the Battery-supported vehicle charging threshold to 85%.
- Toggle Prevent discharge in fast mode and planned charging to ON.
- Start a fast charge session by enabling Battery Boost.
- Observe battery SoC drop below 85%, despite protections.
✅ Expected Behavior
EV charging from the battery should stop once the SoC reaches the configured minimum (e.g., 85%), regardless of fast charge mode.
❌ Actual Behavior
EV charging continues to draw power from the battery, even when the battery drops below the configured threshold, and despite “prevent discharge” being enabled.
Configuration details
log: info #trace
network:
port: 7070
interval: 20s
mqtt:
broker: REDACTED:1883
topic: evcc
user: REDACTED
password: REDACTED
#influx:
# url: http://x.x.x.x:8086
# database: evcc_log
# token: influx_token
# org: influx_org
site:
title: Home # display name for UI
meters:
grid: my_grid
pv:
- my_pv
battery:
- my_battery
residualPower: 100
#loadpoints:
# - title: Tesla Wall Charger # display name for UI
# charger: my_charger # charger
# vehicle: tesla # default vehicle
meters:
- name: my_grid
type: custom
power:
source: mqtt
topic: dongle-REDACTED/inputbank1
jq: (-1 * .payload.Ptogrid) + .payload.Ptouser
timeout: 20s
energy:
source: mqtt
topic: dongle-REDACTED/inputbank1
jq: .payload.Einv_day
timeout: 20s
- name: my_pv
type: custom
power:
source: mqtt
topic: dongle-REDACTED/inputbank1
jq: .payload.Pall
timeout: 20s
energy:
source: mqtt
topic: dongle-REDACTED/inputbank1
jq: .payload.Epv1_day + .payload.Epv2_day + .payload.Epv3_day
timeout: 20s
- name: my_battery
type: custom
power:
source: mqtt
topic: dongle-REDACTED/inputbank1
jq: (-1 * .payload.Pcharge) + .payload.Pdischarge
timeout: 20s
soc:
source: mqtt
topic: dongle-REDACTED/inputbank1
jq: .payload.SOC
timeout: 20s
# {"setting": "DischgPowerPercentCMD", "value": 94.0, "from": "homeassistant"}
# 1: normal, 2: hold, 3: charge
batterymode:
source: mqtt
topic: dongle-REDACTED/update
payload: '{"setting": "DischgPowerPercentCMD", "value": {{ if eq .batteryMode 1 }}100{{ else }}0{{ end }}, "from": "evcc"}'
chargers:
- name: my_charger
type: template
template: twc3
host: REDACTED
vehicles:
- name: tesla
type: template
template: tesla-ble
vin: REDACTED
url: http://REDACTED
capacity: 75
messaging:
events:
start: # charge start event
title: Charge started
msg: Started charging in "${mode}" mode
stop: # charge stop event
title: Charge finished
msg: Finished charging ${chargedEnergy:%.1fk}kWh in ${chargeDuration}.
connect: # vehicle connect event
title: Car connected
msg: "Car connected at ${pvPower:%.1fk}kW PV"
disconnect: # vehicle connected event
title: Car disconnected
msg: Car disconnected after ${connectedDuration}
soc: # vehicle soc update event
title: Soc updated
msg: Battery charged to ${vehicleSoc:%.0f}%
guest: # vehicle could not be identified
title: Unknown vehicle
msg: Unknown vehicle, guest connected?
services:
- type: pushover
app: REDACTED
recipients: ["REDACTED"]
tariffs:
currency: USD
grid:
type: custom
price:
source: const
value: 0
formula: |
base := 0.09927;
if ts.Month() >= 6 && ts.Month() <= 9 {
base = 0.15828;
if ts.Hour() >= 15 && ts.Hour() < 16 {
base = 0.21022
} else if ts.Hour() >= 16 && ts.Hour() < 21 {
base = 0.32437
} else if ts.Hour() >= 21 {
base = 0.21022
}
} else if ts.Hour() >= 15 && ts.Hour() < 16 {
base = 0.11464
} else if ts.Hour() >= 16 && ts.Hour() < 21 {
base = 0.13764
} else if ts.Hour() >= 21 {
base = 0.11464
};
base
feedin:
type: fixed
price: 0.0893
solar:
- type: template
template: open-meteo
interval: 1h
lat: REDACTED
lon: -REDACTED
dec: 28
kwp: 5.6
az: -90
# efficiency: 78
- type: template
template: open-meteo
interval: 1h
lat: REDACTED
lon: -REDACTED
dec: 27
kwp: 2
az: 90
# efficiency: 78
- type: template
template: open-meteo
interval: 1h
lat: REDACTED
lon: -REDACTED
dec: 11
kwp: 3.2
az: 0
# efficiency: 78
Log details
[site ] DEBUG 2025/05/19 11:18:17 ----
[lp-1 ] DEBUG 2025/05/19 11:18:17 charge power: 7721W
[lp-1 ] DEBUG 2025/05/19 11:18:17 charge currents: [31.8 0 0]A
[site ] DEBUG 2025/05/19 11:18:17 grid power: 0W
[site ] DEBUG 2025/05/19 11:18:17 pv 1 power: 8163W
[site ] DEBUG 2025/05/19 11:18:17 battery 1 power: 307W
[site ] DEBUG 2025/05/19 11:18:17 battery 1 soc: 73%
[site ] DEBUG 2025/05/19 11:18:17 site power: 407W
[lp-1 ] DEBUG 2025/05/19 11:18:17 charge voltages: [243 0 0]V
[lp-1 ] DEBUG 2025/05/19 11:18:17 detected connected phases: 1p
[lp-1 ] DEBUG 2025/05/19 11:18:17 detected active phases: 1p
[lp-1 ] DEBUG 2025/05/19 11:18:17 charger status: C
[lp-1 ] DEBUG 2025/05/19 11:18:21 vehicle soc: 45%
[lp-1 ] DEBUG 2025/05/19 11:18:23 vehicle soc limit: 80%
[lp-1 ] DEBUG 2025/05/19 11:18:25 vehicle range: 184km
[lp-1 ] DEBUG 2025/05/19 11:18:25 pv charge battery boost: -737W = -307W battery - 330W boost
[lp-1 ] DEBUG 2025/05/19 11:18:25 pv charge current: 33.4A = 32A + 1.43A (-330W @ 1p)
[site ] DEBUG 2025/05/19 11:18:25 solar forecast: accumulated 18.933kWh, produced 15.800kWh, scale 0.835
What type of operating system or environment does evcc run on?
Linux
External automation
- [x] I have made sure that no external automation like HomeAssistant or Node-RED is active or accessing any of the mentioned devices when this issue occurs.
Nightly build
- [x] I have verified that the issue is reproducible with the latest nightly build
Version
evcc version 0.203.6
There was a quorum of users expecting boost to do so irrespective of further battery configuration. If we need both more user input is required.
/cc @naltatis
@danielraffel what you describe is expected and documented behavior.
The complete energy of the home battery will be used. The above-mentioned priority settings are overridden for this charging session.
See https://docs.evcc.io/en/docs/features/battery#battery-boost
@andig I'd suggest to think about adding an optional home battery soc limit to the boost feature.
We decided against connecting battery boost with priority/buffer-soc since the later ones are global. I still think it's a good idea to keep them separate.
Dann sollten wir das bei der Gelegenheit vllt. auch gleich aus Settings raus bewegen weil es eher eine Einmalaktion denn ein Setting ist?
Dann sollten wir das bei der Gelegenheit vllt. auch gleich aus Settings raus bewegen.
Sehe ich erst einmal unabhängig davon. Ja, mittelfristig gehört das direkt an die Ladepunkt-Kachel als eigener Button. Hier müssen wir aber noch etwas mehr Konzeptenergie reinstecken wann und wie prominent der Button überhaupt angezeigt werden soll.
I’ve found Battery Boost a bit confusing, as it has often left my home battery more depleted than I’d like.
Ideally, there would be a sub-setting under Settings > Charger > Battery Boost that allows users to define a minimum state of charge (SoC) to preserve. When enabled, this setting would let Battery Boost operate as usual—but with a safeguard that stops discharging once the battery reaches the defined threshold. A corresponding control under Home Charger to configure this minimum SoC would make the behavior more flexible for users like me who want to charge their car without ending up pulling from the grid.
In my typical use case, I’m happy to discharge the battery overnight to charge my vehicle—but only to a point. I want to start the day with a charged car and still have enough battery reserve to avoid using grid power that evening or the next morning.
In short: I’d love for Battery Boost to respect a minimum SoC setting.
I’ve included a quick mockup of what I wish existed.
1. Added "stop boost at min level":
2. Added "minimum battery level for boost":
I would not make the boost limit a global(!) setting since a) the boost feature is usually used temporarily and b) it's loadpoint dependent (multi vehicle scenarios).
The idea is to provide a limit selection in the same location you also activate/deacivate the boost.
I would not make the boost limit a global(!) setting since a) the boost feature is usually used temporarily and b) it's loadpoint dependent (multi vehicle scenarios).
The idea is to provide a limit selection in the same location you also activate/deacivate the boost.
I think that’s fair. What I’m finding is that during the summer, I’m generating so much excess solar energy that my goal is really to deplete my home battery as much as possible overnight—within reasonable limits—so that I can free it up to recharge during the day and push the energy to my car. This is especially useful when my car isn’t at home and available to charge directly from solar during the day. While it’s not the most efficient workflow, it’s actually more cost-effective than drawing from the grid. And it’s becoming a more consistent pattern than I expected. Lately, I want to do this several nights a week and almost always Fri/Sat night.
Ideally this wouldn't be static configurations but dynamic based on regular home/car consumption, solar production and battery discharge rates. But a simple static home battery setting near boost would be really nice. I'm currently enabling boost and having to remember to disable it before I go to bed so I don't end up using the grid for home consumption needs.
Dynamic would be awesome. Currently I am doing the same when going into the night. In my case I forgot it yesterday and this morning I woke up with my battery of 15kWh at 65% in the morning and the car was gone at 7h30.
It would be very nice if one could deplete the battery based on kWh, "use S amount of kWh by 7:00" or even better would be to look at projected solar generation and keep a reserve. Say: "deplete battery until time when PV is more than xxx Watt and keep Y kWh as reserve".
Say: "deplete battery until time when PV is more than xxx Watt and keep Y kWh as reserve".
How does x kWh reserve map to PV forecast?
Just to Rehash the Use Case
On high-production days (like summer), my EV is often away during the day, so I want to:
- Deplete the home battery using Battery Boost in the late afternoon/early evening by charging the car,
- Retain just enough battery to cover overnight home usage, and
- Free up capacity to capture as much of the next day's solar production rather than selling it back to the grid .
Core Goal
Allow users to shift stored solar energy from their home battery to their EV, while ensuring enough energy remains to power the home overnight—based on recent consumption patterns and upcoming solar forecasts. This isn't about maximizing energy efficiency (round-trip losses exist), but about maximizing solar utilization and cost-effectiveness.
Stab at a High-level Technical Proposal
Inspired by similar implementations like pv_opt, emhass, and solarbatteryoptimize, this approach could involve:
1. Required Inputs
- Battery SoC and capacity (e.g., 43 kWh)
- 24-hour solar forecast (e.g., 50 kWh from SolCast or similar)
- Rolling average household consumption (e.g., trailing 7-day mean of 25 kWh/day)
- Overnight consumption pattern (e.g., percentage of daily usage occurring between sunset and sunrise)
- EV parameters:
- Charging window
- EV battery capacity
- Required range/charge level
- Optional user input:
- Override minimum battery reserve percentage
- Override average household consumption estimate
- Goal preference: "Prioritize EV charging" vs. "Prioritize home reserve" (eg how aggressive not sure this is useful)
2. Battery Reserve Calculation
The system calculates the minimum battery state of charge to maintain as reserve using:
# Calculate reserve needs based on historical data
overnight_hours = hours_between_sunset_and_sunrise
overnight_percentage = historical_overnight_consumption / daily_consumption
overnight_expected_kwh = rolling_avg_daily_consumption * overnight_percentage
# Apply safety factor (configurable)
safety_factor = 1.2 # 20% buffer for unexpected usage
minimum_reserve_kwh = overnight_expected_kwh * safety_factor
# Convert to battery percentage
minimum_reserve_percentage = (minimum_reserve_kwh / battery_capacity) * 100
# Allow user override if set
if user_override_reserve_percentage:
minimum_reserve_percentage = user_override_reserve_percentage
This gives us a dynamic minimum battery level that:
- Adapts to seasonal changes in consumption patterns
- Provides a buffer for unexpected usage spikes
- Can be manually overridden by the user when needed
3. Basic Logic
# Calculate available energy for EV charging
available_energy_now = battery_soc_kwh - (battery_capacity * minimum_reserve_percentage / 100)
# Calculate tomorrow's battery space
battery_space_tomorrow = battery_capacity - (battery_soc_kwh - available_energy_now)
# Check for potential solar waste
if forecasted_solar > battery_space_tomorrow:
potential_solar_waste = forecasted_solar - battery_space_tomorrow
else:
potential_solar_waste = 0
# EV charge amount = min(available now, EV capacity, amount to avoid solar waste)
ev_charge_amount = min(
available_energy_now,
ev_capacity - ev_current_charge,
battery_capacity - minimum_reserve_kwh
)
This gives a dynamic discharge threshold based on:
- What the home will likely need overnight (the reserve percentage)
- What solar is expected to bring tomorrow
- How much battery space can be created by moving energy into the EV
4. Potential UI Suggestions
Let the user:
- View a chart of historical consumption patterns with day/night breakdown
- See the calculated minimum reserve percentage and kWh value
- Manually override the minimum reserve percentage with a slider
- Adjust aggressiveness of the strategy (slider: Home Reserve ←→ EV Priority)
- See "tomorrow's projected energy sellback if no action taken"
- Enable a "smart discharge to EV" toggle (e.g., activate from 4–9 p.m.)
- View historical accuracy of overnight usage predictions
Value This type of forecasting-based reserve logic is implemented in multiple open-source projects (e.g., emhass, pv_opt), often with:
- 24-hour PV optimization using SolCast or weather APIs,
- Manual or automated battery reserve settings (kWh or %),
- Day-ahead solar + demand modeling to shape charging/discharging profiles.``
Rolling average household consumption (e.g., trailing 7-day mean of 25 kWh/day) Overnight consumption pattern (e.g., percentage of daily usage occurring between sunset and sunrise)
We have non of that.
Tbo and without any pun intended, this feels to me like some AI-generated verbal denial of service attack. Can we please do some scope management? I have long lost track what this issue is about. Feel free to open a discussion about advanced battery depletion strategies.
Tbo and without any pun intended, this feels to me like some AI-generated verbal denial of service attack.
I put genuine thought and research into this before sharing, so I found your response unexpectedly harsh. It didn’t feel particularly fair or constructive—especially in the context of a community-driven project. I imagine there’s a kinder way to express frustration or disagreement.
Can we please do some scope management? I have long lost track what this issue is about
Here’s the core of what I’m experiencing:
I’m currently generating a lot of excess solar, but my EV isn’t home during the day to use it. I want to use battery boost in solar mode at night to charge my car—but without fully draining my battery and falling back to grid power overnight. Right now, EVCC isn’t handling this scenario. I’d love for it to:
- Enable battery boost intelligently,
- Avoid depleting my home battery entirely, and
- Ideally factor in PV forecast and average home consumption so I don’t have to micromanage it daily.
I opened this issue with a mock-up to illustrate a possible solution—specifically, setting a minimum battery threshold when battery boost is enabled. I genuinely believe that alone would address most of my concerns.
When you asked how PV forecasting might be integrated, I took time to attempt think it through and offered a suggestion in good faith. I was surprised to see that effort met with such a dismissive response. That said, I’m happy to move forward and want to express my sincere appreciation for all the time and effort you’ve invested in this fantastic project.
I imagine there’s a kinder way to express frustration or disagreement.
I can't even disagree. A simple thing that matched the requirement:
EV charging from the battery should stop once the SoC reaches the configured minimum (e.g., 85%), regardless of fast charge mode.
The idea is to provide a limit selection in the same location you also activate/deacivate the boost.
has become unintelligible (to me).
Like I said above...
I opened this issue with a mock-up to illustrate a possible solution—specifically, setting a minimum battery threshold when battery boost is enabled. I genuinely believe that alone would address most of my concerns.
I think any confusion mostly lies in my attempt to expand scope apologies for getting us off track...maybe we can move past it?
When you asked how PV forecasting might be integrated, I took time to attempt think it through and offered a suggestion in good faith. I was surprised to see that effort met with such a dismissive response. That said, I’m happy to move forward and want to express my sincere appreciation for all the time and effort you’ve invested in this fantastic project.
Do you feel you have a clear understanding of the original request and proposed solution? I’m happy to clarify or provide more detail if that would be helpful.
Do you feel you have a clear understanding of the original request and proposed solution?
Sincerely hope so. Proposed approach is in https://github.com/evcc-io/evcc/issues/21318#issuecomment-2892393973, similar to https://github.com/evcc-io/evcc/discussions/20936#discussioncomment-13077554.
That would be a great solution — adding a configurable battery boost limit, such as discharging the home battery down to a user-defined SoC (e.g., in 10% increments), would be a great enhancement. It would be especially useful in summer when the battery often stays full and only a partial discharge is needed to power the home. Thank you!!
Looking at the code, I realised we have a consistency issue with >1 loadpoints. If we limit the discharge depth, we can only do this globally. It doesn't make sense to discharge for one loadpoint to x% and for the other to y%. This begs the question if we want to discharge the battery (which could be a global option without specific loadpoints targeted, any PV mode would be active then) or charge a loadpoint (which could be a loadpoint setting as today but somehow needs to convey that the fact that the limit holds for all loadpoints that opt-in to the discharging). Not sure how to do this elegantly. Also not sure how the current "boost" the battery logic would do with multiple loadpoints. Waybe we could limit this to working for a single loadpoint only? A global action would be a no-go then. If anybody is able to test the existing boost with >1 loadpoint that would really help.
If I can be helpful testing, please let me know. Perhaps you could recommend what you want me to adjust with the configuration I attached in the original post? And, what you want me to try! One thing to note is I only have one physical charger...
Hi guys maybe you could give me an update of the current status of this feature.
When I look in the documentation (https://docs.evcc.io/docs/features/battery#batterie-boost) I see screenshots of an experimental feature, that switches a "battery boost" on/off.
In my current version (ver.0.204.2) I can't see any of the GUI-switches mentioned in the documentation.
Ist it only a feature in the nightly builds? Do I need to set any command in the yaml-file to make the gui-switches appear?
I'm grateful for any insight.
My problem is that my car can't get enough power (currently only 1.3kW) out of the home battery during night-charging and the home battery could deliver a lot more speed.
Is there any news update about the implementation for this Change Request?
If you switch on Experiment Mode in Setting you can use the battery boost switch.
If you switch on Experiment Mode in Setting you can use the battery boost switch.
This funktion is already Long Time existing - I am asking for the limit after toggling on this option. This is still not part and developed.
@undauntedjogging asking when it's ready does not accelerate and creates noise. You'll see progress here once development has started or someone else provided a PR for it. We're planning to implement it, but can't provide timelines.
It seems what "this change request" means has changed over time. Afaikt it is "add a soc limit to battery boost".
Imho we should not do that and instead keep it simple. Keeping it simple would mean to optionally allow boost to stop when pre-configured battery minimum soc has been reached (instead of adding yet another configurable value). So boost becomes "fully drain" (as today) or "drain until default limit".
Is that a consensus?
It seems what "this change request" means has changed over time. Afaikt it is "add a soc limit to battery boost".
Imho we should not do that and instead keep it simple. Keeping it simple would mean to optionally allow boost to stop when pre-configured battery minimum soc has been reached (instead of adding yet another configurable value). So boost becomes "fully drain" (as today) or "drain until default limit".
Is that a consensus?
For me, it would be fine if it could be controlled via the battery's MIN Soc (home battery configuration) and no additional button would be implemented for the charging process itself.
I think we should stick with a per-loadpoint configuration. We're planning to make the boost button directly visible in the loadpoint tile. But the feature may not relevant for every type of loadpoint (heater, some switch devices) or a user does not want to encourage bat-bat charging in general. So I think we should make the button opt-in per loadpoint. We can add a boost limit definition (0% = full drain) in the lp settings dialog for this. No selected limit, no boost button.
Keeping it simple would mean to optionally allow boost to stop when pre-configured battery minimum soc has been reached
Currently we dont have this global battery minsoc setting that aggregates across configured batteries. We would have to introduce this. If we do, would this minimum be only applicable for battery-boost or other features as well? I think its clearer to keep boost-related features (limit + activation) together if possible.
Looking at the code, I realised we have a consistency issue with >1 loadpoints. If we limit the discharge depth, we can only do this globally. It doesn't make sense to discharge for one loadpoint to x% and for the other to y%.
I don't see an issue here. Currently multiple loadpoints can have boost enabled. If LP A would have a limit of 50% and LP B of 0%, I'd expect LP A's boost feature to disable as soon as the house battery level drops below 50%. LP B continues charging. Same behavior as today when only one LP as boost enabled.