Will fleet chargers keep sharing power when the internet fails?

Which functions must survive loss of communications?

A fleet operator on Reddit sought chargers for up to 25 vehicles and explicitly wanted load balancing that did not depend on the cloud. The question is more specific than whether a charger works offline. A charger can continue delivering electricity while losing reporting, authorization, scheduling, or group coordination. Those functions can fail differently. Procurement needs a written description of each failure state, particularly the behavior that keeps the site's electrical limit intact.

Source: Fleet charging - best options for depot chargers?

Identify the controller for each operating layer

Separate three layers: the approved electrical limit, allocation of that power between vehicles, and business functions such as authorization and reporting. Ask which device enforces each layer and what it does when its inputs disappear. A loss of cloud reporting does not necessarily stop local sharing; a lost local controller or site-meter signal may produce a different result. The vendor's instructions for the installed models and firmware must define those states. Do not substitute another manufacturer's product documentation for that evidence.

Illustrative scenario: twelve ports lose their internet link

Illustrative scenario: twelve chargers share a 48 kW operating allocation. During normal operation, six vehicles might receive 8 kW each. If the internet connection fails, a safe system might retain local sharing, reduce each port to a conservative limit, or pause charging. These outcomes have very different dispatch consequences even if all are electrically acceptable. The site should not discover during a storm that its conservative fallback leaves half the vans below their morning target.

Ask for a written failure matrix

Ask the vendor to complete a failure matrix for loss of internet, loss of local network, loss of the meter signal, controller restart, and power restoration. For each event, obtain the aggregate limit, authorization behavior, schedule behavior, alarm destination, and recovery method. Ask whether fallback settings survive a reset and whether a replacement charger must be commissioned into the group before use. An installer should not have to infer these details from an app screenshot.

Verify OCPP scope before switching networks

Open Charge Point Protocol, usually abbreviated OCPP, can help separate charging hardware from a network provider, but it is not a promise that every advanced feature transfers unchanged. Request the supported protocol version, certification or test evidence, and a list of functions that require the original backend. A station might move networks while losing a particular load-management feature. Also clarify administrator ownership, data export, firmware support, subscription termination, and access to commissioning credentials through secure handoff. OCA certifies identified implementations against defined profiles. For example, Smart Charging is an optional profile for an OCPP 1.6 charging station; a Core certificate alone does not establish that capability. Verify the certificate scope, software version, target backend, and the particular migration functions you intend to use.

Source: Open Charge Alliance: OCPP certification program · Open Charge Alliance: OCPP 1.6 certification profiles

Agree on the recovery state before the first communications failure

Ask a bidder to describe a specific sequence: internet access disappears at 11 p.m., the local controller remains powered, and two additional vans connect afterward. Does the system admit those vehicles, recognize their departure priorities, and keep the agreed aggregate limit? Next, consider a restart while the internet is still unavailable. A system that continued an already authorized session might behave differently when starting from a powered-off condition. Obtain answers for both states rather than accepting a demonstration of only the easier one.

Recovery also needs an owner. Suppose connectivity returns after a dispatcher has manually moved a van to the spare bay. The system should reconcile the current port assignment and schedule before old queued commands or alerts are treated as current instructions. Ask what information is retained locally and what is reconstructed when reporting resumes. Missing cloud records do not necessarily prove that no energy was delivered; equally, a recovered connection does not prove that every vehicle reached its target. Compare the vehicle or session evidence with the actual departure plan.

Put these behaviors into procurement acceptance criteria, using observable outcomes instead of promises such as resilient or cloud-ready. The electrical professional verifies that approved operating limits remain enforced. Fleet staff verify authorization, usable charging, alarms, and dispatch readiness. The support agreement should identify who restores each failed layer and what information the operator can collect without changing electrical settings. Keep a dated copy of the accepted configuration. When a vendor proposes a new controller or network subscription, ask whether the previously tested failure behavior changes; a like-for-like billing description is not evidence of like-for-like operation.

Commission the agreed offline states

Run a controlled acceptance exercise with the vendor and electrician. Simulate the agreed communication failures through their approved procedure, observe the total measured load, and check which vehicles still meet their energy targets. Document restoration without improvising changes to protective settings. The fleet should leave with an offline operating plan, a named support path, and a clear threshold for dispatch intervention. Repeat the relevant checks after a controller replacement or major firmware change, rather than assuming a previously demonstrated behavior is permanent.

Put it into practice

A decision table to keep handy