Car charging

As a bare minimum, a HA-controllable smart plug with a granny charger could be used, but do consider there could be an electrical spike to the car if the smart plug is turned off when the car is charging. A proper car charger and HA integration are preferable.

You will first need to have installed the appropriate Home Assistant integration for your car charger. Details of existing Car charging configurations can be found in the Devices section.

If you have the Intelligent Octopus tariff, have completed enrollment of your car/charger to Intelligent Octopus (requires a compatible charger or car), and want to take advantage of Octopus planning your charging via the Octopus app, then Predbat will obtain the Octopus charging information through the Octopus Energy integration in Home Assistant or the Octopus direct connection. Predbat will plan your home battery charging around the Intelligent Octopus slots.

This is referred to as 'Octopus led' charging in this documentation.

Alternatively, Predbat can plan your car charging based upon your energy rates, this is known as 'Predbat led' charging'.

There are different configuration options that have to be set in Predbat depending upon whether you are using Octopus-led or Predbat-led car charging. Note that if you are on the Intelligent Octopus tariff then you can still have Predbat plan your car charging, not Octopus, in which case you need to follow the Predbat-led configuration steps.

Configure apps.yaml for your car charging

Start by configuring the car charging settings in apps.yaml with the following car-charging related configuration items:

  • num_cars should be set in apps.yaml to the number of cars you want Predbat to plan for. Set to 0 if you don't have an EV or don't want Predbat to plan for your EV charging (and the remaining car sensors in apps.yaml can safely be commented out or deleted as they won't be required).
    NB: num_cars must be set correctly regardless of whether you are using Octopus Intelligent Go to control your EV charging or Predbat to control the charging; or else Predbat could start discharging your battery when the EV is charging.

  • car_charging_exclusive should be set to true for each car in apps.yaml if you have multiple cars configured in Predbat, but only one car charger. This indicates that only one car may charge at once (the first car reporting as plugged in will be considered as charging). If you set this to false for each car then it is assumed that the cars can charge independently, and hence two or more cars could charge at once. One entry per car.

  car_charging_exclusive:
    - true
    - true

Filtering Car Charging Energy from house load

Depending upon how the CT clamps and your inverter and electric car charger have been wired, your inverter may 'see' your EV charging as being part of the house load. This means your house load is artificially raised whenever you charge your car. In this circumstance you might want to remove your electric car charging data from the historical house load data so as to not bias the calculations, otherwise you will get high battery charge levels when the car was charged previously (e.g. last week).

TIP: Check the house load being reported by your inverter when your car is charging. If it doesn't include the car charging load then there is no need to follow these steps below (and if you do, you'll artificially deflate your house load).

  • switch.predbat_car_energy_reported_load - A switch (default On) that tells Predbat whether your EV charger is on the house-load side of the CT clamp (i.e. the inverter 'sees' the car charging as part of house load).

    • On (default) - The car charger is inside the CT clamp and its energy is reported as part of the house load. Predbat will attempt to strip car charging energy from historical load data (via switch.predbat_car_charging_hold) and will prevent the battery from discharging into the car when switch.predbat_car_charging_from_battery is Off.
    • Off - The car charger is wired outside the CT clamp (e.g. directly to the grid connection). The inverter cannot see the car charging load directly. In this case Predbat will:
      • Automatically disable switch.predbat_car_charging_hold (no need to strip car data from house load, as it was never included).
      • Automatically set switch.predbat_car_charging_from_battery to On in the model (the battery cannot discharge into the car anyway as it is on a separate circuit).
      • Model that any export from the battery/PV may flow into the car rather than the grid, and so conservatively not credit that energy with export income.

  • switch.predbat_car_charging_hold - A switch that when turned On (the default) tells Predbat to remove car charging data from your historical house load so that Predbat's battery prediction plan is not distorted by previous car charging. This switch is automatically overridden to Off when switch.predbat_car_energy_reported_load is Off, since the car load is not in the house load data.

If you are getting erroneous house load predictions in your plan then check this setting and car_charging_energy or input_number.predbat_car_charging_threshold are set correctly.

If you don't have an EV then turn switch.predbat_car_charging_hold Off as Predbat will by default still consider any house load in excess of input_number.predbat_car_charging_threshold to be car charging activity and will exclude it.

  • car_charging_energy - Set in apps.yaml to point to an entity which is the daily incrementing kWh data for the car charger. This has been pre-defined as a regular expression that should auto-detect the appropriate Wallbox and Zappi car charger sensors, or edit as necessary in apps.yaml for your charger sensor.
    Note that this must be configured to point to an 'energy today' sensor in kWh not an instantaneous power sensor (in kW) from the car charger.

    IMPORTANT: Predbat will subtract all car_charging_energy from your historic house load so if car_charging_energy is not configured with the correct sensor, your car charging energy sensor does not accurately report your car charging data (e.g. it falsely reports charging data when not actually charging), or your house load sensor already excludes car charging, then this will really mess up your Predbat plan as Predbat will exclude all car_charging_energy from your load predictions and you could end up with erroneous or zero house load predictions. Do check the entity!

    NOTE: The car charging energy sensor must be a daily incrementing kWh sensor. Check the history of your sensor in Home Assistant, that it increments through the day when your car is charging, resets to zero at midnight, and does not dip down in value or reset to zero other than at midnight. Some car charger energy sensors do not behave as Predbat requires them to do; for example, they may show cumulative energy per charge, not cumulative charge energy today.
    You may need to wrap the car charger energy sensor into a daily resetting utility meter to create a sensor that increments through the day and only changes to zero at midnight.

NOTE: A charger that reports 'unavailable' or 'unknown' when the car isn't plugged in needs no special handling. Predbat skips those readings when it loads the sensor history, and does not treat them as a configuration error, so the sensor can be used exactly as it is.
Do not wrap such a sensor in a template that substitutes zero (for example | float(0)). For a daily incrementing sensor, a zero part way through the day looks exactly like the midnight reset, so Predbat starts counting the day's energy again from that point and the charging before it is counted twice.

TIP: You can also use car_charging_energy to remove other house load kWh from the data Predbat uses for the forecast, e.g. if you want to remove Mixergy hot water tank heating data from the forecast such as if you sometimes heat on gas, and sometimes electric depending upon import rates.
car_charging_energy can be set to a list of energy sensors, one per line if you have multiple EV car chargers, or want to exclude multiple loads such as heat pump load, e.g.:

  car_charging_energy:
    - 're:(sensor.myenergi_zappi_[0-9a-z]+_charge_added_session|sensor.wallbox_portal_added_energy)'
    - sensor.mixergy_ID_energy
    - sensor.ashp_energy_today

  • input_number.predbat_car_charging_energy_scale - Used to define a scaling factor (in the range of 0 to 1.0) to multiply the car_charging_energy sensor data by if required (e.g. set to 0.001 to convert Watts to kW). Default 1.0, i.e. no scaling.

  • car_charging_power - Set in apps.yaml to point to an entity giving the live charging power of your car charger (in Watts, or any unit Predbat can convert such as kW). This has been pre-defined as a regular expression that should auto-detect the appropriate Wallbox and Zappi car charger sensors, or edit as necessary in apps.yaml for your charger sensor.
    Unlike car_charging_energy this is display only - it has no effect at all on the Predbat plan. When it is set:

  • the web interface power flow diagram gains a Car showing what the charger is drawing. What the Car is drawn as being fed from follows switch.predbat_car_energy_reported_load: with it on (the default) your charger sits inside the house CT clamp, so the Car hangs off the House and its power is subtracted from the House figure to stop the car being counted twice; with it off the charger is outside the clamp and was never part of your house load, so the Car hangs off the Grid instead and the House figure is left alone

  • Predbat publishes a predbat.car_charging_power sensor (in kW) which you can graph or use in your own automations

