OCPP Message Types Reference: 1.6 and 2.0.1 Explained

OCPP message types define every interaction between a charge point and a Charging Station Management System (CSMS). Each message type corresponds to a specific operation: authorizing a user, starting a transaction, reporting meter data, updating firmware, or configuring smart charging profiles. The Open Charge Point Protocol specifies exactly which party initiates each message, what fields are required, and what response is expected.

OCPP communication follows a strict request-response pattern over WebSocket. Every request is a CALL message containing an action name and payload. The receiver responds with either a CALLRESULT (success) or a CALLERROR (failure). There are no unsolicited responses, no partial acknowledgments, and no message queuing within the protocol itself. Understanding the full catalog of message types is the foundation for building any OCPP-compliant system.

This reference covers every message type in OCPP 1.6 and 2.0.1, organized by direction and protocol version.

If you want version-specific execution guidance beyond the message catalog, see OCPP 1.6 testing and OCPP 2.0.1 testing.

OCPP Message Format

All OCPP messages are JSON arrays transmitted over WebSocket. There are three message types, each identified by a MessageTypeId integer.

CALL (Request) — MessageTypeId 2

[2, "uniqueId-123", "BootNotification", {
  "chargePointVendor": "OCPPLab",
  "chargePointModel": "Emulator-v1"
}]

CALLRESULT (Success Response) — MessageTypeId 3

[3, "uniqueId-123", {
  "currentTime": "2025-03-20T10:00:00.000Z",
  "interval": 300,
  "status": "Accepted"
}]

CALLERROR (Error Response) — MessageTypeId 4

[4, "uniqueId-123", "InternalError",
  "Database connection timeout",
  {"retryAfter": 30}]

The UniqueId ties every response to its request. A charge point or CSMS must never send a CALLRESULT or CALLERROR without a matching pending CALL. If a response is not received within the configured timeout, the sender should treat the request as failed.

OCPP 1.6 Messages — Charger-Initiated

These messages are sent from the charge point to the CSMS. The charge point creates the CALL; the CSMS responds with CALLRESULT or CALLERROR.

Every charger-initiated message expects a .conf response from the CSMS. For example, BootNotification expects a BootNotification.conf containing status, currentTime, and interval. If the CSMS responds with status: Rejected, the charger must retry at the interval specified and must not accept charging sessions until accepted.

OCPP 1.6 Messages — CSMS-Initiated

These messages are sent from the CSMS to the charge point. The CSMS creates the CALL; the charge point responds.

All 18 CSMS-initiated messages follow the same CALL/CALLRESULT pattern. The charge point must implement handlers for every message it claims to support in its feature profile.

OCPP 2.0.1 New Messages

OCPP 2.0.1 introduces a significantly expanded message set organized into functional blocks. Many OCPP 1.6 messages were renamed, split, or consolidated. The following table lists messages that are new in 2.0.1 or substantially changed from 1.6.

New Charger-Initiated Messages (2.0.1)

New CSMS-Initiated Messages (2.0.1)

The most significant architectural change in 2.0.1 is the introduction of TransactionEvent, which consolidates StartTransaction, StopTransaction, and in-transaction MeterValues into a single message with an eventType field (Started, Updated, Ended). This simplifies transaction tracking and eliminates race conditions common in 1.6 implementations.

Key Messages Deep Dive

The following sections provide detailed request/response examples for the six most commonly implemented and debugged OCPP messages.

BootNotification

BootNotification is the first meaningful message a charger sends after establishing a WebSocket connection. It registers the charger with the CSMS and receives time synchronization and heartbeat configuration.

OCPP 1.6 Request:

[2, "boot-001", "BootNotification", {
  "chargePointVendor": "OCPPLab",
  "chargePointModel": "Emulator-Pro",
  "chargePointSerialNumber": "OCPPLAB-001-2025",
  "chargeBoxSerialNumber": "CB-001",
  "firmwareVersion": "2.5.0",
  "iccid": "8901260882902730001",
  "imsi": "310260000000001",
  "meterType": "ACMeter",
  "meterSerialNumber": "MTR-001"
}]

