Blog
MQTT – Message Queue Telemetry Protocol
MQTT – Network Level Transmission
MQTT uses TCP as the basic protocol and thus works according to the client/server principle.

The broker is the server that can accept connections on TCP port 1883 by default. The MQTT users act as TCP clients and connect to the broker when required.

MQTT – Protocol level data exchange
With MQTT there are two roles that a client can assume.
Publisher
As a publisher, the client sends data to the broker. This can be measured values, switching statuses or any other process data. In addition to readable text content, MQTT also allows binary data. Whether the publisher transmits its data to the broker when there is a change or cyclically depends on the application.
Subscriber
The subscriber accepts data from the broker. In the role of the subscriber, the client tells the broker which data it would like to receive or subscribe to after the connection has been established.
Each MQTT client can be a publisher, subscriber or both. So there is no mandatory master/slave principle as with other industrial protocols. All MQTT end devices or clients are initially equal at the MQTT level. Who supplies data and who receives it is determined exclusively by the application through the publisher/subscriber assignment.
Topic
The MQTT broker manages the data to be exchanged according to data endpoints. The data endpoints are named using topics. These are strings, i.e. character chains, which can be structured similar to the URL when the website is called up.
Example:
A W&T web thermo-hygrobarometer measures temperature, humidity and air pressure in the server room of the W&T company building. Each of the three values represents a data endpoint.
The topics for this could look like this:
wut/serverraum/temperatur
wut/serverraum/luftfeuchte
wut/serverraum/luftdruck
The web thermohygrobarometer transfers the measured values as a payload, i.e. as data content, under these topics to the MQTT broker via MQTT publish.
Any MQTT client can now send a Subscribe specifying the desired topic to the MQTT broker. Here the MQTT client sends a Subscribe wut/serverraum/temperaturand thus subscribes to the temperature value of the web thermohygrobarometer.

As long as the PC is connected to the broker as an MQTT client, it automatically receives the value sent by the web thermohygrobarometer via publish.
The subscriber can work with wildcards “#” when specifying the topics.
Beispiel: wut/serverraum/# abonniert Temperatur, Luftfeuchte und Luftdruck für den Serverraum.
In addition to “#”, there is also “+” as a wildcard. If you enter “+”, only end topics of the corresponding level are subscribed to – topics from subsequent levels are ignored.
Each subscribed value has its own data broadcast.
The transmission of the data is byte-oriented and therefore binary-transparent – so any content can be transmitted. For all text content, UTF8 is specified as the format for standardization.
MQTT – Special Features
MQTT offers some special options for the transport and exchange of data, which can be set using flags for each connection or subscription.
Quality of Service – QoS
Values between 0 and 2 determine the reliability with which a publish message is sent to the broker.
- out and forget
The MQTT client does not expect any confirmation for sent data.
This method is insecure, but very fast. - at least once
The MQTT client may send the data multiple times
until it receives a confirmation of receipt from the MQTT broker.
This procedure ensures that the data arrives at the broker, but
if necessary several times. - exactly once
Each data transmission must be explicitly acknowledged by the MQTT broker.
This ensures that nothing is sent twice.
This method is the safest, but also the slowest.
With QoS1 and 2, the question arises at first glance as to why a single data transmission is more secure than multiple transmissions. However, the background quickly becomes clear on the basis of two examples.
Is it about transmitting a measured value – e.g. B. a temperature – it does not matter whether the value arrives multiple times at a subscriber. However, if the angle transmitted is that a robot arm should move – e.g. B. 5° – and the data transmission arrives at the subscriber three times, the robot arm would move by 15°, which could have fatal consequences.
Last Will and Testament
A publisher can specify that the broker sends a specific message to the subscriber(s) instead of the subscribed values/data in the event that the MQTT connection is lost.
Retained Message
By setting this flag, the publisher instructs the broker to temporarily store the last value/data sent and immediately transmit it to a subscriber who is reconnecting.
All three features are particularly useful when the transmission is not always reliable (e.g. mobile networks).
Features and benefits of MQTT
MQTT is considered the transmission protocol for the “Internet of Things” and offers various advantages, especially for data exchange via the Internet:
- Since all end devices using MQTT work as clients, it is usually possible to overcome firewalls and security measures with little or no effort (no port releases and no NAT routing / port forwarding have to be set up in the firewalls).
- The publisher does not have to worry about which recipients actually receive the data provided.
- Unlike other Internet-based protocols, binary data can be transmitted without Base64 or other encoding.
characteristics and disadvantages
- The data supplier does not know who is actually receiving his data (no end-to-end acknowledgment).
- No real-time capability