Quick Summary (TL;DR)
Give one system authority to schedule EV charging. For a simple overnight price window, the charger’s built-in timer is usually the most dependable choice. For truly variable electricity prices, solar generation, battery priorities or two EVs sharing a supply, Home Assistant can be a useful supervisory scheduler—provided the charger offers a tested command interface and a reliable fallback. If a tariff supplier controls charging, follow its eligibility and scheduling rules rather than competing with it.
Do not confuse scheduling with electrical protection. An EV charger’s installer-configured current limit, residual-current/PEN fault arrangements where required, and independent dynamic load management must continue working even if Home Assistant, Wi-Fi or the internet fails. A Home Assistant schedule is a convenience and energy-optimisation layer, not a safety-rated load limiter.
A workable default: charger handles safety and reliable baseline charging; Home Assistant monitors power, tariffs and readiness. Enable its optional start/stop control only after testing conflicts, cloud failures, clock changes, cold reboots and departure deadlines. Keep a clearly documented manual override.
What does “in charge” actually mean?
Scheduling sounds like a single setting, but an EV can be controlled by several separate systems: the vehicle’s built-in timer, its mobile app, the wallbox’s schedule, the wallbox’s solar or load-management mode, Home Assistant automations, and the energy supplier’s demand-response service. Each may be able to request a start, stop, current change or charging target. The final outcome is not necessarily the last button pressed: devices can re-apply saved timers, a charge session may require authorisation, and a cloud API can deliver a command later than expected.
A control plan needs a hierarchy. At the bottom sit mandatory protection and the installer-established maximum current. Above these are the charger and vehicle’s operational restrictions. Above those is one designated scheduling owner. Monitoring, reporting and notifications can be shared without creating a conflicting second owner. The owner should also have a tested manual override and a clear rule for when an automation becomes unavailable.
| Function | Usually belongs to | Reason |
|---|---|---|
| Circuit protection, contactor, earthing/PEN protection as applicable | Certified hardware and installation | Must not depend on a home automation server |
| Maximum site/phase current and mandatory load shedding | Charger or supported independent load controller | Requires predictable response and installer commissioning |
| Vehicle battery charge ceiling | Vehicle/BMS | Car knows its battery and charging limits |
| Simple recurring overnight window | Native charger or vehicle schedule | Continues without a third-party automation hub if locally stored |
| Half-hourly price optimisation | Supplier-managed system or Home Assistant, not both | Needs tariff data and a single accountable scheduler |
| Solar/battery-aware discretionary charging | Dedicated charger EMS or tested Home Assistant supervisory control | Depends on measured grid flow and chosen battery priority |
| Dashboards, audit trail, notifications | Home Assistant | Read-only reporting is low-conflict |
Decision rule: choose the least complicated scheduler that delivers the features you actually need. More integrations and automations do not automatically mean lower bills.
Native EV charger scheduling: the case for simplicity
A wallbox’s native schedule is commonly configured through its app, but whether the schedule itself is stored and executed locally is product- and firmware-specific. Do not assume a mobile app means the wallbox will continue obeying the schedule without internet. Conversely, do not assume it will stop charging when the internet drops. Verify the manual and perform a disconnected test. Some devices continue previously stored programmes; others depend on cloud connectivity for a particular smart feature.
Native charging control has three strengths. First, it has fewer moving parts once configured: a home server does not need to wake, query tariff data, authenticate and send a remote command. Second, charger vendors can coordinate their own contactor, solar mode, load balancing and schedule states. Third, household members normally understand the charger app and the physical override better than a bespoke Home Assistant dashboard.
But the native timer can be limited. An inexpensive unit may offer only start/end clock times rather than the day’s cheapest half-hours. An app may not let you specify a deadline, minimum energy and an export-aware battery priority. Some charging programmes require the vendor’s cloud, another energy meterAliExpress price or a subscription. Check features for the exact hardware version and country rather than a brand’s broad marketing page.
When native is the stronger choice
A single household with one car, a predictable commute and a fixed 00:30–05:30 off-peak window will rarely recover the time cost of building a complex external scheduler. A local timer that persists through a router restart is often enough. Use Home Assistant for alerts when the car did not charge, energy reporting, and recording tariff changes; leave its charger-control automations disabled.
Where Home Assistant adds real value
Home Assistant becomes useful when the charging question is more sophisticated than “charge at night”. It can combine grid import/export power, a house battery state-of-charge, future electricity prices, car readiness and household demand. It can also enforce discretionary priorities: for example, charge a second EV only when the first is finished, or postpone EV charging when an upcoming high-price period makes battery storage more valuable.
This advantage comes with operational work. Home Assistant must be running, the integration must expose useful control entities, updates must be timely enough for the proposed behaviour, and automations must recover after restarts. External price and vehicle data can be unavailable or delayed. For cost optimisation, those are engineering inconveniences; for electrical load protection, they are reasons to use an independently certified charger/controller.
| Decision factor | Charger native schedule | Home Assistant as scheduler | Supplier/managed charging |
|---|---|---|---|
| One fixed overnight window | Usually a good fit | Often unnecessary | Depends on tariff |
| Rapidly changing half-hourly tariff | Model-dependent | Strong with reliable price feed | Strong where supplier offers it |
| Solar surplus and house battery priority | Good on compatible EMS models | Flexible, but requires accurate metering | Usually outside supplier’s scope |
| Two EVs plus other flexible loads | Charger ecosystem-dependent | Cross-system optimisation possible | Often controls only eligible EV/charger |
| Behaviour during HA downtime | Potentially independent; verify | Requires deliberately designed fallback | Supplier integration and connectivity-dependent |
| Clear household override | Vendor app or charger control | Requires dashboard and procedures | Supplier app, depending on plan |
| Software maintenance | Vendor firmware and cloud | HA, custom integrations, APIs, automations | Supplier, vehicle and charger software |
| Risk of conflicting controllers | Lower if car schedule disabled | Higher if multiple timers remain active | Higher if third-party control remains active |
Integration choice determines what is practical
Do not buy a charger solely because an integration exists in Home Assistant. Ask whether the exact model exposes a reliable charging enable/disable command, whether the current can be changed during a live session, whether solar mode is controlled through the charger or through Home Assistant, and whether the response is local. A dashboard with useful energy sensors is not proof of command authority.
The built-in OpenEVSE integration offers local charger controls including an override state on supported firmware. It also exposes solar divert and current-shaper switches. However, enabling solar divert in Home Assistant does not itself feed the charger a grid import/export measurement; OpenEVSE needs its own appropriately configured live source. The built-in Wallbox integration retrieves data from the MyWallbox Portal and can pause/resume charging and adjust several settings. Its published update interval for a single-charger account is 90 seconds, so treat it as a supervisory cloud connection—not a rapid demand-limiting loop.
A zappi charger has its own Eco/Eco+ solar modes when fitted with the proper measurement arrangement; a community myenergi integration can make modes visible to Home Assistant, but its API and supported controls should be checked before automating them. OCPP-compatible wallboxes may support local central-system control through community integrations, but individual firmware builds can reject charging profiles even when OCPP appears on a specification sheet. Test the command on real hardware before trusting it with a departure deadline.
| Route | Connection character | Scheduling capability to verify | Main caveat |
|---|---|---|---|
| Local OpenEVSE integration | Local network | Override and current setting subject to firmware | Check override persistence, sensor source and charger states |
| Built-in Wallbox integration | MyWallbox cloud | Pause/resume, charge power, resume native schedule | Cloud availability, account permissions, approximately 90 s update per one-charger account |
| myenergi native charger functions | Charger/hub ecosystem | Timers, ECO and ECO+ with supported meter/CTs | Community HA integration is not equivalent to a safety controller |
| OCPP central system for compatible wallbox | Protocol/network, often local | Availability, limit/profile commands if actually implemented | Version, firmware, transaction handling and smart-charging support vary |
| Supplier-managed charging | Supplier integration with vehicle or charger | Sets charge plan to tariff’s managed conditions | Third-party commands may conflict or violate eligibility |
| Vehicle timer / vehicle app | Vehicle-side, sometimes cloud | Target state of charge and times | Can block an otherwise authorised wallbox session |
For equipment shortlists, see Best Smart EV Chargers for Home Assistant. This article focuses on control ownership, rather than duplicating the hardware comparison.
Supplier-managed charging needs a different hierarchy
An important exception to a DIY scheduler is a managed tariff such as Intelligent Octopus Go. Octopus explicitly warns against allowing third-party smart-charging services to issue competing instructions. Its published guidance says those other services can cause missed charge targets, grid-programme registration problems and schedule clashes; customers who want such third-party control cannot simultaneously use Intelligent Octopus Go on those terms. Where Ohme manages a compatible setup, the relevant target and savings settings may live in Ohme’s own app.
The exact tariff economics and hours also change over time. Octopus introduced its six-hour Charge Cap approach in 2026, so older articles promising unlimited cheap supplier-managed hours are not a reliable basis for selecting hardware or automations. Check your actual contract, account app and current programme rather than copying a historical schedule.
Use Home Assistant for read-only measurements and alerts when a supplier has contractual dispatch authority. If you wish to switch to direct Home Assistant control, confirm what that does to tariff eligibility, the available rates and the supplier programme first. A technically successful automation can be financially worse than simply leaving the supplier in charge.
Seven realistic households: which scheduler wins?
| Household situation | Recommended scheduling owner | Home Assistant role |
|---|---|---|
| One EV, fixed cheap overnight period, no solar | Charger native timer | Optional history and missed-charge alert |
| Smart tariff that dispatches the vehicle or charger | Energy supplier / designated compatible app | Read-only monitoring unless supplier permits otherwise |
| Solar-only home with a supported surplus-diverting charger | Charger native solar mode | Visualisation, forecasts and optional mode-selection |
| Solar plus battery, variable electricity prices | Home Assistant or supported integrated EMS | Control only after charger/EMS limits and fallback are validated |
| Two cars sharing a constrained supply | Charger ecosystem’s independent load manager | Supervisory priorities and reporting |
| Rural home with unreliable broadband | Verified offline-capable native timer | Nonessential analytics when online |
| Enthusiast with local OpenEVSE or proven OCPP commands | Home Assistant may own the schedule | Single source of control, audited commands and testing |
The word verified is important. A wallbox that stores its schedule locally may be excellent in an offline property; another model with the same marketing description may need periodic cloud communication. A device’s behaviour after a 10-minute outage can also differ from its behaviour after a 24-hour outage or reboot. Test the latter as well.
One scheduler, one override: an implementation pattern
Before building automations, write down the owner of each command. Turn off competing vehicle departure timers if Home Assistant will decide charging times. Disable duplicate charger schedules, except for a deliberate fail-safe schedule whose behaviour you have tested. Do not silently rely on two independent systems both granting permission to charge: one hidden pause can leave the car empty the next morning.
A practical architecture has four layers:
- Independent electrical envelope: the installer’s configured current limit, upstream protection, and local whole-site load management if fitted.
- Operational authority: the charger and EV decide whether a session is safe and physically possible, including cable presence, battery limits and fault states.
- Single scheduler: either native charger, approved supplier, or one Home Assistant decision engine.
- Observability: Home Assistant energy dashboard, actual power meterAliExpress price, charger state and alerts. These must detect—not merely assume—a successful start.
Keep a paper or digital commissioning note showing who owns scheduling, which automations are enabled, what an override does and how to restore a usable baseline after a firmware or server change. Treat a schedule as an operational system, not a one-time YAML exercise.
Compare a fixed timer and a variable-price schedule
Suppose an EV requires 18 kWh at the battery before 07:00. Assume 90% wall-to-battery charging efficiency. The electricity needed at the wall is 18 / 0.90 = 20 kWh. With a measured wall charging rate of 7.0 kW, the minimum charging duration is approximately 20 / 7 = 2.86 hours. Allow at least a suitable buffer for reduced supply current, car temperature or session start delays.
Under a fixed overnight tariff of 9 p/kWh for an available four-hour window, those 20 kWh cost £1.80, excluding standing charges. The charger can simply charge within the cheap window: there may be nothing to optimise. If a dynamic tariff instead offers 10 kWh at 5 p/kWh and 10 kWh at 12 p/kWh, the same delivered wall energy costs £1.70. That illustrative 10 p saving is real, but hardly justifies a fragile custom controller on its own.
| Assumption or calculation | Value | Why it matters |
|---|---|---|
| Battery energy needed | 18.0 kWh | Energy to add at the car, not at the meter |
| Assumed charging efficiency | 90% | Adjust from measured data |
| Metered electricity required | 20.0 kWh | Includes charging losses |
| Assumed charging power | 7.0 kW | Lower if house load limit reduces current |
| Minimum charging time | 2.86 h | Add a practical buffer |
| Fixed off-peak at 9 p/kWh | £1.80 | Simple charger timer |
| Example variable slots: 10 kWh at 5p + 10 kWh at 12p | £1.70 | Savings are only £0.10 |
For an owner who needs charging at unexpected times, the cost of a missed departure can exceed months of tariff savings. An automation should therefore have a ready-by deadline, not merely a rule that postpones charging whenever a cheaper slot might occur later.
Budget for the actual integration, not only the wallbox
The purchase price of a compatible charger is only part of the total cost. An external schedule may need a reliable whole-house meter, the correct charger integration, a network that reaches an outbuilding or garage, an always-on Home Assistant computer, and commissioning time. Solar diversion may need additional approved CTs or a dedicated energy meterAliExpress price. A battery-aware schedule needs battery status that represents the same physical system and time interval as grid power.
| Cost or constraint | Native-first installation | Home Assistant-supervised installation |
|---|---|---|
| Charger and certified installation | Required | Required |
| Vendor-supported load-management meter | As specified by installer | Still required when mandated for capacity |
| Always-on Home Assistant host | Optional | Required |
| Home/garage Wi-Fi or Ethernet reliability | Model-dependent | Necessary for consistent live control |
| Electricity price feed and configuration | Sometimes included | Must be obtained, parsed and kept current |
| Ongoing firmware or integration updates | Primarily vendor | Vendor plus HA and integration compatibility |
| Household training and recovery notes | Basic | More involved |
| Backup charge path | Native schedule or manual override | Must be tested, not assumed |
Do not estimate an unsupported percentage saving. You need your actual charging pattern, half-hourly meter readings, current tariff, charging losses and hardware quotations to build a meaningful ROI. Sometimes native scheduling is cheaper because there is no additional installation; sometimes Home Assistant is already running for solar and heating, making extra supervisory logic economical.
How to choose a master scheduler step by step
Step 1 — Map the existing timers. Inspect the car, charger, supplier and Home Assistant apps. Record every active charge window and departure target. Look for a forgotten vehicle timer that would ignore a charger start request. Photograph settings before changing them.
Step 2 — Confirm exact model and firmware. Search the charger’s documentation for “offline scheduling”, “local API”, “OCPP”, “charge current limit” and “pause/resume”. Different firmware and geographical variants can change the answer. If the only Home Assistant function is energy monitoring, do not design a control system around it.
Step 3 — Identify the tariff owner. If a supplier enrols and dispatches the charger or vehicle, respect that service’s rules. If prices vary every half-hour and the contract permits external control, decide whether to use a native dynamic-tariff feature or Home Assistant. Where the tariff changes its rules, update the scheduler before relying on old timings.
Step 4 — Decide the fallback. If Home Assistant is the owner, choose what should happen after a restart, internet loss, stale tariff data or a failed command. A safe operational policy might retain native scheduled charging for a later window, but verify how that schedule interacts with automation overrides. Another installation might revert to manual charging and send an urgent alert. No universally safe fallback exists for every charger.
Step 5 — Make the control path observable. An API accepting start is not proof of charging. Check both the charger’s actual session state and measured current after an appropriate delay. If the car declines to charge, escalate before the departure deadline.
Step 6 — Run real outage tests. Disable Wi-Fi, shut down Home Assistant, interrupt broadband, reboot the charger as permitted by the manufacturer, and simulate a missed forecast. Document what physically happens—charge starts, continues, pauses or rejects the command.
Step 7 — Commission a manual override. Everyone who uses the car should understand how to request an urgent charge without reprogramming YAML. Label the chosen override and confirm how long it lasts. A manual override should not bypass an electrical limit or protective fault state.
Home Assistant automation: start with a read-only conflict detector
Rather than immediately setting up a time-based script to toggle charger power, first detect when several scheduling systems seem to disagree. The following conceptual YAML example sends a notification when a car has been connected for 15 minutes during a designated charge window but the charger reports that it is not charging. Replace all sample entity IDs and test the actual state names exposed by your charger; they differ across integrations.
alias: EV charge window - investigate missing session
mode: single
triggers:
- trigger: state
entity_id: binary_sensor.ev_connected
to: "on"
for: "00:15:00"
- trigger: state
entity_id: input_boolean.ev_charge_window
to: "on"
for: "00:15:00"
conditions:
- condition: state
entity_id: binary_sensor.ev_connected
state: "on"
- condition: state
entity_id: input_boolean.ev_charge_window
state: "on"
- condition: template
value_template: "{{ states('sensor.ev_charger_power') | float(0) < 300 }}"
actions:
- action: persistent_notification.create
data:
title: EV has not started charging
message: >-
Car is connected and the charge window is active,
but reported charging power is below 300 W.
Check car and charger schedules, authorisation and faults.
This example is observational: it never energises a charger or adjusts a safety current limit. It is deliberately a starting point, not a reliable missed-charge alarm on its own. A vehicle can take time to negotiate, sensors can be stale, and a Home Assistant restart during an already-active window may require a separate periodic trigger. Add an hourly or more appropriate periodic watchdog, sensor-availability checks, and your actual state semantics before relying on it.
If you later add active control, start with a read-only planned schedule and logs. Then test one command through the supported charger entity, confirming it is acknowledged by a physically measured power change. Restrict repeated commands, set a maximum allowable age for price and power measurements, and make all unsupported states fail to a clearly defined operational policy.
Native schedule versus Home Assistant: failure-mode tests
| Failure or conflict | What to test | What not to assume |
|---|---|---|
| Router or internet unavailable | Does a locally stored timer still start charging? | That every “smart schedule” is local |
| Home Assistant server reboot | Can charger charge as planned without HA? | That automations run immediately after restart |
| Charger cloud API delay | When does measured power change after a command? | That API success means current has changed |
| Phone app and HA both enabled | Does a manual resume get cancelled by the other app? | That last command always wins |
| Car’s own scheduled departure setting | Does it refuse charger start outside the car window? | That charger permission forces car to accept power |
| Daylight-saving transition | Does a 01:00 timer run once, twice or not at all? | That local clock windows are unambiguous |
| Supplier-managed charging | Are third-party commands permitted under the contract? | That tariff eligibility survives override |
| Stale meter or unavailable battery state | Does discretionary charging stop or use a defined fallback? | That a missing sensor reading equals zero load |
| Charger protective fault | Can manual recovery clear the fault only through approved controls? | That resetting via HA is always appropriate |
A reliable system has an answer to each of these before it is used unattended. Record actual results for your exact charger, firmware, phone app, car software and Home Assistant integration. Retest after major updates.
What about charge targets and the vehicle battery?
Even if Home Assistant owns the time window, the vehicle may own the battery target. A charger knows wall current and energy throughput, not necessarily the car’s battery state-of-charge. Cloud vehicle integrations can report SoC, but readings may be delayed, the car may sleep, and waking it repeatedly can create unwanted activity.
Where actual vehicle SoC is not reliable, work with a measured energy-to-add target in kWh, allow a realistic efficiency margin and enforce a readiness buffer. Avoid making a critical departure depend on a fragile online vehicle sensor. A useful dashboard can show time until departure, last confirmed charging power, energy delivered this session and an estimate of whether the target remains achievable.
If charging is intentionally paused to exploit cheap future electricity or preserve solar export income, display this clearly to other users. “Not charging” is not the same as “broken”: a successful dashboard should show why it is waiting and what will happen next.
Solar and home-battery priorities: avoid two energy managers fighting
Homes with solar and batteries can have multiple control loops: the inverter attempts zero export, the charger diverts surplus, Home Assistant changes charging current, and the supplier prices import differently across time. If each uses a different measurement or priority, the EV can oscillate between pause and start, import expensive power, or unintentionally drain the home battery.
Prefer the vendor’s tested site load-management path for immediate overload response. Choose one controller to allocate discretionary solar surplus. If the charger has an effective native solar mode, Home Assistant may need only select the mode for tariff periods and show battery priorities. If Home Assistant coordinates the house battery and EV, disable competing solar-diversion functions after verifying the installed architecture, or make the control hierarchy explicit.
Measurements must share a common electrical boundary. The grid meter should see EV load, and the battery’s discharge to the EV must be considered if you want “solar-only” charging. Use measured grid import/export instead of inferring surplus from solar inverter output alone. Meter sign conventions, three-phase netting and update intervals require installation-specific tests.
Common mistakes when Home Assistant is put in charge
Two timers remain active. The charger says “charge now” while the car says “wait until midnight”. Home Assistant logs a successful call but no energy flows. Check every app and clear one competing timer at a time.
The cloud integration is too slow. A 90-second update may be fine for tariff windows but unsuitable for adjusting current against second-by-second household load. Retain the charger’s local current-limiting system, and use the cloud API only for slow supervisory requests.
The scheduling algorithm chases tiny price differences. A series of start/stop commands saves pennies but adds unreliability and violates minimum on/off times of some charging systems. Use a minimum expected saving and a reasonable dwell time.
The controller forgets the deadline. A schedule that always seeks the cheapest future slot may fail to finish. Treat meeting a reasonable target by departure as an objective alongside cost, with early warnings if the remaining charge cannot be completed.
Tariff rules were copied from an old guide. Smart tariff hours, conditions and eligible chargers can change. Confirm the contract before writing a script to “game” a historical off-peak window.
An external automation controls electrical safety. A Home Assistant number helper cannot be the sole safeguard against exceeding the house supply limit. Installer-approved hardware and any required local load management stay independent and commissioned.
Buying checklist: questions to ask before choosing a charger
- Does the exact charger model store and execute schedules while broadband and Home Assistant are offline?
- Does its Home Assistant integration expose documented start/pause/resume controls and actual session status, or only energy sensors?
- If cloud-managed, what happens during vendor downtime, login expiry or rate limiting?
- Does it support a robust manual boost and resume-original-schedule action?
- Does the charger require its own CT or meter for solar export detection or dynamic load management?
- Can it coexist with the chosen electricity supplier’s managed tariff, or does the supplier require exclusive control?
- Is current-limiting and any mandatory installation protection independent of Home Assistant?
- Does the app provide a household-friendly manual override without circumventing safety?
- Can you perform and document commissioning tests for delayed start, restart, daylight-saving time and lost connectivity?
For an uncomplicated fixed off-peak household, a well-supported native scheduling system generally wins. For an enthusiast’s home with reliable local hardware, several electricity sources and changing rates, Home Assistant can earn its place—but only as an engineered scheduler with measured results and tested recovery.
FAQ
Can I leave both the car and charger timers enabled?
You can technically do so on many systems, but it usually means charging happens only when both schedules permit it. That may be intentional, but it often causes missed charging. Prefer a single documented master schedule unless you have tested the interaction and have a reason for the second restriction.
Does using Home Assistant make EV charging unsafe?
Not inherently. Monitoring, scheduling requests and energy optimisation can be useful. The issue is assigning it an inappropriate safety function. Installations must keep electrical protection and required site load management in suitable charger/approved hardware, independent of HA uptime.
Can I schedule Wallbox locally through Home Assistant?
The official built-in Wallbox integration uses MyWallbox Portal, so it depends on the cloud. Some models and business arrangements have other interfaces; verify the exact unit, firmware and interface rather than assuming a local API is present.
Is OCPP always better than a vendor API?
No. OCPP is a useful open protocol for chargers and central systems, but feature availability and charging-profile support vary. A well-documented local vendor integration can be easier and more predictable than an OCPP connection whose charger firmware rejects the commands you need.
Should I use Home Assistant with Intelligent Octopus Go?
Read-only monitoring and alerts are useful, but supplier-managed charging must follow supplier terms. Octopus explicitly warns that third-party charging controls can conflict with its smart dispatch programme. Do not enable competing start/stop commands without the supplier’s approval.
Which is cheapest in the long run?
There is no universal winner. Native scheduling can avoid extra infrastructure and maintenance. Home Assistant can improve bill optimisation where half-hourly rates, solar and multiple loads matter. Compare actual annual additional savings against any extra hardware, integration maintenance and the consequences of a missed charge.
Final verdict
Choose native charger or supplier scheduling first when a well-defined off-peak window, simple departure target or managed tariff is the goal. Choose Home Assistant as the sole supervisory scheduler when there is a measurable benefit from dynamic prices, solar/battery coordination or complex household constraints, and only after verifying the charger’s control interface and recovery behaviour. Either way, retain independent electrical protection and a tested, understandable manual charging option.
Official documentation and further reading
- Home Assistant: OpenEVSE integration — local controls, solar divert conditions and override state.
- Home Assistant: Wallbox integration — MyWallbox cloud requirements, pause/resume functions and data refresh rates.
- Home Assistant: automation triggers — event and state-trigger behaviour.
- Octopus Energy: Why third-party controls conflict with Intelligent Octopus Go — supplier policy and conflict explanation.
- Octopus Energy: Intelligent Octopus charging and Charge Cap — current managed charging arrangements.
- Home Assistant OCPP community project — independent integration, supported protocol versions and ongoing changes.
- Myenergi community integration — available zappi and hub entities (community-maintained; verify model support).
- ESP32.co.uk: Best smart EV chargers for Home Assistant — complementary charger buying comparison.
Accuracy and safety note (October 2026): Specific features, supplier conditions and integration behaviour may change with firmware, Home Assistant releases or tariff updates. The monetary illustration is not a current tariff quote. EV charging installation and electrical protection should be designed and commissioned by appropriately qualified professionals. Test scheduling with the actual hardware before leaving it unattended.