Like car_charging_energy it can be a list of sensors, one per line per car charger, if you have more than one charger - they are added together in Predbat:

  car_charging_power:
    - sensor.zappi_charge_power
    - sensor.wallbox_charging_power

If you have multiple cars sharing one charger, then only include a single entry for the charger.

If your car charger has no live power sensor, leave car_charging_power commented out in apps.yaml; the power flow diagram then shows the same four items it always has, and no predbat.car_charging_power sensor is published.
If you use one of the supported charger integrations (Ohme, myenergi Zappi, Wallbox, GivEnergy EV charger, AlphaESS EV charger or the Predbat gateway) then this is configured automatically and you do not need an apps.yaml entry of your own.

If you do not have a suitable car charging energy kWh sensor in Home Assistant then comment the car_charging_energy line out of apps.yaml and configure input_number.predbat_car_charging_threshold

  • input_number.predbat_car_charging_threshold (default 6 = 6kW)- Sets the kW power threshold above which home consumption is assumed to be car charging and input_number.predbat_car_charging_rate (in kW) will be subtracted from the historical load data.

Used to 'detect' EV charging if you have an EV charger but it does not have an energy today sensor that you can use. If car_charging_energy is set in apps.yaml then input_number.predbat_car_charging_threshold is ignored.

If you do not have an EV charger then ensure you set switch.predbat_car_charging_hold to Off otherwise Predbat will assume any house load in excess of car_charging_threshold is EV charging and remove it from your house load predictions!

Planned Car Charging

These features allow Predbat to know when you plan to charge your car.

If you are on the Octopus Intelligent Tariff set the following entries in apps.yaml:

  • octopus_slot_low_rate - Default is true, meaning any Octopus Intelligent Slot reported will be at the lowest rate if at home. If false the existing rates only will be used which is only suitable for tariffs other than IOG.

  • octopus_slot_max - Sets the maximum number of 30-minute cheap rate slots per 24-hour period. Slots beyond this limit will use standard rates. If unset, Predbat defaults this to 12 (6 hours) automatically for tariffs that Octopus enforces the 6-hour Intelligent cap on (tariff codes containing IOG-SMB), and to 48 (disabled) for other tariffs such as the older INTELLI-VAR. Set this explicitly to override the automatic default in either direction.

If you are using Octopus-led charging with the Octopus Energy integration:

The following apps.yaml configuration items are pre-defined with regular expressions to point to appropriate sensors in the Octopus Energy integration. You should not normally need to change these if you have the Octopus Intelligent tariff:

  octopus_intelligent_slot: 're:(binary_sensor.octopus_energy([0-9a-z_]+|)_intelligent_dispatching)'
  octopus_ready_time: 're:((select|time).octopus_energy_([0-9a-z_]+|)_intelligent_target_time)'
  octopus_charge_limit: 're:(number.octopus_energy([0-9a-z_]+|)_intelligent_charge_target)'

  • octopus_intelligent_slot - Points to the Octopus Energy integration 'intelligent dispatching' sensor in the Octopus Energy integration that indicates whether you are within an Octopus Energy "smart charge" slot, and provides the list of future planned charging activity. For multiple IOG-enrolled vehicles, set this to a list with one sensor per car (see Multiple Electric Cars).

  • octopus_ready_time - Points to the Octopus Energy integration sensor that details when the car charging will be completed.
    Note: the Octopus Integration now provides Octopus Intelligent target time in two formats, either a 'select' entity or a 'time' entity. Predbat uses the time entity (time.octopus_energy_{{DEVICE_ID}}_intelligent_target_time) which is disabled by default, so you will need to enable the time entity and disable the matching select entity. For multiple IOG-enrolled vehicles, set this to a list with one sensor per car.

  • octopus_charge_limit - Points to the Octopus Energy integration sensor that provides the car charging limit you want the car to charge to. For multiple IOG-enrolled vehicles, set this to a list with one sensor per car.

If you are using Octopus-led charging with the Octopus direct connection method:

  • Predbat gets its Octopus charging slot information direct from the Octopus API, so comment out or delete octopus_intelligent_slot, octopus_ready_time and octopus_charge_limit from apps.yaml.

If you are using Predbat-led charging:

The following entries are pre-configured in the apps.yaml template:

  car_charging_planned:
    - 're:(sensor.wallbox_portal_status_description|sensor.myenergi_zappi_[0-9a-z]+_plug_status)'

  car_charging_planned_response:
    - 'yes'
    - 'on'
    - 'true'
    - 'connected'
    - 'ev connected'
    - 'charging'
    - 'paused'
    - 'waiting for car demand'
    - 'waiting for ev'
    - 'scheduled'
    - 'enabled'
    - 'latched'
    - 'locked'
    - 'plugged in'
    - 'waiting'

  #car_charging_now:
  #  - off

  # Positive responses for car_charging_now
  car_charging_now_response:
    - 'yes'
    - 'on'
    - 'true'
    - 'charging'

  • car_charging_planned - Optional, can be set to a Home Assistant sensor (e.g. from your car charger integration) which lets Predbat know the car is plugged in and planned to charge during low-rate slots. Or manually set it to 'false' to disable this feature, or 'true' to always enable it.
    The apps.yaml template supplied with Predbat comes pre-configured with a regular expression that should automatically match Zappi or Wallbox car chargers. If you have a different type of EV charger you will need to configure it manually.

  • car_charging_planned_response - An array of values for the above car_charging_planned sensor which indicate that the car is plugged in and will charge in the next low rate slot. The template apps.yaml comes with a set of pre-defined sensor values that should match most EV chargers. Customise for your car charger sensor if it sets sensor values that are not in the list.

  • car_charging_now - Optional, can be set to a Home Assistant sensor that tells Predbat the car is charging right now (e.g. from your car charger integration). This can be an on/off sensor, matched against car_charging_now_response, or - for chargers that have no "charging" sensor - a charging power sensor in W or kW, where 200W or more counts as charging (e.g. sensor.wallbox_portal_charging_power for a Wallbox).
    While it reports the car charging, Predbat holds the house battery for the car ("Hold for car") so the battery does not discharge into it, unless switch.predbat_car_charging_from_battery is On. The hold starts and stops within about 15 seconds of the sensor changing, rather than at the next 5-minute plan update. It also counts as the car being plugged in, so Predbat-led charging will plan for the car.
    car_charging_now never adds a charging slot of its own: slots come only from the Predbat car planner or from Octopus Intelligent dispatches. So it does not turn on binary_sensor.predbat_car_charging_slot, and an automation that starts the charger from that sensor cannot keep a charge going through it. With Octopus Intelligent charging a charge outside a dispatch does not get the cheap rate either.
    A car charging outside any charging slot is also modelled in the plan at input_number.predbat_car_charging_rate until the end of the current plan slot (plan_interval_minutes, 30 minutes by default), so no export is planned over it. With switch.predbat_metric_dynamic_load_adjust On its load is also taken out of the recent-load estimate, so it is not counted twice - see Dynamic Load Adjust.
    Leave it commented out if you have no sensor that reports the car actually drawing power. The Ohme (ohme_automatic), myenergi Zappi (myenergi_automatic), Wallbox (wallbox_automatic) and Predbat gateway integrations set it for you, unless you have set it yourself in apps.yaml.

  • car_charging_now_response - Set to the range of positive responses for car_charging_now to indicate that the car is charging. Useful if you have a sensor for your car charger that isn't binary. The sensor's state must match one of these exactly (ignoring case). If unset it defaults to yes, on, enable, true and charging, which covers on/off sensors and chargers whose status reads Charging, such as a myenergi Zappi's plug status. If your charger reports something else while charging, add that value here. Otherwise Predbat never sees the car charging, and with Octopus Intelligent it cancels the car's dispatches.

