OCPP 2.0.1 sample messages

Same CALL / CALLRESULT / CALLERROR envelope as 1.6J. Different actions. A session is TransactionEvent (Started / Updated / Ended), not StartTransaction and StopTransaction.

The Open Charge Alliance released 2.0.1 in 2020. It is not compatible with 1.6. Edition 3 is IEC 63584. Subprotocol: ocpp2.0.1. Official spec download.

Launch the simulator (set protocol to 2.0.1) · TransactionEvent · 1.6J samples

How to read an OCPP 2.0.1 message

The envelope is the same JSON array as 1.6J. Only the action names and payloads change.

CALL       [2, "unique-id", "ActionName", { payload }]
CALLRESULT [3, "unique-id", { payload }]
CALLERROR  [4, "unique-id", "ErrorCode", "why it failed", { details }]

2.0.1 talks about a Charging Station with one or more EVSEs, each with connectors. That is why you will see evseId next to connectorId.

A first sample: BootNotification (2.0.1)

Triggered as soon as the ocpp2.0.1 WebSocket opens. Identity now sits under chargingStation, and the station must say why it booted.

JSON[
  2,
  "cf-boot-201",
  "BootNotification",
  {
    "reason": "PowerUp",
    "chargingStation": {
      "model": "CF-AC7 Type 2",
      "vendorName": "Chargeflux",
      "firmwareVersion": "1.6.0-cf",
      "serialNumber": "CF-DEMO-A7K2"
    }
  }
]

JSON[
  3,
  "cf-boot-201",
  {
    "status": "Accepted",
    "currentTime": "2026-08-14T10:15:03.000Z",
    "interval": 300
  }
]

Full trigger rules: OCPP 2.0.1 BootNotification.

When each OCPP 2.0.1 message is triggered

A complete 2.0.1 session (sample)

1. Socket opens with subprotocol ocpp2.0.1. BootNotification → Accepted.
2. StatusNotification reports EVSE 1 Available, then Occupied when the cable is in.
3. Authorize for the idToken → Accepted.
4. TransactionEvent Started (the station picks the transactionId string).
5. TransactionEvent Updated carries periodic meter samples.
6. TransactionEvent Ended closes the session.

JSON[
  2,
  "t1",
  "TransactionEvent",
  {
    "eventType": "Started",
    "timestamp": "2026-08-14T10:16:01.000Z",
    "triggerReason": "Authorized",
    "seqNo": 0,
    "transactionInfo": {
      "transactionId": "tx-1001"
    },
    "evse": {
      "id": 1,
      "connectorId": 1
    },
    "idToken": {
      "idToken": "TAG-1001",
      "type": "ISO14443"
    }
  }
]

JSON[
  2,
  "t2",
  "TransactionEvent",
  {
    "eventType": "Updated",
    "timestamp": "2026-08-14T10:17:01.000Z",
    "triggerReason": "MeterValuePeriodic",
    "seqNo": 1,
    "transactionInfo": {
      "transactionId": "tx-1001"
    },
    "evse": {
      "id": 1,
      "connectorId": 1
    },
    "meterValue": [
      {
        "timestamp": "2026-08-14T10:17:01.000Z",
        "sampledValue": [
          {
            "value": 1850,
            "measurand": "Energy.Active.Import.Register",
            "unitOfMeasure": {
              "unit": "Wh"
            },
            "context": "Sample.Periodic"
          }
        ]
      }
    ]
  }
]

Field notes: TransactionEvent. Remote start from the CSMS: RequestStartTransaction.

1.6J names you should not send on 2.0.1

• StartTransaction / StopTransaction → TransactionEvent
• RemoteStartTransaction → RequestStartTransaction
• idTag string → idToken object
• Nine 1.6 connector statuses → five 2.0.1 connectorStatus values

Side-by-side: OCPP 1.6 vs 2.0.1 vs 2.1. Still supporting fleets on 1.6? Keep the OCPP 1.6J sample messages.

Related guides

• OCPP 2.0.1 BootNotification — chargingStation identity, reason, and Accepted / Pending / Rejected.
• OCPP 2.0.1 status notification — EVSE + connector statuses: Available, Occupied, Reserved, Unavailable, Faulted.
• TransactionEvent — Started, Updated, and Ended — the 2.0.1 replacement for Start/Stop/MeterValues.
• RequestStartTransaction — How the CSMS remotely starts or stops a 2.0.1 session.

• OCPP 2.0.1 simulator
• OCPP 2.1 — what 2.1 adds (planned in Chargeflux)
• Open the OCPP simulator — set protocol to 2.0.1

FAQ

Last reviewed August 2026 · Chargeflux.io