Can an OCPP charger keep charging when it goes offline?

Often, yes, but not always. Losing the OCPP connection means the charger can no longer exchange live messages with its CPMS. It does not necessarily mean that the electrical charging function stops. The result depends on the charger firmware, local authorisation data, operator settings and the rules already stored on the device.

 

OCPP provides mechanisms that can support offline operation, but it does not impose one universal policy. Operators must decide which users may start or continue charging, how limits are applied 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 record meter values and transaction events locally, then send the relevant records when the CPMS connection returns. Storage capacity, retry behaviour and the exact 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 locally stored authorisation list or cached credentials. It may also be configured to accept certain identifiers while offline. A stricter deployment may reject new sessions because the CPMS cannot validate the user, tariff, contract or payment method.

 

Public, workplace, fleet and residential networks can therefore behave differently even when they all use OCPP. The operator should define the acceptable 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, remote stop and configuration changes may not work;
  • new authorisation-list or tariff updates cannot reach the charger;
  • dynamic smart-charging commands may stop updating;
  • payment and roaming services that depend on online systems may fail; and
  • the CPMS may show the station as offline even while local charging continues.

How amina handles offline authorisation and recovery

amina’s OCPP authentication guide documents LocalAuthorizeOffline and LocalAuthListEnabled as enabled by default, while the authorisation cache and unknown offline identifiers are disabled by default. In that standard configuration, an identifier on the local list may start charging offline, but an unknown identifier is rejected. Factory provisioning can change these settings, so operators should confirm the live values.

 

The implementation overview lists automatic reconnection, an offline message queue and transaction-state recovery after power loss. The configuration reference also provides two CSMS connection profiles with priority-based fallback. Cst_SilentOfflineTransactions is disabled by default; enabling it can permit charging when a valid charge-data record is not guaranteed.

 

The CSMS integration guide documents a direct charger-to-CSMS connection without a proprietary manufacturer cloud. In this setup, going offline refers to losing that direct OCPP connection to the chosen CSMS.

What happens to smart-charging limits?

The charger may continue using the last valid profile, a default profile or a local fallback limit. Time-bound profiles can expire while the charger is offline. A safe design should define what replaces them, particularly where the site connection depends on active load management.

 

Critical limits should not depend solely on a continuous CPMS connection. Hardware protection, installation limits and any local energy controls remain important.

What happens when the connection returns?

The charger should reconnect, identify itself and transfer the stored information required by the CPMS. The backend then has to reconcile delayed events without creating duplicate sessions, incorrect energy totals or billing errors. Reconnection should also restore monitoring and receive any pending configuration or profile updates.

What should operators test before deployment?

  • ongoing and new sessions during mobile, Ethernet or internet loss;
  • known, unknown, expired and blocked credentials while offline;
  • local storage limits and behaviour when the buffer is full;
  • power loss while both the charger and CPMS connection are unavailable;
  • expiry of charging profiles and local fallback limits;
  • reconnection timing, retry intervals and data replay;
  • duplicate-event and billing reconciliation; and
  • alerting when a charger stops reporting.

Offline behaviour should be part of the charger and CPMS acceptance test. It is a deployment choice, not a capability that can be assumed from an OCPP label alone.