OCPP Message Types Reference: 1.6 and 2.0.1 Explained

Quick answer: OCPP message types are the named actions a charge point and CSMS exchange over WebSocket in a strict request-response pattern. Every request is a CALL; responses are a CALLRESULT or CALLERROR. OCPP 1.6 defines 28 core actions (plus 11 in the Security Whitepaper). OCPP 2.0.1 Edition 2 defines 64 operations and unifies transactions under TransactionEvent.

OCPP message types define every interaction between a charge point and a CSMS (Charging Station Management System; OCPP 1.6: Central System). 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, maintained by the Open Charge Alliance, 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.

How Is an OCPP Message Formatted?

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 CPMS 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.

Which OCPP 1.6 Messages Are Charger-Initiated?

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

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

Which OCPP 1.6 Messages Are CPMS-Initiated?

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

All 19 CPMS-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.

What Messages Are New in OCPP 2.0.1?

OCPP 2.0.1 introduces a significantly expanded message set organized into functional blocks, as documented in the OCPP 2.0.1 specification from the Open Charge Alliance. 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 CPMS-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 CPMS 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: CPMS 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 CPMS 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 CPMS). 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 CPMS response to MeterValues is always an empty object {}. There is no mechanism for the CPMS 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 (OCPP 1.6, off-peak boost). OCPP 2.0.1 uses ChargingStationMaxProfile instead of ChargePointMaxProfile, and targets an EVSE rather than connectorId: 0 for the station-wide limit:

[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 (OCPP 1.6):

• 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.

Charging profile purposes (OCPP 2.0.1): ChargingStationMaxProfile, ChargingStationExternalConstraints, TxDefaultProfile, TxProfile. There is no ChargePointMaxProfile in 2.0.1.

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 CPMS 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.

How Should You Handle OCPP Errors?

When a CALL message cannot be processed, the receiver sends a CALLERROR instead of a CALLRESULT. The allowed error codes differ by version: OCPP 1.6 defines 10, OCPP 2.0.1 defines 12.

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 (1.6) or FormatViolation (2.0.1) 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?

As enumerated in the OCPP 1.6 specification published by the Open Charge Alliance (first released in 2015), the core profile defines 28 unique actions: 10 charger-initiated and 19 CPMS-initiated, with DataTransfer appearing in both directions. Each action has a corresponding .conf response structure, but these are not counted as separate messages. The OCPP 1.6 Security Whitepaper, whose security extension was introduced in edition 2, adds 11 more actions (signed firmware, certificate management, log upload, and SecurityEventNotification), bringing the full count to roughly 39 when both the core and the security extension are implemented.

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 CPMS 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 CPMS does not support?

The CPMS 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 CPMS 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