Send vendor-specific data

OCPP functional block P — DataTransfer.

OCPP cannot model everything a manufacturer builds. DataTransfer is the protocol's escape hatch: a message that carries an opaque payload the specification deliberately says nothing about.

You will need it eventually. Display control, proprietary diagnostics, a vendor's own firmware or configuration mechanism — anything a manufacturer added beyond the standard tends to live here.

curl -X POST https://api.flowion.io/v1/chargers/$CHARGER/commands/data-transfer \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"vendor_id": "com.example.chargers",
       "message_id": "SetDisplayText",
       "data": "{\"line1\":\"Welcome\"}"}'

vendor_id should be a reverse domain name. data is a string, whatever the vendor's format actually is — JSON, CSV, a bare number. The platform does not parse it, validate it, or care.

The four answers#

The last two are the useful ones. unknown_vendor_id usually means you have the identifier wrong or the station is a different model than you think. unknown_message_id means the vendor id is right but the firmware does not implement that message — often a version difference across a fleet that looks homogeneous.

The one command that answers with data#

DataTransfer is the only OCPP command whose response can carry a payload rather than just a status. A station's answer may include its own data field, reported back exactly as received:

{ "status": "accepted", "data": "{\"firmware\":\"2.3.1\",\"uptime\":98122}" }

Interpreting it is between you and the vendor.

Stations can send it too#

DataTransfer is bidirectional. A station may send one to the CSMS — proprietary events, diagnostics, whatever the manufacturer decided.

There is no domain concept for these, because vendor-specific by definition means there is nothing protocol-neutral to map them to. They are recorded in the command history, which is the only place a payload the platform cannot interpret is kept:

curl https://api.flowion.io/v1/chargers/$CHARGER/commands \
  -H "Authorization: Bearer $TOKEN"

If you are integrating with hardware that reports something interesting this way, that endpoint is where to look for it.

Use it sparingly#

Everything sent through DataTransfer is outside the protocol, which means:

• It is not portable. A payload built for one manufacturer is meaningless to another. Every vendor in a mixed fleet needs its own code path.
• It is not validated. Nothing checks your payload before it goes out. Errors surface as a status from the station, if at all.
• It is not modelled. Effects do not appear as transactions, statuses or meter values. If a DataTransfer changes something, only you know.
• It is undocumented by the specification. Your reference is whatever the manufacturer gave you.

So: reach for a standard message first. If OCPP models what you want, use that. Keep vendor-specific integrations behind an interface in your own code, because the second manufacturer will do it differently.

Getting the details#

There is nothing this documentation can tell you about a specific vendor's messages. Ask the manufacturer for their OCPP integration or DataTransfer documentation — most publish one, and it is often the only place a station's more interesting capabilities are written down.

Endpoints#

Commands · Command History