MQTT is a lightweight messaging protocol for exchanging data between devices and software applications. MQTT is based on the publish-subscribe principle and is particularly suitable for transmitting measurements, statuses and events between sensors, gateways, energy management systems (EMS), monitoring platforms and cloud systems.

MQTT at a glance

• MQTT transfers messages through a central broker, which distributes them to authorized recipients based on defined topics.
• Publishers and subscribers do not communicate directly. This decouples them technically, although they must use the same topic structure and data model.
• Three Quality of Service levels allow a use-case-specific balance between delivery assurance and communication overhead.
• MQTT defines how messages are transported, but it does not automatically define their data model, unit or technical meaning.

How does MQTT work?

An MQTT system consists of a broker and multiple clients. Clients can publish messages and act as publishers or subscribe to specific messages as subscribers. A client can perform both roles simultaneously.

For example, an energy meter can publish its current active power under a topic such as site/plant/meter/active-power. An EMS or monitoring platform subscribes to this topic. The broker receives the message, checks the access permissions and distributes it to the authorized subscribers.

Topics can be organized hierarchically by site, plant, device and measurement. Wildcards also allow clients to subscribe to multiple levels or groups of devices. The topic structure, data format and technical meaning must be documented so that receiving systems can interpret the data correctly.

MQTT provides three Quality of Service levels. These apply separately to each transmission leg between a sender and a receiver. When communication takes place through a broker, transmission from the publisher to the broker and forwarding from the broker to the subscriber are handled as separate processes. The QoS used for forwarding may therefore be lower than the QoS of the originally published message.

• QoS 0 – at most once: The message is transmitted without an MQTT acknowledgment. It may be lost but causes little communication overhead.
• QoS 1 – at least once: The receiver acknowledges the message. Delivery is assured within the respective transmission leg, although duplicates may occur.
• QoS 2 – exactly once: A multi-stage acknowledgment process ensures that the message is delivered exactly once within the respective transmission leg. This causes the highest communication and processing overhead.

A retained message allows the broker to store the last message published with the retained flag for a topic. New subscribers immediately receive this last stored value. Because the value may be outdated, the receiving application should check its timestamp, validity period and data quality.

The Last Will mechanism also allows a client to define a message that the broker publishes if the connection is lost unexpectedly. Other systems can use this information, for example, to identify that a gateway is no longer available.

Where is MQTT used in energy management?

MQTT is often used to transfer measurements from energy meters, sensors or IoT gateways to an EMS or monitoring platform. These data can include active power, energy consumption, temperatures, operating statuses and alarms.

Another use case is connecting local energy systems to cloud platforms. A gateway can collect and process data from multiple devices before transmitting it to a higher-level system via MQTT. The protocol can also support data exchange between different software applications.

Control commands and setpoints can also be transmitted through MQTT. For control applications, the system must additionally define how the acceptance, execution and actual effect of a command are reported and monitored. Successful message delivery does not automatically confirm that the target device has accepted or implemented the setpoint.

Benefits, limitations and technical requirements

MQTT generates comparatively little protocol overhead and enables the flexible distribution of information to multiple recipients. Its technical decoupling allows additional clients to be integrated without establishing direct communication links to all other participants.

However, the protocol only defines message transport. The topic structure, data format, unit, timestamp, sign convention, data quality and technical meaning must be agreed separately. Without a shared data model, systems may interpret a technically correct message differently.

MQTT is also not inherently real-time capable. Transmission time and availability depend on factors including the network, broker, selected QoS level and participating applications. A different communication solution may therefore be necessary for fast, deterministic protection or control functions.

Secure operation generally requires Transport Layer Security (TLS) encryption, client authentication, differentiated access permissions and a protected broker. The system must also define how to handle reconnections, outdated values, duplicate messages and communication failures.

How can EcoPhi use MQTT?

Depending on the project configuration, EcoPhi can use MQTT to integrate sensors, gateways and external platforms. EcoPhi systems can act as MQTT clients that receive data from defined topics or make plant information available through corresponding topics.

Control commands can also be processed through MQTT if the system architecture is suitable. The specific implementation depends on the available device interfaces, agreed data model, security requirements and intended behavior during communication failures. The system responsible for providing and operating the broker is defined within the respective project architecture. Additional configuration or engineering services may be required.

MQTT summarized

MQTT is a resource-efficient publish-subscribe protocol for the flexible transmission of measurements, statuses and events. Reliable use in energy management requires a clearly defined data model, appropriate QoS selection, defined feedback mechanisms and a secure communication infrastructure.

Frequently asked questions about MQTT

What is an MQTT broker?

The MQTT broker is the central communication intermediary. It receives published messages and distributes them to the respective recipients based on topics, subscriptions and access permissions.

What is an MQTT topic?

A topic is a hierarchically structured message channel. For example, it can assign a message to a specific site, plant, device and measurement.

Does MQTT encrypt transmitted data?

MQTT itself does not encrypt transmitted data. Secure communication typically requires TLS, secure authentication and differentiated access permissions.

Is MQTT suitable for plant control?

MQTT can transfer setpoints and control commands, but it is not inherently deterministic or real-time capable. Its suitability depends on factors including the required response times, feedback mechanisms, security requirements and fallback strategies.