IoT is a trending topic for the best part of the last decade or so. It is a network of a number of devices that can communicate with each other and control a bunch of things. The communication part is where MQTT comes into play. It helps in sending/receiving messages between “IoT” devices in a publish – subscribe model. But what is MQTT? How it Works? Why we use MQTT in IoT Projects? We will get answers to all these questions regarding MQTT in this guide.
An important note before we proceed further is that this guide is just the theory behind MQTT but not a practical implementation. If you are interested, we can make a few IoT Projects involving MQTT that includes how to setup MQTT.
What is MQTT?
Internet of Things or IoT is simply a combination of computing devices, sensors, actuators, wireless communication and communication protocols. The goal of IoT is to connect a group of devices (known as ‘things’) to the internet and exchange data between them.
Now imagine we have setup an IoT System with a bunch of devices connected to the internet and want to send and receive data in “near real-time”. We can use HTTP based server – client style of communication system. But what if I told you that there is a protocol designed specifically for this type of requirements? It is known MQTT.
MQTT is short for Message Queueing Telemetry Transport. It is a light-weight messaging protocol that works on a publish – subscribe model (which is similar to server – client model of HTTP but slightly different) on top of TCP/IP.
When we say ‘light-weight’, we mean a smaller code footprint than HTTP and also requires less network bandwidth.
IBM originally developed MQTT as a simple and reliable machine – to – machine (M2M) communication protocol. But over the years, it slowly became an integral part of embedded systems, especially IoT Projects.
Here is a list of some important features of MQTT:
- It uses a publish – subscribe model for one-to-many communication.
- An extremely lightweight protocol with small code footprint. There is a small overhead to transport the message and protocol exchange.
- It is a type of messaging protocol that works without the knowledge of the actual contents of the message.
- MQTT supports event-oriented messaging with asynchronous, bidirectional and low-latency message delivery.
- It supports both “always connected” and “sometimes connected” devices.
- The responsiveness of MQTT is “near real-time” message delivery.
- Can publish data even on slow, unreliable or fragile networks.
- It offers data security and privacy. This is very important as the data goes through internet.
- Is suitable for battery-operated and low-power devices.
MQTT Client Broker & Other Important Terminology
In order to understand its working, we need to first get familiar with some important terminology associated with MQTT.
Application Message
This is the actual data (with some overhead) that the MQTT Protocol carries in the network. The overhead can be a topic name (more about this later), QoS (Quality of Service) information etc.
MQTT Client and Broker
We said earlier that the MQTT protocol is similar to HTTP’s server – client model. This is true but with some caveats. First, we will see about the client. An MQTT client is a device (or a program) that runs MQTT library and connects to a server (or a Broker to be precise) over internet.
If a client wants to send the Application Message to another client, it doesn’t do it directly but rather sends it to the Broker, which then checks for authenticity of the message and sends it to appropriate clients.
An MQTT Broker is a device (or a program) acts as an intermediate device between the client that publishes the message on a topic and the clients that made subscription to that topic.
Apart from authenticating the clients, the broker is also responsible for managing subscriptions, sessions and connections. MQTT Clients and Brokers can be anything from a tiny microcontroller, a Raspberry Pi, ESP8266, ESP32 or even a large server.
Topic
We said ‘topic’ earlier, but what exactly is a topic in MQTT? A Topic is a label associated with the message and is usually a part of the overall application message. Each subscriber client must subscribe to a topic and the broker sends the message from the publisher client if and only if a client has a matching subscription.
For example, if there is a topic known as ‘weather’ and when a client publishes a message with this topic, all the clients that subscribed to this topic will receive the message.
There can be multiple levels of topics with each level of topic separated by a forward slash. Also, topic is case sensitive.
Subscription
It is an arrangement made by clients to specific topic and even QoS. A client must have a subscription for a topic in order to receive messages on that topic. All subscriptions are valid for a session.
Topic Filter
A client can use Topic Filters to subscribe to multiple topics simultaneously. It can contain wildcard characters such as ‘+’ and ‘#’.
Session
A session indicates a successful interaction between a client (publisher or subscriber) and a broker.
Control Packet
It is a packet of information from one of the 14 control packets. The PUBLISH is also a control packet that is responsible to publish application messages.
Publish – Subscribe
By this time, you might have a clear idea about publish – subscribe model of MQTT. In this, clients do not send messages directly. A client ‘publishes’ a message on a topic to the broker. If any client is ‘subscribed’ to that topic, only then it receives that message.
How MQTT Works?
Let us now see how MQTT actually works. It is a type of client – server message transport protocol that works over TCP/IP. In regular client – server model, the communication is confined to client and server where the client initiates the communication and server, which is essentially stores the data, responds with the data.
But the requirement in IoT (and other similar applications) is that data must be transmitted between several devices, which can be unidirectional, bidirectional or one to many.
This is where the publish – subscribe model of MQTT comes handy. In this model, clients don’t send data to other clients directly but rather a client that wants to send the data on a particular topic, ‘publishes’ the message to a broker.
If there are clients that are ‘subscribed’ to that topic, then the broker will send the message to all those clients. Here, the broker acts as an intermediary rather than the main data supplier (which is job of server in the regular client – server model).
There are no addresses in this model. All the communication is based on topics. A client publishes messages on a topic and a client receives the message if it is subscribed to that topic. Broker is responsible for subscription of topics.
If the publisher is unable to send messages due to network issues or any other reasons, it can send ‘Last Will Message’ to subscribing clients saying that this is the last message. If the connection between the broker and publisher fails, then the broker will send this last message to all the subscribers.
Importance of MQTT in Home Automation and IoT Projects
As we mentioned earlier, IBM originally developed MQTT as a light-weight messaging protocol for machine-to-machine (M2M) communication in oil and gas industries. Due to its small code size and reliability even with weak networks, it slowly became an integral part of IoT Projects.
- Easy to Implement: MQTT is very easy to implement. Its code size very small when we compare to HTTP. This means both the memory requirements as well as network requirements are very moderate. Getting started with MQTT is also simple with devices like Raspberry Pi, ESP32, etc.
- Multiple Ways of Communication: MQTT uses a publish – subscribe communication model, where the publisher publishes a message on a topic and if a subscriber is subscribed to it, then it will receive the message. There is no direct client to client communication and all the data flows through a broker. You can implement one to one, bidirectional as well as one to many styles of communication.
- QoS: The Quality of Service or QoS of MQTT ensures that the broker once receives the message will transmit to appropriate clients even if there is a problem with the network.
- Easy to Scale: The benefit of small IoT implementations is that you can easily scale the operation by adding more devices. The MQTT protocol can easily adjust to this scaling as there is no address or names to store and everything works as topic publish and topic subscribe fashion.
Advantages of MQTT
Apart from IoT projects, we can MQTT is several other areas such as: SCADA (Supervisory Control and Data Acquisition) Systems, POS (Point of Sale) Machines, Traffic Monitoring, Home Automation etc. Here are the advantages of MQTT.
- Simple communication
- Can very efficiently transmit information
- Less code overhead and small code size
- Less network bandwidth requirements
- Discovery of devices/services is very easy with less chance of errors
- You can easily modify the system without disturbing the network
- No polling with instantaneous delivery of messages in publish-subscribe model
- You can easily scale the system to involve additional devices
- Perfectly suitable for remote monitoring, sensing and control
- Has very good security measures to protect data
Conclusion
This was in introductory guide on MQTT. It is a very interesting topic, especially if you are working with IoT projects or Home Automation Systems (or other similar applications). If you are into DIY Projects, then you can use Raspberry Pi, Arduino, Beaglebone Black, ESP8266, ESP32 or other similar boards with internet connectivity to communicate using MQTT (to send data from a sensor or control a motor).
We learned what is MQTT, how it works, its basic structure and elements and also the terminology. We also saw some advantages of this protocol. If you are interested, we can dive deeper into the World of MQTT by doing more projects on this topic.
