MQTT - The ultimate ingredient of IoT
The sauce of protocol which makes IoT taste better
Nowadays IoT has become an integral part of our life and it’s changing everything around us drastically like shopping, manufacturing, traveling, health monitoring, home automation, and so on. IoT is the concept of connecting any device to the internet and other connected devices like smartwatches, microwaves, fitness trackers, TVs, fire detectors, bulbs, etc. IoT devices have very limited bandwidth and a small code footprint, because of it they need lightweight and flexible network protocol for communication, and MQTT is the perfect solution for it.
The Message Queuing Telemetry Transport (MQTT) is a lightweight and flexible network protocol that is mostly used to transport messages between devices. It is built on top of the TCP/IP stack however, any network protocol which provides ordered, lossless and bi-directional connections can support MQTT. It is designed to work with a small code footprint and limited bandwidth, and that’s why it became the ultimate ingredient of IoT.
MQTT Components
MQTT protocol is based on the pub-sub (publisher and subscriber) model. This model decouples the publisher and subscriber from each other and they never contact each other directly. The connection and communication between them are handled by a third component called a Broker.
Based on roles, MQTT has 3 types of components,
- Publisher: The publisher or sender is a component that publishes messages to the MQTT broker component. Each message contains the payload and topic. MQTT is data agnostic so the publisher decides that how to structure the payload, it could be binary data, text data, or even full-fledged XML or JSON.
- Subscriber: The subscriber or receiver is a component that is connected to the MQTT broker component. It receives the messages for the subscribed topics from the broker. The subscriber sends subscribe message to the MQTT broker, this message contains a list of subscriptions and a unique packet.
- Broker: The Broker is an intermediate component between the Publisher and the Subscriber. The responsibility of the broker is to receive information from publishers regardless of topics and broadcasting it to the subscribers who have subscribed for the received topic.
MQTT Topic
The MQTT topic is a lightweight case-sensitive UTF-8 string that acts like a route. The topic can consist of more than one topic level and each topic level is separated by a forward slash (eg. home/hall/temperature). The topic is used by the broker to filter messages for each connected component. Without any prior initialization, the broker can accept any valid topic. Publisher or subscriber does not need to create a topic before they publish or subscribe the information.
Subscribers can subscribe to the exact topic or use wildcards to subscribe to multiple topics simultaneously. There are two types of wildcards as below,
Single Level +: Single level wildcard only replaces one topic level which is represented by the plus symbol.
Ex. Subscriber of topic home/+/temp will receive messages with a topic like home/hall/temp and home/kitchen/temp
Multi-Level #: The multi-level wildcard is used to cover multiple topic levels which are represented by the hash symbol. To determine the matched topics, the multi-level wildcard must be placed at the end of the topic and preceded by a forward slash.
Ex. Subscriber of topic home/hall/# will receive a message with a topic like home/hall/temp and home/hall/light
Real-World Example
Now we have a better idea about the MQTT components and the Topic. Let’s take a real-world example,
In the above diagram, we have a home automation setup with MQTT. We have two rooms i.e. Hall and Kitchen. Each room contains one temperature and one light (ambient) sensor which are publishers and connected to the MQTT Broker. Each sensor is publishing messages(which contain Topic and Payload) to MQTT Broker.
On the other side, we have two subscribers connected to the MQTT Broker. Subscriber A is subscribed to topic home/hall/# by using a multi-level topic wildcard. Subscriber A will receive all the message which has topic prefix with home/hall like home/hall/temp and home/hall/light.
On the other hand, Subscriber B is subscribed to topic home/+/temp by using a single-level topic wildcard. So Subscriber B will receive messages which contains topic like home/hall/temp and home/kitchen/temp.
So far we have been discussing the MQTT protocol, MQTT components, and the Topic.
Demo
Let’s build this home automation example using NodeJs, Mosca, and MQTT.
Mosca is a node.js mqtt broker and MQTT is a client library for the MQTT protocol, written in JavaScript for node.js and the browser.
The first thing we need to do is install NodeJS on your machine,
The next step is to create one project folder named MQTT,
Open the MQTT folder and create a package.json file(using most of the default settings) inside the folder using the npm init command.
Now install two packages i.e Mosca and MQTT using the command npm I mosca mqtt.
Now we are done with all installation parts and your package.json file looks like this,
Now create a new file named broker.js, this will be our broker,
On line no. 8, we created a Mosca broker with settings.
On lines 11 and 16, we have added broker events ready and published respectively.
Create one more file named hall.js, this will be our first publisher.
On lines no. 5 and 6, we have created topic variables.
On line no. 9, we have created the last will and testament.
On line no. 15, we have created an MQTT component and connected it to a broker which is available on “mqtt://localhost:1200” with the last “will”.
On line no. 18, we have added a connect event and once it gets connected to the broker we started publishing messages to the broker.
On lines 30 and 39, we are publishing messages with topics home/hall/temp and home/hall/light respectively.
We are done with our first publisher and let’s create another one. Create a new file named kitchen.js.
This publisher file is almost the same as hall.js, only the topics are different.
On lines 5 and 6, defined topics are home/kitchen/temp and home/kitchen/light.
Apart from this one difference, kitchen publishers are the same as hall publishers.
Now we are done with publishers.
Let’s create subscribers, create a new file named subscriberA.js.
On line no. 5, we have created an MQTT component and connected it to a broker which is available on “mqtt://localhost:1200”.
On line no. 8, we created a multi-level wildcard topic, i.e. home/hall/#.
On line no. 15, we have subscribed to the topic home/hall/#. Now subscriber A will receive all the messages which have the topic prefix home/hall/ like home/hall/temp and home/hall/light.
On line no. 19, we have added a message event listener.
We have done with Subscriber A, let’s create one more subscriber.
Create a new file named subscriberB.js.
Subscriber B is almost the same as subscriber A, just one difference is there.
On line 8, we created a single-level wildcard topic, i.e. home/+/temp. Now subscriber B will receive all the messages for topics like home/hall/temp and home/kitchen/temp.
Cool, we are done with all the coding part, now let’s check all the code in action,
To start the MQTT broker, run the command node broker in the command prompt.
Awesome, our MQTT broker up and running.
Let’s run all publishers and subscribers, we have opened 4 command prompts and started our MQTT components one by one using commands node hall, node kitchen, node subscriberA, and node subscriberB.
On the left-hand side, we are running both publishers i.e hall and kitchen. And on the right-hand side, we are running both subscribers i.e subscriberA and subscriberB.
We can see subscribers are only receiving messages with topics for which they have subscribed.
SubscriberA is the subscriber to multi-level topics so it receives messages with topics like home/hall/temp and home/hall/light.
On the other hand, SubscriberB is the subscriber to single-level topics so it receives messages with topics like home/hall/temp and home/kitchen/temp.
Last but the most important thing, what will happen if any publisher gets disconnected ungracefully? In our case, if the hall gets disconnected ungracefully, will all the subscribers get a stale value of temperature? Don’t worry MQTT also has a solution for this, called Last Will and Testament. Last Will is a special setting sent by the publisher to the MQTT broker, which tells the broker to publish a special message for all subscribers when the publisher gets disconnected ungracefully.
In our case, you can see “Last Will and Testament” in the hall.js file on line no. 9. We have defined the topic and the last message i.e payload. So when we disconnected our hall publisher, subscriberA will get a special testament from the broker i.e “Something went wrong with Hall”.
By now, you should have a better understanding of the MQTT protocol, MQTT components, and the Topic with a practical example. We also understand that how MQTT is energy efficient and can work with limited bandwidth by using its reliable pub-sub model. The pub-sub model allows IoT devices to only receive messages from a subscribed topics. Because of these features, MQTT became the first choice in the IoT community.
Thank you so much and keep learning. :)