OCPP 1.6 Response (Accepted):

[3, "boot-001", {
  "currentTime": "2025-03-20T10:00:00.000Z",
  "interval": 300,
  "status": "Accepted"
}]

OCPP 2.0.1 Request (restructured with nested chargingStation object):

[2, "boot-001", "BootNotification", {
  "reason": "PowerUp",
  "chargingStation": {
    "model": "Emulator-Pro",
    "vendorName": "OCPPLab",
    "serialNumber": "OCPPLAB-001-2025",
    "firmwareVersion": "2.5.0"
  }
}]

The status field in the response determines charger behavior:

• Accepted: Charger operates normally, sends Heartbeat at the specified interval.
• Pending: CSMS needs more time or configuration. Charger must not accept transactions. Retry at interval.
• Rejected: Charger is not recognized. Charger must not accept transactions. Retry at interval.

A charger stuck in Pending or Rejected is one of the most common deployment issues. Check the serial number, vendor name, and CSMS registration status when troubleshooting.

StartTransaction vs. TransactionEvent

In OCPP 1.6, StartTransaction and StopTransaction are separate messages. In 2.0.1, both are replaced by TransactionEvent.

OCPP 1.6 StartTransaction:

[2, "tx-001", "StartTransaction", {
  "connectorId": 1,
  "idTag": "RFID-ABC123",
  "meterStart": 1500,
  "timestamp": "2025-03-20T10:05:00.000Z"
}]

OCPP 1.6 StartTransaction Response:

[3, "tx-001", {
  "idTagInfo": {
    "status": "Accepted",
    "expiryDate": "2025-12-31T23:59:59.000Z"
  },
  "transactionId": 42
}]

OCPP 2.0.1 TransactionEvent (Started):

[2, "tx-001", "TransactionEvent", {
  "eventType": "Started",
  "timestamp": "2025-03-20T10:05:00.000Z",
  "triggerReason": "Authorized",
  "seqNo": 0,
  "transactionInfo": {
    "transactionId": "TX-20250320-001"
  },
  "idToken": {
    "idToken": "RFID-ABC123",
    "type": "ISO14443"
  },
  "evse": {
    "id": 1,
    "connectorId": 1
  }
}]

OCPP 2.0.1 TransactionEvent (Ended):

[2, "tx-002", "TransactionEvent", {
  "eventType": "Ended",
  "timestamp": "2025-03-20T12:30:00.000Z",
  "triggerReason": "EVDeparted",
  "seqNo": 15,
  "transactionInfo": {
    "transactionId": "TX-20250320-001",
    "stoppedReason": "EVDisconnected"
  },
  "meterValue": [{
    "timestamp": "2025-03-20T12:30:00.000Z",
    "sampledValue": [{
      "value": 32.5,
      "measurand": "Energy.Active.Import.Register",
      "unitOfMeasure": {
        "unit": "kWh"
      }
    }]
  }]
}]

Key differences: In 2.0.1, the transaction ID is a string generated by the charger (not an integer assigned by the CSMS). Meter values can be included directly in TransactionEvent messages, reducing the number of separate MeterValues calls needed during a session.

MeterValues

MeterValues reports energy consumption, power levels, voltage, current, and other electrical measurements during a charging session. It is one of the highest-frequency messages in any OCPP deployment.

OCPP 1.6 MeterValues:

[2, "meter-001", "MeterValues", {
  "connectorId": 1,
  "transactionId": 42,
  "meterValue": [{
    "timestamp": "2025-03-20T10:15:00.000Z",
    "sampledValue": [
      {
        "value": "1.85",
        "context": "Sample.Periodic",
        "format": "Raw",
        "measurand": "Energy.Active.Import.Register",
        "location": "Outlet",
        "unit": "kWh"
      },
      {
        "value": "7200",
        "context": "Sample.Periodic",
        "measurand": "Power.Active.Import",
        "unit": "W"
      },
      {
        "value": "230.1",
        "context": "Sample.Periodic",
        "measurand": "Voltage",
        "unit": "V"
      },
      {
        "value": "31.3",
        "context": "Sample.Periodic",
        "measurand": "Current.Import",
        "unit": "A"
      }
    ]
  }]
}]

