Quick Summary (TL;DR)
The cheapest EV charge is the one that finishes before you need the car, respects your electricity contract and never overrides the charger’s electrical safety controls. For a simple fixed overnight tariff, use the supplier or charger’s native timer. For an electricity contract with variable half-hourly prices, Home Assistant can select lower-cost windows using a published price feed, a departure deadline and an energy target. Keep the car’s own schedule, charger schedule and Home Assistant from issuing contradictory commands.
Begin with a read-only schedule, then use a tested and documented charger pause/resume interface. Retain the installer’s independent load balancing, RCD/PEN-fault arrangements where applicable and the charger’s current limit. With supplier-managed smart charging, such as Intelligent Octopus Go, the supplier may need control of the charging session: do not add competing Home Assistant start/stop logic without confirming the tariff conditions.
A useful first calculation is energy still needed at the mains, not merely the vehicle’s battery percentage. An EV needing 12 kWh in its battery may require roughly 13.3 kWh at the wall at an assumed 90% charging efficiency. At 7.2 kW, allow about two hours plus a buffer, subject to the car’s onboard charger, temperature and supply limits. Price feeds, forecast slots, connected-car status and load limits must all be checked before a schedule is allowed to control a real charger.
What counts as a dynamic EV electricity tariff?
The words smart, off-peak and dynamic are not interchangeable. A contract can offer a fixed cheap night period, half-hourly prices that change daily, a supplier-generated vehicle charging plan, or wholesale-market-linked prices plus retail charges. The scheduling strategy is different in each case.
| Tariff arrangement | What changes? | Suitable scheduling method | Main trap |
|---|---|---|---|
| Fixed off-peak window | The cheap hours repeat according to the contract | Charger-native schedule, Home Assistant Schedule helper, or vehicle timer | Local clocks and British Summer Time boundaries |
| Half-hourly dynamic import price | Each published settlement interval has its own retail rate | Select eligible time slots before departure | Sorting an incomplete or stale price feed |
| Supplier-managed EV charging | Supplier schedules eligible car or charger | Give the authorised supplier control; monitor independently | Two systems repeatedly pausing each other |
| Wholesale/spot-indexed electricity | A market price changes hourly or every 15 minutes | Convert market data into the household’s actual retail marginal price | Forgetting network costs, VAT, levies and supplier margin |
| Flat-rate electricity | The import price is constant | Schedule for convenience, carbon intensity or grid limits | Paying for automation that cannot create tariff savings |
In the UK, Octopus Go is an example of a fixed overnight EV tariff, while Agile Octopus publishes time-varying half-hourly import rates. Intelligent Octopus Go provides supplier-managed smart charging for compatible equipment. Product availability, eligibility, clock windows, rates and export-tariff compatibility change: verify the currently contracted product rather than copying an example from a blog. The official documentation is linked at the end of this guide.
In continental Europe, a supplier may pass through a Nord Pool or other spot-market index, sometimes with separate per-kWh charges and taxes. Home Assistant’s built-in Nord Pool integration supplies market prices, not an all-in retail bill; it may also expose intervals of different lengths during the move from hourly to 15-minute market time units. A scheduler that silently assumes 60-minute rows can charge at the wrong price.
The hardware and data you actually need
The simplest system includes a smart meter/tariff price source, a properly installed EVSE (electric-vehicle supply equipment), a reliable way to start or defer a session, and an accurate deadline. A vehicle API is helpful but not indispensable. Home Assistant makes decisions; the EVSE and electrical installation retain the protection functions.
| Component | Minimum practical requirement | Useful upgrade | Why it matters |
|---|---|---|---|
| Electricity tariff | Confirm the actual import contract and cheap windows | Timestamped future retail price slots | Without this, the algorithm may optimise the wrong price |
| Charger | Certified, commissioned equipment with its own protection and load limit | Supported local start/pause or current-limit interface | You cannot safely automate a charger that exposes monitoring only |
| Vehicle energy need | A user-entered kWh target or time allowance | Reliable SOC and battery capacity estimate | ‘Charge until full’ is not a cost-optimised target |
| Departure time | User-selected ready-by deadline | Calendar or verified vehicle departure setting | The cheapest slot is useless after the car must leave |
| Actual grid power | Not essential to fixed tariff scheduling | Correctly measured import/export and house battery SOC | Helps avoid import peaks and solar/battery conflicts |
| Communication health | Know when data is stale or unavailable | Local API, monitoring alerts and command acknowledgement | A failed cloud request must not be mistaken for a stopped session |
| Safety fallback | A normal charger/vehicle schedule that can operate without HA | Explicit manual override and departure-ready recovery policy | Avoids an empty car after a Home Assistant restart |
For general charger selection, read our published smart EV charger comparison. If you also want solar scheduling, first establish correct metering boundaries: avoid import/export double counting.
Local control versus cloud control
Home Assistant’s OpenEVSE integration communicates over the local network and documents current adjustment and charging control. The Wallbox integration uses the MyWallbox service, has monitoring and pause/resume entities for supported setups and currently refreshes about every 90 seconds for one charger. That difference affects how rapidly a short cheap window can be used and how failures behave. Entity availability depends on hardware, firmware, permissions and the integration version, so confirm actions in Developer Tools → States and Actions before automating anything.
A charger with a built-in timer may be the better choice where the price schedule is stable. OCPP compatibility alone does not guarantee that Home Assistant can execute the exact remote-start, stop or charging-profile commands your model implements. Consult the charger and controller’s interoperability lists; do not infer control support from a marketing logo.
Convert a required battery top-up into charging slots
The planner should work in grid-side kWh, because that is what your electricity supplier bills. If a vehicle exposes a trustworthy usable-battery state of charge, estimate:
Battery energy needed (kWh) = usable battery capacity (kWh) × max(0, target SOC − present SOC) / 100
Grid energy needed (kWh) = battery energy needed / estimated AC charging efficiency
Available grid energy in a slot (kWh) = effective charging power (kW) × slot duration (h)
Use the lower of the wallbox limit, installed supply/current limit and the car’s onboard AC charging capacity. Actual delivered power may be reduced by load balancing, vehicle temperature, battery conditioning or charging taper. Treat efficiency as a measured range rather than an exact specification.
Worked example: A 60 kWh usable battery at 40% needs 20 percentage points to reach 60%. That means 12 kWh into the battery. At an illustrative 90% wall-to-battery efficiency, budget 13.33 kWh from the mains. If the charger sustainably provides 7.2 kW, the ideal wall-energy time is 13.33 / 7.2 = 1.85 hours. Four half-hour slots can deliver up to 14.4 kWh at that rate, providing some margin. A vehicle whose onboard charger is limited to 3.6 kW would instead need approximately 3.7 hours plus contingency.
| Example parameter | Value | Check before using it |
|---|---|---|
| Usable battery capacity | 60 kWh | Manufacturer’s usable, not gross, figure |
| Starting SOC | 40% | Is the reading recent? |
| Target SOC | 60% | Confirm vehicle’s recommended daily limit |
| Energy to battery | 12.00 kWh | 60 × 0.20 |
| Assumed wall-to-battery efficiency | 90% | Actual efficiency varies with current and temperature |
| Energy from grid | 13.33 kWh | 12 ÷ 0.90 |
| Sustained AC charging power | 7.2 kW | Limited by circuit, EVSE and car |
| Theoretical charging duration | 1.85 hours | Before start delay, taper and load balancing |
| Practical planning window | 2+ hours | Include a reserve chosen for the user’s reliability needs |
If SOC is unavailable, let the owner enter kWh to add and set a conservative wall-energy target. A kWh meter on the charger is better than estimating solely from elapsed time. Never assume a cloud vehicle SOC entity is fresh just because it retains its last numeric state.
Choosing the cheapest slots: a transparent calculation
Suppose you have six half-hour intervals before departure, each offering 7.2 kW of charging power. Each slot can deliver 3.6 kWh at the meter. The prices below are invented for a calculation exercise, not current supplier rates.
| Example slot | Retail import price | Energy at wall | Cost if selected |
|---|---|---|---|
| 00:00–00:30 | 13 p/kWh | 3.6 kWh | £0.468 |
| 00:30–01:00 | 6 p/kWh | 3.6 kWh | £0.216 |
| 01:00–01:30 | 9 p/kWh | 3.6 kWh | £0.324 |
| 01:30–02:00 | 17 p/kWh | 3.6 kWh | £0.612 |
| 02:00–02:30 | 22 p/kWh | 3.6 kWh | £0.792 |
| 02:30–03:00 | 12 p/kWh | 3.6 kWh | £0.432 |
To provide at least 13.33 kWh, select four intervals (up to 14.4 kWh of meter energy): 00:30, 01:00, 02:30 and 00:00, in chronological execution order. Their total indicative cost is £1.44 (3.6 × (0.06 + 0.09 + 0.12 + 0.13)). The same 14.4 kWh at a flat 25 p/kWh would cost £3.60, a difference of £2.16. This comparison assumes equal energy, equal availability and no additional tariff terms. It is not a prediction of monthly savings.
A naive script that picks only the single cheapest interval will not put enough energy in the car. Another naive script that simply picks the cheapest four intervals may fail if the vehicle needs a continuous block, the charger enforces a minimum dwell time or remote commands take too long. In those cases, evaluate contiguous windows or add a penalty for every pause/resume transition.
For partial final intervals, a controller can request a reduced charging current only if the charger and car support it and the result stays within the manufacturer’s AC-current limits. Otherwise choose one extra whole slot and allow the car’s own target to end the session.
Decision hierarchy: reliability before the absolute lowest cost
Home Assistant should make decisions in a strict order. Focusing on the cheapest spot price without the rest of the context is a good way to miss a departure or overload a service.
- Electrical safety and installer-set current limits always win. Dynamic load management must remain functional even if Home Assistant or the internet disappears.
- Vehicle readiness comes next. If insufficient eligible cheap slots remain, explicitly choose whether the car is allowed to charge at an expensive rate to meet the departure deadline.
- Tariff authority decides who is allowed to schedule. A supplier-managed charging programme must not fight independent HA or vehicle timers.
- Valid data is mandatory. Reject stale prices, unknown timezone, implausible gaps and unavailable SOC rather than sorting blank values as zero.
- Optimisation preference comes last: minimise cost, favour solar, avoid importing during battery discharge, or reduce estimated carbon intensity.
For example, a car requiring 18 kWh before 07:00, with only 12 kWh of cheap-grid capacity available, has a 6 kWh shortfall. A correct planner raises that constraint immediately: the user may approve additional peak-rate energy, reduce the target or change the departure time. It should not quietly promise that it can meet all three conditions.
Set up the price feed in Home Assistant
For a fixed off-peak tariff
The most resilient approach is often Home Assistant’s built-in Schedule helper: go to Settings → Devices & services → Helpers → Create helper → Schedule, create the contractually permitted cheap window and name it schedule.ev_cheap_hours. It becomes on during scheduled blocks and off outside them. Test time-zone and daylight-saving changes, especially around a UK clock change; the supplier’s billing intervals are authoritative.
If the tariff is supplier-managed, do not use that example as an independent start/stop controller. The supplier’s charging schedule and terms take precedence. On Intelligent Octopus Go, for instance, Octopus advises users to pause other charging schedules after connecting the eligible car or charger.
For half-hourly dynamic prices
Use a tariff-specific feed that provides each future interval’s start time, end time and the household’s actual applicable import price. Octopus’s documented REST API exposes Agile unit rates with valid_from, valid_to and VAT-inclusive fields; its examples also show why timestamps should carry explicit UTC offsets. Do not hard-code an old tariff product code into a supposedly universal integration: obtain the code for the reader’s own contract.
| Validation gate | Pass condition | If it fails |
|---|---|---|
| Contract match | Correct supplier, tariff, region and meter | Disable dynamic optimisation |
| Timestamp | Every row has unambiguous start/end with timezone | Reject schedule; do not guess local time |
| Completeness | Coverage extends to the planned departure | Use only a documented fallback |
| Price units | Confirm pence versus pounds, €/MWh versus €/kWh, VAT status | Convert and display before sorting |
| Interval length | Duration is taken from each row, not assumed | Recompute slot energy with real duration |
| Publication age | Feed updated within an appropriate window | Mark stale and alert |
| Negative rates | Handled as signed prices, with contract constraints | Do not clamp negative prices to zero |
| Price gaps/duplicates | No missing or overlapping intervals in execution horizon | Reject malformed plan |
Home Assistant’s official Nord Pool integration provides market data that may be updated hourly; it does not automatically add your retailer’s charges, VAT and network components. Treat it as one input to a derived retail price only where the supplier’s contract makes that appropriate. For more detail on forecast-based scheduling alongside prices, see our Forecast.Solar versus Solcast guide.
A working baseline: fixed-price window automation
The following Home Assistant automation is deliberately a simple baseline for a standard fixed cheap schedule. It assumes you already created schedule.ev_cheap_hours and input_boolean.ev_smart_charging_enabled, and that your tested charger integration exposes a controllable switch.ev_charging_enabled. Those identifiers are examples, not universal entities. Replace them with the actual entity and service names shown by your own supported charger; some chargers use a button, action or lock instead of a switch.
alias: EV charging - fixed cheap window (example)
mode: restart
triggers:
- trigger: state
entity_id: schedule.ev_cheap_hours
- trigger: state
entity_id: input_boolean.ev_smart_charging_enabled
- trigger: homeassistant
event: start
conditions: []
actions:
- choose:
- conditions:
- condition: state
entity_id: input_boolean.ev_smart_charging_enabled
state: "on"
- condition: state
entity_id: schedule.ev_cheap_hours
state: "on"
sequence:
- action: switch.turn_on
target:
entity_id: switch.ev_charging_enabled
default:
- action: switch.turn_off
target:
entity_id: switch.ev_charging_enabled
This example does not manage tariff subscription, vehicle readiness, cable state or supplier smart charging. It also does not acknowledge whether the EVSE obeyed a command. Do not deploy it unmodified. First test a safe, simulated switch; then verify that the charger really permits this on/off function and that its native load management continues working.
If the price is dynamic, do not replace the fixed schedule with a condition such as price < 10 and call it finished. That may charge too little energy before departure. Dynamic planning should determine an explicit permitted set of future windows, recalculate when price data changes, and verify progress against a metered energy target.
Safe dynamic planning: an auditable read-only algorithm
Before issuing charger commands, develop a dry-run planner. It can run in an AppDaemon app, pyscript, a separate local service, or a workflow whose output Home Assistant reads. The key is that the algorithm is not the protective control loop. The charger’s supported interface is the only route used for optional supervisory instructions, and it must obey independently configured limits.
# Illustrative pure-Python planning logic, NOT a direct EVSE controller.
# Input rows use timezone-aware start/end datetime values and GBP/kWh.
from datetime import datetime
from math import ceil
def select_slots(rows, required_wall_kwh, max_kw, ready_by):
eligible = []
for row in rows:
start, end = row["start"], row["end"]
if start.tzinfo is None or end.tzinfo is None:
raise ValueError("Prices require timezone-aware datetimes")
if end <= start or end > ready_by:
continue
hours = (end - start).total_seconds() / 3600
eligible.append({**row, "kwh": max_kw * hours})
# Cheapest-first is suitable only when interruption is supported.
chosen = []
remaining = required_wall_kwh
for slot in sorted(eligible, key=lambda x: (x["price_gbp_kwh"], x["start"])):
if remaining <= 0:
break
chosen.append(slot)
remaining -= slot["kwh"]
if remaining > 0:
raise ValueError("Not enough scheduled capacity before departure")
return sorted(chosen, key=lambda x: x["start"])
This is a planning sketch, not production-ready software: it assumes each slot can deliver max_kw continuously, takes whole slots, does not subtract overlaps or pre-existing sessions, does not include standby, cable detection, battery temperature, load derating, API failures or start/stop costs, and does not implement dynamic tariff fetching. Validate interval continuity and uniqueness separately. A practical implementation should add dwell constraints, charger feedback, immutable timezone-aware schedules, a metered delivered-energy target and explicit overrides.
A useful architecture is price feed → validated slot table → read-only recommended schedule → user approval/fallback policy → charger action → metered acknowledgement. The grid supply current limit remains entirely outside this supervisory chain.
What happens when the price changes, data disappears or the car wakes up late?
A dynamic price service can fail, the car may arrive later than expected, and a cheap interval can be too short for a remote API to react reliably. The safe design specifies what happens in each failure mode before automation is enabled.
| Situation | Detection | Recommended response |
|---|---|---|
| Tomorrow’s rates unpublished | Missing future slots at schedule computation | Wait for valid data; retain authorised fallback schedule |
| Partial API response | Gap or overlapping timestamps | Reject the incomplete dynamic plan |
| HA reboot mid-charge | Start trigger and real charger state disagree | Reconcile charger state and current contract authority |
| Car offline or disconnected | Charger session status not charging/connected | Don’t pretend target energy is being delivered; alert if deadline at risk |
| Cloud command delayed | No acknowledgement or energy flow change | Stop retry storms; escalate after bounded retries |
| Charger current derated | Measured kW less than plan | Recompute remaining slot capacity and deadline feasibility |
| Smart battery discharging | Import/house battery power indicates undesired flow | Apply declared battery policy; don’t bypass battery management |
| UK clock change | Interval offsets and local departure disagree | Convert to timezone-aware instants before sorting |
| Manual override requested | Owner disables smart charging | Respect override; avoid turning EVSE back on automatically |
| Supplier-managed charging active | Provider controls session or contract requires it | Observe only; do not compete for charger control |
Set a ready-by buffer appropriate to the household rather than a universal 15-minute guess. A driver who must leave at 05:00 in winter may rationally pay for higher-priced energy earlier, because reaching 100% of a price target is less important than having sufficient charge. Surface the trade-off visibly: ‘Additional 4.2 kWh needed outside the cheap window; estimated extra cost £0.73. Allow?’
How tariff optimisation interacts with solar generation and a home battery
Charging from rooftop PV can look free, but every exported kilowatt-hour may have an opportunity cost equal to the export rate you forgo. A rational scheduler compares the marginal cost of alternatives rather than declaring all solar energy worth zero. If electricity costs 7 p/kWh overnight while surplus PV could otherwise earn 15 p/kWh exported, off-peak charging may have a better pure-cash outcome than diverting that export into the car. But that depends on real export terms, eligibility, inverter flows and battery losses—not just tariff headlines.
| Decision | Economic input | Operational restriction |
|---|---|---|
| Charge from cheap grid overnight | Actual import p/kWh, EV efficiency | Supply limit and vehicle readiness |
| Charge from solar surplus | Foregone export p/kWh, forecast PV | Minimum 6 A charging current and variable sunshine |
| Charge from home battery | Stored energy cost, cycling loss, degradation | Battery reserve for backup/household needs |
| Export solar and import later | Contract’s export and import settlement rates | Some import/export product combinations are restricted |
| Delay until a negative-price event | Verified negative retail rate and sufficient future capacity | No guaranteed negative price; risk of missed departure |
For homes with PV and batteries, avoid double counting the EV as both household demand and an extra grid import in the Home Assistant Energy dashboard. A correct utility boundary meter remains the reference. A solar forecast may inform tomorrow’s plan, but the actual signed grid power should be used for near-real-time surplus control. Our metering guide explains the accounting.
Charger and tariff combinations: what to buy
If you are purchasing a wallbox primarily for tariff optimisation, rank the requirements in this order: electrical suitability and installer approval; supplier tariff eligibility; proven start/pause scheduling; local versus cloud reliability; accurate meter readings; compatibility with dynamic load balancing; and only then the appeal of dashboards or additional integrations.
| Configuration | When it makes sense | Limitations to check |
|---|---|---|
| Any compliant charger with native timer | Fixed recurring off-peak contract | Clock/DST handling, charge confirmation and manual exceptions |
| OpenEVSE with documented local interface | Enthusiast-run local automation with supported installation | Local command semantics, installer acceptance and protected current limit |
| Wallbox supported by official HA integration | Owners wanting integrated scheduling and monitoring | Cloud service availability, authorisation and polling delay |
| Supplier-approved managed charger/vehicle | Smart tariff that requires provider dispatch | Do not install conflicting independent scheduling |
| OCPP-capable charger with a tested controller | Multi-vendor site control and robust local workflows | Actual command/firmware support; version labels are insufficient |
| Vehicle-only API schedule | No controllable charger interface | Wake-up limitations, subscription/API costs and unreliable connectivity |
Do not buy a wallbox on the assumption that all models of one brand have identical APIs. Confirm the exact SKU, firmware, country variant, neutral/PEN-fault arrangements where required, network interface, user permissions and which entity can stop a charge without switching mains power. Never use a general-purpose smart plugAliExpress price to start or interrupt a high-current fixed EV charger.
Five commissioning tests before activating control
- Run the plan with no charger actions. Compare each calculated price window against the supplier’s portal, including VAT and daylight-saving offsets; record the projected energy and cost.
- Verify control mapping. Trigger the supported pause/resume command manually, read back the actual charge state, and confirm the vehicle resumes within an acceptable time. Test with the car connected and disconnected.
- Verify delivered energy. Compare wallbox kWh to a suitable electricity meterAliExpress price and record what changes when load balancing limits current below the planned figure.
- Unplug connectivity. Test loss of Home Assistant, router and tariff API in a controlled setting. The EVSE must retain protections and the driver must know the fallback charging arrangement.
- Test the deadline. Simulate late arrival, missing cheap intervals, a reduced 3.6 kW limit and manual override. Confirm the plan flags shortfalls instead of silently reporting success.
A weekly review matters because tariff changes and firmware updates can alter control behaviour. Log the requested plan, executed periods, wall energy delivered, peak-priced fallback energy, actual supplier charges, and reasons for deviations. If the measured saving is negligible and the automation frequently fails, simplify the system: a reliable fixed off-peak schedule can be better than a complex optimiser.
Common questions
Does Home Assistant automatically find the cheapest hours?
Not from the Energy dashboard alone. You need a validated price feed containing future intervals and a scheduler that respects charging energy, availability and departure time. The Energy dashboard records costs; it is not a universal EV charge optimiser.
Can I use Nord Pool spot prices to calculate my bill?
Not directly. Home Assistant’s Nord Pool integration exposes market prices without every retailer-specific fee, network charge or tax. Convert the data according to your actual contract, and account for 15-minute versus hourly slots before using it in cost calculations.
Should I leave Intelligent Octopus Go to control the charging schedule?
Generally yes when your account is enrolled in its managed service. Octopus explicitly warns customers to pause competing schedules when connecting a compatible car or charger. Use Home Assistant to monitor charging and display costs unless the supplier confirms an interoperable control arrangement.
Is a negative electricity price a guarantee that charging is profitable?
No. The applicable retail import rate, not a headline wholesale market price, determines the electricity cost. Standing charges, special contract conditions, battery wear, scheduling errors and missed departures can outweigh any negative-price opportunity.
Can I use a car API instead of a smart wallbox?
Sometimes, but confirm that the car’s integration has authorised, supported charging commands and acceptable reliability. Vehicle APIs may wake the car, be rate-limited, require paid access or change without notice. A local charger timer is often more predictable for fixed nightly windows.
What if the car is already charged enough before the selected slots finish?
Let the vehicle’s own charging target stop the session; treat the planned kWh as a maximum requirement, not a reason to exceed battery guidance. Prefer charger-meter feedback over schedule duration to determine actual energy delivery.
What is the simplest reliable setup?
For many households: a compliant 7 kW charger with independent load balancing, a tariff whose cheap times are known, a charger-native schedule, and Home Assistant used for visibility and reminders. Add dynamic slot selection only when price variability and realistic savings justify the extra failure modes.
Final recommendation
For fixed cheap hours, use the charger or tariff provider’s native scheduler and let Home Assistant monitor it. For genuine dynamic half-hourly tariffs, use Home Assistant as a cautious optimiser that plans an energy target before a departure deadline—but only through a verified charger API and with explicit fallbacks. Calculate wall energy including losses, reject stale or malformed prices, keep tariff authority clear, and never hand electrical safety to YAML. Successful automation is not the cheapest theoretical schedule: it is the lowest reasonable cost while the car is actually ready when needed.
Official documentation and further reading
- Home Assistant: Schedule integration — fixed weekly windows and transitions.
- Home Assistant: automation triggers — time patterns, state changes and restart logic.
- Home Assistant: Nord Pool integration — spot prices, limitations and interval changes.
- Home Assistant: OpenEVSE integration — local charging monitoring and controls.
- Home Assistant: Wallbox integration — cloud-dependent charger entities and data update interval.
- Octopus Energy API: tariff price endpoints — half-hourly prices with date ranges and timezone guidance.
- Octopus Go — fixed overnight EV tariff terms and eligibility.
- Intelligent Octopus Go — supplier-managed compatible EV/charger scheduling.
- esp32.co.uk: smart EV chargers for Home Assistant — equipment comparison.
- esp32.co.uk: solar import/export metering — accurate energy boundaries.
Accuracy note (October 2026): This guide uses illustrative tariffs, charger entities and costs. Suppliers, integrations and EV firmware can change. Always confirm the applicable retailer contract and your particular charger/car model before enabling control. Electrical work and charger commissioning should be performed by appropriately qualified professionals.