OCPP 1.6J sample messages

These are the JSON frames a charge point and a CSMS exchange on OCPP 1.6 over WebSocket. Each request is a CALL. The reply is a CALLRESULT with the same unique ID — or a CALLERROR if something is wrong.

The Open Charge Alliance published OCPP 1.6 in 2015. J is the JSON binding (there is also SOAP). Most implementations follow Edition 2 (28 September 2017). The charger opens wss:// with subprotocol ocpp1.6. Core is 16 messages; the full edition has 28 across six profiles. Download the official spec.

Launch the simulator and send these yourself · BootNotification · Session messages · 2.0.1 samples

Message shape

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

Only one unanswered CALL may be outstanding in each direction. If boot looks accepted in your UI but Authorize never comes back, you are missing a CALLRESULT — not an HTTP webhook.

BootNotification

First message after the socket opens. The charger identifies itself. The CSMS returns Accepted, Pending, or Rejected, plus a heartbeat interval in seconds.

JSON[
  2,
  "a7k2-boot-01",
  "BootNotification",
  {
    "chargePointVendor": "Chargeflux",
    "chargePointModel": "CF-AC7 Type 2",
    "chargePointSerialNumber": "CF-DEMO-A7K2",
    "firmwareVersion": "1.6.0-cf"
  }
]

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

Pending and Rejected rules, plus Heartbeat: BootNotification.

When each message is sent

One local session

1. Connect. BootNotification → Accepted.
2. StatusNotification Available, then Preparing when the cable is in.
3. Authorize → Accepted.
4. StartTransaction → transactionId 1001. Status Charging.
5. MeterValues on the configured interval.
6. StopTransaction (reason Local). Status Finishing, then Available.

JSON[
  2,
  "s1",
  "Authorize",
  {
    "idTag": "TAG-1001"
  }
]

JSON[
  3,
  "s1",
  {
    "idTagInfo": {
      "status": "Accepted"
    }
  }
]

JSON[
  2,
  "s2",
  "StartTransaction",
  {
    "connectorId": 1,
    "idTag": "TAG-1001",
    "meterStart": 0,
    "timestamp": "2026-08-14T10:16:01.000Z"
  }
]

JSON[
  3,
  "s2",
  {
    "transactionId": 1001,
    "idTagInfo": {
      "status": "Accepted"
    }
  }
]

JSON[
  2,
  "s3",
  "MeterValues",
  {
    "connectorId": 1,
    "transactionId": 1001,
    "meterValue": [
      {
        "timestamp": "2026-08-14T10:17:01.000Z",
        "sampledValue": [
          {
            "value": "1850",
            "measurand": "Energy.Active.Import.Register",
            "unit": "Wh"
          }
        ]
      }
    ]
  }
]

JSON[
  2,
  "s4",
  "StopTransaction",
  {
    "transactionId": 1001,
    "meterStop": 5550,
    "timestamp": "2026-08-14T10:19:10.000Z",
    "reason": "Local"
  }
]

More field notes: charging session messages. App start: RemoteStartTransaction. Roaming sits on a different protocol — see OCPI vs OCPP.

This page covers Core, not firmware, reservations, or smart charging. It is not certification. 2.0.1 sessions use TransactionEvent — those samples are separate.

More

• BootNotification — The charger introduces itself. Heartbeat keeps the line alive.
• Connector status — StatusNotification and the nine connector states in plain language.
• Charging session messages — Authorize, StartTransaction, MeterValues, and StopTransaction.
• RemoteStartTransaction — How the office starts or stops a session from the CSMS.

• OCPP 2.0.1 sample messages
• 1.6 vs 2.0.1 vs 2.1
• OCPI vs OCPP
• What is OCPP?

FAQ

Last reviewed August 2026 · Chargeflux.io