The MQTT communication protocol

The MQTT communication protocol stands for “Message Queuing Telemetry Transport” and is a lightweight, reliable and efficient protocol for messaging in distributed systems. It is designed for communication between devices with limited resources, such as sensors and actuators in embedded systems or even Internet of Things (IoT) devices. MQTT was developed by IBM back in 1999 and is now a widely used protocol for the Internet of Things.

The protocol is based on a publish/subscribe pattern in which one device (publisher) sends messages on a specific topic and other devices (subscribers) can receive these messages if they are interested in that topic. MQTT thus enables efficient delivery of messages while minimizing overhead. This makes it particularly interesting for use in environments with limited bandwidth and high latency.

Would you like to learn more about the MQTT communication protocol and the associated potentials for your application? Simply arrange a free initial appointment:

An MQTT broker is a central part of an MQTT network. He is responsible for accepting, storing, managing and distributing messages between publishers and subscribers. The broker is a server that runs on a computer or cloud platform and acts as an intermediary between the devices. The MQTT broker manages the connections between publishers and subscribers, includes a list of current topics and their subscribers, and then ensures that messages are properly routed to the appropriate recipients. A well-configured MQTT broker ensures efficient and reliable communication between participants in the network.

A topic is a channel or topic under which messages are published and received. Topics are represented as strings that reflect the hierarchy of information. For example, a topic for a temperature specification can be called “Hall1/Production/Machine1/Drive1/Temperature”. It is important to choose a sensible and well-structured topic system to ensure the scalability and efficiency of the MQTT network.

General recommendations for choosing a suitable topic

1. Clear structuring: Use a clear hierarchy to group topics by function or location for ease of organization and management.
2. Uniqueness: Use unique topics to avoid confusion and ensure clear assignment of messages.
3. Avoid special characters and spaces: Only use alphanumeric characters and separate words with slashes (“/”) or underscores (“_”).
4. Flexibility: Design topics to meet future requirements to avoid frequent changes.
5. Minimize the length: Avoid excessively long topics to reduce the network load.

With a well-chosen structuring of the topics, clients can access the information they need much more easily and with less prior knowledge with the help of topic filters.

Topic filters are special strings that are used to select messages based on the topics a subscriber is interested in. They offer a flexible way to subscribe only to relevant news and consequently avoid unwanted data floods. Effective use of topic filters allows subscribers to receive only the messages that are relevant to them and ultimately optimize network traffic.

The Two Types of Topic Filters: Single-Level Filters and Multi-Level Filters

• Single-level filters: Use the plus sign (+) as a placeholder for exactly one level in the topic. For example, a filter “Halle1/+” can cover all topics that start with “Halle1/” followed by another level. If you want to receive the temperature of all components of the first machine using the example above, you can use the filter “Hall1/Production/Machine1/+/Temperature”.
• Multi-level filters: Use the pound sign (#) as a wildcard for zero or more characters in the topic. For example, a filter “Halle1/#” can cover all topics that start with “Halle1/”, regardless of the number of additional levels. With the filter “Hall1/Production/#” the client would also display the values of the topic “Hall1/Production/Machine1/Drive1/Temperature”. However, this also includes all other values that are provided for any machine in this structure.

There are a variety of MQTT brokers that can be used in different environments. Some of the common MQTT brokers are:

• Mosquitto: Mosquitto is a well-known and popular open-source MQTT broker developed by the Eclipse Foundation. It is characterized by its simplicity, lightness and reliability. Mosquitto supports MQTT versions 3.1 and 3.1.1 and is easy to set up and configure. Although Mosquitto also supports some features of MQTT 5, it does not offer full support for this version. Nevertheless, Mosquitto is a good choice for small to medium-sized IoT projects and use cases due to its ease of use and broad community.
• HiveMQ: HiveMQ is a commercial MQTT broker known for its scalability, performance, and extensive support for MQTT 5. It offers full support for MQTT versions 3.1, 3.1.1 and 5.0. HiveMQ is therefore ideal for demanding and mission-critical IoT applications where high demands are placed on reliability, scalability and security. The broker also offers features such as cluster support and MQTT-based plugins that make it possible to realize complex and customized IoT solutions .
• RabbitMQ: RabbitMQ is an open-source broker that supports not only MQTT but also other protocols such as AMQP, STOMP, and others. It provides support for MQTT versions 3.1, 3.1.1 and 5.0 (since version 3.8.0). RabbitMQ is also known for its flexibility, extensibility, and ability to handle large volumes of messages. Accordingly, multi-protocol support makes it a versatile option for complex environments where different communication protocols are required.
• EMQ X: EMQ X is an MQTT broker that is available in both an open-source version and a commercial variant. It fully supports MQTT versions 3.1, 3.1.1 and 5.0. EMQ X also provides a robust and high-performance implementation of MQTT 5, making it ideal for demanding and distributed IoT applications. The broker also makes it possible to efficiently manage and scale large IoT networks, and also offers features such as high availability, advanced authentication, and access control.

Choosing the right MQTT broker ultimately depends on the specific needs of the IoT project, including the size of the network, the features needed, as well as the desired performance. It is also advisable to compare the features, performance and scalability of the different brokers in order to finally make the best choice for the respective project.

The BITMOTECOsystem can directly send messages via Node-RED and the MQTT-Node available in it with one or more MQTT brokers via MQTT versions 3.1, 3.1.1 and 5.0 . The received data can be transferred directly from Node-RED to a database, such as the InfluxDB Times Series Data Platform. Alternatively, the data can be analysed or merged into Node-RED or an outsourced analysis module. The results can then be made available to other interested parties via MQTT on a broker.

Increase your machine availability in the future with the help of the MQTT communication protocol. Simply schedule a free appointment for your use case: