StatusNotification reports the current state of a connector to the CSMS. It must be sent after every state change and after every BootNotification. The three required fields are connectorId, errorCode (always "NoError" when there is no fault), and status — one of 9 enum values: Available, Preparing, Charging, SuspendedEVSE, SuspendedEV, Finishing, Reserved, Unavailable, or Faulted.
What is StatusNotification?
StatusNotification is the mechanism by which a Charge Point keeps the CSMS informed of the physical state of each connector. Every time a connector changes state — a cable is plugged in, a transaction starts, a fault is detected — the Charge Point sends a StatusNotification so the CSMS can update its real-time dashboard and trigger any configured automations.
Unlike most OCPP messages, StatusNotification is always initiated by the Charge Point (it is a CP→CSMS message). The CSMS responds with an empty CALLRESULT — no data, just an acknowledgment.
When to send it
OCPP 1.6 §4.7 defines the following mandatory trigger points (Open Charge Alliance, 2015, §4.7):
- After BootNotification is Accepted — send StatusNotification for every connector to initialize the CSMS state.
- On every connector state change — immediately when the connector transitions to a new status.
- When a fault is detected or cleared — transition to
Faultedand back to the previous state when resolved.
The CSMS has no other way to learn the connector state. If a Charge Point misses a StatusNotification, the CSMS will show a stale status indefinitely — until the next reboot or a manual refresh triggers a new one.
Field reference
| Field | Required | Type / max | Description |
|---|---|---|---|
| connectorId | Yes | integer | Connector index. 0 = entire Charge Point; 1, 2… = individual connectors. |
| errorCode | Yes | enum | Active fault code. Use "NoError" when the connector is healthy. See error code table below. |
| status | Yes | enum | Current connector state. One of 9 values — detailed in the next section. |
| timestamp | No | date-time | UTC time of the status change. Optional in the schema; required by most CSMSes for accurate logging. Always include it. |
| info | No | string / 50 | Free-text description of the status or error. Useful for maintenance notes. |
| vendorId | No | string / 255 | Vendor identifier for OtherError conditions. Required when errorCode is OtherError. |
| vendorErrorCode | No | string / 50 | Vendor-specific error code string. Used alongside vendorId for proprietary fault diagnostics. |
All 9 connector states
Available
The connector is powered, operational, and ready to accept a new session. No cable is plugged in. This is the resting state.
Triggered by: After boot, after a session ends and the EV unplugs, after clearing a reservation.
Preparing
A cable has been plugged in or an idTag has been presented, but authorization or EV communication has not yet completed.
Triggered by: EV plugs in, RFID card tapped, app initiates session.
Charging
Energy is actively flowing from the Charge Point to the EV. Transaction is running.
Triggered by: EV begins drawing current after authorization.
SuspendedEVSE
The Charge Point has paused energy delivery. The transaction is still active but the EVSE side is holding back power — e.g. a smart charging profile has set the limit to 0A.
Triggered by: Smart charging profile triggers a zero-power period; CSMS-commanded pause.
SuspendedEV
The EV has paused its power draw. The Charge Point is ready and willing to deliver power, but the vehicle's BMS is not requesting it — e.g. pre-conditioning, cell balancing.
Triggered by: Vehicle battery management defers charging.
Finishing
The transaction has ended but the connector has not yet returned to Available. Typically the cable is still plugged in.
Triggered by: Transaction ends (StopTransaction sent) but EV has not yet disconnected.
Reserved
A ReserveNow command has been accepted. The connector is held for a specific idTag and will not accept other sessions until the reservation expires.
Triggered by: CSMS sends ReserveNow and Charge Point responds Accepted.
Unavailable
The connector is intentionally out of service — maintenance, firmware update, or a ChangeAvailability command from the CSMS.
Triggered by: ChangeAvailability (Inoperative), firmware update in progress, manual shutdown.
Faulted
A hardware or software fault has been detected. The connector cannot be used until the fault is cleared. errorCode will contain the specific fault type.
Triggered by: Hardware fault detected (GroundFailure, OverVoltage, ReaderFailure, etc.).
State transition rules
Not every transition is valid. The most common valid sequences during a normal session:
Key rule: a connector that enters Faulted should stay in Faulted until the fault is resolved — it must not transition through other states while faulted. When the fault clears, the Charge Point sends a new StatusNotification with the appropriate non-faulted state and errorCode: "NoError".
Error codes
| errorCode | Meaning |
|---|---|
| NoError | No fault present. Must be used in all normal-operation StatusNotification messages. |
| ConnectorLockFailure | The connector lock mechanism failed to engage or disengage. |
| EVCommunicationError | Error in the communication between Charge Point and EV (IEC 61851 / ISO 15118). |
| GroundFailure | Ground fault detected on the connector. Session aborted for safety. |
| HighTemperature | Internal temperature exceeded safe operating limits. |
| InternalError | An internal software or hardware error not covered by another code. |
| LocalListConflict | The local authorization list entry conflicts with the CSMS database. |
| OtherError | A vendor-specific fault not covered by the standard codes. Use with vendorId and vendorErrorCode. |
| OverCurrentFailure | Current exceeded safe limits. |
| PowerMeterFailure | Energy meter is unresponsive or reporting inconsistent values. |
| PowerSwitchFailure | The power switch (contactor/relay) failed to open or close. |
| ReaderFailure | RFID / NFC card reader hardware fault. |
| ResetFailure | The Charge Point failed to complete a reset operation. |
| UnderVoltage | Supply voltage dropped below the operational threshold. |
| OverVoltage | Supply voltage exceeded the safe upper limit. |
| WeakSignal | Cellular or Wi-Fi signal strength is too low for reliable communication. |
connectorId 0 — whole unit status
connectorId 0 refers to the Charge Point as a whole, not any individual connector. It is used to report conditions that affect all connectors simultaneously:
- Setting the entire unit
Unavailable(e.g. maintenance mode) - Reporting a unit-wide
Faultedcondition (e.g. main power failure) - Signaling availability restoration after a firmware update
OCPP 2.0.1 differences
In OCPP 2.0.1, StatusNotification was restructured. The main changes:
- New connector states:
Occupiedreplaces some uses ofCharging/SuspendedEV/SuspendedEVSE/Finishing; operational status is now decoupled into a separateoperationalStatusfield. - evseId + connectorId: Instead of a single flat
connectorId, 2.0.1 uses anevseIdand a nestedconnectorIdto address multi-EVSE units. - Error reporting moved: Hardware fault events are now reported via
NotifyEvent(not StatusNotification), using the component/variable monitoring system.
Common errors
Sending Faulted without an errorCode
When status is Faulted, errorCode must be something other than NoError. A Faulted status with errorCode: "NoError" is technically valid but misleading — use InternalError or OtherError if no specific code applies.
Not sending StatusNotification after boot
The CSMS shows every connector as Unknown until the first StatusNotification arrives. Always iterate over all connectors and send one immediately after BootNotification is Accepted.
Omitting timestamp
Without a timestamp the CSMS assigns its own server time to the event — which may differ from the actual state change time by the message round-trip latency. Always include the Charge Point's local UTC timestamp.
Not sending Finishing before Available
Skipping Finishing and jumping directly to Available after a transaction ends causes the CSMS to miss the cable-still-plugged state. Some CSMSes use this window to send unlock commands or post-session surveys.
Rodolfo Carrillo
OCPP integration engineer and creator of OCPP Tools. All articles are verified against the official OCA specification and tested using the on-site tools.
Build a frame in seconds
Form-driven payload builder — pick fields, get a valid frame, copy to clipboard.
Frequently asked questions
What is the difference between SuspendedEV and SuspendedEVSE?
Must the Charge Point send StatusNotification on every reboot?
What should errorCode be when there is no error?
When should a Charge Point send status Finishing?
What does connectorId 0 mean in StatusNotification?
Is the timestamp field required in StatusNotification?
Sources & further reading
- · Open Charge Alliance. (2015). Open Charge Point Protocol 1.6, Edition 2, §4.7 — StatusNotification. https://openchargealliance.org/my-oca/ocpp/
- · Open Charge Alliance. (2020). Open Charge Point Protocol 2.0.1, §5 — StatusNotification. https://openchargealliance.org/my-oca/ocpp/