Quick Summary (TL;DR)
Choose an EV charger’s connection for the functions you need, not for the largest number of wireless icons on its specification sheet. Wi-Fi is convenient in a house with reliable outdoor coverage; wired Ethernet is attractive where the chosen wallbox genuinely supports it; integrated cellular can be useful at a detached garage, shared car park or unreliable broadband site. None of these links automatically gives you local Home Assistant control, and none alone guarantees that charging, schedules, energy records or safety-related load management will survive a network outage.
The practical buying question is which functions remain inside the charger when its router, internet service, cloud platform or mobile network disappears? Basic vehicle charging often continues, but authentication rules, new schedules, remote start commands, live data, tariff optimisation and automatic load adjustment have different dependencies. Check the exact model, country, firmware, installed meter and backend before buying.
For most single-house installations, a well-installed 2.4 GHz Wi-Fi wallbox with documented offline charging is enough. Choose Ethernet where supported and cabling is easy, or cellular where site coverage and the recurring service arrangement are demonstrably reliable. Keep protective electrical limits independent of Home Assistant and provide a safe, documented manual charging fallback.
First separate the five different connections
People say that an EV wallbox is ‘connected’, but the word can describe five very different paths. A charger can communicate with the vehicle over the charging cable while its app is offline. It can communicate with a phone over Bluetooth without reaching your router. It can talk to Home Assistant on the LAN but not reach the internet. Or it can be reachable from a manufacturer’s servers despite offering no local API at all.
| Connection | What it normally does | What it does not prove |
|---|---|---|
| EV charging signalling and power | Negotiates permitted charging current with the vehicle and closes the charger’s contactor when allowed | Internet access, app access or any cloud service |
| Charger to phone via Bluetooth or temporary access point | Commissioning, local status and possibly limited settings | Always-on integration with Home Assistant or remote access |
| Charger to router via Wi-Fi or Ethernet | LAN connectivity; potentially firmware downloads or cloud uplink | Availability of a documented local API |
| Charger to mobile network through built-in cellular | Independent path to a cloud backend where coverage and subscription permit | Offline operation without the vendor’s servers |
| Charger or gateway to a Home Assistant/OCPP controller | Monitoring and potentially permitted commands | Safety-rated dynamic load limiting or guaranteed control while offline |
This distinction prevents two common mistakes: buying a ‘Wi-Fi charger’ that exposes only a cloud API, and assuming that a local charger is useless when a public internet connection fails. For example, the official Home Assistant OpenEVSE integration communicates locally over the home network. The official Wallbox integration obtains data from MyWallbox servers; connecting that charger to the same router as Home Assistant does not turn that integration into a LAN API.
Wi-Fi vs Ethernet vs cellular: the buying comparison
| Criterion | Wi-Fi | Wired Ethernet | Built-in cellular / LTE-M / 4G |
|---|---|---|---|
| Installation | Usually easiest; no separate data cable | Requires supported Ethernet hardware and a routed cable | Requires antenna coverage and a supported service plan |
| Reliability at an outside wall | Depends on radio coverage, construction and interference | Typically consistent if cable and terminations are protected | Depends on operator, signal, service and modem behaviour |
| Router needed | Normally yes for home LAN or broadband | Normally yes for LAN or broadband | Not necessarily, if cellular is genuinely independent |
| Home Assistant local access | Possible only with documented local interface | Possible only with documented local interface | Usually indirect through a remote cloud platform unless an additional local path exists |
| Internet outage | Local LAN can continue if router/AP has power | Local LAN can continue if router/switch has power | Cellular may remain online even if broadband fails |
| Mobile operator outage | Not directly relevant | Not directly relevant | Can lose remote services despite charger power |
| Recurring cost | Usually none beyond home network | Usually none beyond home network | May include bundled connectivity term or subscription; verify |
| Best fit | Typical driveway with strong coverage | Garage or plant room where cabling is practical | Detached, communal or broadband-poor installation |
Ethernet is not an upgrade you can assume exists on a product. A charger’s manufacturer may offer a different communication arrangement on a Pro, business or regional model; another charger may use Ethernet between a gateway and meter rather than between wallbox and router. Confirm the interface on the exact product datasheet, where the cable terminates and whether the manufacturer supports that topology. Don’t drill through an outdoor enclosure to add a network cableAliExpress price unless the manufacturer and installer approve it; doing so can compromise ingress protection and warranty.
Likewise, cellular is not necessarily a fallback for a broken cloud platform. It is usually just another transport to the same platform. It is valuable when your broadband or Wi-Fi goes down, but not when the manufacturer’s service or charging account is unavailable. A charger may fall back from Wi-Fi to LTE-M automatically, or it may use cellular only as its primary path. Check both the technical arrangement and contractual connectivity period.
What happens when the connection fails?
An outage test is more useful than a marketing phrase such as ‘works offline’. There are at least five failures to distinguish: loss of internet with working home Wi-Fi; router or access-point failure; manufacturer cloud outage; cellular service failure; and an actual loss of electrical supply to the charger. The fifth is not a communications problem; an ordinary grid-connected home charger cannot charge a vehicle without a compatible live power supplyAliExpress price.
| Function | Internet down, LAN up | Router/AP down | Manufacturer cloud down | Power to charger down |
|---|---|---|---|---|
| Basic charging of an authorised car | Often continues; verify the model | Often continues; verify | Often continues; verify backend rules | Stops unless a separately engineered backup supply serves the circuit |
| Previously stored charger timer | Often continues if stored on device | May continue if local | May continue; confirm clock and time synchronisation | May recover after power returns; test |
| Modify remote app schedule | Generally unavailable | Generally unavailable | Often unavailable | Unavailable |
| Home Assistant local LAN sensor | Continues where router/network still operates | Unavailable unless another working network path exists | Continues if the integration is genuinely local | Unavailable |
| Cloud Home Assistant sensor | Usually unavailable | Usually unavailable | Unavailable | Unavailable |
| Meter-based dynamic load management | Must be verified as an independent supported safety/control path | Depends on meter–charger link and failure logic | Ideally independent of cloud | No charge load |
| Access-controlled/shared charging | May be restricted; depends on local authorisation/cache policy | May be restricted | May be restricted | Unavailable |
The table describes typical possibilities, not universal promises. Never infer that a charger starts an offline session merely because its status light is green. At a managed or pay-to-use site, an authorisation backend may need to approve the transaction. Some systems retain approved users locally; others cannot start new sessions. For a private driveway, set up offline authorisation and any lock/access rule before relying on the installation.
How actual manufacturers describe offline behaviour
Easee: Easee states that its chargers can charge without an internet connection, while warning that a charger operated by another backend may not be able to begin an offline session. Its guidance also notes that schedules cannot be created or changed while offline and charging-session timing in reports may be inaccurate. Easee recommends local Wi-Fi with built-in 4G/LTE-M as a fallback where available, and provides Bluetooth access for local diagnostics. Verify the region and model, because hardware, mobile networks and firmware availability differ. See Easee offline charging guidance and offline recovery instructions.
Wallbox Pulsar Plus: Wallbox describes Bluetooth and Wi-Fi management. Its Pulsar Plus product documentation states that scheduling and static load management can function without a cloud connection on applicable versions; its quick-start guide similarly says that an active Wi-Fi connection is not necessary for basic charging. However, the official Home Assistant Wallbox integration is cloud polling through MyWallbox. You can therefore have functioning charger-local scheduling while a Home Assistant entity is stale or unavailable. See the Wallbox UK/EU product guide and Home Assistant Wallbox integration.
Tesla Gen 3 Wall Connector: Tesla explicitly states that power-management features do not require internet or a Wi-Fi network to operate, although Wi-Fi is recommended for firmware and diagnostics. This refers to its supported static, dynamic and group power-management arrangements, not to unrestricted use of all online services. The Tesla power-management guide is the relevant reference. Its official Home Assistant Wall Connector integration monitors the charger over the LAN; it is not the same as a fully supported remote charge-current control API.
OpenEVSE: Its official Home Assistant integration requires supported OpenEVSE Wi-Fi firmware, communicates over the local LAN and exposes current, session and lifetime energy, charging status and certain controls. Internet access is not needed for that integration to operate. Wi-Fi still needs to connect to a local network and both the charger and Home Assistant need electrical power. Consult the official OpenEVSE integration for firmware support, controls and limitations. The OpenEVSE system’s actual charging behaviour on lost Wi-Fi remains a matter for its configured firmware settings and hardware rather than for Home Assistant.
Choosing Wi-Fi: test the installation, not just the phone signal
An outside charger faces conditions very different from a device beside your broadband router. Brick walls, foil-backed insulation, metal gates, garages, consumer-unit enclosures, vehicles and seasonal foliage can weaken coverage. Water and reflections can change propagation, too. Many EV chargers use 2.4 GHz Wi-Fi; some are selective about WPA modes, combined SSIDs, captive portals or enterprise authentication. For example, Tesla’s model-specific network guidance calls for compatible 2.4 GHz security settings; do not assume that a new router’s 5 GHz-only network or captive-portal guest Wi-Fi will work.
A practical site survey consists of more than checking a signal icon. Test at the final charger position with the garage door closed and the car parked as usual. Check signal strength (if the wallbox reports RSSI), actual connection stability over hours, whether the access point stays powered overnight, and whether authentication recovers automatically after a router reboot. Use a correctly positioned mesh node or dedicated access point if needed; an unreliable mains plug repeater inside a metal garage may simply move the problem. If you use a powerline adaptor, test stability on the actual electrical circuit rather than assuming its advertised throughput will materialise.
| Wi-Fi symptom | Likely cause | Sensible test | Potential remedy |
|---|---|---|---|
| Charger associates then goes offline | Weak/variable signal; access point steering | Check logs and RSSI at charge point | Move AP, add correctly placed outdoor coverage |
| Only fails after router replacement | WPA/security or band incompatibility | Compare against manufacturer SSID/security guidance | Use compatible 2.4 GHz protected network |
| Local Home Assistant works but app says offline | Internet, DNS or vendor service failure | Check router WAN and vendor status separately | Restore WAN/cloud service; do not reinstall local integration |
| App works but Home Assistant cannot reach charger | Cloud-only integration or LAN segmentation | Inspect integration’s IoT class and local route | Use supported local integration or appropriate firewall rules |
| Charger IP changes | DHCP lease or network change | Inspect router client list | Create DHCP reservation if supported |
| Scheduled charging misses start | Clock, time zone, cloud/backend dependence | Simulate router outage before scheduled start | Use device-stored timer with confirmed offline handling |
Is a stronger antenna worth paying for?
Usually improve the access point position first. A charger is an electrical appliance with a certified enclosure, not a hobby development board. External antennas, case openings and altered radio modules may violate its approvals or warranty. Ask the manufacturer whether an official network accessory, approved antenna arrangement or Ethernet-capable variant exists. If your router and charger are close enough for a cable, a supported wired connection often costs less to support over several years than repeated attempts to rescue an unstable wireless link.
Ethernet: excellent where available, but inspect the entire route
Wired Ethernet avoids Wi-Fi interference, but it cannot solve cloud dependence. If the wallbox talks to its manufacturer’s servers over Ethernet, an internet outage can still disable remote app controls or a cloud Home Assistant integration. Conversely, a genuine local API works across a functioning LAN even when the broadband link fails. Ask for the exact Ethernet feature and supported protocols rather than assuming ‘RJ45’ means Home Assistant compatibility.
Plan the cable route with the electrician and network installer before mounting the wallbox. Consider conduit, weatherproof external runs, correct outdoor-rated cable, bend radius and separation from mains circuits to applicable standards. In outbuildings or across buildings with different earthing environments, discuss surge exposure and whether fibre or a properly isolated network route is more appropriate. A PoE injector is not a substitute for power to the charger; the wallbox still requires its independently protected electrical circuit. Provide switch/router UPS power only if its purpose and limits are understood.
If the selected charger uses a separate network bridge or gateway, check which components remain working when that bridge loses power. An Ethernet connection to a remote gateway does not establish that the safety-critical meter-to-charger link will remain functional. Ask the manufacturer for the meter’s communication requirements and permitted behaviour if that link fails.
Cellular: independent access, not independence from the supplier
Integrated LTE-M or 4G can be compelling where Wi-Fi is weak and running Ethernet is expensive. A charger may connect to the vendor cloud over a mobile network without sharing the home’s broadband. The useful questions are more precise than ‘does it have 4G?’
- Which radio technology and network bands are fitted in the exact regional model? LTE-M coverage and roaming arrangements are not the same as normal phone 4G coverage.
- Is the SIM soldered, supplied, replaceable or managed only by the vendor? Who owns it, and who can change network providers?
- Is connectivity included indefinitely, for a stated number of years, or under a renewable subscription? What happens if the service ends?
- Does mobile coverage work at the wallbox’s installed position, including inside a concrete or metal enclosure? A phone’s signal reading on the driveway is not proof.
- Does it automatically switch between Wi-Fi and cellular and return without intervention? Does switching interrupt a session?
- Will the same cloud, identity and scheduler remain usable if the supplier withdraws service or the backend is down?
- Is a local API also available, or does cellular tie you to cloud monitoring and remote control?
Easee is a useful concrete example: its documentation distinguishes local Wi-Fi, integrated LTE-M and Bluetooth. Wi-Fi is recommended because it can improve command response and update speed; the LTE-M path can restore cloud access independently where covered. That is a resilience advantage for broadband failures, not proof of independent cloud-free charge scheduling. Easee connectivity guidance.
For a shared or commercial site, also ask about SIM ownership, data retention, cellular antenna maintenance and the ability to transfer the charger to another management platform. A bargain unit with a locked-in provider may become expensive or difficult to operate after a change of property manager.
Local API, cloud API and OCPP: three separate buying decisions
Network transport is only the path. The integration mechanism determines who actually controls the charger. A manufacturer app might be accessible over Bluetooth near the charger, but the Home Assistant integration might still require a remote account. Similarly, an OCPP-compatible charger may need to be configured to connect to a designated OCPP central system rather than the manufacturer’s usual servers. Do not buy on the assumption that changing an OCPP endpoint preserves all of the manufacturer’s mobile app functions.
| Control route | Where commands travel | Internet-free Home Assistant? | Key caution |
|---|---|---|---|
| Local HTTP/REST or WebSocket API | Home Assistant → home LAN → charger | Yes, if officially supported and LAN powered | Authentication, firmware behaviour and exposed controls matter |
| Local Modbus / supported gateway | Local controller → inverter/meter/charger interface | Sometimes | Register maps and safety boundaries are model-specific |
| Vendor cloud API | HA → internet → vendor → charger | No | Backend outages, rate limits, credentials and polling delay |
| OCPP to a local central system | Charger → working LAN → local OCPP server | Potentially | Charger must support and permit the chosen CSMS and commands |
| Bluetooth phone app | Phone nearby → charger | Local phone control, not necessarily HA | Range and pairing/permission restrictions |
The official OpenEVSE integration is marked Local Push and the Tesla Wall Connector integration Local Polling. The official Wallbox integration is Cloud Polling. These are useful facts when choosing hardware for Home Assistant; they are more informative than a generic Wi-Fi logo. See the Home Assistant EV charger comparison article already on esp32.co.uk for the broader buying shortlist.
Is OCPP a cure for cloud dependence?
Not automatically. OCPP is a protocol between a charging station and a central management system. In a supported deployment you might run a local CSMS on your network. However, an advertised ‘OCPP-ready’ device may need manufacturer configuration, licensing or specific firmware, and supported operations differ by charger and OCPP version. In particular, smart-charging profiles and remote start/stop should be tested rather than assumed. If the OCPP controller is offline, fallback charging and transaction reconciliation depend on the station’s policies and offline authorisation configuration.
For a private home with one car, OCPP may add complexity with little benefit. For multiple chargers, shared parking, access control or a deliberately self-hosted management system, the control benefits can justify the effort. Keep a supported recovery route: if you replace the vendor cloud endpoint with a local OCPP server and your server later dies, how will the wallbox authorise charging and restore its original configuration?
Safety-critical load balancing must not depend on broadband
The greatest mistake in network architecture is using a cloud-connected automation as the only safeguard against exceeding the supply rating. A charger’s installer-commissioned maximum, residual-current and earthing/PEN protective provisions where required, and any safety-relevant dynamic load controller must behave correctly without your laptop, Wi-Fi, router, supplier cloud or Home Assistant being online.
Where a charger uses an external current transformerAliExpress price or energy meter, the communication path between meter and charger matters. It could be wired RS485, a vendor-approved wireless link or a supported energy gateway; don’t assume its resilience from the charger’s phone-app network specifications. Before installation, obtain the vendor’s documented lost-meter behaviour: reduce current, pause charging, fall back to a safe commissioned limit, or some other approved response. Have the installer test it.
An energy management automation may instruct a charger to pause for a tariff, battery reserve or solar export target. This is an optimisation layer, not a safety function. If communications fail, the system should have an independently safe current limit and a defined operator-visible default. An EV is also permitted to draw less current than the wallbox offers; an app command does not override the car’s battery-management protections.
What offline features matter most for a normal home?
A household can accept different trade-offs depending on how it actually charges.
Case A: One EV, cheap-rate overnight tariff. A charger-local schedule that survives broadband and router outages is often more useful than extra remote integrations. Test that the timer is stored locally, preserves the time zone and restarts correctly after a power cut. Keep only one device authoritative for scheduling so a car timer and charger timer do not cancel each other.
Case B: Rooftop solar and battery. Local metering, a supported solar-surplus algorithm and a properly commissioned dynamic load limit matter. If Home Assistant supervises charging, it should use measured grid import/export, current EV draw and stable hysteresis rather than reacting to every transient watt. If it loses connectivity, the charger still needs a safe independent mode. Battery charging priorities and solar charging are separate features; confirm which controller owns each decision.
Case C: Two EVs sharing a limited supply. Prefer manufacturer-supported charger-group load sharing or an appropriate dedicated site controller. Tesla, for example, documents Gen 3 group power management between supported Tesla Wall Connectors without requiring internet. Check brand/model mixing rules and what happens if group communications disappear.
Case D: A detached garage without Wi-Fi. Compare a supported Ethernet cable route against integrated cellular with proven coverage and a clear service term. If you install a cellular router as a network gateway for a cloud-only charger, you still depend on the manufacturer’s cloud platform. A cheap SIM router may work, but assess antenna, power supplyAliExpress price, router reboot behaviour and ongoing costs.
Case E: A holiday let or shared-access parking bay. Off-network access-control policy matters more than app polish. Confirm whether authorised users can charge when the backend is unreachable, what data can be reconciled later and how visitors gain access if the owner is away. A charger that defaults to open charging during outages may be inappropriate; one that locks everyone out may be equally unsuitable.
An end-to-end outage acceptance test
Before treating the installation as dependable, record a short set of tests with the installer and the vehicle. You do not need to manipulate mains wiring or bypass protective devices. Keep charging disabled if there is a fault indicator or tripped protective device and have the authorised installer investigate.
| Test | Expected observation to document | Why it matters |
|---|---|---|
| Normal charging with internet | Charging starts; meter records expected power | Baseline and vehicle compatibility |
| Disconnect broadband WAN, leave local router on | Record whether charging continues and whether local/remote features survive | Separates internet reliance from Wi-Fi coverage |
| Power down Wi-Fi access point only after charging has stopped safely | Record starting a permitted session and local status where supported | Separates router reliance from basic operation |
| Vendor backend unavailable (if safely simulated or during an incident) | Identify which app controls and authorisation functions remain | Cloud architecture |
| Timer starts while network is offline | Record scheduled start/stop and clock correctness | Offline schedule persistence |
| Router and charger power cycle using installer-approved methods | Confirm reconnection, timers and current limits | Restart resilience |
| External dynamic-load-meter link lost (installer test) | Charger follows documented safe fallback | Electrical load-limit integrity |
| Reconnect network | Check charging logs, energy counters, firmware/clock and duplicate sessions | Record reconciliation |
Record the exact firmware version and app/backend version. A newer firmware might improve offline behaviour or alter an API. If the charger needs initial cloud provisioning before it can charge, perform commissioning and offline tests before a car is dependent on it.
A simple Home Assistant watchdog—not a protective interlock
You can watch a local EV charging integration for loss of visibility. This example sends a notification only; it deliberately does not send a stop/start or current-limit command. Replace the entity and notification target with those available on your installation.
alias: EV charger local connection lost
mode: single
triggers:
- trigger: state
entity_id: sensor.openevse_charging_status
to: "unavailable"
for: "00:05:00"
actions:
- action: persistent_notification.create
data:
title: "EV charger connection needs checking"
message: >-
Home Assistant has not received charger status for five minutes.
Charging may still be operating normally. Check the charger locally;
do not interpret this notification as an electrical fault.
Entities vary by vendor and integration version. If a charger is cloud-only, the entity may show unavailable because the vendor API failed even though the charger is charging perfectly. Distinguish network telemetry failure from power and protective faults, and never let this notification substitute for the manufacturer’s status indication.
Practical cost considerations: a transparent example
Connectivity affects total installed cost in ways that a wallbox price omits. The following are illustrative scenario inputs, not live quotations. Ask an installer to quote the actual cable route, enclosure, mounting, certification and device model. Do not double-count a wireless gateway if the manufacturer already provides one.
| Example incremental cost item | Planning assumption | Five-year cash effect |
|---|---|---|
| Better-positioned Wi-Fi access point | £90 upfront, £0 service fee | £90 |
| Ethernet cable route and terminations | £180 installed once | £180 |
| Cellular-enabled gateway premium | £120 upfront | £120 before mobile service |
| Cellular service at £4/month | £4 × 60 months | £240 |
| Cellular gateway plus example service | £120 + £240 | £360 |
Under those invented but transparent assumptions, Ethernet costs £90 more than a single added Wi-Fi access point, while the cellular setup costs £180 more than Ethernet over five years. These are not comparable quotations because site labour and included mobile-service terms vary. In an outbuilding where a proper wired route costs hundreds of pounds more, cellular could be the better economic decision. Where coverage is poor, the cheapest connection can be the most expensive to maintain.
Also account for recurring API subscriptions or optional smart-charging services, any roaming end date for the included SIM, contractor attendance for network reconfiguration, and the risk of losing cloud features if a service closes. A device with a documented local control path generally provides more flexibility, though only if the manufacturer continues to support it and the owner maintains the local network.
Choosing a charger: the questions that prevent an expensive mistake
Ask the seller or installer to answer these questions for the exact product code and firmware, ideally in writing:
- Does an authorised car start and continue charging with all internet access unavailable? Does the result differ for locked, RFID-authorised or shared sites?
- Do stored charge schedules keep running after internet, router and power outages? How is the clock maintained when offline?
- Which features are local, which require vendor cloud, and which require a paid service? What happens if service is discontinued?
- Is Wi-Fi 2.4 GHz only? Which WPA modes are supported? Is a captive portal or enterprise network supported?
- Is wired Ethernet actually included on this SKU, or on a distinct gateway/professional model?
- If integrated cellular exists, who pays for data, how long is service included, which bands and operators are used, and can the SIM be changed?
- Does the Home Assistant integration use a local protocol or a vendor portal? Is control read-only, or can current and schedules be changed?
- Is OCPP supported today, in what version, with which firmware and what tested offline authorisation behaviour?
- How does the charger’s approved load-management system behave if its meter communication disappears?
- Who supplies the credentials, commissioning record, firmware path and recovery procedure when the home owner changes router or installer?
These questions are particularly important for affiliate purchases: the same brand can sell domestic, socketed, tethered, commercial and regional variations with different networking hardware. Do not copy connectivity claims from a superficially similar model.
Common problems and fixes
| Symptom | First check | Avoid doing this |
|---|---|---|
| App says offline but car is charging | Confirm WAN/cloud status and local charger status | Resetting electrical protection simply to fix the app |
| Wi-Fi disconnects every evening | Signal when car is parked; router schedules; AP logs | Assuming more expensive broadband fixes local RF |
| Ethernet works but app cannot reach charger | Internet DNS, vendor account and backend availability | Assuming an RJ45 port provides local API access |
| Cellular shows coverage but cannot connect | LTE-M bands, network, SIM status, vendor service | Assuming phone 4G signal equals LTE-M support |
| Home Assistant entities frozen | Check local vs cloud IoT class and current API status | Using stale readings to control supply limits |
| Charging blocked only while offline | Check RFID/backend authorisation and policy | Disabling access restrictions without site approval |
| Timers missed after outage | Clock synchronisation, DST and stored schedule | Adding a competing second scheduler |
| Unexpected reduction to 6 A or pause | Meter-link fallback, car limitations, dynamic load management | Increasing installer safety limit through automation |
| Charger stopped completely | Local fault indication, protective device, vehicle status | Bypassing tripped RCD/RCBO or opening sealed case |
A phone app showing ‘offline’ is a network observation, not an electrical diagnostic. Conversely, a charger showing online does not prove that an earth fault, overheating fault or overload condition is absent. Use the manufacturer’s fault indications and qualified support.
Final buying recommendation
For a typical UK home with one EV, a dependable charger-local timer plus proven offline charging is more important than cellular connectivity. Use Wi-Fi if the installed location has stable coverage; choose approved Ethernet when convenient and supported; choose cellular where it solves an actual broadband/site-access problem and where ongoing connectivity terms are clear.
For Home Assistant enthusiasts, favour a documented local API and verify what controls it actually exposes. Local polling or push protects against vendor cloud outages, but it still depends on LAN power, charger firmware and careful configuration. For solar or battery coordination, leave independent electrical protection and installer-approved load management intact. For shared or pay-to-use sites, verify offline authorisation and transaction recovery before placing trust in an app.
A good wallbox is not necessarily the one with the most connection methods. It is the one whose charging, metering, safety and recovery behaviour is predictable when each connection disappears.
Frequently asked questions
Will an EV charger continue charging without Wi-Fi?
Often yes, but not universally. Many domestic chargers support normal charging with no Wi-Fi or internet, provided the vehicle is authorised and the charger is healthy. Some shared or operator-managed setups cannot authorise a new session offline. Test the exact device and configuration.
Does Ethernet make a cloud-based charger local?
No. Ethernet replaces the physical network connection to your router; it does not change the command path. A charger can use Ethernet and still require the supplier’s cloud for Home Assistant control.
Is cellular safer than Wi-Fi for load balancing?
Not by itself. Supply-limit protection depends on the manufacturer’s approved local measurement and control arrangement, not on whether internet traffic uses cellular or Wi-Fi. Confirm the lost-meter communication response with the installer.
Can Home Assistant control a charger when broadband fails?
Yes where a supported local charger interface is reachable on a working LAN. Home Assistant integrations that obtain data from a remote vendor portal generally cannot continue polling that portal during an internet outage.
Does Tesla Wall Connector need internet for dynamic power management?
Tesla states that the supported Gen 3 power-management features do not require internet or Wi-Fi to function. The particular meter and wall-connector arrangement must still be installed and commissioned as specified.
Are 4G and LTE-M equivalent?
No. LTE-M is a low-power cellular technology with its own network coverage and roaming considerations. Confirm that the specific charger’s cellular modem is supported by the operator at the installed site.
Should I use the vehicle schedule, the charger schedule or Home Assistant?
Choose one scheduling authority for each charging objective. A robust charger-local schedule is often best for simple overnight charging, while Home Assistant can coordinate solar, batteries and variable prices if the control path and fallback are thoroughly tested. Do not enable several competing timers.
Official documentation and further reading
- Home Assistant: OpenEVSE integration — local push, supported controls and setup.
- Home Assistant: Tesla Wall Connector — local polling and available sensors.
- Home Assistant: Wallbox — cloud-polling integration.
- Tesla: Wall Connector power-management functions and internet independence.
- Easee: Charging when the charger is disconnected from internet.
- Easee: Offline connectivity and LTE-M recovery.
- Wallbox: Pulsar Plus product and connectivity overview.
- ESP32.co.uk: Best Smart EV Chargers for Home Assistant.
Editorial note (October 2026): Charger connectivity, offline features and connected-service terms can change with hardware revisions, firmware and region. Consult the current product documentation and a qualified installer before purchase or electrical work.
