1. What is an MQTT broker?
The MQTT broker is the center of every Publish / Subscribe protocol. Depending on the implementation, a broker can manage up to thousands of simultaneously connected MQTT clients. The broker is responsible for receiving all messages, filtering the messages, determining who subscribed to each message and sending the message to those subscribed clients. The Broker also holds the sessions of all persistent clients, including subscriptions and missed messages. Another task of the Broker is the authentication and authorization of clients. Usually the broker is extensible, which facilitates custom authentification, authorization and integration with backend systems. Integration is especially important, because the Broker is often the component directly exposed on the Internet, serves many clients and has to forward messages to downstream analysis and processing systems. In short, the Broker is the central hub through which every message must be routed. It is therefore important that your broker is highly scalable, can be integrated into back-end systems, is easy to monitor and, of course, is fail-safe.
2. What does MQTT stand for?
It stands for MQ Telemetry Transport. It is an extremely simple and lightweight messaging protocol (subscribe and publish) designed for limited devices and networks with high latency, low bandwidth or unreliable networks. Its design principles are designed to reduce the network bandwidth and resource requirements of devices and ensure security of supply. In addition, these principles are advantageous for M2M (machine-to-machine) or IoT devices because battery performance and bandwidth are very important.
3. What is MQ Telemetry Transport in IoT (Internet of Things) used for?
With MQ Telemetry Transport, resource-constrained IoT devices can send or publish information on a specific topic to a server that acts as an MQTT message broker. The broker then transmits the information to those customers who have previously subscribed to the customer’s topic. To a human, a topic looks like a hierarchical file path. Customers can subscribe to a specific hierarchy level of a topic or use a wildcard character to subscribe to multiple levels.
The MQTT protocol is a good choice for wireless networks that have varying latency due to occasional bandwidth limitations or unreliable connections. If the connection from a subscribing client to a broker is interrupted, the broker buffers the messages and sends them to the subscriber when the subscriber is back online. If the connection from the Publishing Client to the Broker is disconnected without notification, the Broker can disconnect and send the Subscriber a cached message with instructions from the Publisher.
4. What is a MQTT-Topic?
The word Topic refers to a UTF-8 string that the broker uses to filter messages for each connected client. The topic consists of one or more topic levels. Each topic level is separated by a forward slash (topic level separator). Compared to a message queue, MQTT topics are very simple. The client does not have to create the desired topic before publishing or subscribing to it. The broker accepts any valid topic without prior initialization. Note that each topic must contain at least one character and that the topic string allows spaces. Topics are case-sensitive. For example _myhome / temperature and _MyHome / Temperature are two different topics. Furthermore, the slash alone is a valid topic.
In general, you can name your MQTT topics as you wish. However, there is one exception: __ Topics that start with a $ symbol have a different purpose. __ These topics are not part of the subscription if you subscribe to the multi-level placeholder as a Topic (#). The $ symbol topics are reserved for internal statistics of the MQTT broker. Customers cannot post messages on these topics. Currently there is no official standard for such topics. Usually $ SYS / is used for all of the following information, but the implementation of brokers varies. A suggestion for $ SYS topics is the MQTT-GitHub wiki.
5. When should you use MQ Telemetry Transport and when not?
With Message Queuing Telemetry Transport, data is sent from a large number of machines to a single destination – the cloud – where the data can be analyzed, interpreted and forwarded.
The cloud hosts an MQTT broker – an intermediary between machines and other machines and/or people. And this is an important distinction, as the machines do not communicate directly with each other, but through the broker.
MQTT uses the concept of “themes” to organize its data, and a publish/subscribe model to communicate themes to other parties through the cloud.
For example: an air conditioning system sends (or publishes) data on the “health” of its compressors to the cloud. All interested parties with approved credentials – machine or human – can subscribe to this topic to receive the information.
Subscribers can be maintenance engineers (human), parts procurement systems (software/machine) or maintenance planning systems (software/machine).
Suddenly every aspect of a machine’s lifecycle is available for review, and this represents an exciting and profound opportunity to connect with this information to find defects, save costs, increase efficiency, and make planning for the Internet of Things.
6. How to get started easily with MQ Telemetry Transport ?
Mosquitto is suitable for an easy start. Eclipse Mosquitto is an open source broker (EPL / EDL licensed), which implements the MQTT protocol versions 3.1 and 3.1.1. Mosquitto is lightweight and suitable for all devices, from single-board computers with low power consumption to complete servers.
The MQTT protocol provides an easy way to perform messaging using a publish/subscribe model. This makes it suitable for Internet of Things messaging, such as low-power sensors or mobile devices such as telephones, embedded computers or microcontrollers.
Mosquitto is part of the Eclipse Foundation and is a project of iot.eclipse.org
The download for Mosquitto is available on the project page. With Mosquitto OPC Router connections can be tested easily.