OCPP 1.6 Core Messages. The 6 Messages That Run Every Charger

OCPP 1.6 has about 30 message types. In practice, six of them handle roughly 90% of everything. Understand these six and you understand how EV charging works at the protocol level.

1. BootNotification

The very first message after connection. The charger announces itself:

{
  "chargePointVendor": "Acme",
  "chargePointModel": "FastCharge-50",
  "chargePointSerialNumber": "SN-2024-001",
  "firmwareVersion": "2.3.1"
}

The backend responds Accepted, Pending, or Rejected. If a charger keeps getting Pending, it's almost always a backend configuration issue. the charger serial exists but hasn't been activated in the CSMS yet.

2. Authorize

User taps RFID, app sends a token, or the charger reads a credit card. Either way, the charger asks: "Is this person allowed to charge?"

Rendering diagram...

Possible responses: Accepted, Blocked, Expired, Invalid, ConcurrentTx (this card is already charging somewhere else).

One detail that saves deployments: smart backends push a Local Authorization List to the charger, so even when the internet drops, known cards can still start sessions. I've seen sites where the 4G was spotty enough that 20% of authorization attempts would fail without a local list. With it, zero failures.

3. StartTransaction

Once authorized, the charger starts a transaction:

{
  "connectorId": 1,
  "idTag": "RFID-ABC123",
  "meterStart": 1000,
  "timestamp": "2026-01-07T14:30:00Z"
}

The backend responds with a transactionId. This number ties together every MeterValues message and the eventual StopTransaction. Without it, billing falls apart.

Rendering diagram...

4. StopTransaction

Session ends. user unplugs, app sends stop, error occurs:

{
  "transactionId": 42,
  "meterStop": 15000,
  "timestamp": "2026-01-07T16:45:00Z",
  "reason": "EVDisconnected"
}

Stop reasons: EVDisconnected, Remote, Local, PowerLoss, EmergencyStop. Each one matters for billing and audit trails.

If the charger loses internet during a session, it must store the StopTransaction offline and send it when connectivity returns. This is non-negotiable. without it you lose revenue on every network dropout. I've seen operators lose thousands of euros per month from chargers that silently dropped StopTransaction messages because the offline queue wasn't implemented properly.

5. MeterValues

While a session is active, the charger sends periodic energy measurements:

{
  "connectorId": 1,
  "transactionId": 42,
  "meterValue": [{
    "timestamp": "2026-01-07T15:00:00Z",
    "sampledValue": [
      {"value": "7500", "measurand": "Energy.Active.Import.Register", "unit": "Wh"},
      {"value": "11.2", "measurand": "Power.Active.Import", "unit": "kW"},
      {"value": "16.1", "measurand": "Current.Import", "unit": "A"}
    ]
  }]
}

This powers the "live charging" screen in apps. The kWh counter climbing in real time? That's MeterValues arriving every 30-60 seconds.

Rendering diagram...

6. StatusNotification

The charger reports connector state changes:

{
  "connectorId": 1,
  "status": "Charging",
  "errorCode": "NoError",
  "timestamp": "2026-01-07T14:31:00Z"
}

The complete cycle

Rendering diagram...

Six messages. That's the core of OCPP 1.6. The remaining ~24 message types exist for remote control, firmware management, diagnostics, and configuration. but these six are what your backend will process thousands of times per day.