OCPP standardises most of the communication between a charger and its management software. But every manufacturer has its own features: printing a custom message on the screen, sending data from a device-specific sensor, talking to a local payment terminal and so on. For data that has no equivalent in the standard, OCPP offers an escape hatch: the DataTransfer message.

Message structure

DataTransfer can be sent in both directions: from the charger to the CSMS or from the CSMS to the charger. It contains three fields:

  • vendorId (required): The manufacturer or organisation that defines the data. Usually in reverse domain format, for example com.examplebrand.
  • messageId (optional): A label identifying the type of message.
  • data (optional): The data being carried. It is sent as text and usually contains JSON.

Example:

[2, "12001", "DataTransfer", {"vendorId": "com.examplebrand", "messageId": "CableTemperature", "data": "{\"connector\":1,\"tempC\":48}"}]

The reply contains a status and optional data. Status values:

  • Accepted: The message was understood and processed.
  • Rejected: The message was understood but not accepted.
  • UnknownVendorId: The other side does not recognise this vendorId.
  • UnknownMessageId: The vendorId is known but the messageId is not recognised.

Where is it used?

  • Screen messages: OCPP 1.6J has no standard command for screen messages. Some manufacturers show prices or a welcome text through DataTransfer. In OCPP 2.0.1 and 2.1 this is replaced by SetDisplayMessage.
  • Additional sensor data: Cable temperature, door-open sensors, fan status and so on.
  • Payment terminal integration: Transaction results from a card reader fitted to the charger.
  • Local network features: Vendor-specific load sharing information.
  • Country-specific requirements: Extra data fields required in some markets.

Risks and limits

DataTransfer is powerful, but used carelessly it weakens OCPP's greatest advantage: interoperability.

  • Lock-in risk: If you base a function entirely on DataTransfer, that function only works with that manufacturer's chargers and software that supports it.
  • Lack of documentation: The meaning of vendorId and messageId values varies from manufacturer to manufacturer and is often poorly documented.
  • Difficult testing: Standard test tools cannot validate the content of these messages.
  • Security: The data field is free text; incoming data must always be validated.

The right approach

  1. Check the standard first: If the function you need already exists in OCPP (for example a temperature reading via MeterValues), do not use DataTransfer.
  2. Consider the newer version: OCPP 2.0.1 and 2.1 standardised many functions that require DataTransfer in 1.6J.
  3. Document it: For every vendorId and messageId you use, keep a written record of the fields, sample data and expected reply.
  4. Accept in a controlled way: Returning UnknownVendorId or UnknownMessageId for messages you do not recognise makes the other side's behaviour predictable.

When you see DataTransfer in the logs

When a new charger model connects, you may see many DataTransfer messages in the logs. Find out from the manufacturer what they are; some are purely diagnostic and can be ignored. Messages that go unanswered or keep getting UnknownVendorId may indicate a missing integration the charger expects. Our article on how to read OCPP logs can guide you here.

DataTransfer in OCPP 2.0.1 and 2.1

The DataTransfer message is kept in the newer versions and works with the same logic. However, the 2.0.1 device model makes it possible to define vendor-specific components and variables within a standard structure. As a result, much configuration and monitoring data that used to travel through DataTransfer can now be managed with GetVariables, SetVariables and NotifyReport. If you are designing a new integration, it is recommended to check first whether you can solve it with the device model.

Storing it on the management software side

Even if you do not process incoming DataTransfer messages, it is useful to store them in raw form. Later, when solving a problem with a manufacturer or enabling a new feature, these records are the only source that shows what the charger actually sent.

Conclusion

DataTransfer is a tool that provides flexibility where OCPP's standard messages are not enough. But every use means giving up a little interoperability. Üreticy's OCPP software is hardware-agnostic; it offers every function that can be managed with standard messages regardless of brand, and makes all DataTransfer traffic visible in the logs.