Skip to main content

Start sending data

Alternative ingress methods

This guide covers sending data via MQTT. If you use the Smart OCPP Broker or Eniris Smart Grid One, data ingress is handled automatically and you can skip this step. See Integration Options for a full comparison.

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.

tip

Lost your MQTT topic? No worries—retrieve the site details via the API. View API Docs.

warning

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:

  1. 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.
  2. 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.
info

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).

An example measurement could look like:

{
  "assetId": "charger-A1",
  "timestamp": "2024-07-29T15:51:28.071Z",
  "energyValue": 1030404,
  "powerValue": 7000,
  "currentStateOfCharge": 85.49
}

For reference, the full schema for an Energy Measurement is:

MQTT Measurement

    assetIdAssetid (string)required

    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).

    timestampstring<date-time>required

    The timestamp when the measurement was taken

    energyValueEnergyvalue (number)required

    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.

    powerValuePowervalue (number)required

    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.

    anyOf
    number

    State of Charge in percentage (0-100%)

    Possible values: >= 0 and <= 100

info

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.

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,
  "userId": "default",
  "type": "ac",
  "noChargingPhases": "3Phase",
  "usedChargingPins": [
    "pin1",
    "pin2",
    "pin3"
  ],
  "maxPower": 10500,
  "initialEnergyValue": 1361389,
  "requestedMinEnergy": 30000,
  "requestedMaxEnergy": 30000
}

For reference, the full schema for an AC Transaction is:

AC MQTT Transaction

    assetIdAssetid (string)required

    The unique identifier of the charging pole asset. This matches the name in the site configuration.

    transactionIdTransactionid (string)required

    The unique identifier for this transaction. This is generated by the charging pole and must be globally unique (e.g. a UUID).

    timestampstring<date-time>required

    The timestamp when the transaction state changed (e.g. started, updated, EV suspended, stopped, etc).

    transactionStaterequired

    The reason why the transaction message is sent (e.g. started, updated, EV suspended, stopped, etc).

    startTimestring<date-time>required

    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.

    anyOf
    string
    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.

    anyOf
    string
    priorityPriority (integer)required

    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

    userIdUserid (string)

    The user identifier for this transaction. This should be the badge ID of the user.

    Default value: default
    typeType (string)

    The type of the transaction, must be 'ac' for AC transactions

    Constant value: ac
    Default value: ac
    noChargingPhases object

    The number of phases used for charging.

    anyOf
    string

    Possible values: [3Phase, 2Phase, 1Phase]

    usedChargingPins object

    The pins used for charging. This should match the noChargingPhases field. If noChargingPhases is 3Phase, this should contain 3 pins. If noChargingPhases is 1Phase, this should contain 1 pin.

    anyOf
  • Array [
    • string

    Possible values: [pin1, pin2, pin3]

  • ]
    • maxPower object

    The maximum power (in W) that the vehicle is able to charge. 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. It can be measured by allowing the vehicle to charge at max power for a short period of time and then reading the power it charges at or can be estimated based on the vehicle type or number of charging phases (e.g. 3.5 kW per phase).

    anyOf
    number
    initialEnergyValue object

    The meter value of the charging pole when the transaction started (in Wh). If not sent, it will be based on energyValue of the energy measurements for this charging pole

    anyOf
    number
    requestedMinEnergy object

    The minimum amount of energy (in Wh) that the vehicle needs to have charged 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. If a profile_id is passed and the corresponding profile is configured, the requestedMinEnergy will be set to the profile's default requestedMinEnergy if not provided in the transaction.

    anyOf
    integer
    requestedMaxEnergy object

    The maximum amount of energy (in Wh) that the vehicle can accept. 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 requestedMinEnergy. If you don't know the maximum or want to charge a fixed amount, you can set it equal to the requestedMinEnergy. If a profile_id is passed and the corresponding profile is configured, the requestedMaxEnergy will be set to the profile's default requestedMaxEnergy if not provided in the transaction.

    anyOf
    integer
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 requestedMinEnergy and requestedMaxEnergy to 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.