To make Predbat-led car charging more accurate, additionally you can configure the following items in apps.yaml:

  #car_charging_battery_size:
  #  - 75
  #car_charging_limit:
  #  - 're:number.tsunami_charge_limit'
  #car_charging_soc:
  #  - 're:sensor.tsunami_battery'
  • car_charging_battery_size - Set this value in apps.yaml to the car's battery size in kWh, as a list with one entry per car:
  car_charging_battery_size:
    - 75

Writing the number on the same line as the key (car_charging_battery_size: 75) fails Predbat's apps.yaml validation with "is not of type 'sensor'", so use the list form above. A whole number is fine - a decimal place is not required. If not set, Predbat defaults to 100.0kWh. This will be used to predict when Predbat will stop car charging.

  • car_charging_limit - You should configure this to point to a sensor that specifies the % limit the car is set to charge to. This could be a sensor on the EV charger integration or a Home Assistant helper entity you can set as you wish. If you don't specify a sensor Predbat will default to 100% - i.e. fill the car to full.

  • car_charging_soc - You should configure this to point to a sensor (on the HA integration for your EV charger) that specifies the car's current charge level expressed as a percentage - it must NOT be set to a sensor that gives the car's current kWh value as this will cause Predbat to charge the car to an incorrect level. If you don't specify a sensor, Predbat will default to 0%.

If you have multiple electric cars then car_charging_soc should be set to a list of sensors, e.g.:

  car_charging_soc:
    - 'sensor.tsunami_battery'
    - 'sensor.toyota_XXX_battery_level'

Multiple Electric Cars

Multiple cars can be planned with Predbat, in which case you should set num_cars in apps.yaml to the number of cars you want to plan.

  • car_charging_limit, car_charging_planned, car_charging_battery_size and car_charging_soc must then be a list of values (i.e. 2 entries for 2 cars)

  • Each car will have its own Home Assistant slot sensor created e.g. binary_sensor.predbat_car_charging_slot_1, SoC planning sensor e.g predbat.car_soc_1 and predbat.car_soc_best_1 for car 1

Multiple cars with Octopus Intelligent Go (IOG)

If you have two or more EVs enrolled in Octopus Intelligent Go, Predbat can track the scheduled dispatch slots for each car independently.

If you use the Octopus Direct function inside Predbat then you can set octopus_automatic to True to automatically configure IOG cars.

Otherwise if using Bottle Cap Dave's Octopus integration then set octopus_intelligent_slot, octopus_ready_time and octopus_charge_limit to lists with one entry per car in apps.yaml:

  num_cars: 2

  car_charging_exclusive:
    - True
    - True

  octopus_intelligent_slot:
    - 'binary_sensor.octopus_energy_{{DEVICE_ID_CAR1}}_intelligent_dispatching'
    - 'binary_sensor.octopus_energy_{{DEVICE_ID_CAR2}}_intelligent_dispatching'

  octopus_ready_time:
    - 'time.octopus_energy_{{DEVICE_ID_CAR1}}_intelligent_target_time'
    - 'time.octopus_energy_{{DEVICE_ID_CAR2}}_intelligent_target_time'

  octopus_charge_limit:
    - 'number.octopus_energy_{{DEVICE_ID_CAR1}}_intelligent_charge_target'
    - 'number.octopus_energy_{{DEVICE_ID_CAR2}}_intelligent_charge_target'

Replace {{DEVICE_ID_CAR1}} and {{DEVICE_ID_CAR2}} with the actual device IDs shown in your Octopus Energy integration. Each entry in the list corresponds to the matching car index (car 0, car 1, …).

Only one car on IOG? If you have num_cars: 2 but only car 0 is enrolled in Octopus Intelligent Go, you do not need to provide a list. Just keep the single-sensor config (or provide a one-entry list) and car 1 will be managed by Predbat-led charging instead:

  num_cars: 2

  # Only car 0 uses IOG - a single entry is sufficient
  octopus_intelligent_slot: 'binary_sensor.octopus_energy_{{DEVICE_ID_CAR1}}_intelligent_dispatching'
  octopus_ready_time: 'time.octopus_energy_{{DEVICE_ID_CAR1}}_intelligent_target_time'
  octopus_charge_limit: 'number.octopus_energy_{{DEVICE_ID_CAR1}}_intelligent_charge_target'

Note: The octopus_slot_max limit applies per-car, so with two cars on IOG each car is subject to its own slot-count cap.

How Predbat picks which car goes in which slot (octopus_automatic)

With octopus_automatic set to True, Predbat wires the car slots itself from the devices your Octopus account reports as live. Devices that Octopus reports as suspended are skipped, and the remaining devices are assigned to car slots in a fixed order, so the same set of cars always produces the same car indexes.

Slots are re-packed when a car goes away, so removing or suspending a car can move the cars after it up an index - for example if car 0 is removed, the car that was car 1 becomes car 0. num_cars is never reduced automatically, so the now-unused slot at the end simply falls back to Predbat-led charging. If you set per-car options in apps.yaml (car_charging_battery_size, car_charging_limit, car_charging_exclusive) or use manual SoC entry, check they still line up after adding or removing a car.

Predbat re-checks this on every device poll (roughly every 2 minutes) and re-wires the slots if the set of live, non-suspended devices changes - for example when you enrol a second EV, remove one, or suspend one car in favour of another. You do not need to restart Predbat for a change made in the Octopus app to be picked up. Each re-wire is logged as:

OctopusAPI: Live intelligent devices changed from [...] to [...], reconfiguring car slots
OctopusAPI: Car slots wired to intelligent devices [...]

To confirm which car slot is actually following IOG, look for the per-car lines from the plan cycle:

Car 0 using Octopus Intelligent, charging planned - charging limit ..., ready time ...
Car 0 using Octopus Intelligent, no charging is planned

The earlier Cars {n} charging from battery ... smart ... max_price ... line is not the IOG state. It is printed during configuration read, before any Octopus dispatch data is merged, and reports the Predbat-led car charging settings (car_charging_plan_smart, car_charging_plan_max_price). It shows those settings as configured (for example max_price: 0.0p) even when IOG is working correctly, so do not use it to diagnose IOG linkage.

An excellent worked example of setting up multiple car charging with Predbat is in the 'Show and tell' part of Predbat's GitHub.

Ohme car charger direct integration

Predbat can talk directly to the Ohme charger by configuring your Ohme account details in apps.yaml.

  ohme_login: !secret ohme_login
  ohme_password: !secret ohme_password
  ohme_automatic: true

Keep your Ohme login and password in secrets.yaml rather than in apps.yaml - see Storing secrets.

There are two separate automatic settings, so you can have Predbat plan for the car without involving Octopus Intelligent at all:

