Skip to content

Predbat disables battery discharge and reports "Hold for car" while EV is charging #4572

Description

@ward0

Background

I am using Predbat with a Huawei inverter and a ~10 kWh home battery.

I also have one EV connected to Predbat. The EV is normally charged through Home Assistant and I want to use Predbat for the energy planning.

My intended behaviour is:

PV surplus should be used for the EV whenever possible.
When there is insufficient PV, I do not want the home battery to discharge into the EV.
I am fine with the EV taking power from the grid when there is insufficient PV.
However, I would like this behaviour to be conditional on the EV SOC. For example, if the EV is below 30% SOC, I may want grid charging to continue, but above 30% I would rather wait for PV/cheap charging opportunities.
I am therefore trying to understand whether this can be configured within Predbat, rather than building all EV charging logic externally in Home Assistant.
Problem

At the moment, when the EV is charging, Predbat reports:

Info: record_status Hold for car
Info: Completed run status Hold for car

and:

Disabling battery discharge whilst car 0 is charging
Car charging from battery is off, next slot for car 0 is 08-17 18:25:00 - 08-17 18:30:00

The relevant inverter state at that moment was:

Inverter 0 SoC: 9.59kW 99%, current charge rate 4400W, current discharge rate 0W, current battery power 0W, current battery voltage 52.0V, grid power 0W, load power 2407W, PV Power 589W

So the battery was at 99% SOC, PV production was only 589 W, and the house load was 2407 W.

The EV was charging at approximately 1.43 kW according to:

Dynamic load last period 1.43kW, status low, threshold_battery 4.4kWh, threshold_car 6.0kWh

Predbat then explicitly disabled battery discharge:

Disabling battery discharge whilst car 0 is charging

followed by:

Completed run status Hold for car

The plan also says:

Your car is currently charging.
The battery is currently at 99% and is in eco mode for the next 1 and a quarter hours.
Why I am asking

I understand why Predbat prevents the battery from discharging into the EV when car_charging_from_battery is disabled.

However, in this situation I am not sure this is the behaviour I actually want.

The battery is at 99%, PV is almost gone, and the EV is charging. Instead of using the available battery energy, Predbat effectively leaves the battery idle and the EV/home load is supplied from the grid.

I would like to control this more intelligently.

For example:

Case A — EV SOC < 30%

Allow grid charging, even when there is no PV, because I consider getting the EV above 30% a priority.

Case B — EV SOC >= 30%

Prefer PV surplus. If PV is insufficient, do not discharge the home battery into the EV and potentially wait for a cheaper charging slot.

Ideally I would like Predbat to make this decision dynamically based on:

EV SOC
PV surplus
current home battery SOC
import price
possibly a minimum EV SOC
possibly a configurable EV charging price threshold
Questions
Is Hold for car expected behaviour in this situation?
Is switch.predbat_car_charging_from_battery the correct setting controlling this behaviour?
Is there a Predbat parameter that allows me to define a minimum EV SOC before grid charging is allowed?
Could this be achieved by changing the effective EV charging/import price used by Predbat?
Would something like an EV charging threshold (for example, only consider grid charging attractive below 30% EV SOC) be a better approach?
Is there an existing Predbat configuration pattern for PV-first EV charging + conditional grid charging based on EV SOC?
If Predbat is not intended to handle this logic, what is the recommended way to implement it in Home Assistant?
Home Assistant automation

If this is better handled outside Predbat, I would also appreciate an example architecture for HA.

For example, would the recommended approach be:

Predbat
↓
determines cheap charging slots
↓
binary_sensor.predbat_car_charging_slot
↓
Home Assistant automation
↓
EV charger start/stop

with additional HA conditions such as:

EV SOC < 30%
AND
PV surplus insufficient
AND
import price < X

while ensuring that the home battery is not discharged into the EV?

I am particularly interested in the recommended way to combine Predbat's charging slots with my own HA automation, rather than fighting Predbat's internal car-charging logic.

The current Predbat documentation mentions car_charging_soc, car_charging_planned, car_charging_from_battery and binary_sensor.predbat_car_charging_slot, so I would like to understand which of these should be used for this type of setup.

