OCPP 1.6 Command Purposes and Request/Response Examples

This page covers 14 commands with their direction, purpose and complete JSON frames for debugging. Examples follow the OCPP 1.6 request and response structures.

Message Format and Usage

• Request CALL: [2, "unique-message-id", "Action", {request payload}].
• Successful response CALLRESULT: [3, "same-message-id", {response payload}]. The response does not repeat the action name.
• Protocol error CALLERROR: [4, "same-message-id", "ErrorCode", "Error description", {}].
• Use a new message ID for each request. The response must use the corresponding request ID. Replace the example timestamps, device IDs, tokens and transaction IDs when debugging.
• An empty object {} is a valid payload and must not be omitted. Accepted usually acknowledges a request; verify subsequent notifications to confirm the actual transaction or device state.

Command Index

• BootNotification
• Heartbeat
• Authorize
• StatusNotification
• StartTransaction
• MeterValues
• StopTransaction
• RemoteStartTransaction
• RemoteStopTransaction
• ChangeAvailability
• UnlockConnector
• Reset
• DataTransfer
• TriggerMessage

BootNotification

Direction: Charging station → server.

Purpose: Register the station vendor, model and other information after startup. Accepted confirms registration; interval is the heartbeat interval in seconds. Do not proceed directly to a transaction after Rejected or Pending.

Request:

[
  2,
  "ocpp16-001",
  "BootNotification",
  {
    "chargePointVendor": "devTest",
    "chargePointModel": "QA",
    "firmwareVersion": "1.0"
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-001",
  {
    "status": "Accepted",
    "currentTime": "2026-11-08T08:00:00Z",
    "interval": 60
  }
]

Heartbeat

Direction: Charging station → server.

Purpose: Keep the connection alive and obtain the server time. The request payload is an empty object; currentTime in the response can be used for clock synchronization.

Request:

[
  2,
  "ocpp16-002",
  "Heartbeat",
  {}
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-002",
  {
    "currentTime": "2026-11-08T08:00:00Z"
  }
]

Authorize

Direction: Charging station → server.

Purpose: Check whether an idTag may be used before charging. Inspect idTagInfo.status; Blocked and other denied statuses must not be treated as successful authorization.

Request:

[
  2,
  "ocpp16-003",
  "Authorize",
  {
    "idTag": "QA-TAG"
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-003",
  {
    "idTagInfo": {
      "status": "Accepted"
    }
  }
]

StatusNotification

Direction: Charging station → server.

Purpose: Report the connector status and error code. Connector 1 is available with no error in this example. An empty response acknowledges receipt.

Request:

[
  2,
  "ocpp16-004",
  "StatusNotification",
  {
    "connectorId": 1,
    "errorCode": "NoError",
    "status": "Available",
    "timestamp": "2026-11-08T08:00:00Z"
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-004",
  {}
]

StartTransaction

Direction: Charging station → server.

Purpose: Report the start of a transaction and its initial meter reading. Save the integer transactionId assigned by the server for subsequent metering and transaction termination.

Request:

[
  2,
  "ocpp16-005",
  "StartTransaction",
  {
    "connectorId": 1,
    "idTag": "QA-TAG",
    "meterStart": 1000,
    "timestamp": "2026-11-08T08:00:00Z"
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-005",
  {
    "transactionId": 101,
    "idTagInfo": {
      "status": "Accepted"
    }
  }
]

MeterValues

Direction: Charging station → server.

Purpose: Upload connector meter samples. The cumulative energy reading is 1000 Wh. For an active transaction, use the transactionId returned by StartTransaction.

Request:

[
  2,
  "ocpp16-006",
  "MeterValues",
  {
    "connectorId": 1,
    "transactionId": 101,
    "meterValue": [
      {
        "timestamp": "2026-11-08T08:00:00Z",
        "sampledValue": [
          {
            "value": "1000",
            "measurand": "Energy.Active.Import.Register",
            "unit": "Wh"
          }
        ]
      }
    ]
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-006",
  {}
]

StopTransaction

Direction: Charging station → server.

Purpose: End an existing transaction and report the final meter reading. The final reading of 1100 Wh minus the initial reading gives 100 Wh. transactionId must match the StartTransaction response.

Request:

[
  2,
  "ocpp16-007",
  "StopTransaction",
  {
    "transactionId": 101,
    "timestamp": "2026-11-08T08:10:00Z",
    "meterStop": 1100,
    "idTag": "QA-TAG",
    "reason": "Local"
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-007",
  {}
]

RemoteStartTransaction

Direction: Server → charging station.

Purpose: Request charging on a connector using an idTag. Accepted acknowledges the command; the station must still send StartTransaction to report the actual transaction.

Request:

[
  2,
  "ocpp16-008",
  "RemoteStartTransaction",
  {
    "connectorId": 1,
    "idTag": "QA-TAG"
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-008",
  {
    "status": "Accepted"
  }
]

RemoteStopTransaction

Direction: Server → charging station.

Purpose: Request termination of a specified transaction. The station should send StopTransaction after accepting the request. Accepted alone does not confirm that the transaction has ended.

Request:

[
  2,
  "ocpp16-009",
  "RemoteStopTransaction",
  {
    "transactionId": 101
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-009",
  {
    "status": "Accepted"
  }
]

ChangeAvailability

Direction: Server → charging station.

Purpose: Set a connector to Operative or Inoperative. connectorId=0 addresses the entire station. This example disables connector 1; StatusNotification reports the resulting state.

Request:

[
  2,
  "ocpp16-010",
  "ChangeAvailability",
  {
    "connectorId": 1,
    "type": "Inoperative"
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-010",
  {
    "status": "Accepted"
  }
]

UnlockConnector

Direction: Server → charging station.

Purpose: Request connector unlocking. status=Unlocked indicates success; inspect other response statuses when unlocking fails.

Request:

[
  2,
  "ocpp16-011",
  "UnlockConnector",
  {
    "connectorId": 1
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-011",
  {
    "status": "Unlocked"
  }
]

Reset

Direction: Server → charging station.

Purpose: Request a station restart. Soft requests a soft reset and Hard a hard reset. Accepted acknowledges the request; confirm recovery after reconnection and registration.

Request:

[
  2,
  "ocpp16-012",
  "Reset",
  {
    "type": "Soft"
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-012",
  {
    "status": "Accepted"
  }
]

DataTransfer

Direction: Bidirectional (example: charging station → server).

Purpose: Exchange vendor-specific data. vendorId identifies the vendor and messageId identifies the operation. Accepted means that the extension request was accepted.

Request:

[
  2,
  "ocpp16-013",
  "DataTransfer",
  {
    "vendorId": "devTest",
    "messageId": "GetChargeInstruction",
    "data": ""
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-013",
  {
    "status": "Accepted"
  }
]

TriggerMessage

Direction: Server → charging station.

Purpose: Ask the station to send a specific message. This example triggers Heartbeat. After Accepted, expect a separate Heartbeat CALL from the station.

Request:

[
  2,
  "ocpp16-014",
  "TriggerMessage",
  {
    "requestedMessage": "Heartbeat"
  }
]

Response (returned by the receiver of the request):

[
  3,
  "ocpp16-014",
  {
    "status": "Accepted"
  }
]