ohme_automatic registers the Ohme charger with Predbat as a car. Predbat wires num_cars, car_charging_planned (from binary_sensor.predbat_ohme_connected, on whenever a car is plugged in and still wants charge), car_charging_now (from sensor.predbat_ohme_power_watts, so the car counts as charging from 200W), car_charging_soc (from sensor.predbat_ohme_battery_percent) and car_charging_energy (see Ohme charge energy below). If you have already set car_charging_now in apps.yaml - to your car's own charging sensor, say - Predbat keeps yours. The car's battery size and target charge level are left to your existing car_charging_battery_size and car_charging_limit settings, as Ohme cannot report them.

ohme_automatic_octopus_intelligent takes the Octopus Intelligent car charging slots from Ohme rather than from Octopus Intelligent directly, by pointing octopus_intelligent_slot, octopus_ready_time and octopus_charge_limit at the Ohme entities. Left unset it is auto-detected: if ohme_automatic is on, the Octopus component reports an Intelligent tariff and the device Octopus Intelligent controls is your Ohme charger, Predbat uses the Ohme slots. Set it explicitly to override that either way - true forces it on (needed if you have no Octopus component for Predbat to detect from), false forces it off so the slots come from Octopus directly.

Which device Octopus Intelligent controls matters, because that is the device Octopus schedules the charge through:

  • Your Ohme charger - Ohme's slots are the Octopus dispatches, so Predbat takes them from Ohme.
  • Your car (a BMW, Mini or Volkswagen linked to Octopus directly, say) or another make of charger - Octopus schedules the charge through that device and the Ohme is just the socket. Predbat leaves the car slots, ready time and charge limit with the Octopus component, and does not use Ohme's schedule at all. The Ohme is still registered as the charger, so its power and energy readings are used. ohme_control is ignored here too, as Octopus is already scheduling the charge.
  • Smart charging suspended on every device in the Octopus app - Octopus is not scheduling anything, so there are no dispatches. Predbat uses Ohme's own schedule at your normal tariff rates, as described in Which car charging plan Predbat shows below.
  • No Intelligent device on the account at all - Predbat takes the slots from Ohme, as Octopus has nothing of its own to offer.

Predbat checks this every two minutes, so linking a different device to Octopus Intelligent is picked up without a restart.

  ohme_login: !secret ohme_login
  ohme_password: !secret ohme_password
  ohme_automatic: true
  ohme_automatic_octopus_intelligent: true

If you run the Octopus component as well, only one of them can own the car slot wiring. Whichever source is in use, Predbat records the owner so the other component stops re-wiring those settings - previously both could write them and the wiring would alternate as Octopus re-detected your tariff or devices.

Setting only ohme_automatic_octopus_intelligent (with no ohme_automatic) still behaves as it did before: the Intelligent slots are wired, and nothing else is.

Which car charging plan Predbat shows

With ohme_automatic on, the car charging plan in Predbat comes from whoever is starting and stopping the charger:

Setup Who schedules the car The car plan in Predbat
Octopus Intelligent tariff with the Ohme as the Intelligent device, unless you have set ohme_automatic_octopus_intelligent: false - or any setup with it set to true Octopus, through Ohme Ohme's slots, priced at the Intelligent off-peak rate
Octopus Intelligent tariff with your car (or another charger) as the Intelligent device Octopus, through that device Octopus's own dispatches, from the Octopus component
ohme_control: true Predbat Predbat's own plan, which it carries out on the charger
Neither of the above Ohme Ohme's own schedule, priced at your normal tariff rates

In the last case Predbat reads the slots of Ohme's current charge session and uses them as the car plan, so the plan matches what the charger is actually going to do. The slots add the car's load to the plan and nothing else: your import rates are not changed, and the car is costed at whatever your tariff charges at that time. If Ohme has no slots scheduled, Predbat plans no car charging. Predbat does not work out a plan of its own here, as nothing would carry it out - turn on ohme_control if you want Predbat to decide when the car charges.

Predbat re-checks which row applies every two minutes, so if you move on or off an Octopus Intelligent tariff it switches over by itself, without a restart. The tariff is read from the Octopus component, which refreshes your account details every 30 minutes. If you set ohme_automatic_octopus_intelligent to true or false yourself, that is kept whatever the tariff.

A few things to know about this mode:

  • car_charging_battery_size, car_charging_limit and the Ohme battery percentage are not used to size the charge - Ohme's schedule is trusted as it stands.
  • The energy in each slot is the charge rate Ohme reports for the slot multiplied by its length. Ohme can charge below that rate, so the planned energy can be higher than the car takes.
  • If the car is inside an Ohme slot but is not drawing power, Predbat drops the slots from the plan until it sees the car charging again (switch.predbat_octopus_intelligent_dynamic, see Checking Intelligent dispatches against the car).
  • It relies on switch.predbat_octopus_intelligent_charging being on (the default), as the slots reach the plan the same way Octopus Intelligent slots do.
  • If octopus_intelligent_slot is already set to another sensor, in apps.yaml or by the Octopus component, Predbat leaves it alone and the Ohme schedule is not used. That is what happens on an Intelligent tariff with ohme_automatic_octopus_intelligent: false: the Octopus component supplies the slots and their off-peak rate, not Ohme.

Predbat-led Ohme charging

ohme_control lets Predbat start and stop the charger itself, according to its own car charging plan:

  ohme_login: !secret ohme_login
  ohme_password: !secret ohme_password
  ohme_automatic: true
  ohme_control: true

It requires ohme_automatic (there is no plan to enforce until the car is registered) and is ignored when the Intelligent slots come from Ohme, as Octopus already schedules the charge in that case.

You must still set car_charging_battery_size and car_charging_limit yourself - Ohme cannot report either, and Predbat needs them to work out how much charge to add. Getting these right matters more than usual here: setting the charger to max charge overrides its own target percentage, so the length of Predbat's planned window is the only thing limiting the charge - the target you have set in the Ohme app will not stop it. Predbat restores that target when it releases the charger, so your normal Ohme charging is unaffected once Predbat is no longer in control.

Predbat sets the charger to max charge while a planned window is running, and pauses it the rest of the time. It re-reads the plan every minute rather than following the binary_sensor.predbat_car_charging_slot state directly, so window boundaries are acted on promptly instead of waiting for Predbat's next full update. If you change the charger in the Ohme app while Predbat is in control, Predbat notices at its next poll and puts it back.

While ohme_control is on, Predbat owns the charger. Outside a planned window it holds the charger paused, including when nothing is planned at all. Switching Predbat to read only mode is what releases it - Predbat then hands the charger back to Ohme's own smart schedule, and picks it up again when you turn read only off. A component restart deliberately does not release the charger, so restarting Predbat will not interrupt a charge in progress. If Predbat stops unexpectedly while the charger is paused, it stays paused until you turn read only on, disable ohme_control, or resume the charge in the Ohme app.

Ohme charge energy

Predbat publishes sensor.predbat_ohme_energy_today - the energy the charger has delivered to the car so far today, in kWh, resetting at midnight.

Ohme's API does not report delivered energy directly; the figure it does report is the car's own battery level, which reads zero for cars that don't report their state of charge and jumps by the whole battery content for those that do. Predbat therefore builds the sensor itself by summing the charger's power reading over time, the same approach the Home Assistant Ohme integration recommends now that its own energy sensor has been removed. The charge session is polled every two minutes, so expect an error of up to a couple of hundred Wh per charging session - fine for filtering car charging out of your house load, but not a revenue-grade meter reading.

