> ## Documentation Index
> Fetch the complete documentation index at: https://dynamo-csms.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 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 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 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:
```bash theme={null}
GET /api/v1/installer/charge-points/{charge_point_id}/connection-status
```
```json theme={null}
{
"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:
```bash theme={null}
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
```bash theme={null}
POST /api/v1/ocpp16/remote_start_transaction
Authorization: Bearer
Content-Type: application/json
{
"charge_point_id": "cp_01HXYZ123ABC",
"connector_id": 1,
"id_tag": "RFID-ABC123"
}
```
```json theme={null}
{
"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
```bash theme={null}
POST /api/v1/ocpp16/set_charging_profile
Authorization: Bearer
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:
```json theme={null}
{
"error": "NotSupported",
"message": "The charge point does not support this command.",
"charge_point_id": "cp_01HXYZ123ABC"
}
```
Common OCPP error codes you may encounter:
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.
The charge point encountered an internal error while processing the command. Trigger a `TriggerMessage` with `DiagnosticsStatusNotification` to collect diagnostics.
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.
Dynamo CSMS did not receive a response from the charge point within the configured timeout window. This typically indicates a connectivity issue.
Learn about the charge point resource, connector statuses, and the commissioning lifecycle.
Understand how OCPP sessions map to billing records and how tariffs are applied.