Start sending DC data
Pleevi supports DC (fast) Chargers as well as AC Chargers. In the tutorial, we focussed on sending AC Data. In this page, we'll explain everything you need to know for DC Charging.
Publishing DC Transactions to MQTT
For DC the transaction format is slightly different. Instead of maxPower, requestedMinEnergy and requestedMaxEnergy, we have instead powerCurveId, batteryCapacity and requestedMinStateOfCharge and requestedMaxStateOfCharge. To differentiate in case these fields are not yet set, you'll also need to set type to 'dc'.
Given DC charging always uses three phases, we don't need noChargingPhases or usedChargingPins for DC Transactions.
An example transaction could look like:
{
"assetId": "charger-A1",
"transactionId": "550e8400-e29b-41d4-a716-446655440000",
"timestamp": "2025-11-05T08:48:00.000Z",
"startTime": "2025-11-05T08:48:00.000Z",
"stopTime": null,
"estimatedDepartureTime": "2025-11-05T17:48:00.000Z",
"priority": 0,
"profileId": "employees",
"driverId": "badge-1234",
"type": "string",
"powerCurveId": "bus2024-my-brand",
"batteryCapacity": 400000,
"initialStateOfCharge": 42.28,
"requestedMinStateOfCharge": 95,
"requestedMaxStateOfCharge": 100
}
For reference, the full schema for a DC Transaction is:
DC MQTT Transaction
- string
- null
- string
- null
- string
- null
- string
- null
- integer
- null
- number
- null
- number
- null
- number
- null
The unique identifier of the charging pole asset. This matches the name in the site configuration.
The unique identifier for this transaction. This is generated by the charging pole and must be globally unique (e.g. a UUID).
The timestamp when the transaction state changed (e.g. started, updated, EV suspended, stopped, etc).
The reason why the transaction message is sent (e.g. started, updated, EV suspended, stopped, etc).
The timestamp when the transaction started (i.e. when the vehicle was connected and charging began).
stopTime object
The timestamp when the transaction stopped (i.e. when the vehicle disconnected). This can be null/omitted if the transaction is still ongoing.
estimatedDepartureTime object
The estimated time when the vehicle will depart and no longer be connected to the charging pole. This can be null/omitted if not yet known but is required for the transaction to be included for optimization. It can be added later through an 'Update' event. If the estimated departure time changes, an 'Update' event must be sent with the new estimated departure time. If the vehicle leaves earlier than the estimated departure time, it might not have received the requested amount of energy. If it leaves after the estimated departure time, the optimizer has less flexibility in planning the vehicle and will result in less optimal schedules. If a profile_id is passed and the corresponding profile is configured, the estimatedDepartureTime will be set to the profile's default duration after startTime if not provided in the transaction.
The priority of the transaction. This is used to determine which transactions to optimize first when there is not enough capacity to optimize all transactions. Lower values indicate higher priority.
Possible values: >= 0 and <= 10
The profile to use for this transaction. This can be used to set default values for requestedMinEnergy, requestedMaxEnergy and estimatedDepartureTime if they are not provided in the transaction. The profile must be configured in the portal or through the API
defaultdriverId object
Driver profile associated with the transaction. This can be used to overwrite departure time and requested energy for specific drivers.
The type of the transaction, must be 'dc' for DC transactions
dcpowerCurveId objectrequired
The id of the DC power curve (power to state of charge), as configured through the API / the portal, that this vehicle follows. This can be null/omitted if not yet known but is required for the transaction to be included for optimization. It can be measured beforehand by draining the battery of the vehicle to almost zero and allowing it to charge at max power until its fully charged, continously noting the power it uses.
batteryCapacity object
The (current) full capacity of the battery (in Wh). i.e. this should be the energy in the battery if the state of charge is 100%. If the battery is degraded, the battery_capacity should be decreased reflecting this degradation. If there is a difference between technical capacity (what theoretically the capacity is) and operationl capacity (what it actually is in practice), the operational is preferred. This can be null/omitted if not yet known but is required for the transaction to be included for optimization. It can be added later through an 'Update' event.
initialStateOfCharge object
The initial state of charge (in percentage) of the vehicle when it arrived. This can be null/omitted if not yet known but is required for the transaction to be included for optimization. It can be added later through an 'Update' event or the latest value can be sent through an energyMeasurement's currentStateOfCharge.
State of Charge in percentage (0-100%)
Possible values: >= 0 and <= 100
requestedMinStateOfCharge object
The minimum state of charge (in percentage) that the vehicle needs to have by the estimated departure time. This can be null/omitted if not yet known but is required for the transaction to be included for optimization. It can be added later through an 'Update' event.
State of Charge in percentage (0-100%)
Possible values: >= 0 and <= 100
requestedMaxStateOfCharge object
The maximum state of charge (in percentage) that the vehicle can charge to. This can be null/omitted if not yet known but is required for the transaction to be included for optimization. It can be added later through an 'Update' event. This should be greater than or equal to requestedMinStateOfCharge. If you don't know the maximum or want to charge a fixed amount, you can set it equal to the requestedMinEnergy. If we can fully charge the vehicle, this should be equal to the batteryCapacity.
State of Charge in percentage (0-100%)
Possible values: >= 0 and <= 100
Publishing DC Measurements to MQTT
For measurements, the format is the same but currentStateOfCharge has been added. This is important so the optimizer can now how much of the energy actually went into the battery. If the currentStateOfCharge is not sent over, an estimation will be done on the difference of the energyValue between the start of the transaction and now.
{
"assetId": "charger-A1",
"timestamp": "2024-07-29T15:51:28.071Z",
"energyValue": 1030404,
"powerValue": 7000,
"currentStateOfCharge": 85.49
}
DC MQTT Measurement
- number
- null
The unique identifier of the asset. This matches the name in the site configuration. This can be a metered device such as a charging pole or a battery, a subcollector meter or any (virtual) device supplying energy data (metered, estimated or calculated).
The timestamp when the measurement was taken
The energy (in Wh) that has been delivered/received by the asset up to the timestamp. This can be an absolute value that indicates the meter value across the lifetime of the meter (e.g. for a charging pole that keeps increasing across transactions). For charging poles, it can also be a relative one, that only includes the energy charged since the start of the transaction.
The power (in W) measured at the timestamp for this asset
currentStateOfCharge object
State of charge of the battery in percentage. Can be null / omitted if not available or if there is no battery connected to this asset. For charging poles, this should be the state of charge of the connected EV.
State of Charge in percentage (0-100%)
Possible values: >= 0 and <= 100
Site Configuration
In the device_list of the Site Configuration, you can add a DC device as follows:
{
"name": "LR34_001",
"collector": "main_collector",
"type": "dc_charging_pole",
"max_power": 250000
}
The main difference with an AC Charging Pole device is the new type and max_power instead of line_current.
The full schema is:
DC Charging Pole
The name of the device itself. This value will be used as the asset ID in the rest of the API.
The name of the collector to which this device is connected.
dc_charging_poledc_charging_poleThe maximum power in Watt for the charging pole itself / connection to the charging pole.