As electric vehicle (EV) adoption continues to accelerate worldwide, interoperability between charging stations and charging management platforms has become a critical requirement. The Open Charge Point Protocol (OCPP) was created to solve this challenge by providing a standardized communication protocol between charging stations and central management systems.
Whether you are developing a Charge Point Operator (CPO) platform, integrating charging stations from multiple vendors, or troubleshooting communication issues with chargers such as Teltonika TeltoCharge, understanding OCPP is essential.
This article explains the fundamentals of OCPP 1.6, the most commonly deployed version today, and covers important concepts including BootNotification, Heartbeat, StartTransaction, ReserveNow, TriggerMessage, Remote Start, Remote Stop, and charging session simulation.
What is OCPP?
OCPP (Open Charge Point Protocol) is an open communication standard that enables electric vehicle charging stations (Charge Points) to communicate with a backend platform called a Central System or Central Management System (CMS).
Without OCPP, each charging station manufacturer would require its own proprietary management software.
With OCPP, a charging station from one manufacturer can communicate with a management platform developed by another vendor.
Benefits include:
- Vendor independence
- Easier charger management
- Remote diagnostics
- Smart charging capabilities
- Transaction management
- Firmware updates
- Reservation management
- Real-time monitoring
OCPP 1.6 Architecture
An OCPP 1.6 deployment consists of two primary components:
Charge Point (CP)
The physical EV charging station installed in the field.
Examples:
- Teltonika TeltoCharge
- ABB Terra
- Alfen chargers
- Wallbox chargers
- EVBox stations
Central System (CSMS/CMS)
The backend platform responsible for:
- Monitoring chargers
- Starting and stopping charging sessions
- Managing users
- Processing transactions
- Collecting meter values
- Performing diagnostics
Communication is usually established over WebSockets.
Example connection:
wss://ocpp.example.com/CentralSystemService/CP001
OCPP Message Format
OCPP 1.6 uses JSON arrays.
CALL Message
Request sent by one side:
[
2,
"123",
"Heartbeat",
{}
]
Where:
| Element | Meaning |
|---|---|
| 2 | Message Type (CALL) |
| 123 | Unique Message ID |
| Heartbeat | Action |
| {} | Payload |
CALLRESULT Message
Successful response:
[
3,
"123",
{
"currentTime":"2026-06-07T10:00:00Z"
}
]
CALLERROR Message
Error response:
[
4,
"123",
"NotImplemented",
"Action not supported",
{}
]
BootNotification
The first message sent by a charging station after connecting to the Central System.
Example from a Teltonika TeltoCharge charger:
[
2,
"3",
"BootNotification",
{
"chargePointModel":"TeltoCharge_EVC1010P",
"chargePointVendor":"Teltonika Energy",
"chargePointSerialNumber":"6000165377",
"firmwareVersion":"v1.10.9"
}
]
The Central System should respond:
[
3,
"3",
{
"status":"Accepted",
"currentTime":"2026-06-07T12:00:00Z",
"interval":300
}
]
The interval indicates how frequently Heartbeat messages should be sent.
Heartbeat
Heartbeat messages keep the connection alive and synchronize the charger’s clock.
Request:
[
2,
"10",
"Heartbeat",
{}
]
Response:
[
3,
"10",
{
"currentTime":"2026-06-07T12:00:00Z"
}
]
Heartbeats are essential because:
- They verify connectivity.
- They synchronize timestamps.
- They allow backend systems to detect offline chargers.
Authorize
Before charging starts, many stations request authorization.
Request:
[
2,
"20",
"Authorize",
{
"idTag":"ABC123"
}
]
Response:
[
3,
"20",
{
"idTagInfo":{
"status":"Accepted"
}
}
]
StartTransaction
A common misconception is that the Central System initiates a StartTransaction request.
In OCPP 1.6, StartTransaction is normally sent by the Charge Point to the Central System after:
- An EV is connected.
- Authorization succeeds.
- Charging begins.
Example:
[
2,
"30",
"StartTransaction",
{
"connectorId":1,
"idTag":"ABC123",
"meterStart":1000,
"timestamp":"2026-06-07T12:05:00Z"
}
]
Response:
[
3,
"30",
{
"transactionId":12345,
"idTagInfo":{
"status":"Accepted"
}
}
]
The transaction ID returned by the backend uniquely identifies the charging session.
RemoteStartTransaction
If you want to start charging from the backend, the correct OCPP command is not StartTransaction.
The Central System must send:
[
2,
"40",
"RemoteStartTransaction",
{
"idTag":"ABC123",
"connectorId":1
}
]
Response:
[
3,
"40",
{
"status":"Accepted"
}
]
The charging station then decides whether charging can actually begin.
StopTransaction
When charging ends, the charger sends:
[
2,
"50",
"StopTransaction",
{
"transactionId":12345,
"meterStop":1350,
"timestamp":"2026-06-07T13:00:00Z"
}
]
Response:
[
3,
"50",
{
"idTagInfo":{
"status":"Accepted"
}
}
]
ReserveNow
ReserveNow allows a charging connector to be reserved for a specific user.
Request:
[
2,
"60",
"ReserveNow",
{
"connectorId":1,
"expiryDate":"2026-06-07T14:00:00Z",
"idTag":"ABC123",
"reservationId":1001
}
]
Response:
[
3,
"60",
{
"status":"Accepted"
}
]
Possible statuses include:
- Accepted
- Faulted
- Occupied
- Rejected
- Unavailable
TriggerMessage
TriggerMessage allows the backend to request that a charger immediately send a specific message.
Common use cases:
- Force a Heartbeat
- Force a StatusNotification
- Force a MeterValues report
- Force a BootNotification
Example:
[
2,
"70",
"TriggerMessage",
{
"requestedMessage":"Heartbeat"
}
]
Response:
[
3,
"70",
{
"status":"Accepted"
}
]
After acceptance, the charger sends the requested message.
Simulating a Charging Session
Many developers want to verify that a charger is operational without physically plugging in an EV.
Typical test sequence:
- Charger connects.
- BootNotification.
- Heartbeat.
- StatusNotification (Available).
- RemoteStartTransaction.
- Charger accepts.
- EV plugs in.
- StartTransaction.
- MeterValues.
- StopTransaction.
Important:
Most chargers, including Teltonika TeltoCharge devices, will not generate a StartTransaction simply because the backend requests it. The charger must detect a valid charging condition such as:
- Connected vehicle
- Successful authorization
- Pilot signal state
- Energy transfer initiation
Therefore, if a charger responds with “NotImplemented” or refuses a transaction, it may indicate that the requested operation is unsupported or that physical charging conditions have not been met.
Understanding “NotImplemented” Errors
A common OCPP error response is:
[
4,
"123",
"NotImplemented",
"Action not supported",
{}
]
Possible causes:
- Unsupported OCPP feature.
- Vendor-specific limitation.
- Incorrect message format.
- Unsupported optional profile.
- Invalid direction of the message.
For example:
- StartTransaction is CP → CS.
- RemoteStartTransaction is CS → CP.
Sending StartTransaction from the backend to the charger may result in an error because that action is defined in the opposite direction.
OCPP Profiles in Version 1.6
OCPP 1.6 supports several functional profiles:
Core Profile
- BootNotification
- Heartbeat
- Authorize
- StartTransaction
- StopTransaction
Firmware Management
- UpdateFirmware
- FirmwareStatusNotification
Reservation Profile
- ReserveNow
- CancelReservation
Remote Trigger Profile
- TriggerMessage
Smart Charging Profile
- SetChargingProfile
- ClearChargingProfile
Remote Trigger Profile
- RemoteStartTransaction
- RemoteStopTransaction
Teltonika TeltoCharge and OCPP 1.6
Teltonika TeltoCharge charging stations support OCPP 1.6 JSON communication and can integrate with third-party backend systems.
Typical OCPP interactions include:
- BootNotification
- Heartbeat
- StatusNotification
- Authorize
- StartTransaction
- StopTransaction
- MeterValues
- RemoteStartTransaction
- RemoteStopTransaction
When integrating TeltoCharge devices, always verify the specific firmware version and supported OCPP profiles, as supported features may vary between firmware releases.
Conclusion
OCPP 1.6 remains the dominant protocol for EV charging infrastructure worldwide. Understanding messages such as BootNotification, Heartbeat, Authorize, StartTransaction, ReserveNow, TriggerMessage, and RemoteStartTransaction is essential for anyone developing or integrating charging management platforms.
When working with chargers such as the Teltonika TeltoCharge series, understanding the direction of OCPP messages and the distinction between charger-initiated and backend-initiated operations can prevent many integration issues and significantly reduce troubleshooting time.
A well-designed OCPP implementation enables reliable charger management, seamless interoperability, and scalable EV charging infrastructure for the future.
