MQTT
MQTT (Message Queuing Telemetry Transport) is a lightweight communication protocol for machine-to-machine communication. It was specifically designed for environments with limited bandwidth and unstable network connections. Today, it is firmly established as one of the key protocols in the Industrial Internet of Things (IIoT) and in connected manufacturing.
Contents
- What is MQTT?
- How does MQTT work? (Broker, Client, Server, Topics)
- What QoS (Quality of Service) levels are available with MQTT?
- What are the advantages of MQTT?
- What are the limitations and challenges of MQTT?
- MQTT vs. OPC UA – what are the differences?
- Where is MQTT used? (Use cases in IIoT & manufacturing)
- What do I need to use MQTT?
- How has MQTT evolved? (History & Versions)
- Summary
What is MQTT?
MQTT stands for Message Queuing Telemetry Transport and refers to a lightweight messaging protocol based on the publish-subscribe principle. Unlike classic client-server communication – where two parties talk directly to each other – MQTT decouples sender and receiver via a central intermediary, the broker.
The protocol was originally developed for the remote monitoring of oil pipelines, where satellite connections were expensive, narrowband and at times unreliable. This origin explains its key characteristics: minimal overhead, robust message delivery even over unstable connections, and efficient use of resources.
Today MQTT is an established standard in IoT infrastructures – from building automation and connected vehicles through to industrial manufacturing.
How does MQTT work? Broker, client, server and topics explained
The MQTT model consists of three core components: broker, publisher and subscriber. Together they form a flexible communication architecture in which publishers and subscribers do not need to know each other directly.
The MQTT broker (server)
The broker is the heart of every MQTT network. It receives incoming messages and forwards them to all clients that have subscribed to the relevant topics. The broker does not interpret the business meaning of the payload – it acts purely as an intermediary between senders and receivers. Widely used solutions include Eclipse Mosquitto, HiveMQ and EMQX. Operation typically uses the IANA-registered ports 1883 for unencrypted MQTT connections and 8883 for MQTT over TLS.
Publishers and subscribers (clients)
Every participant in the network is an MQTT client – either as a publisher (data sender), as a subscriber (data receiver) or in both roles at once. A temperature sensor in production, for example, continuously sends readings to the broker; a control system on the receiving side subscribes to that data stream and reacts automatically when limits are exceeded.
Topics: how messages are structured
In MQTT, messages are addressed via topics – hierarchically structured character strings that classify the content. A typical example from a manufacturing environment:
plant/hall3/line2/machine07/temperature
Subscribers can subscribe to individual topics or entire topic areas using wildcards: # covers multiple topic levels, + exactly one level. This makes the architecture scalable and flexible. New machines or sensors can be added without coupling publishers and subscribers directly to one another.
What QoS (Quality of Service) levels are available with MQTT?
A key feature of MQTT is that transmission reliability can be controlled via three quality-of-service levels (QoS). Depending on the use case, this allows the trade-off between speed, network overhead and delivery assurance to be managed deliberately.
QoS 0 – At most once
The message is sent once, without acknowledgement. If it is lost, it is not resent. This level suits non-critical telemetry data where occasional data loss is acceptable – for example high-frequency sensor readings where the next value follows shortly afterwards anyway.
QoS 1 – At least once
The broker sends the message and expects an acknowledgement from the recipient. If none arrives, it retransmits until receipt is confirmed. This guarantees delivery at least once; the same message may, however, arrive more than once. Recipients therefore need to be able to handle duplicates.
QoS 2 – Exactly once
The most elaborate mode: a multi-stage handshake ensures at protocol level that the message reaches the recipient exactly once. This level creates the highest overhead and is intended for cases where neither message loss nor duplicates are acceptable – for example acknowledgements, production orders, quality releases or billing data.
What are the advantages of MQTT?
It is no coincidence that MQTT has established itself as the de facto standard in the IIoT. Its architecture brings a set of properties that are decisive in industrial environments in particular.
Low resource requirements: The protocol works with minimal message overhead – an MQTT packet can be just a few bytes in size. Even devices with very limited processing power and little memory, such as simple microcontrollers on machine controls or sensors directly on the production line, can run as MQTT clients without difficulty. This significantly reduces hardware requirements and therefore the cost per connected device.
Robustness on poor networks: MQTT is designed to work reliably even with high latency, limited bandwidth or unstable connections – a property that is relevant every day in sprawling production halls or at remote machines. Connection losses are detected by a configurable keep-alive mechanism. For clients that go offline temporarily, the broker can buffer messages under certain conditions, for example with persistent sessions and QoS 1 or QoS 2. Retained messages serve a different purpose: they store the most recently published message with the retained flag per topic, giving new subscribers the last known state immediately.
Scalability without architectural breaks: Decoupling publishers and subscribers makes it possible to connect thousands of end devices to a single broker without having to adapt the existing infrastructure. A new machine, an additional sensor or another control system can be added at any time – the system grows with you instead of requiring a redesign.
Bidirectional communication: Unlike pure polling mechanisms, where a system has to query actively at regular intervals, MQTT makes it just as easy to send control commands to devices as it is to receive status information. That is a decisive advantage for control loops and remote-control scenarios in manufacturing.
Timely data availability: Thanks to the event-driven publish-subscribe model, new readings are available to all matching subscribers immediately after they are captured – with no additional polling delay. For time-critical applications such as quality assurance, plant monitoring, condition monitoring or process visualisation, this is a substantial advantage over interval-based transmission methods.
Open, widely supported standard: MQTT is an internationally standardised protocol with a large developer community and a mature ecosystem. Almost every common programming language offers stable client libraries, and most IIoT platforms and cloud providers support MQTT natively – which makes integration projects considerably easier.
What are the limitations and challenges of MQTT?
As well suited as MQTT is to many IIoT scenarios, there are requirements where the protocol reaches its limits.
No built-in data model: MQTT transports messages as raw bytes with no defined format. What a reading means, what unit it carries or how it relates to other values is not defined in the protocol itself. This calls for additional conventions or metadata at application level.
Security not fully part of the protocol core: MQTT does not encrypt messages itself. In practice, security is implemented via TLS at transport level along with authentication, authorisation and access controls in the broker. That is powerful, but it requires careful configuration – not least with regard to data protection.
No business-level transaction logic: MQTT can secure the delivery of individual messages via QoS levels, for example with QoS 2 for exactly-once delivery at protocol level. Complex, stateful sequences – such as multi-stage order or process flows with feedback loops – are not modelled by MQTT itself. Such process states, dependencies and error cases have to be modelled at application level.
Broker as a potential single point of failure: In simple architectures, the broker’s central role is also a weak point. If a single broker fails, communication can be interrupted. High-availability setups with clustering, replication or managed broker services are possible, but they increase technical complexity.
MQTT vs. OPC UA – what are the differences?
In industrial environments, MQTT and OPC UA often appear to be competitors – in fact they are complementary technologies that address different problems.
OPC UA (Open Platform Communications Unified Architecture) is a comprehensive industry standard that defines not only data transport but also semantic data modelling, security, access control and platform-independent interoperability. Values are not merely transmitted; they can be described via an information model with meaning, unit, data type and context. The device effectively describes itself.
MQTT, by contrast, is considerably leaner and agnostic to content. It defines how messages are transported – not what they mean in business terms.
| Feature | MQTT | OPC UA |
|---|---|---|
| Main focus | Data transport | Data modelling + transport |
| Resource requirements | Very low | Higher |
| Semantics | No semantics in the protocol core | Built in via information model |
| Security | Typically via TLS, broker configuration and ACLs | Comprehensively covered by the standard |
| Typical application | Sensor data, telemetry, edge-to-cloud | Machine integration, MES/SCADA, industrial interoperability |
In practice the two protocols are often combined: OPC UA structures and describes data at machine level, MQTT transports it efficiently towards the cloud or higher-level systems. With OPC UA PubSub, the transmission of structured OPC UA data over MQTT is now formally specified.
Where is MQTT used? Use cases in IIoT and manufacturing
MQTT is used wherever many devices need to exchange data reliably and with minimal resource consumption. In industrial manufacturing, these are primarily the following scenarios:
Machine condition monitoring
Sensors on production equipment continuously send vibration, temperature or pressure values via MQTT to higher-level systems. Deviations from the normal state can be detected promptly, before they lead to unplanned downtime. An automotive supplier can, for example, monitor numerous inspection or process points in parallel and report quality deviations automatically to an analytics or control system – without anyone having to query data actively.
Machine data acquisition (MDA)
MQTT serves as the transport layer for the automatic capture of machine data – such as quantities, cycle times or error codes – and its forwarding to MES or ERP systems. In a linked production line, each machine publishes its status independently; the higher-level system subscribes to all relevant topics and thus receives a continuously updated picture of overall utilisation.
Edge-to-cloud communication
At the interface between the shop floor and cloud platforms, MQTT has established itself as a lean protocol for transmitting telemetry and status information. Data is pre-processed at the edge and then forwarded efficiently – for example when a production site sends machine data to a central analytics platform that produces cross-site OEE evaluations.
Predictive maintenance
The continuous transmission of sensor data is an important basis for predictive maintenance. A typical scenario: vibration sensors on the spindles of a CNC machine deliver readings continuously via MQTT; an analytics model recognises characteristic patterns early on, identifies indications of a possible bearing failure and automatically triggers a maintenance order.
Energy management
Consumption data from machines, lighting or air conditioning can be consolidated centrally via MQTT and evaluated promptly. In a foundry, for example, load peaks can be reduced in a targeted way: as soon as total consumption exceeds a defined threshold, the system throttles non-critical loads or postpones energy-intensive processes – based on the MQTT messages arriving continuously.
What do I need to use MQTT?
Getting started with MQTT is technically manageable – the core components are quickly assembled, and thanks to broad ecosystem support there are ready-made building blocks for almost every use case.
MQTT broker
The broker is the central infrastructure component of a classic MQTT architecture. For getting started and for smaller installations, Eclipse Mosquitto is a good fit – a lean open-source broker that runs on standard hardware and is easy to configure. For production environments with high demands on scalability and manageability, commercial broker solutions or hosted MQTT services from major cloud and platform providers are worth considering.
MQTT client library
An MQTT client library is required on every device or system that is to send or receive data. The choice is wide: for Python, Eclipse Paho MQTT is an established solution with extensive documentation; mature MQTT client implementations also exist for Java, C and other languages. Embedded systems and microcontrollers are connected via specially optimised libraries or frameworks, such as PubSubClient or ArduinoMqttClient in the Arduino world, and the ESP-IDF MQTT client for ESP32-based systems.
Network connection
MQTT itself places no particular demands on the network infrastructure – it runs over any TCP/IP-capable connection, whether Ethernet, Wi-Fi or mobile network. TLS at transport level is recommended for encrypted transmission, which, depending on the security model, requires appropriate certificate management.
Planning the topic structure
Not a tool, but often underestimated in practice: before the first devices are connected, the topic hierarchy should be planned carefully. Consistent naming – for example following the pattern site/area/machine/datapoint – makes later extensions considerably easier and prevents a hard-to-maintain tangle during operation.
Test and debugging tools
Graphical MQTT clients are very helpful for development, testing and troubleshooting. Tools such as MQTT Explorer make the topic structure visible, show incoming messages live and make it possible to publish test messages manually – without having to write your own code first.
How has MQTT evolved? History and versions
MQTT was developed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (then at Arcom) to transmit sensor data from oil pipelines reliably over narrowband and expensive satellite connections. The requirements at the time – low resource consumption, scarce bandwidth and high reliability – have shaped the protocol design to this day.
2013 saw the start of MQTT standardisation at OASIS, the Organization for the Advancement of Structured Information Standards.
MQTT 3.1.1 was adopted as an OASIS standard in 2014 and later also ratified as ISO/IEC 20922:2016. This version is still in use in many production environments today.
MQTT 5.0 was adopted as an OASIS standard in 2019 and brought substantial extensions: improved error handling, message expiry, shared subscriptions for load distribution and richer metadata in the form of user properties. For new projects, MQTT 5.0 is usually the preferred choice, provided the broker and clients support the version fully.
MQTT in brief: the key points
MQTT is a lightweight communication protocol based on the publish-subscribe principle, developed specifically for resource-constrained devices and unreliable networks. Its central element is the broker, which relays messages between sending and receiving clients without the two having to communicate directly.
Three QoS levels allow delivery assurance to be graded deliberately – from fast transmission without acknowledgement through to exactly-once delivery at protocol level. Compared with OPC UA, MQTT scores on low resource consumption and high scalability; for semantically rich data models it is frequently combined with OPC UA in practice.
In connected manufacturing and the IIoT, MQTT is firmly established today: as a transport layer for machine data, as the link between the shop floor and the cloud, and as the basis for applications ranging from condition monitoring to predictive maintenance. MQTT 5.0 provides a modern, functionally extended version that also supports more demanding IIoT architectures.