Activity

  1. chalfontchubby commented on Aug 18, 2026

    @chalfontchubby
    Collaborator

    I don't believe there is anything that would change the behaviour based on ev soc - that feels like it belongs in external automation since there are a lot of different preferences in this area.

    car_charging_from_battery = False would cause Hold For Car - I think the assumption there is that there is a cheap tariff for the car available using e.g. Intelligent Octopus Go - so any power the car draws is cheaper than the value of the power stored in the battery - and typically the whole house in that case gets a cheaper rate - so discharging the battery into the car is more costly than saving that charge - charging the car cheaply - and either using or exporting the house battery later when import rates are higher.

    I have a sensor setup in my configurations.yaml that decides whether to charge full power, charge on solar excess, or disable the charger - but it's based around having Octopus decide the high power charge slots, then looking at the export price I'd get from exporting solar excess - if my export rate is greater than I can charge the car for (8p/kWh) then it would be making a loss to charge the car with it. Only if the export rates are particularly low does it make sense to charge for solar excess. That decision full_power/solarexcess/off is then used in an automation to set the car charger. Something similar that looked at the car SoC.

    binary_sensor.predbat_car_charging_slot I think indicates it's a slot that predbat has selected for charging.

    I don't think (I may have missed it) you say what tariff you have for import/export or what your car charger is capable of. I'd ask Claude to help setup what you want in automations etc.

  2. gcoan commented on Aug 18, 2026

    @gcoan
    Collaborator

    @ward0 as above, what you are asking for is not capable directly with predbat, you will need to write automations to control the predbat switches to get something like the effect you want.

    Predbat controls are all covered in the car charging part of the documentation https://springfall2008.github.io/batpred/car-charging/

    Predbat aims to minimise your expenditure, so in most cases exporting all solar and charging your car on an overnight tariff is your cheapest option.

  3. ward0 commented on Aug 20, 2026

    @ward0
    Author

    @chalfontchubby @gcoan I'm Belgium based, so no Otcopus prices for me. (I use it for EV abroad charging tough 👍 )

    Also on dynamic elektric tarrif, and we have special prices when going above 2.5kWh import...

    I'm still thinking this PR #3791 (comment) would really work out for me any many non UK others.

  4. chalfontchubby commented on Aug 20, 2026

    @chalfontchubby
    Collaborator

    3791 reads like something I handle with automation quite easily, putting my charger into super eco when the export rate is lower than I will be able to charge at later, potentially triggering the car to charge as well.

    Is it targeting chargers that don't have that facility themselves?
    I don't have the power to merge patches but I'll have a look when I get a chance. Quite a few outstanding issues.

  5. chalfontchubby commented on Aug 20, 2026

    @chalfontchubby
    Collaborator

    I've commented on 3791 - suggesting you add to predbat the tools needed to allow what you want to be implemented outside of predbat in automations. We don't want to duplicate in Predbat what can be done gluing things together outside - so just add the tools (sensors) that make that possible.

    For the current issue - when car_charging_from_battery is false, you expect discharge to be disabled when the car is charging. If you want to change that - then use automations to turn on/off car_charging_from_battery. Adding the sensors as suggested in my reply to 3791 should then give you what you need.

  6. ward0 commented on Oct 1, 2026

    @ward0
    Author

    @chalfontchubby and almost a whole month has passed :(
    Love all the free work people are putting in, but many people need to maintain so many PR's in personal forks..

  7. chalfontchubby commented on Oct 1, 2026

    @chalfontchubby
    Collaborator

    There are 460 open issues and 2-3 people actually writing much code for this, very few reviewing. Only one capable of merging.

    I am not a maintainer - I'm a contributer. I cannot merge my own or anyone else's pr. I've got around 12 of my own pr I'm trying to get merged and some are more than a month old. It costs me money to request copilot reviews on tickets.

    @Springfall is the only person that can merge. Nagging me can't help.

  8. springfall2008 commented on Oct 1, 2026

    @springfall2008
    Owner

    Automated first-pass triage — this is a bot-generated review; a maintainer will look it over before any action is taken.

    Classified as question (the not a bug label already applied covers it) — no priority set. I confirmed the behaviour in the source on current main (v9.3.3, 57ec7bf):

    • Is "Hold for car" expected here? Yes. When car_charging_from_battery is off (the default) and a car is charging now, or sits inside a planned slot, Predbat disables battery discharge for the duration — pause mode on inverters with timed pause, otherwise discharge rate 0 — and reports "Hold for car". See execute.py:773 (trigger), execute.py:811 (the two log lines you quoted), execute.py:814 (status). It does not fire while the battery is force-charging or force-exporting, but with the battery at 99% in demand/eco it applies exactly as you saw.
    • Is switch.predbat_car_charging_from_battery the right setting? Yes — config.py:954, "Allow car to charge from battery", default off.
    • Minimum-EV-SOC parameter: there isn't one. I enumerated the car-charging config surface (config.py: car_charging_energy_scale, car_charging_threshold, car_charging_rate, car_charging_loss, car_charging_hold, car_energy_reported_load, car_charging_manual_soc(+_kwh), car_charging_plan_smart, car_charging_plan_max_price, car_charging_from_battery, car_charging_plan_time) — nothing gates charging on the car's SoC. The car_charging_soc/car_charging_limit entries in apps.yaml are input sensors for the car's current SoC and limit, not thresholds Predbat enforces.
    • Price threshold for EV charging: likewise none. car_charging_plan_smart / car_charging_plan_max_price shape which slots get planned; they don't condition the hold, and nothing overrides the price the plan attributes to charging the car.

    One framing that may help: the hold itself never stops the car charging from the grid — it only stops the battery feeding it. So at 99% SoC with PV gone, what you observed (battery idle, EV + house on PV-then-grid) is exactly the hold doing what it's for, and it matches your Case A already. The only piece Predbat can't do natively is your Case B: pausing the charger when EV SoC ≥ 30% and the import price is high. That is a decision about the charger, not the battery, and as @chalfontchubby and @gcoan say it belongs in external automation — e.g. an HA automation toggling switch.predbat_car_charging_from_battery on car SoC/price, and a charger start/stop automation conditioned on binary_sensor.predbat_car_charging_slot, car SoC, PV surplus and import price.

    If a SOC-conditional hold were ever wanted inside Predbat it would be a new feature, not a configuration question — the direction already agreed on this ticket (sensors that let automations do it outside) is what open PR #3791 proposes: predbat.solar_surplus_power (kW a load could take now without importing or draining the battery) plus binary_sensor.predbat_force_export_slot. Those two would support exactly your Case-B automation; the PR has been pared back to just those sensors and is awaiting maintainer review — worth subscribing to it.

    No additional files needed for this ticket.

  9. added
    BOT_TRIAGEDHas been through the triage bot
    and removed
    BOT_REVIEWTrigger an autotriage
    on Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions