Explanation, Advantages & Use Cases
What is MQTT?
MQTT is a robust network protocol for exchanging data between machines, devices and other applications. It is based on a publish-subscribe model and has established itself as one of the most important protocols for the Internet of Things (IoT). MQTT is widely used in areas such as industrial manufacturing and home automation.
Definition
What does MQTT mean?
MQTT (Message Queuing Telemetry Transport) is an open, lightweight messaging protocol that machines, sensors and applications use to exchange messages via a central broker according to the publish/subscribe principle. Senders (publishers) and receivers (subscribers) do not know each other: they only connect to the broker, which distributes the messages based on their subject (topic).
MQTT was developed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom) to monitor oil pipelines over satellite links with low bandwidth. Since 2014, the MQTT protocol has been an open OASIS standard (version 3.1.1), and since 2016 it has also been standardised as ISO/IEC 20922. MQTT 5.0 followed in 2019. Today, MQTT is regarded as a name in its own right, but the former long form “Message Queuing Telemetry Transport” is still widely used.
MQTT runs on top of TCP/IP and uses port 1883 by default, or port 8883 when encrypted with TLS. Both versions are common in industry: MQTT 5 adds reason codes, shared subscriptions, message expiry and user properties, among other things. This makes MQTT, alongside OPC UA, one of the most important protocols for machine-to-machine (M2M) communication in the Industrial Internet of Things (IIoT). The following sections explain the most important functions of the MQTT protocol – publish/subscribe, topics, delivery guarantees, retained messages and Last Will.
Explanation
How does MQTT work?
MQTT is an open and resource-efficient network protocol for exchanging messages between devices, machines and other systems. Due to its reliability, it has established itself as one of the most important protocols for the Internet of Things (IoT). In the OSI model, MQTT is located at the application layer.
At the centre of MQTT communication is the MQTT broker.
MQTT clients send messages linked to a specific topic to the MQTT broker. The broker in turn automatically forwards these messages to all clients that have subscribed to the respective topic. The MQTT broker thus acts as a middleman between the MQTT clients.
This publish-subscribe mechanism has an important advantage: The powerful MQTT broker, which is often operated in the cloud or locally on the plant network, manages sessions and data, while the participating client devices only receive the requested messages. This means that smaller, less powerful devices such as sensors, embedded devices and industrial controllers are able to participate in MQTT communication. In addition, network bandwidth is used less heavily.
MQTT also defines certain mechanisms for dealing with connection interruptions (see “How does MQTT handle connection loss?”).
MQTT communication explained
In general, data exchange via MQTT works as follows:
- Devices or other applications transmit messages to an MQTT broker (also called MQTT server). These messages contain a topic. MQTT clients that publish messages via the MQTT broker like this are also referred to as publishers.
- Devices or other applications subscribe to selected topics via the MQTT broker. The broker automatically sends new messages about a topic to clients that have subscribed to this topic (subscribers).
Different MQTT clients therefore never communicate directly with each other, but always via a central broker.
An MQTT broker is not a database and does not normally store any previous messages relating to a topic. However, with the help of so-called “retained messages”, selected messages can be permanently saved and automatically transmitted to new subscribers of a topic.
What is an MQTT broker?
An MQTT broker is a server that is often operated in the cloud. It handles the distribution of messages to the MQTT clients. To do this, it must save the client sessions, i.e. which clients have subscribed to which topics.
In manufacturing, the broker often runs on a server or edge device on the plant network, so that machine data does not leave the local network unprotected. Which brokers meet industrial requirements is shown in our comparison of industrial MQTT brokers.
What is an MQTT client?
An MQTT client can act as both a publisher and a subscriber. A subscriber client receives new messages for one or more topics to which it has subscribed. A publisher client publishes messages on a topic, which are then forwarded to the subscribers by the broker. Strictly speaking, the MQTT client is a small program that is installed on a sensor, computer or other device and enables the MQTT functionality.
What are MQTT topics?
Each MQTT message is assigned to a specific topic. The MQTT broker organises topics and the associated messages in a hierarchical structure that is similar to a file system on a PC.
An MQTT topic could be structured like this:
Site/Line/Machine/Measurement
Clients can subscribe to any hierarchy level of a topic. There are two wildcards for this: + stands for exactly one level, # for all following levels. The subscription Plant1/Line3/+/Temperature delivers the temperature of all machines on line 3, Plant1/Line3/# all values of this line.
In manufacturing, a topic structure that follows the structure of the company has proven itself – for example enterprise, site, area, line and machine according to the ISA-95 level model. Meaningful, consistent names without spaces or special characters make subscriptions and analyses easier. The Unified Namespace concept builds on this idea.
What is the MQTT payload?
The MQTT payload is the actual content of an MQTT message. In addition to this content, a topic and a quality of service (QoS) level must be specified for each message. MQTT does not define the payload format: simple values, JSON objects or binary formats are common.
What is the Quality of Service (QoS)?
The Quality of Service (QoS) of an MQTT message defines how often the message is sent to the subscribers of a topic.
The following QoS are possible:
- “At most once” (0): The message is only sent once and there is no confirmation of successful delivery.
- “At least once” (1): The message is sent repeatedly until a confirmation of delivery is received.
- “Exactly once” (2): An exchange between client and broker ensures that the message is delivered exactly once. This is the most reliable QoS, but requires multiple data transmissions between client and broker and is therefore also the most resource-intensive.
QoS
MQTT QoS Levels Compared
The QoS level determines the delivery guarantee MQTT provides for a message. The higher the level, the higher the reliability of delivery – and the more packets are exchanged between client and broker. In manufacturing, the level is therefore chosen per type of data.
| Criterion | QoS 0 – At most once | QoS 1 – At least once | QoS 2 – Exactly once |
|---|---|---|---|
| Delivery | At most once, loss possible | At least once | Exactly once |
| Acknowledgement | None | PUBACK from the receiver | Four steps: PUBLISH, PUBREC, PUBREL, PUBCOMP |
| Duplicate messages | No | Possible, the receiver must detect them | No |
| Network and device load | Low | Medium | High |
| Typical use in manufacturing | Cyclic measurements such as temperature or pressure every second – the next value follows anyway | Status and fault messages from a machine | Meter readings, order confirmations and bookings that must not arrive twice |
The level applies per leg: publisher and broker, and broker and subscriber negotiate it separately. If a subscriber subscribes with level 0, it receives a message without acknowledgement even if it was published with level 2. For subscribers that are currently disconnected, the broker only holds data if they use a persistent session and level 1 or 2.
How does MQTT handle connection loss?
If the connection of a publisher client to the broker is unexpectedly interrupted, a so-called “Last Will” message can be published for a specific topic. The client deposits this message with the broker when it connects; the broker sends it itself as soon as it detects the interruption – for example because the agreed keep-alive signal is missing. This can be used to notify subscribers to the topic that the client is no longer available. In manufacturing, a controller can thus automatically report “offline” if its network connection fails.
If the subscriber of a topic cannot be reached, messages can be temporarily stored by the broker and sent at a later time. This requires a persistent session and QoS 1 or 2.
Which security measures does MQTT implement?
The authorisations of MQTT clients are managed by the broker. Here you can specify which clients can access which topics. It is also common for clients to have to authenticate themselves to the broker with a user name and password.
The transmitted data is usually encrypted using TLS.
MQTT Security: 4 Risks and How to Address Them
MQTT itself is only as secure as its configuration. The protocol provides functions for authentication, encryption and permissions, but does not switch them on by itself. In manufacturing, the protocol carries machine data and sometimes commands – which is why the following four measures belong in every installation.
Openly accessible broker
A broker that can be reached from the internet on port 1883 without authentication hands its data to anyone. Operate the broker on the plant network or only expose it via encrypted, authenticated connections.
Data in plain text
Without encryption, messages can be read and altered. TLS encrypts the connection between client and broker, usually via port 8883.
Unknown clients
Every client should authenticate itself to the broker – with user name and password or, more securely, with a client certificate.
Overly broad permissions
Topic permissions (access control lists) define for each client what it may read and write. An energy meter, for example, only needs write access to its own topic.
What are the advantages of MQTT?
Data exchange via MQTT offers key advantages for IoT communication – especially when smaller devices or limited network resources are involved.
Low network utilisation
MQTT is a lightweight and efficient protocol. Data packets (headers) are lean as MQTT uses a binary message format (HTTP, for example, uses a text-based message format).
Communication over unstable networks
Due to the low network utilisation (see above) and the mechanisms for dealing with connection failures, MQTT is well suited for data exchange in unreliable networks.
Low demands on device resources
The lean data packets, the distributed client-server structure and the options for handling connection failures enable reliable data exchange with low-resource devices such as sensors.
Scalability
Since message exchange via MQTT takes place via a central broker, additional devices can be integrated as clients at any time. MQTT brokers themselves are often located in the cloud and offer high performance.
Security
MQTT supports both the authentication of communication participants and encryption mechanisms such as TLS.
Simplicity
Especially on the client side, MQTT is very easy to implement and use.
Limitations
Limitations of MQTT – and How to Solve Them in Practice
As a messaging protocol, MQTT delivers reliably, but does not define what its payloads contain. This and other limitations are no reason against MQTT, but they determine which components are added in an industrial IoT architecture.
| Topic | Limitation | Solution in practice |
|---|---|---|
| Data model | The payload has no fixed format and no semantics – what “72.4” means is not part of the message. | A consistent topic structure and payload conventions, specifications such as Sparkplug B, or a data model in the platform that analyses the data. |
| Central broker | If the broker fails, all communication stops. | Broker clusters or redundant brokers, buffering in the clients. |
| Queries and commands | MQTT 3.1.1 has no request/response pattern; commands need their own response topics. | MQTT 5 with request/response; REST or OPC UA for queries and write access. |
| History | The broker stores no history; retained messages only hold the last value. | A database or software platform subscribes to the data and stores the values as time series. |
| Configuration | Without authentication, TLS and topic permissions, the broker is open. | Set up the four measures from the security section right from the start. |
For queries, write access and machines with a standardised information model, OPC UA is often the better choice. When to use which protocol is covered in the section “Where is MQTT used?”.
Use Cases
Where is MQTT used?
The use cases for MQTT are extremely diverse. Communication via MQTT is characterised by its low network load and low resource requirements for the devices involved (see also “What are the advantages of MQTT?”). As a result, MQTT is used in situations where smaller devices need to exchange data reliably. MQTT has been established as one of the most important protocols for the Internet of Things (IoT), Industrial Internet of Things (IIoT) and edge computing.
In many cases, MQTT is used to transfer data between devices and cloud platforms. Cloud environments such as Microsoft Azure and Amazon Web Services integrate their own MQTT brokers to process MQTT data from IoT devices.
The most important areas of application for MQTT include the following:
- Industrial production: Data exchange with production systems (see “MQTT in manufacturing”)
- Logistics: Tracking of goods and stock levels
- Healthcare: Communication with medical devices
- Energy supply: Monitoring of energy consumption and power grid components
- Vehicle networking: Monitoring of vehicles and communication with traffic systems
- Agriculture: Monitoring of equipment, irrigation systems and environmental conditions
- Security systems: Use in surveillance cameras and alarm systems
MQTT is particularly suitable for environments in which edge computing and cloud computing are combined. Data from edge devices can be transmitted to central cloud platforms using MQTT.
In many industrial environments, MQTT is used alongside other communication standards such as OPC UA and REST. In our blog post MQTT vs. REST vs. OPC UA – Differences and Use Cases, we compare the three technologies. The two worlds can also be combined: with OPC UA PubSub, OPC UA data can be distributed via a broker.
MQTT in Manufacturing
MQTT in Manufacturing: Topic Structure, Unified Namespace and Sparkplug B
In the industrial IoT, MQTT connects controllers, sensors and meters with the systems that use their data – from the dashboard on the shop floor monitor to the MES. This architecture has one advantage: because publishers and subscribers are decoupled, any new application can subscribe to existing topics without changing anything on the machine.
How machine data gets to MQTT: Many current controllers, industrial PCs and IoT sensors come with an MQTT client and publish their values directly to the broker. Older controllers without MQTT are connected via an IoT gateway or edge device: it reads the data via OPC UA, Modbus or a proprietary protocol and publishes it via MQTT. One example is the OPC Router by inray, which connects machines and IT systems via OPC UA and MQTT, among others.
Unified Namespace: Instead of connecting each application to each machine individually, all systems publish their current data to a shared topic structure on the broker. ERP, MES, dashboards and analytics read what they need from there. MQTT is the usual transport protocol for this.
Sparkplug B: This Eclipse Foundation specification adds a fixed topic namespace, a binary payload format (Protocol Buffers) and status messages to MQTT, with which participants announce their online state and data points (birth and death certificates). It thus closes the data model gap. Without Sparkplug B, a fixed topic structure and a data model in the platform achieve a similar result.
Typical scenarios:
- Collecting machine states and part counts from several lines in real time
- Reading electricity, compressed air and cooling water meters for energy monitoring
- Passing measurements from test benches and sensors on to quality assurance
- Distributing fault messages from a machine directly to maintenance
MQTT for Industrial Production
MQTT communication with manubes
manubes, our cloud platform for digital production management, uses MQTT to communicate with industrial machines, devices and cloud platforms.
manubes can be connected to an MQTT broker as a subscriber and thus gain access to a wide variety of data sources – including sensors, controllers and other devices. Within manubes, this data can not only be stored and structured in the form of data models, but also visualised interactively and in real time.
As a publisher, manubes is able to send data to cloud platforms such as Microsoft Azure, which integrate an MQTT broker.
The use cases mentioned above and many other scenarios can be implemented as part of automated workflows. Together, the manubes features enable the development and management of comprehensive industrial applications on a no-code basis (Citizen Development).
How the connection works: An Edge Node on the production network connects to an existing broker as an MQTT client via a connector – manubes does not include its own broker. The connection to the broker can be encrypted with TLS, subscriptions may contain wildcards, and manubes processes different payload formats. The Edge Node only establishes outbound, encrypted connections to the manubes cloud (security concept); if the connection drops, it buffers the data. In the Workflow Designer, an incoming MQTT message can trigger a workflow, and a workflow can in turn publish values to a broker.
Use MQTT data from production in real time
Connect manubes to your MQTT broker, subscribe to topics using wildcards and use machine data in dashboards, data models and workflows – without programming.
Try manubes for freeFrequently asked questions about MQTT
What does MQTT stand for?
MQTT originally stood for Message Queuing Telemetry Transport and refers to an open, lightweight messaging protocol for the Internet of Things. Devices and applications use it to exchange messages via a central broker according to the publish/subscribe principle. We need MQTT where many devices must send small amounts of data reliably over limited networks. MQTT is standardised by OASIS and as ISO/IEC 20922.
What protocol is MQTT based on?
MQTT is based on TCP/IP. TCP provides an ordered, lossless connection between client and broker, on which MQTT builds its sessions and QoS levels. For networks and very small devices that only use UDP or radio protocols such as Zigbee, there is the variant MQTT-SN (MQTT for Sensor Networks).
Which port does MQTT use?
MQTT uses TCP port 1883 for unencrypted connections and port 8883 for connections with TLS encryption by default. Both ports are registered with IANA for MQTT. Via WebSockets, MQTT can also run over the usual web ports, for example for browser applications. In manufacturing, only port 8883 with authentication should be used as soon as data leaves the local network.
What is the difference between an MQTT broker and an MQTT client?
The MQTT broker is the central server that receives incoming data, manages subscriptions and distributes it to the right recipients. MQTT clients are the participants – controllers, sensors or applications – that publish messages (publishers) or subscribe to topics (subscribers). An overview of industrial brokers can be found in the MQTT broker comparison.
What do QoS 0, 1 and 2 mean in MQTT?
The Quality of Service defines the delivery guarantee: QoS 0 delivers a message at most once without acknowledgement, QoS 1 at least once with acknowledgement, where duplicates are possible, and QoS 2 exactly once via a four-step exchange. For cyclic measurements, QoS 0 is usually sufficient; QoS 1 or 2 are common for messages and meter readings (QoS levels compared).
Which devices support MQTT?
Many IoT sensors, energy meters, IoT gateways, edge devices, industrial PCs and increasingly also controllers (PLCs) with a built-in MQTT client support MQTT. Older controllers without MQTT are connected via a gateway or edge device that reads their data, for example via OPC UA or Modbus, and publishes it via MQTT.
What is Sparkplug B?
Sparkplug B is an Eclipse Foundation specification that extends MQTT for industry with a fixed topic namespace, a uniform payload format and device status messages. It thus addresses the missing data model in MQTT. manubes does not support Sparkplug B; instead, a fixed topic structure, wildcard subscriptions and the data model assign the values.
What is the difference between MQTT and OPC UA?
MQTT is a lean transport protocol that distributes messages via a broker but does not describe their content. OPC UA additionally provides functions such as a standardised information model, read and write access and integrated security mechanisms. In practice, the two are often combined. Details can be found in the comparison MQTT vs. REST vs. OPC UA.
Product video: Get to know manubes
Further information
Optimise your production with manubes
manubes offers a central platform for production data management, data visualisation and workflow-based process automation.
Manufacturers gain access to a variety of innovative tools in order to quickly develop their own applications – tailored to their requirements.
Try manubes for free
Test the different manubes features in your personal cloud environment.
Get started
'/%3E%3C/svg%3E){kind=small}