When ohme_automatic is set to true, Predbat points car_charging_energy at this sensor automatically so that car charging hold can subtract your car charging precisely rather than falling back to the car_charging_threshold heuristic. If you already have another charger's energy sensor configured - a Zappi or Wallbox, say - Predbat leaves your setting alone and logs that it has done so.

Wallbox car charger direct integration

Predbat can talk directly to your Wallbox charger by configuring your Wallbox account details in apps.yaml:

  wallbox_username: !secret wallbox_username
  wallbox_password: !secret wallbox_password
  # Let Predbat pause and resume the charger from its own car charging plan
  #wallbox_control: True

Predbat then registers each charger on the account as a car and sets car_charging_energy, car_charging_planned, car_charging_power and car_charging_now for you. A Wallbox charger cannot report the car's state of charge, so set car_charging_soc from your car's own integration if you want Predbat to plan to a target.

See Wallbox Charger for the entities it publishes and how Predbat-led charging behaves.

If you would rather use the Home Assistant Wallbox integration, see Wallbox Pulsar.

GivEnergy Gateway OCPP EV charger

When Predbat is connected to a GivEnergy Gateway that has an OCPP EV charger attached, the charger's live state is reported to Predbat over the gateway's MQTT telemetry and exposed as Home Assistant entities.

Entities are named after the charger, using the last 6 characters of its OCPP charge point id (lower-cased) — for example a charge point id ending 3XB749 gives sensor.predbat_gateway_ev_3xb749_power. The id is used whether one charger or several are attached, so a charger keeps the same entity ids for its whole life. Below, <id> stands for that suffix; a charger that has not yet reported an id falls back to a bare ev.

  • binary_sensor.predbat_gateway_ev_<id>_connected - a charge point is connected
  • sensor.predbat_gateway_ev_<id>_status - OCPP status (e.g. Available, Charging)
  • sensor.predbat_gateway_ev_<id>_power - live charge power (W)
  • sensor.predbat_gateway_ev_<id>_session_energy - energy delivered this session (kWh)
  • sensor.predbat_gateway_ev_<id>_soc - EV battery SoC % (reported directly by the car, or estimated from session energy / configured battery size when the car does not report it)
  • sensor.predbat_gateway_ev_<id>_current_limit / sensor.predbat_gateway_ev_<id>_max_current - present and configured charge current (A)
  • sensor.predbat_gateway_ev_<id>_voltage - supply voltage (V)
  • sensor.predbat_gateway_ev_<id>_eco_mode - the charger's current EcoMode setting
  • sensor.predbat_gateway_ev_<id>_charge_rate - charge-rate capability (kW), derived from the reported current/voltage (falls back to 7.4 kW when the charger does not report its capability)

To have Predbat plan for the gateway charger as a car, enable it in apps.yaml:

  gateway_evc_automatic: true

When enabled, Predbat registers the charger as a car and maps the EV entities above onto the standard car_charging_* settings, so the normal Predbat-led car charging planning applies. The charge rate tracks the sensor.predbat_gateway_ev_<id>_charge_rate capability sensor. The car's battery size and target charge level are taken from your existing car_charging_battery_size and car_charging_limit settings (the charger cannot report them).

