Step 2: Start sending data
Each site configuration is linked to an MQTT topic. This topic is included in the response body when a new site is created, like we did in the previous step.
Lost your MQTT topic? No worries—retrieve the site details via the API. View API Docs.
It's currently not possible to get the credentials to the mqtt cluster through the API. You should have received these from us but if not, you can contact our support
Publishing measurements and transactions to MQTT
To start sending data, configure an MQTT client to publish messages from the charging station. This is typically done within a local PLC, an EMS platform or another device that bridges the Pleevi solution with local infrastructure.
There are two types of messages that should be sent over MQTT:
- Energy Measurements - Provides the latest energy status of a metered device. We require these to be sent at least every 5 minutes but ideally every minute.
- Transactions - Provides details about active charging sessions. These are OCPP-like transactions, enhanced with driver departure time and requested energy. These should be sent on an event-basis.
The topics that each of these need to be send to can be found on the Site payload when retrieving or creating a site. View API Docs
Energy Measurements
These messages provide the latest energy measurement status of a metered device, such as a charging pole, subcollector meter, or any device supplying energy data (metered, estimated, or calculated).
| Fieldname | Required | Description |
|---|---|---|
assetId | Yes | Unique id of the asset (a metered device, this should match the name of the device in the site configuration) |
timestamp | Yes | ISO 8601 timestamp of when the measurement was taken. |
energyValue | Yes | The measured energy value on the electricity meter in Wh. |
powerValue | Yes | The power measured at this device in W. |
currentStateOfCharge | No | State of charge as a percentage (0-100). Required for BESS devices, optional for charging poles with connected EVs. |
JSON Structure:
{
"assetId": "<ASSET_ID>",
"timestamp": "2024-05-28T10:52:00+00:00",
"energyValue": 2371835,
"powerValue": 3463.99
}
for charging stations, energyValue can be both a cummulative counter (absolute value) or a relative counter (value since the start of the session).
Transactions
Transaction messages provide data on active charging sessions. Smart charging decisions and power optimizations are based on these messages.
JSON Structure:
{
"assetId": "6d1e358e-8f8c-488d-b234-9564c3c282be",
"transactionId": "d9108f64-669d-411c-a963-9c365cbc5dcc",
"timestamp": "2023-02-23T09:43:33+00:00",
"transactionState": "Started",
"type": "ac",
"startTime": "2023-02-23T09:43:33+00:00",
"stopTime": null,
"noChargingPhases": "3Phase",
"usedChargingPins": ["pin1", "pin2", "pin3"],
"maxPower": 7000,
"requestedMinEnergy": 20000,
"requestedMaxEnergy": 24000,
"estimatedDepartureTime": "2023-02-23T17:00:00+00:00",
"priority": 0,
"profileId": "profile-1"
}
| Fieldname | Required | Description |
|---|---|---|
assetId | Yes | Unique id of the (virtual) asset, must match the device name in the site configuration. |
transactionId | Yes | Unique id of the transaction. Must be the same across all events within the same charging session. |
timestamp | Yes | ISO 8601 timestamp of when the transaction state changed. |
transactionState | Yes | Started, Updated, SuspendedEV or Ended. |
type | No | "ac" for AC transactions (default if omitted), "dc" for DC transactions. See Sending DC data for DC-specific fields. |
startTime | Yes | Datetime of when the transaction started. |
stopTime | No | Datetime filled in after the session stopped. Should be null while the session is active. |
noChargingPhases | No | Number of charging phases: "1Phase", "2Phase" or "3Phase". |
usedChargingPins | No | A list indicating the pins used for charging. 1 phase charging transactions should only include one pin ["pin2"] while 3 phase charging transactions should include all pins ["pin1", "pin2", "pin3"]. The names should link to the pin_to_phase_mapping found on the linked device on the site_configuration. |
maxPower | No | The maximum power (in W) the vehicle is able to charge. Required for optimization. If not available in the "Started" event, it can be sent in a follow-up "Updated" event. |
requestedMinEnergy | No | Integer, the minimum amount of energy (in Wh) to be charged in this session. Required for optimization. The value should stay the same through the entire transaction, unless the user has changed the initial requested energy. |
requestedMaxEnergy | No | Integer, the maximum amount of energy (in Wh) to be charged in this session. Required for optimization. The value should stay the same through the entire transaction, unless the user has changed the initial requested energy. |
estimatedDepartureTime | No | ISO 8601 datetime indicating when the car will leave. Required for optimization. Can be provided later in an "Updated" event. |
priority | integer (0-10) to indicate the priority of a charging session/transaction. Lower values indicate higher priority. Default value is 0, meaning highest priority. | |
profileId | No | Profile id related to this transaction. Used to retrieve configured default estimatedDepartureTime, requestedMinEnergy and requestedMaxEnergy. Defaults to "default". See Profiles. |
transactionStates- Started: This transaction should be published as soon as the EV begins charging. Ideally, all required information is already available at this point.
- Updated: If some information was missing during the "Started" transaction, you can publish an "Updated" transaction once the missing data becomes available.
- SuspendedEV: This event is triggered by the EV itself, for example, when the battery is fully charged or the EV pauses charging for other reasons. The EV stops charging but remains physically connected to the charging station.
- Ended: This event should be published when the charging session finishes, and the EV is physically disconnected from the charging station.
requestedMinEnergy and requestedMaxEnergy- If only one requested energy value exists, set both
requestedMinEnergyandrequestedMaxEnergyto the same value. - If you do not know this information you can rely on default profiles that can be configured via our portal or API See Profiles.
estimatedDepartureTime- The estimated departure time should always be provided. Either immediately on the Started transaction or as a follow-up Updated transaction.
- If you do not know this information you can rely on default profiles that can be configured via our portal or API See Profiles.
Need Help?
If you have any issues, contact our support team at support@pleevi.ai.