Menu

Send manufacturer-specific data

Reach the features a charger maker built beyond the standard set, such as display control or proprietary diagnostics, and read the answer.

2 min readEdit this page
On this page

Charger makers build features of their own: control of the display, proprietary diagnostics, their own configuration tools. You can reach them through Flowion by sending the message the manufacturer documents, and read the charger's answer, payload included.

POST/v1/charging-stations/$CHARGER/commands/data-transferbash
curl -X POST \
  "$API/charging-stations/$CHARGER/commands/data-transfer" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"vendorId": "com.example.chargers",
       "messageId": "GetUptime",
       "data": "{\"verbose\":true}"}'
200Response
{
  "status": "Accepted",
  "data": "{\"firmware\":\"2.3.1\",\"uptime\":98122}"
}
FieldRequiredWhat to send
vendorIdyesThe manufacturer's identifier, usually a reversed domain name
messageIdnoWhich of the manufacturer's messages
datanoThe body, in whatever format the manufacturer specifies

data is a string in both directions, whatever the format inside it: JSON, CSV or a bare number. Flowion passes it through as it is, without reading or checking it, and hands back the charger's own data exactly as it arrived.

The values for all three fields come from the manufacturer. Ask them for their integration documentation; most publish one, and it is often where a charger's most useful extras are written down.

Read the answer

The call waits for the charger, so the charger has to be online. A 200 means it answered; status says how:

statusMeaningWhat to do
AcceptedUnderstood and doneRead data if you expected a reply
RejectedUnderstood and refusedCheck the payload against the manufacturer's documentation
UnknownMessageIdThe manufacturer is right, the message is notThis firmware does not have the message. Chargers of one model on different firmware often differ here
UnknownVendorIdThe charger does not recognise the manufacturerCheck vendorId, and that the charger is the model you think

The failure codes are the same as for any call that waits on a charger: 409 when it is offline, 504 when it does not answer in about 35 seconds. See Sending commands.

Find what you sent

Every message you send is kept in the charger's command history, with the charger's answer:

GET/v1/charging-stations/$CHARGER/commandsbash
curl "$API/charging-stations/$CHARGER/commands" \
  -H "Authorization: Bearer $TOKEN"

Messages a charger sends on its own, including manufacturer-specific ones, appear in its inbound message log for seven days. Filter with action=DataTransfer. Flowion records these but does not act on them. Reading the log needs the ocpp.diagnostics.read permission.

Keep manufacturer code in one place

Everything you build on this is specific to one manufacturer, and sometimes to one firmware line:

  • A payload for one make means nothing to another, so a mixed fleet needs one code path per manufacturer.

  • Flowion does not check the payload, so a mistake shows up only as the charger's status.

  • Whatever the message changes on the charger does not show up in sessions, statuses or meter readings unless the charger reports it.

Use the standard features first: settings, restarts, availability. Keep manufacturer messages behind one interface in your own code, so the second manufacturer is an addition rather than a rewrite.

Endpoints

Commands

In the API reference