To also have Predbat send the plan to the charger (so the EVC charges according to Predbat's schedule), add a second flag:

  gateway_evc_automatic: true
  gateway_evc_control: true

When gateway_evc_control is enabled, Predbat checks once per minute whether the current time falls inside one of the planned car-charging windows (from binary_sensor.predbat_car_charging_slot). On each state transition it sends OCPP commands to the EVC via MQTT — SetChargingProfile (at the configured max current) followed by RemoteStartTransaction to begin a session, or RemoteStopTransaction to end one. This means the charger responds within a minute of a window boundary rather than relying on a schedule that must be reprogrammed each time the plan changes.

car_charging_now is wired to the charger's charging sensor, which is on while the car is drawing power (OCPP status Charging), so Predbat holds the house battery for the car while it charges. A car that stays connected once it is full or paused (SuspendedEV) does not hold the battery. It never adds a charging slot, so it cannot hold a session open against the window boundaries gateway_evc_control enforces.

Car Charging Planning

There are two ways that Predbat can plan the slots for charging your car:

Octopus-led charging

  • switch.predbat_octopus_intelligent_charging - Turn this Home Assistant switch to On and Predbat will plan charging around the Intelligent Octopus slots, taking it into account for battery load and generating the slot information

  • You should set the car's current SoC sensor, car_charging_soc in apps.yaml to point to a Home Assistant sensor that specifies the car's current % charge level to have accurate detection of when the car charging will be complete. This should normally be a sensor provided by your car charger. If you don't have this available for your charger then Predbat will assume the car's current charge level is 0%.

  • If you set car_charging_limit in apps.yaml then Predbat can also know if the car's limit is set lower than in Intelligent Octopus. If you don't set this Predbat will default to 100%.

  • octopus_charge_limit and octopus_ready_time in apps.yaml are pre-configured with regular expressions to point to the appropriate sensors for your EV charger in the Octopus Energy integration. These retrieve details of the charge limit and when the car will finish charging from your Octopus app settings. Again, if you are using the Octopus Energy direct method for Predbat then these configuration lines are not required and should be commented out of apps.yaml.

  • You can configure car_charging_now in apps.yaml to point to a Home Assistant sensor that indicates that the car is currently charging - an on/off sensor, or a charging power sensor. Predbat then holds the house battery for the car while it charges, and checks the car really is charging during each dispatch - see Checking Intelligent dispatches against the car. It does not add an Intelligent slot or its cheap rate for a charge the Intelligent API hasn't reported - those come only from Octopus's dispatches.

  • The switch switch.predbat_octopus_intelligent_consider_full (expert mode) (default is Off) when turned On will cause Predbat to predict when your car battery is full and assume no further charging will occur. This can be useful if Octopus does not know your car battery's state of charge but you have a sensor setup in Predbat (car_charging_soc) which does know the current charge level. Slots your car won't need are also not trusted as low rate for the house battery: Octopus only bills a slot at the low rate when the car charges in it, so once Predbat expects the car to be full, the rest of that dispatch and any later daytime slots are planned at the normal rate. The half hour in which the car is expected to finish stays low rate, as does any slot another car still needs and the overnight 23:30-05:30 rate, which is part of the tariff.

  • The switch switch.predbat_octopus_intelligent_ignore_unplugged (expert mode) (default value is Off) can be used to prevent Predbat from assuming the car will be charging or that future extra low-rate slots apply when the car is unplugged. This will only work correctly if car_charging_planned is set correctly in apps.yaml to detect your car being plugged in

  • The switch switch.predbat_octopus_intelligent_dynamic (expert mode) (default value is On) checks each dispatch against whether your car is actually charging, and cancels the car's slots and the dispatch's cheap rate when it is not - see Checking Intelligent dispatches against the car. It is independent of switch.predbat_metric_dynamic_load_adjust.

  • The switch switch.predbat_octopus_intelligent_trust_slots (expert mode) (default value is On) controls whether Predbat believes an Intelligent charging slot will happen before your car has actually been seen charging in it. When On, every slot is trusted until the car is seen not charging in one (see Checking Intelligent dispatches against the car). When Off, Intelligent slots are assumed not to happen: the car's charging is not predicted and a daytime slot's low rate is not used for the house battery, until the car is seen charging inside a slot. From then on that slot and the later ones are trusted, until the car stops charging or the slot ends, after which the next slot has to be confirmed again. The overnight 23:30-05:30 rate stays low either way, as that is part of the tariff. Whether the car is charging is judged the same way as for switch.predbat_octopus_intelligent_dynamic. With neither car_charging_now nor the car inside the CT clamp, the car's slots can never be confirmed, and Predbat logs a warning. It needs switch.predbat_octopus_intelligent_dynamic On, which does the checking; with that Off this switch has no effect and Predbat logs a warning. It only applies when switch.predbat_octopus_intelligent_charging is On, as it acts on the car plan that Octopus Intelligent charging builds. With that Off, the Intelligent dispatch rates are used as before and Predbat logs a warning.

  • Octopus often moves or withdraws a dispatch before it starts, so Predbat plans for that in its pessimistic PV10% scenario (weighted by input_number.predbat_pv_metric10_weight). In that scenario, any part of a dispatch more than 30 minutes ahead that is cheap only because of the dispatch - not the fixed 23:30-05:30 off-peak - is assumed to go away. The rest of the house then pays the peak rate for those minutes, and the battery is not held for the car, although the car's own charging is still costed at the dispatch rate so the two scenarios stay comparable. The effect is that with a low battery Predbat may top it up in the first half hour of a dispatch, which is treated as certain, so that it can carry the house through to the fixed off-peak window if the rest of the dispatch disappears. This applies whether the dispatches come from the Octopus Energy integration or from Predbat's own Octopus connection.

  • Let the Octopus app control when your car charges.

Checking Intelligent dispatches against the car

Octopus Intelligent tells Predbat when it plans to charge your car (its dispatches), and Predbat treats those times as cheap for the house battery too - it may charge the battery then, or hold it back for the car. But a dispatch does not always happen: the car may be full, asleep or unplugged, or Octopus may change its plan. Octopus may also bill a dispatch the car does not use at the full rate. switch.predbat_octopus_intelligent_dynamic (expert mode, On by default) makes Predbat check that the car really is charging during a dispatch, and stop relying on the dispatch when it is not. It only applies to Octopus Intelligent charging (switch.predbat_octopus_intelligent_charging On); slots Predbat plans itself (Predbat-led charging) are never checked.

Setting it up

Point car_charging_now in apps.yaml at a sensor that shows the car charging. If you use ohme_automatic, myenergi_automatic, wallbox_automatic or the Predbat gateway this is already done for you. It can be an on/off sensor (matched against car_charging_now_response), or a charging power sensor in W or kW, where 200W or more counts as charging - useful for chargers such as Wallbox that have no "charging" sensor:

  car_charging_now:
    - sensor.wallbox_portal_charging_power

A status sensor works too, as long as its state while charging is one of the car_charging_now_response values. For example a myenergi Zappi's plug status, from the Home Assistant myenergi integration, reads Charging, which the default list accepts:

  car_charging_now:
    - sensor.myenergi_zappi_XXXXXXXX_plug_status

If you set car_charging_now_response yourself, keep charging in it, and the values your other cars' sensors use: the one list covers every car. With myenergi_automatic, Predbat already points car_charging_now at the Zappi's charging power, so leave it unset.

If the sensor's state never matches, Predbat never sees the car charging, so it cancels every dispatch the car is in, even while the car charges.

Without car_charging_now, if your car is inside the CT clamp (switch.predbat_car_energy_reported_load On), Predbat uses the house load instead - slower and less certain, as other appliances also move it. With neither, nothing is checked.

How Predbat decides

Octopus schedules dispatches to the minute, and Predbat checks them against their real start and end times. Back-to-back dispatch slots count as one dispatch.

Evidence A "not charging" reading counts... Slots cancelled, at the earliest
car_charging_now from 3 minutes into the dispatch, while the car and charger wake up, and it must last 2 minutes 5 minutes after the dispatch starts
House load only for a 5-minute load reading taken entirely inside the dispatch, and two in a row must be too low for a car to be charging 10 minutes after the dispatch starts

The house load is too low for a car to be charging when it is under 85% of car_charging_threshold (5.1kW with the default of 6kW). Where load_power is set in apps.yaml, the live load has to be under that figure as well as the 5-minute reading: the 5-minute reading lags a car that is still ramping up, and an inverter whose data arrives late, so on its own it can read low while the car is charging at full power. A low 5-minute reading with a live load that is not low, or is unavailable, is ignored - it neither cancels the slots nor brings them back.

A reading that shows the car charging counts straight away, and an "unknown" or "unavailable" sensor is ignored rather than taken as not charging. With car_charging_now, Predbat checks the sensor every 15 seconds between plan updates, so it reacts within seconds of these times.

What happens when the car is not charging

  • That dispatch slot and every later one for the car are cancelled: Predbat no longer holds the battery for the car ("Hold for car"), no longer predicts the car's load, and no longer uses the dispatch's cheap rate for the house battery. The overnight 23:30-05:30 rate stays cheap, as that is part of the tariff.
  • If the car was seen charging earlier in the same half hour (for example it finished its planned kWh early), the house keeps the cheap rate until the end of that half hour: once a dispatch has started, Octopus bills the whole half hour off-peak. Later half hours of the dispatch lose it as above. A car_charging_now reading only counts for this from 2 minutes into the half hour, as the sensor can still show charging for a car that stopped just before it. Without car_charging_now, this needs the house load to have reached car_charging_threshold, so a cooker or hot tub alone does not count.
  • This is remembered across a Predbat restart, as is which cars are currently cancelled, so restarting part-way through a dispatch does not lose the kept half hour or briefly trust a slot the car has stopped charging in.
  • The slots come back as soon as the car starts charging again, or the dispatch ends.
  • Cancelled slots are still shown in the car column of the plan with a question mark after the kWh (e.g. 3.5?), so you can see the car's schedule even though the plan is not counting on it.
  • The log shows Octopus Intelligent: car 0 is in a dispatch but not charging, cancelling its slots, and later Octopus Intelligent: car 0 slots resumed.

For example, Octopus dispatches the car from 15:55 to 16:01 but the charger reports 0W throughout:

Time What Predbat does
15:55 The dispatch starts. Too early to judge - the car may still be waking up.
15:58 Still 0W, 3 minutes in: Predbat starts timing.
16:00 Still 0W after 2 more minutes: the slots are cancelled, the battery hold is released, and the dispatch's cheap rate is dropped.
16:01 The dispatch ends, and the car's next dispatch is trusted again as normal.

Only trusting slots once the car charges

switch.predbat_octopus_intelligent_trust_slots (expert mode, On by default) reverses this check when turned Off: Intelligent slots are assumed not to happen until the car is seen charging inside one, see below.

If nothing is ever cancelled

  • Check switch.predbat_octopus_intelligent_dynamic is On (you need expert mode to see it).
  • Check car_charging_now names a real sensor, e.g. sensor.wallbox_portal_charging_power, not a fixed value like off - or that your car is inside the CT clamp.
  • Check switch.predbat_octopus_intelligent_charging is On, so Predbat builds the car plan from the Octopus dispatches.
  • Look in the log for Octopus Intelligent: car lines. If there are none while the car sits idle in a dispatch, the check is not running. Note that the Dynamic load last period ... line is written every cycle whatever these settings are, so it does not show the check is running.

If a dispatch is cancelled while the car is charging

The log shows car 0 is in a dispatch but not charging, cancelling its slots although the car is charging. Predbat is not reading car_charging_now as charging:

  • Look at the sensor's history in Home Assistant while the car charges. If it shows a status such as Charging, check that value is in car_charging_now_response. A car_charging_now_response list you set in apps.yaml replaces the default, so it must include charging itself.
  • The log's Cars ... charging_now [False] line shows what Predbat made of the sensor each cycle.
  • A charging power sensor (200W or more counts as charging) avoids matching status text altogether.

Reading the dispatch timeline in the logs

When Octopus Intelligent charging is active Predbat writes a diagnostic line to the log each cycle showing how your dispatch slots have changed over time. It is purely informational - nothing in the plan depends on it - but it is the quickest way to see whether Octopus has moved or withdrawn a slot Predbat was relying on:

Octopus: Dispatch timeline car 0 @ 09-13 18:00:00 [-4h..+24h]: -----P--|....p.......................... soc 12.4/40.0kWh plugged

Each character covers 30 minutes, running from 4 hours in the past to 24 hours ahead, and the | marks now - so everything left of it has already happened. The characters are:

Symbol Meaning
. Nothing scheduled, at a normal (expensive) import rate
- Nothing scheduled, but this is a cheap slot - normally the overnight off-peak session
? The import rate for that block is not known yet (rates are still being fetched)
p A planned (provisional) dispatch slot
s A slot Octopus has started
c A completed slot
P S C UPPERCASE means Predbat's own plan is charging in that slot too
I Predbat plans to import here on a cheap rate, with no dispatch slot
X Predbat plans to import here at a normal rate, with no dispatch slot

The case distinction is the useful one. A lowercase p that vanishes costs nothing because Predbat was not relying on it, whereas an uppercase P that disappears before reaching the | column is a charge Predbat had committed to and will now not get - so the slots worth worrying about are the ones that shout.

X is the one to watch for. Every block where Predbat plans to import shows as exactly one of P/S/C (inside a dispatch slot), I (cheap rate, no slot) or X (normal rate, no slot). When Octopus withdraws a slot Predbat had committed to, the dispatch letter disappears but the import does not - so the stripe turns from P into I or X instead of vanishing, and an X trail means Predbat is planning to import at full price where it expected a dispatch.

The end of the line shows the car's current SoC and target, and whether the car is plugged in (plugged / unplugged, from the car_charging_planned sensor in apps.yaml). An unplugged car with planned slots is normal - Octopus still publishes the schedule - but an unplugged car is also the usual explanation for a plan that never charges.

Lines are written every 30 minutes, plus immediately whenever the timeline changes - a change-driven line is marked with a trailing *. Because every line is the same width and aligned to the same 30-minute grid, stacking them in a monospace viewer shows each dispatch drifting one column left per line, so a withdrawn slot appears as a stripe that stops before it reaches |.

Predbat-led charging

Here Predbat plans and can initiate the car charging based upon the upcoming low import rate slots

  • Ensure car_charging_limit, car_charging_soc and car_charging_planned are set correctly in apps.yaml to point to the appropriate sensors from your EV (see Car charging config in apps.yaml)

  • Check (and if necessary add) the sensor response value from the sensor configured in car_charging_planned that is returned when the car is 'plugged in and ready to charge' is in the list of car_charging_planned_response values configured in apps.yaml

  • If your car does not have a state of charge (SoC) sensor you can set switch.predbat_car_charging_manual_soc (for car 0) to On to have Predbat create input_number.predbat_car_charging_manual_soc_kwh which will hold the car's SoC in kWh.
    For multiple cars, use switch.predbat_car_charging_manual_soc_1/2/3 and input_number.predbat_car_charging_manual_soc_kwh_1/2/3 for cars 1, 2, and 3 respectively.
    You will need to manually set this to the car's current charge level before charging, Predbat will increment it during charging sessions but will not reset it automatically.
    NB: input_number.predbat_car_charging_manual_soc_kwh must be set to the current kWh value of your car battery NOT a percentage SoC figure otherwise, Predbat won't know how much energy there currently is in the battery.
    NB2: If you have car_charging_soc set and working for your car SoC sensor in apps.yaml, switch.predbat_car_charging_manual_soc must be set to Off as otherwise the car SoC sensor will be ignored

  • Ensure switch.predbat_octopus_intelligent_charging in Home Assistant is set to Off

  • Set input_number.predbat_car_charging_rate to the car's charging rate in kW per hour (e.g. 7.5 for 7.5kWh)

  • If you have more than one car then input_number.predbat_car_charging_rate_1 will be the second car etc. To set the starting values in apps.yaml instead, use either a key per car (car_charging_rate: 11.0 and car_charging_rate_1: 7.4) or one list with an entry per car (car_charging_rate: [11.0, 7.4]). As with any Predbat setting these are only the initial values, once the input_number exists in Home Assistant its value is what Predbat uses.

  • Set select.predbat_car_charging_plan_time to the time you want the car charging to be completed by

  • switch.predbat_car_charging_plan_smart (On by default) makes Predbat use the cheapest slots before the charge-by time. When disabled (turned Off) all low-rate slots will be used in time order, so the car starts charging in the first low-rate slot after it is plugged in, even when cheaper slots come later. Low-rate slots are time periods where the import rate is below the threshold determined by input_number.predbat_rate_low_threshold (expert mode). By default this threshold is calculated automatically based upon future import rates - see Battery margins and metrics options for details of configuring this threshold.

  • You can set input_number.predbat_car_charging_plan_max_price if you want to set a maximum price in pence per kWh to charge your car (e.g. 10p). If you set this to zero, this feature is disabled, and all low-rate slots will be used. This may mean you need to use expert mode and change your low-rate threshold (input_number.predbat_rate_low_threshold) to configure which slots should be considered if you have a tariff with more than 2 import rates (e.g. Flux)

  • You can set car_charging_now in apps.yaml to a sensor that reports the car charging, so Predbat holds the house battery while it charges - including a charge you start by hand. It never adds a charging slot, so it cannot keep binary_sensor.predbat_car_charging_slot (and your automation) on.

  • Predbat will set binary_sensor.predbat_car_charging_slot when it determines the car can be charged; you will need to write a Home Assistant automation based upon this sensor to control when your car charges.

A sample automation to start/stop car charging using a Zappi car charger and the MyEnergi Zappi integration is as follows, this should be adapted for your charger type and how it controls starting/stopping car charging:

alias: Car charging
description: "Start/stop car charging based upon Predbat determined slots"
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.predbat_car_charging_slot
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: binary_sensor.predbat_car_charging_slot
            state: "on"
        sequence:
          <commands to turn on your car charger, e.g.>
          - service: select.select_option
            data:
              option: Eco+
            target:
              entity_id: select.myenergi_zappi_charge_mode
      - conditions:
          - condition: state
            entity_id: binary_sensor.predbat_car_charging_slot
            state: "off"
        sequence:
          <commands to turn off your car charger, e.g.>
          - service: select.select_option
            data:
              option: Stopped
            target:
              entity_id: select.myenergi_zappi_charge_mode
mode: single

Note: Multiple cars can be planned with Predbat.

Additional Car charging configurations

  • switch.predbat_car_charging_from_battery - When set to On the car can drain the home battery, Predbat will manage the correct level of battery accordingly. When set to Off home battery discharge will be prevented when your car charges, and all load from the car and home will be from the grid. This is achieved by setting the battery discharge rate to 0 during car charging and to the maximum otherwise. The home battery can still charge from the grid/solar in either case. Only use this if Predbat knows your car charging plan, e.g. you are using Intelligent Octopus or you use the car slots in Predbat to control your car charging.

Note: If switch.predbat_car_energy_reported_load is set to Off (car outside the CT clamp), this setting has no effect as the battery cannot supply the car directly. Predbat will automatically treat the car as being supplied from the grid/export.

  • input_number.predbat_car_charging_loss gives the percentage amount of energy lost when charging the car (load in the home vs energy added to the battery). A good setting is 0.08 which is 8%.

  • switch.predbat_octopus_intelligent_dynamic (default true) - cancels an Octopus Intelligent car's slots, and the dispatch's cheap rate, while the car is inside a dispatch but not actually charging, which releases the battery hold set by switch.predbat_car_charging_from_battery - see Checking Intelligent dispatches against the car above. switch.predbat_metric_dynamic_load_adjust only adjusts the near-term load prediction from your current load; it does not affect car slots.

  • See Car charging filtering and Planned car charging for further car charging setup details.

Example EV and charger setup

Sample setup and Predbat automation to use the cheapest charging slots with no/limited Home Assistant Integration.

MG4 EV Vehicle with a Hypervolt Car Charger. There is no 3rd party integration with the MG (so no idea of the car's current SoC), and the Hypervolt car charger doesn't understand when an EV is plugged in.

Yet it can be stopped and started with a 3rd party integration.

In Home Assistant, create a helper entity (Settings / Devices & Services / Helpers) of type 'Number', check minimum value is set to 0, maximum value to 100, and under Advanced Settings, set 'Unit of Measurement' to '%':

  • Car Max Charge - input_number.car_max_charge

Create a 'Dropdown' helper entity that has two options 'true' and 'false' (in lowercase):

  • Car Charger Plugged in - input_select.car_charger_plugged_in

Within the apps.yaml configuration file specify the following configuration settings:

Find the line for car_charger_battery_size and enter the Car Battery Size in kWh:

Example

  car_charging_battery_size:
    - 61.7

Specify the Car Charging Limit to use the Car Max Charge helper entity created earlier:

  car_charging_limit:
    - 'input_number.car_max_charge'

Find car_charging_planned and replace the template Wallbox and Zappi regular expression with your new dropdown helper entity:

  car_charging_planned:
    - 'input_select.car_charger_plugged_in'

Find car_charging_planned_response and add 'true' to the list:

  car_charging_planned_response:
    - 'yes'
    - 'on'
    - 'true'

If possible, add an entity keeping track of the kWh used for car charging to car_charging_energy.

If your charging device doesn't keep track of kWh you can measure the power sent to the car charger (e.g. from the EV charger integration or an energy monitor/smart plug for the EV charger) then you can create another helper entity to convert kW power into kWh:

Create a helper entity (Settings / Devices & Services / Helpers) of type 'Integration - Riemann Sum integral':

  • Name : car_energy_used
  • Input sensor : sensor that measures power consumed by the car charger
  • Integration method : Right Riemann sum
  • Metric prefix : k (kilo)

Please look into Integration - Riemann sum integral to convert kW into kWh.

And add your custom car charging energy sensor in apps.yaml in place of the template Wallbox and Zappi regular expression:

Example

  car_charging_energy: 'sensor.car_energy_used'

car_charging_now is optional: point it at a sensor that reports the car charging for Predbat to hold the house battery while it does, or leave it commented out (hashed out) in apps.yaml:

  #car_charging_now:
  #  - off

Save the apps.yaml file and exit.

In Home Assistant, turn on the following Predbat control switches:

  • switch.predbat_car_charging_hold
  • switch.predbat_car_charging_manual_soc (for car 0, or switch.predbat_car_charging_manual_soc_1/2/3 for additional cars)
  • switch.predbat_car_charging_plan_smart

And turn off the Predbat control switch:

  • switch.predbat_octopus_intelligent_charging

HA Charging Slot Automation

In Home Assistant (Settings / Automation & Scenes), create an automation to monitor the Predbat car charging slot sensor and turn the charger on and off according to the Predbat plan (the numeric entity id's below would need replacing with the appropriate sensor name for your car charger):

alias: Car Charging Slot
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.predbat_car_charging_slot
actions:
  - if:
      - condition: state
        entity_id: binary_sensor.predbat_car_charging_slot
        state: "off"
    then:
      - type: turn_off
        entity_id: f6de2df0758744aba60f6b5f
        domain: switch
  - if:
      - condition: state
        entity_id: binary_sensor.predbat_car_charging_slot
        state: "on"
    then:
      - type: turn_on
        entity_id: f6de2df0758744aba60f6b5f
        domain: switch
mode: single

Finally, for simplicity, add the below entities to your HA Dashboard so you can set them when needed:

  • Car Max Charge - input_number.car_max_charge
  • Car Manual SoC - input_number.predbat_car_charging_manual_soc_kwh (for car 0)
  • For multiple cars, add input_number.predbat_car_charging_manual_soc_kwh_1/2/3 for cars 1/2/3
  • Car Charger Plugged in - input_select.car_charger_plugged_in

Annoyingly, you have to calculate the kWh your vehicle has in total by taking the Percentage left in the car / 100 * Total Car Battery capacity.
For example:

65/100*61.7=40.1

Enter '40.1' into 'Car Manual SoC' and '80%' into 'Car Max charge'.

Once the charger is switched to true and your Car Max charge (target SoC) % is higher than the kWh currently in the car, Predbat will plan and charge the car with the kW that are needed to reach the target SoC.

Example: Separating car charging costs for multiple cars

Predbat provides predbat.cost_today_car and predbat.cost_total_car which give the cost today and total accumulated cost for all car charging.

If you have multiple cars with a single EV charger then it's not possible to segregate the cost per car.

The following solution will accumulate individual charging costs for each car.

  • Create two helper entities of type number to collect the cost per car:
input_number.car_car1_cost_today
input_number.car_car2_cost_today
Min = 0
Max = 10000
Step = 0.01

Predbat accumulates cost in pence/cents, etc so the Max value should be big enough to hold the maximum car charging cost per day (e.g. £10/$10/€10).

  • Create an automation that triggers when predbat.cost_today_car changes value. Then, based upon which car is connected (sensor.car1_connected or sensor.car2_connected in this case), delta of predbat_cost to the appropriate car cost today sensor:
alias: Allocate EV Charging Cost
description: ""
triggers:
  - entity_id:
   - predbat.cost_today_car
 trigger: state
actions:
  - variables:
   new_cost: "{{ trigger.to_state.state | float }}"
   old_cost: "{{ trigger.from_state.state | float }}"
   delta: "{{ new_cost - old_cost }}"
  - condition: template
 value_template: "{{ delta > 0 }}"
  - choose:
   - conditions:
    - condition: template
   value_template: "{{ is_state('sensor.car1_connected', 'on') }}"
  sequence:
    - target:
     entity_id: input_number.car_car1_cost_today
   data:
     value: >
    {{ (states('input_number.car_car1_cost_today') | float) + delta
    }}
   action: input_number.set_value
   - conditions:
    - condition: template
   value_template: "{{ is_state('sensor.car2_connected', 'on') }}"
  sequence:
    - target:
     entity_id: input_number.car_car2_cost_today
   data:
     value: >
    {{ (states('input_number.car_car2_cost_today') | float) + delta
    }}
   action: input_number.set_value
mode: single
  • Finally, create an automation that will reset the cost to 0 at midnight every day:
alias: Reset Daily EV Car Costs
description: ""
triggers:
  - at: "00:00:00"
 trigger: time
actions:
  - target:
   entity_id:
  - input_number.car_car1_cost_today
  - input_number.car_car2_cost_today
 data:
   value: 0
 action: input_number.set_value
mode: single