Sampling contexts determine when meter values are captured:

Sampled vs. Clock-Aligned: Sample.Periodic values are relative to the transaction start (e.g., every 60 seconds after charging begins). Sample.Clock values align to absolute clock boundaries (e.g., every 15 minutes on the hour: 10:00, 10:15, 10:30). Clock-aligned data is typically used for billing and regulatory reporting because it produces consistent time boundaries across all chargers.

The CSMS response to MeterValues is always an empty object {}. There is no mechanism for the CSMS to reject or request retransmission of meter data within the protocol.

StatusNotification

StatusNotification reports the operational state of a connector or the charge point itself. It is sent whenever a state transition occurs.

OCPP 1.6 StatusNotification:

[2, "status-001", "StatusNotification", {
  "connectorId": 1,
  "errorCode": "NoError",
  "status": "Charging",
  "timestamp": "2025-03-20T10:05:01.000Z",
  "info": "Vehicle connected and charging at 7.2kW",
  "vendorId": "OCPPLab",
  "vendorErrorCode": ""
}]

OCPP 1.6 Status Values:

OCPP 1.6 Error Codes in StatusNotification:

In OCPP 2.0.1, StatusNotification is simplified to report only connectorStatus (Available, Occupied, Reserved, Unavailable, Faulted). Detailed error reporting moves to the NotifyEvent message and the device model.

SetChargingProfile

SetChargingProfile installs a charging profile on a connector for smart charging, load balancing, or demand response. It is the foundation of smart charging in OCPP.

OCPP 1.6 SetChargingProfile (load limiting to 16A):

[2, "profile-001", "SetChargingProfile", {
  "connectorId": 1,
  "csChargingProfiles": {
    "chargingProfileId": 100,
    "stackLevel": 0,
    "chargingProfilePurpose": "TxDefaultProfile",
    "chargingProfileKind": "Absolute",
    "chargingSchedule": {
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [
        {
          "startPeriod": 0,
          "limit": 16.0
        }
      ]
    }
  }
}]

Time-of-use smart charging example (off-peak boost):

[2, "profile-002", "SetChargingProfile", {
  "connectorId": 0,
  "csChargingProfiles": {
    "chargingProfileId": 200,
    "stackLevel": 1,
    "chargingProfilePurpose": "ChargePointMaxProfile",
    "chargingProfileKind": "Recurring",
    "recurrencyKind": "Daily",
    "chargingSchedule": {
      "startSchedule": "2025-03-20T00:00:00.000Z",
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [
        { "startPeriod": 0, "limit": 16.0 },
        { "startPeriod": 25200, "limit": 8.0 },
        { "startPeriod": 72000, "limit": 32.0 }
      ]
    }
  }
}]

This profile limits the entire charge point (connectorId: 0) to 16A from midnight, reduces to 8A at 07:00 (peak hours, startPeriod: 25200 = 7 hours x 3600 seconds), and boosts to 32A at 20:00 (startPeriod: 72000 = 20 hours x 3600 seconds) during off-peak.

Charging Profile Purposes:

• ChargePointMaxProfile: Maximum power for the entire charge point. Applied to connectorId: 0.
• TxDefaultProfile: Default profile applied to all transactions on a connector unless overridden.
• TxProfile: Profile for a specific active transaction. Highest priority for that transaction.

Profiles at higher stackLevel values take precedence when multiple profiles of the same purpose exist. The effective limit is always the minimum of all applicable profiles.

RemoteStartTransaction

RemoteStartTransaction instructs a charger to begin a charging session, typically triggered by a mobile app or backend system. It can optionally include a charging profile for the session.

OCPP 1.6 RemoteStartTransaction:

