Short answer: You don’t have to choose between a charging site that works without internet and one with full cloud capability — real-time session control, dynamic tariff steering, demand response, predictive maintenance and roaming. A local mesh runs everything that must survive a dropped connection: driver access, power sharing and billing records. An optional site gateway carries everything that is inherently a cloud function. Lose the connection and the cloud features pause; charging does not.
The usual objection to offline-first charging is a fair one: if the site isn’t online, don’t I give up remote control, tariff optimisation, grid services and diagnostics? It’s fair because for most “offline” products it’s true — they treat offline as a degraded fallback mode, so anything cloud-side is either absent or fragile. This guide explains a different arrangement, where offline is the normal operating state for the things drivers depend on, and connectivity is an additive capability layer rather than a dependency.
The false choice
Conventional charging architecture puts one network connection in the critical path of every function. Authorisation, metering, load management, monitoring and updates all route through a cloud backend. That single design decision produces two problems at once.
It makes the site fragile: a router reboot, a carrier outage, an expired certificate or a backend incident takes down charging, not just reporting. And it makes the site expensive, because every bay needs a reliable network path — which in an underground garage means cabling, repeaters or a cellular installation, commonly €500–2,000 per parking space before any charger is mounted. More on that in how to cut EV charging infrastructure costs.
The instinctive fix — “make it work offline” — usually means caching an authorisation list so the charger survives a bad afternoon. That helps with outages. It does nothing about cost, because the network still has to reach every bay for normal operation.
Splitting the job by what has to survive a dropped connection
The useful question isn’t online or offline, and it isn’t real-time or batch either — plenty of cloud functions are genuinely real-time. The question is: which functions must keep working when the connection fails, and which are inherently cloud-side because they depend on information or actors from outside the site?
Sort them on that axis and the split is clean:
| Function | Must survive a dropped connection | Inherently a cloud function |
|---|---|---|
| Driver authorisation | ● | |
| Power delivery | ● | |
| Load management between chargers | ● | |
| §14a EnWG curtailment (wired Steuerbox) | ● | |
| Session records for billing | ● (captured locally, synced later) | |
| Remote session start/stop and user support | ● | |
| Dynamic tariff steering | ● | |
| Demand response and market curtailment | ● | |
| Predictive maintenance | ● | |
| Fleet and portfolio reporting | ● | |
| Roaming settlement | ● | |
| Firmware and configuration updates | ● |
The left column is what a driver in the garage actually touches, plus the records you bill from. None of it inherently requires the internet — it requires communication: driver to charger, and charger to charger. Both are local problems with local solutions.
The right column is different. These aren’t slow or unimportant — several are strictly real-time — but they’re real-time from the cloud, because they depend on a live tariff feed, a grid operator’s signal, an aggregator, a support agent, or a fleet manager who isn’t standing in the garage. No amount of local intelligence produces them, which is exactly why the gateway exists.
One row deserves a note: §14a EnWG curtailment sits on the left, because the gateway reaches the grid operator’s control box over a local wired connection, not the internet. Broader market-based demand response sits on the right, because that genuinely involves an outside counterparty.
The architecture
Bluetooth is the access channel. The driver’s phone talks directly to the charger over Bluetooth Low Energy, with each session authorised by patented cryptographic tokens rather than a lookup against a remote server. No round trip, sub-second response, and it works in a concrete basement exactly as well as on a driveway. This is the channel drivers touch every day, and it never depends on the site being online.
A Zigbee mesh is the coordination layer. Chargers discover each other and form a mesh, then balance the building’s available power among themselves in real time. There is no central controller and no network cabling between bays. Buildings with 50+ chargers run on a single grid connection this way. Because the coordination is local, it keeps working during an outage instead of falling back to conservative static limits.
A gateway is the optional bridge. One CONNECT Edge Gateway per site — not per bay — joins the mesh and provides a single connection to the outside world. It reaches every charger through the mesh the chargers already use, which is why one device can serve the whole site.
The economics follow directly from the topology: connectivity cost scales per site, not per parking space. A 60-bay garage needs one uplink, not sixty network drops.
What the gateway unlocks
The gateway isn’t a fallback or a compliance box. It’s where a whole class of capability lives — the things that need a live line to the world outside the garage.
Real-time control from the cloud. Operators can start, stop and manage sessions remotely, and support staff can resolve a driver’s problem without a site visit. For a portfolio manager running buildings across a region, that’s the difference between managing sites and dispatching vans to them.
Session visibility for drivers and operators. Live status, active sessions and consumption, remotely — so a fleet manager can see what an employee’s home charger did last night, and a property manager can answer “was my charger working?” without walking to the basement.
Dynamic tariff steering. Live electricity prices only exist in the cloud. With a gateway, charging shifts toward the cheapest hours against a variable tariff, which on an overnight residential site is where most of the achievable energy saving sits.
Demand response and curtailment. Two distinct things worth separating. §14a EnWG curtailment runs over the gateway’s local wired link to the grid operator’s control box and is enforced across the mesh — no internet required. Broader, market-based demand response — responding to an aggregator or a grid-services contract — is genuinely cloud-side. Architecturally it makes the garage dispatchable rather than a fixed load — the precondition for participating in flexibility markets where they exist.
Predictive maintenance. Continuous telemetry from every charger, analysed centrally, surfaces a failing contactor or a drifting meter before a driver finds it. Downtime and truck rolls are a real cost line at multi-bay sites, and this is the lever that moves them.
Roaming and third-party cards. Drivers with the HeyCharge app authenticate locally over Bluetooth — always, gateway or not. A visitor presenting a third-party RFID card is a different case, because settlement genuinely requires reaching the roaming network. With a gateway, those cards are accepted and settled via Hubject, so someone with a Shell, DKV or EnBW card can charge without being a HeyCharge customer.
The pattern across all six: each is additive. None replaces the local access path, and none of them failing takes charging down with it.
What survives an outage
| Cloud-dependent site | Offline-first with gateway | |
|---|---|---|
| App-based driver starts a session | Fails | Works |
| Load management | Static fallback, or stops | Continues on the mesh |
| Billing records | At risk | Captured locally, synced later |
| §14a curtailment (wired Steuerbox) | Depends on the link | Enforced across the mesh |
| Remote session control and support | Fails | Pauses until the link returns |
| Dynamic tariff steering | Fails | Falls back to the last known plan |
| Market-based demand response | Fails | Pauses until the link returns |
| Predictive maintenance telemetry | Lost | Buffered locally, uploaded later |
| Third-party RFID roaming | Fails | Pauses until the link returns |
| Network infrastructure per bay | Cabling, SIMs, fees | None |
The middle block is the honest trade. Cloud capabilities do degrade without a connection — but they degrade by pausing or falling back, not by breaking, and the degradation is contained to the function that genuinely needed the network. On a cloud-dependent site the same outage takes the charging with it.
When you need a gateway, and when you don’t
A gateway earns its place when a site needs remote operation or support at a distance, wants to charge against a dynamic tariff, participates in grid services, benefits from predictive maintenance across a portfolio, accepts third-party roaming cards, or falls under §14a EnWG. In practice that describes most commercial and mixed-use sites, and a growing share of larger residential ones.
Small residential buildings where every driver is a resident with the app frequently don’t need one at all — and can add one later, since it joins the existing mesh rather than requiring a re-install or a rewire.
That upgrade path is the practical point. Choosing offline-first at the start doesn’t foreclose cloud capability; it just stops you paying to run a network to every bay in order to get it.
FAQ
Does offline-first mean I give up cloud features? No. A site gateway adds remote session control, dynamic tariff steering, demand response, predictive maintenance, portfolio reporting and roaming. What offline-first changes is that none of those sit in the critical path of a driver plugging in.
What happens when the internet drops? Cloud functions pause or fall back — tariff steering reverts to the last known plan, telemetry buffers locally, roaming settlement and remote support wait for the link. Driver authorisation, power delivery, load management and billing records are unaffected.
Can chargers respond to dynamic electricity prices? Yes, via the gateway — live price feeds only exist in the cloud. On an overnight residential site this is usually where the largest achievable energy saving is.
Does demand response need the internet? It depends which kind. §14a EnWG curtailment runs over the gateway’s local wired connection to the grid operator’s control box and is enforced across the mesh without internet. Market-based demand response involves an outside counterparty, so it does need connectivity.
How does predictive maintenance work if the site is usually offline? The site isn’t offline — the gateway keeps a connection. Telemetry streams continuously when the link is up and buffers locally when it isn’t, so an intermittent connection delays the analysis rather than losing the data.
Do I need a gateway for every charger? No — one per site. The gateway joins the same mesh the chargers use to coordinate, which is why connectivity cost scales per site rather than per parking space.
Can I add a gateway later? Yes. It joins the existing mesh, so no charger needs to be replaced or rewired.
Does load management still work without the gateway? Yes. Balancing runs between the chargers over the mesh, with no central controller and no cloud in the loop.
Related guides
- EV charging without internet: a complete guide — the offline-first architecture from first principles
- How to cut EV charging infrastructure costs — why per-bay networking dominates the budget
- EV charging for apartment & multi-tenant buildings — per-tenant billing and shared power
Planning a site that needs both reliability and online features? See the CONNECT Edge Gateway or talk to our team.