OCPP 1.6 and 2.0.1: Protocol Support in Dynamo CSMS

Understand how Dynamo CSMS supports OCPP 1.6 and 2.0.1, how chargers connect via WebSocket, and which commands are available for each protocol.

The Open Charge Point Protocol (OCPP) is the industry-standard communication protocol between EV chargers and a Charge Station Management System (CSMS). Dynamo CSMS supports both OCPP 1.6 and OCPP 2.0.1, allowing you to manage chargers across a wide range of hardware vintages from a single platform.

How chargers connect

Charge points connect to Dynamo CSMS over a persistent WebSocket connection. Each charge point authenticates using its charge_point_id as part of the WebSocket URL path:

wss://csms.dynamo.example.com/ocpp/1.6/{charge_point_id}
wss://csms.dynamo.example.com/ocpp/2.0.1/{charge_point_id}

Once connected, the charge point sends a BootNotification message to identify itself. Dynamo CSMS responds with an Accepted status and a heartbeat interval. From that point on, the charger periodically sends Heartbeat messages to confirm it is still online.

Dynamo CSMS uses the heartbeat interval to determine connectivity status. A charge point is marked offline if no heartbeat is received within 2× the configured interval. You can tune this interval using the HeartbeatInterval configuration key.

OCPP 1.6 vs. OCPP 2.0.1

Both protocol versions are supported in production. The right choice depends on your hardware capabilities and use case requirements.

OCPP 1.6

OCPP 1.6 is the most widely deployed version of the protocol. The majority of chargers currently in the field support OCPP 1.6J (the JSON/WebSocket variant, as opposed to the older SOAP variant).

Key characteristics:

• JSON over WebSocket (OCPP 1.6J)
• Broad hardware support across all major manufacturers
• Core feature set: remote start/stop, availability control, charging profiles, reservations
• Authentication via RFID tags or remote authorization
• Smart charging via SetChargingProfile

API endpoints for OCPP 1.6 commands are available under /api/v1/ocpp16/.

OCPP 2.0.1

OCPP 2.0.1 is the current standard, designed to address limitations in 1.6 and introduce richer capabilities for modern deployments.

Key characteristics:

• Enhanced security with TLS mutual authentication and message signing
• Device management and monitoring improvements
• ISO 15118 Plug & Charge (PnC) support for seamless authentication
• More granular smart charging with transaction cost display
• Improved error reporting and diagnostics
• Device model for detailed hardware component tracking

If you are deploying new hardware that supports OCPP 2.0.1, prefer it over 1.6 for better security posture and access to smart charging features.

Heartbeat monitoring

Every connected charge point sends periodic Heartbeat messages. Dynamo CSMS records each heartbeat and exposes the timestamp via the API:

GET /api/v1/installer/charge-points/{charge_point_id}/connection-status

{
  "charge_point_id": "cp_01HXYZ123ABC",
  "connected": true,
  "last_heartbeat": "2026-05-01T10:22:00Z",
  "ocpp_version": "1.6"
}

You can also subscribe to connectivity webhooks to receive notifications when a charge point goes offline or reconnects.

Status notifications

Charge points send StatusNotification messages whenever a connector’s status changes. Dynamo CSMS processes these in real time and updates the connector record accordingly. You can retrieve the current status of all connectors on a charge point at any time:

GET /api/v1/chargepoints/{charge_point_id}/connectors

OCPP 1.6 supported commands

Dynamo CSMS exposes the following OCPP 1.6 commands as REST API endpoints under /api/v1/ocpp16/{charge_point_id}/. Each request is translated into the corresponding OCPP message and forwarded to the charge point over its active WebSocket connection.

Command	Endpoint	Description
RemoteStartTransaction	POST /api/v1/ocpp16/remote_start_transaction	Instruct a charge point to start a charging session on a specified connector, optionally with a specific idTag for authorization
RemoteStopTransaction	POST /api/v1/ocpp16/remote_stop_transaction	Instruct a charge point to end an active transaction by transactionId
ChangeAvailability	POST /api/v1/ocpp16/change_availability	Set a charge point or individual connector to Operative or Inoperative
SetChargingProfile	POST /api/v1/ocpp16/set_charging_profile	Push a smart charging profile to limit or shape power delivery on a connector
ClearChargingProfile	POST /api/v1/ocpp16/clear_charging_profile	Remove a previously applied charging profile from a connector
Reset	POST /api/v1/ocpp16/reset	Trigger a soft or hard reboot of the charge point
TriggerMessage	POST /api/v1/ocpp16/trigger_message	Request the charge point to send a specific OCPP message immediately, such as StatusNotification or MeterValues
ReserveNow	POST /api/v1/ocpp16/reserve_now	Reserve a connector for a specific idTag until a given expiry time
CancelReservation	POST /api/v1/ocpp16/cancel_reservation	Cancel an active reservation by reservationId

Example: remote start transaction

POST /api/v1/ocpp16/remote_start_transaction
Authorization: Bearer <your-api-key>
Content-Type: application/json

{
  "charge_point_id": "cp_01HXYZ123ABC",
  "connector_id": 1,
  "id_tag": "RFID-ABC123"
}

{
  "status": "Accepted",
  "transaction_id": null
}

A status of Accepted means the charge point acknowledged the command. The transaction ID is not available at this point — it is assigned by the charge point once the session actually begins and delivered via a StartTransaction notification.

Example: set charging profile

POST /api/v1/ocpp16/set_charging_profile
Authorization: Bearer <your-api-key>
Content-Type: application/json

{
  "charge_point_id": "cp_01HXYZ123ABC",
  "connector_id": 1,
  "cs_charging_profiles": {
    "charging_profile_id": 1,
    "stack_level": 0,
    "charging_profile_purpose": "TxProfile",
    "charging_profile_kind": "Absolute",
    "charging_schedule": {
      "charging_rate_unit": "W",
      "charging_schedule_period": [
        { "start_period": 0, "limit": 7400 }
      ]
    }
  }
}

Charging profiles with stack_level conflicts can produce unexpected behavior. Higher stack levels take precedence. Review the OCPP 1.6 specification section 3.12 for conflict resolution rules before deploying overlapping profiles.

Error handling

When a command fails, the API returns the OCPP error code alongside an HTTP error response:

{
  "error": "NotSupported",
  "message": "The charge point does not support this command.",
  "charge_point_id": "cp_01HXYZ123ABC"
}

Common OCPP error codes you may encounter:

NotSupported

The charge point does not implement the requested command. This is common with older firmware versions that lack support for features like smart charging or reservations.

InternalError

The charge point encountered an internal error while processing the command. Trigger a TriggerMessage with DiagnosticsStatusNotification to collect diagnostics.

Rejected

The charge point received the command but rejected it based on its local logic. For example, RemoteStart is rejected if the connector is already occupied.

Timeout

Dynamo CSMS did not receive a response from the charge point within the configured timeout window. This typically indicates a connectivity issue.

Charge points

Learn about the charge point resource, connector statuses, and the commissioning lifecycle.

Billing model

Understand how OCPP sessions map to billing records and how tariffs are applied.