Use case

EV charging management, alongside OCPP

Chargers talk OCPP to your CPMS — that stays. ConnectMQ carries everything around it: grid meter, battery and PV data for load management, live connector and session status for operator dashboards and driver apps, and events between your own backend services.

No card required

Example message

PUBLISH charging/austin-04/grid-meter/power

{"ts":"2026-10-22T18:05:00Z","import_kw":342.8,"limit_kw":400,"pv_kw":12.4,"battery_kw":-60.0,"sessions":9}

QoS 1 · TLS 8883 · PUBACK

The problem

OCPP alone doesn’t run the site

OCPP connects each charger to the CPMS, but a charging site depends on more: the grid connection meter, on-site batteries and PV, the building load and the apps that need live availability. Integrating each of these point-to-point with the CPMS — and fanning charger status out to apps, maps and support tools — becomes the bottleneck as the network grows.

How it works

  1. 1

    Site devices publish

    A site controller or gateway publishes grid import, battery state of charge, PV output and transformer temperature to the site’s topics, read over Modbus or the device’s own API.

  2. 2

    The CPMS shares charger events

    Your CPMS keeps managing chargers over OCPP and publishes connector status, session start and stop and meter values to MQTT for every other consumer.

  3. 3

    Load management decides

    Your load-management service subscribes to site and charger data and calculates the power available per charger; the CPMS applies it to the chargers as OCPP charging profiles.

  4. 4

    Apps and operators see it live

    Driver apps and operator dashboards subscribe over secure WebSocket to retained connector status, and threshold rules alert operations when a site nears its grid limit.

ConnectMQ

What it needs from the broker

Retained availability

Retained status per connector means an app or map shows live availability the moment it connects, then every change.

Fan-out without load on the CPMS

The CPMS publishes an event once; apps, billing, support and analytics each subscribe instead of all calling the CPMS API.

Separation per site and partner

Per-topic ACLs keep site controllers, fleet or roaming partners and internal services to the topics they are allowed to see.

Fast signals for load management

Meter data flows as it is measured, and limit commands to site controllers use QoS 1 on their own topics.

What you get

  • Grid connection, batteries and chargers in one live view
  • Load management fed by measured site data, not static limits
  • Live charger availability in apps without polling the CPMS
  • Faults and grid-limit events flagged while drivers are on site
Example topics
charging/austin-04/grid-meter/power
charging/austin-04/battery/state              (retained)
charging/austin-04/cp-07/connector-1/status   (retained)
charging/austin-04/limits/set

Industries that run this use case

Frequently asked questions

Does MQTT replace OCPP for EV chargers?

No. OCPP remains the protocol between chargers and the charging station management system. MQTT complements it by moving site energy data, charger status and session events between your CPMS, load-management service, apps and dashboards. ConnectMQ does not speak OCPP to chargers itself.

How do I build dynamic load management for an EV charging site?

Measure the grid connection and other site loads, publish those readings over MQTT, and let a load-management service calculate the power available per charger. The CPMS then sets the limits through OCPP smart charging profiles. MQTT keeps the loop from measurement to decision fast and decoupled.

Can driver apps show live charger availability over MQTT?

Yes. Publish connector status as retained messages per charger; the app subscribes over secure WebSocket, gets the current status instantly and then every change. Read-only ACLs make sure apps cannot publish anything.

Build it on ConnectMQ

Start on the Free plan — no card required — connect your first devices today and upgrade when you go live.