What is MQTT?
MQ Telemetry Transport (MQTT) is a very simple client/server, publisher/subscriber, open and lightweight messaging transfer protocol. What is unique about this protocol, is that it is perfectly suited for IoT needs, because it has been designed for small devices with minimal resource requirements. Thus MQTT can often be seen in Smart Home automation systems alongside cloud services such as AWS, Google Cloud IoT Core, Microsoft Azure IoT, IBM IoT Platform and other cloud market leaders. Another important distinction is that this communication standard allows devices to publish messages that are not previously known or predetermined. ‘Whatever you say, I’m listening’ is true as long as the client subscribed to the related topic. The middleman is a broker who receives and stores the messages so they would be available for interested clients. That gives an advantage in case of not stable communication. There is no need for two clients to be ‘online’ at the same time to share information. As long as the message was received by the broker, it would wait for the interested subscriber whenever he would get a connection. Similar principles of work can be seen on Instagram, you don’t need to be available 24/7, the posts from the profiles to which you are subscribed are waiting for you on the server.
MQTT Broker is responsible for receiving all the messages, filtering them, registering who is interested in them and redirecting the messages to interested clients. Additionally, as a boss of the protocol, it authenticates and authorizes clients.
Major characteristics of MQTT
To better understand MQTT, it is essential to know the basic building blocks on which this protocol is built.
There are certain messages that MQTT devices use to communicate with the broker and vice versa. The main are the following:
- Connect (Client to Server) – creates a connection with a broker.
- Connack (Server to Client) – an acknowledgment of the connection.
- Disconnect (Client to Server or Server to Client)- disconnects with a broker.
- Publish (Client to Server) – publishes topic’s data to the broker.
- Subscribe (Client to Server) – subscription request.
- Unsubscribe (Client to Server) – unsubscription request.
MQTT is a secure protocol. The messages between the client and broker can use SSL/TLS encryption to ensure communication security over a network.
Message Structure in MQTT is designed to have a small footprint. The messages are consist of:
- Fixed Header, which consists of the message type, DUP Flag, QoS (Quality of Service) and Retain.
- Variable Header Component
- Message Payload
What’s interesting is that QoS allows choosing the likelihood of message delivery between client and broker. There are three specified levels:
- QoS0: Message will be delivered at most once, meaning there is a likelihood of some messages being lost.
- QoS1: Message will be delivered at least once, meaning that duplication of messages may sometimes occur.
- QoS2: Message will be delivered exactly once, meaning no duplication and no message loss. You may be wondering why there is such classification? Wouldn’t it be enough to use QoS2 all the time and avoid losses and redundant messages? The trick is that the lower the QoS level, the higher the performance. So there is a possibility to choose what is more important for each particular case, performance or quality of communication.
MQTT and Niagara Framework®
The implementation of MQTT is available in Niagara Framework® through the driver “Abstract MQTT Driver”. The driver contains three components:
- AbstractMqttNetwork.
- AbstractMqttDevice.
- AbstractMqttPoints.
It is possible to add multiple devices to the different brokers (Broker IP Address and Port must be specified) under one network. In each device, it is possible to choose one of three levels of Quality Of Service described previously.
The points under driver are standard type: Boolean, Numeric, String and Enum but with two variations: Publish (if you want to send data to the broker) and Subscribe (if you want to read data from the broker). Each point should contain a specified MQTT Topic.
Important to know that Niagara Framework® has a JSON toolkit that allows it to gather the data available on the station of the controller and allows it to publish that data via MQTT, oBIX, HTTP etc. in a fast and standardized way.
Author:
Oleksandr Zdir