StatusNotification: what the connector is doing

The message

// Charge point -> CSMS
[2, "19223202", "StatusNotification", {
  "connectorId": 1,
  "errorCode": "NoError",
  "status": "Charging",
  "timestamp": "2026-08-11T09:12:04Z",
  "info": "Session active",
  "vendorId": "ExampleVendor",
  "vendorErrorCode": ""
}]

// CSMS -> charge point
[3, "19223202", {}]

Note the empty response. The CSMS acknowledges but cannot reject — this is the charger reporting reality, not requesting permission.

The nine states

The two suspends are not the same

This distinction is worth getting right because it changes what you tell the driver and what you tell operations.

• SuspendedEV — the car stopped drawing. Usually a full battery. Nothing is wrong; the driver should be told charging is complete and asked to move the vehicle.
• SuspendedEVSE — the charger stopped supplying, typically because of smart charging limits or a site power constraint. The driver is waiting on you, not on their car.

Reporting both as “paused” means a driver whose car is full sits waiting, and a driver being curtailed thinks their car is finished.

Error codes

errorCode is present on every StatusNotification, and NoError is the normal value. When it is not, it is telling you something specific:

PowerMeterFailure deserves special handling. A charger with a broken meter can still deliver energy, and it will still send MeterValues — they just will not be true. Any transaction on a connector reporting this is a billing dispute waiting to happen; block it rather than invoice from it.

The state machine

A normal session walks a predictable path, and deviations from it are diagnostic:

Available ──plug in──► Preparing ──authorised──► Charging
                                              │
                        ┌─────────────────────┼─────────────────────┐
                        ▼                     ▼                     ▼
                 SuspendedEV           SuspendedEVSE            Finishing
                (battery full)      (curtailed by CSMS)      (session over)
                        │                     │                     │
                        └─────────────────────┴────────► Finishing ─┴──unplug──► Available

What the deviations tell you:

• Stuck in Preparing — authorisation is failing, or the vehicle is not handshaking. A cluster of these at one site points at a reader or connectivity problem.
• Stuck in Finishing — the driver has not unplugged. This is the state to trigger idle fees and notifications from.
• Available straight to Faulted with no session — hardware degrading on its own.
• Rapid oscillation between states — usually a flapping connection rather than genuine state changes.

Mapping to OCPI

If you operate a CPO platform, this message is the origin of the EVSE status you publish to roaming partners through OCPI Locations.

The last row is the one teams forget. A charger that has gone silent has no OCPP status at all, and the honest OCPI answer is UNKNOWN rather than the last value you happened to receive. Publishing a stale AVAILABLE is how a roaming partner sends a driver to a dead charger.

Production lessons

• Handle connectorId: 0 as the charge point. Never create a connector record for it.
• Distinguish the two suspends in your UI. They mean opposite things to a driver.
• Block transactions on PowerMeterFailure. Energy without trustworthy metering is unbillable.
• Store status history, not just current state. Fault patterns are only visible over time, and it is the evidence for a warranty claim.
• Alert on GroundFailure immediately — it is a safety condition, not an availability one.
• Age out status. A status is only as good as the connection that delivered it; combine it with Heartbeat liveness before publishing availability.
• Watch Preparing dwell time per site. It is one of the earliest indicators of an authorisation or hardware problem.