What happens when an OCPP charger loses its connection?
Can an OCPP charger keep charging when it goes offline?
Often. Not always. Losing the OCPP connection stops live communication with the CPMS, but it does not necessarily stop the electrical charging function. The outcome depends on charger firmware, local authorisation data, operator settings and rules already stored on the device.
OCPP provides tools for offline operation, but no universal policy. Operators must decide who may start or continue charging, which limits remain active and how transactions are recovered after reconnection.
What happens to a session already in progress?
A session may continue under the last valid local conditions. The charger can store meter values and transaction events, then send the required records when the CPMS connection returns. Capacity, retry behaviour and message flow vary by implementation and OCPP version.
Can a new charging session start offline?
That depends on the authorisation policy. A charger may use a local authorisation list or cached credentials. It may also accept specified identifiers offline. A stricter setup may reject new sessions because the CPMS cannot check the user, tariff, contract or payment method.
Public, workplace, fleet and residential networks may therefore behave differently while using the same protocol. The operator chooses the balance between availability, access control and revenue risk.
What functions are unavailable without the CPMS?
- live status, alarms and remote diagnostics may be delayed;
- remote start, stop and configuration changes may fail;
- new authorisation-list or tariff updates cannot reach the charger;
- dynamic smart-charging instructions may stop changing;
- online payment and roaming services may be unavailable; and
- the CPMS may show the charger as offline while local charging continues.
How amina handles offline authorisation and recovery
amina’s OCPP authentication guide lists LocalAuthorizeOffline and LocalAuthListEnabled as enabled by default. The authorisation cache and unknown offline identifiers are disabled. In that standard setup, an identifier on the local list may start charging offline; an unknown one is rejected. Factory provisioning can change the settings, so check the live values.
The implementation overview lists automatic reconnection, an offline message queue and transaction-state recovery after power loss. The configuration reference provides two CSMS profiles with priority-based fallback. Cst_SilentOfflineTransactions is off by default; enabling it can allow charging when a valid charge-data record is not guaranteed.
The CSMS integration guide documents a direct charger-to-CSMS connection without a proprietary amina cloud. Here, offline means that direct OCPP connection has been lost.
What happens to smart-charging limits?
The charger may keep the last valid profile, a default profile or a local fallback limit. A time-bound profile can expire while offline. The replacement must be defined, especially where the site relies on active load management.
Critical limits should not depend only on a continuous CPMS link. Hardware protection, installation limits and local energy controls still matter.
What happens when the connection returns?
The charger should reconnect, identify itself and transfer the stored records required by the CPMS. The backend must reconcile delayed events without duplicate sessions, wrong energy totals or billing errors. Monitoring and pending configuration updates can then resume.
What should operators test before deployment?
- ongoing and new sessions during mobile, Ethernet or internet loss;
- known, unknown, expired and blocked credentials offline;
- local storage limits and a full buffer;
- power loss while the CPMS connection is down;
- profile expiry and fallback limits;
- reconnection timing, retries and data replay;
- duplicate events and billing reconciliation; and
- alerting when a charger stops reporting.
Offline behaviour belongs in the charger and CPMS acceptance test. An OCPP label alone proves very little about it.