[2, "remote-001", "RemoteStartTransaction", {
  "connectorId": 1,
  "idTag": "APP-USER-456",
  "chargingProfile": {
    "chargingProfileId": 300,
    "stackLevel": 0,
    "chargingProfilePurpose": "TxProfile",
    "chargingProfileKind": "Absolute",
    "chargingSchedule": {
      "chargingRateUnit": "W",
      "chargingSchedulePeriod": [
        { "startPeriod": 0, "limit": 7400.0 },
        { "startPeriod": 7200, "limit": 11000.0 }
      ]
    }
  }
}]

Response:

[3, "remote-001", {
  "status": "Accepted"
}]

This request starts a session on connector 1 for user APP-USER-456, beginning at 7.4 kW and increasing to 11 kW after 2 hours. The charger will respond Accepted if it can start the session, or Rejected if the connector is unavailable, faulted, or occupied.

After accepting a RemoteStartTransaction, the charger must still send a StartTransaction message to the CSMS once energy transfer actually begins. The RemoteStartTransaction acceptance only means the charger will attempt to start; it does not guarantee the session will begin (the EV may not be plugged in, authorization may fail, etc.).

In OCPP 2.0.1, this message is renamed to RequestStartTransaction and includes an evseId instead of connectorId, along with an optional groupIdToken for group authorization scenarios.

Error Handling

When a CALL message cannot be processed, the receiver sends a CALLERROR instead of a CALLRESULT. OCPP defines these standard error codes:

Best practices for error handling:

1. Always respond. Never leave a CALL unanswered. If you cannot process it, send a CALLERROR.
2. Use specific error codes. FormationViolation is more useful than GenericError when the JSON is malformed.
3. Include error details. The errorDetails object should contain actionable information such as which field failed validation and why.
4. Implement timeouts. If no response arrives within 30 seconds (configurable), treat the request as failed and clean up any pending state.
5. Log everything. Every CALLERROR should be logged with the full request context for debugging.

Frequently Asked Questions

How many message types does OCPP 1.6 define?

OCPP 1.6 defines 28 message types total: 10 charger-initiated and 18 CSMS-initiated. Each message type has a corresponding .conf response structure, but these are not counted as separate messages.

What changed from OCPP 1.6 to OCPP 2.0.1 regarding messages?

OCPP 2.0.1 roughly doubles the message count and reorganizes them into functional blocks. The most impactful change is replacing StartTransaction, StopTransaction, and in-transaction MeterValues with the unified TransactionEvent message. New functional areas include security certificate management, display messaging, device model reporting, and ISO 15118 support. See our detailed comparison guide.

Can I use DataTransfer for anything?

DataTransfer is the escape hatch for vendor-specific functionality not covered by the standard. Both the charger and CSMS can initiate it. Common uses include custom diagnostics, proprietary load management, and feature flags. However, relying heavily on DataTransfer reduces interoperability because each vendor's payloads are different.

What happens if the charger sends a message the CSMS does not support?

The CSMS should respond with a CALLERROR using NotImplemented as the error code. The charger must handle this gracefully. For critical messages like BootNotification, this typically indicates a serious configuration or version mismatch.

How do I test all these message types?

Use an OCPP emulator to simulate both charger and CSMS behavior. A good emulator lets you send any message type with custom payloads, inspect responses, and test error scenarios without physical hardware. This is essential for validating your implementation against the full spec before deploying to production chargers.

Are there differences between OCPP-J and OCPP-S message types?

The message types (actions) are identical between OCPP-J (JSON over WebSocket) and OCPP-S (SOAP over HTTP). The difference is the transport format: OCPP-J uses the JSON array format described in this guide, while OCPP-S wraps the same data in XML/SOAP envelopes. OCPP-J is the dominant implementation today, and OCPP 2.0.1 only supports JSON. Read our WebSocket guide for transport-level details.

What's Next

This reference covers the message catalog. For implementation, start with these focused guides:

• What is OCPP? — Protocol fundamentals and architecture overview
• OCPP 1.6 vs 2.0.1 — Detailed version comparison and migration guidance
• OCPP WebSocket Guide — Connection lifecycle, security, and reconnection strategies
• OCPP Error Codes Reference — Deep dive into every error code with troubleshooting
• Smart Charging Explained — Charging profiles, load management, and demand response