DataTransfer
The vendor extension escape hatch, unchanged in purpose from 1.6.
- Version
- OCPP 2.0.1
- Direction
- Either direction
- Functional block
- Data Transfer
DataTransfer also exists in OCPP 1.6, with a different payload. See the OCPP 1.6 version.
Still the way manufacturers send what the standard does not cover, in either direction. vendorId is required, messageId and data are optional.
It matters less in 2.0.1 than it did in 1.6, because the device model and display messages absorbed much of what vendors previously had to invent.
Request
| Field | Type | Required | Description |
|---|---|---|---|
vendorId | string | Required | Identifies the vendor namespace. |
messageId | string | Optional | Identifies the message within that namespace. |
data | any | Optional | The payload. Any JSON value in 2.0.1, where 1.6 required a string. |
[2, "19223201", "DataTransfer", {
"vendorId": "com.acmecharging",
"messageId": "SetLedPattern",
"data": { "pattern": "breathe", "colour": "cyan" }
}]Response
| Field | Type | Required | Description |
|---|---|---|---|
status | DataTransferStatusEnumType | Required | Whether the receiver understood it. |
data | any | Optional | Optional response payload. |
statusInfo | StatusInfoType | Optional | Reason code. |
[3, "19223201", {
"status": "Accepted"
}]Values
DataTransferStatusEnumType
| Value | Meaning |
|---|---|
Accepted | Understood and processed. |
Rejected | Understood but refused. |
UnknownMessageId | The vendorId is known; the messageId is not. |
UnknownVendorId | The vendorId is not known. |
Implementation notes
`data` is a real JSON value in 2.0.1, not the double-encoded string 1.6 forced on you. Code ported from 1.6 that JSON-parses this field will fail.
UnknownVendorId remains the correct answer to a vendor you do not support — not Rejected.
Heavy reliance on DataTransfer is still a portability warning sign. Check whether the device model already covers what you are extending.