lang="en-GB"> MQTT 101 Tutorial: Introduction and Hands-on using Eclipse Mosquitto - Atadiat

MQTT 101 Tutorial: Introduction and Hands-on using Eclipse Mosquitto

MQTT is one of the most well-known and adopted protocols in IoT world. The lightweight and simplicity design are great addons that make it suitable for embedded devices, with small as well as large processing and storage capabilities. The benefits introduced by using MQTT instead of HTTP include power saving and lower network bandwidth usage which are two important things for almost any IoT device. Numbers from Stephen Nicholas’ great study say that loudly!

In this article we will have a closer look at MQTT and we will get our hands dirty by trying this protocol on localhost.

 

MQTT in a Nutshell

 

MQTT or Message Queuing Telemetry Transport is “a Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed so as to be easy to implement.” according to the official definition. It’s specially designed for IoT context with the limited resource environment in terms of power, bandwidth and footprint.

The MQTT model includes 3 main blocks: broker, publisher and subscriber.

There is no direct connection between the publisher and subscriber, simply the subscriber tells the broker (server) which topics it interested in, and the broker handles sending a message with data for the requested topic/s to all subscribers. The publish/subscribe model is quite different from the request/response model in HTTP, and this allows for one-to-many message transfer.

 

 

The topics can be think of like a tag for each message, and can be in the form of one level or multi-levels (tree) each level separated by a slash (/) (.i.e:  rooms/room1/sensors/temp ). This can be used to organize data in a handy way.

Each device want to get data on a certain topic, must “subscribe” to it by informing the broker (server). The subscription can be done to a certain topic or “pattern”. To accomplish this wildcards (+ and #) are used.

MQTT protocol is based on TCP/IP. Not like HTTP, it’s a binary protocol not an ASCII (plain text) protocol where it uses bit/s as the basic units to control the protocol features while ASCII ones use characters. As a result, Binary protocols consumes less network bandwidth.

MQTT was designed for environments with limited resources in mind especially about network access, thus this protocol has many features and options related to message delivery from server and clients. QoS or Quality of Service is the term for the 3 options for message delivery levels:

The question now is, what if the client/subscriber was not connected at all? Will the messages be lost or received later when the subscriber connects again? The answer is “It depends” . It depends on the option called “Clean Session” specified in the connection packet. If the user set this bit, then each time the client (identified with an id number) connects, the server discard any previous Sessions (including messages) and start a new one, while if this bit is zero, then the server will store QoS 1 and QoS 2 messages that match any subscriptions that the subscriber had while it was disconnected.

More features like retained message and last will are going to be discussed more in the next section. For now, It’s enough to say that MQTT can define a message for each topic to be sent whenever a subscriber subscribed to the topic. This messages is called the “retained message”, while the “last will” is a message published on a specific topic when the broker loses the connection with the client. The will message is defined for each client independently.

 

Hands-on with MQTT

 

To exercise the fundamentals of MQTT, we will use Eclipse Mosquitto broker which is available for many platforms. First, download and install the broker.
There are some extra steps to install and run Mosquitto on Windows 10 that can be found in this Medium blog post.

After installation, start the broker on your localhost by running the mosquitto command.  You can check using netstat -an command to see the port 1883 (the MQQT port).

 

 

Now, run 2 terminals (for linux) or CMDs (for windows). One of them will be used to publish messages and the other to subscribe and get messages.

 

Simple Publisher/Subscriber

 

Eclipse Mosquitto comes with mosquitto_pub and mosquitto_sub which are used to publish and subscribe via topics.

Let’s first use this command to subscribe to “rooms/room1/sensors/temp” topic, using this command:

mosquitto_sub -t rooms/room1/sensors/temp

On the other terminal, let’s publish a message on that topic, using this command:
mosquitto_pub -t rooms/room1/sensors/temp  -m 25

‘-m’ is use to set the message value.

 

QoS & Clean Session

 

Now, let’s see when the QoS comes into action, but first we need to assign an ID to the subscriber using -i option, thus when the client is disconnected the session is saved for the specific ID. The other thing is to add is the -c option which disables the ‘clean session’ feature described in the previous section..

After the client (subscriber with ID = 2) was disconnected, the publisher published 3 messages. But as we can see, the client (ID = 2) received them once it became connected again. The 3 messages are with QoS level 2 using ‘-q’ argument which sets  the QoS level.

 

 

Let’s try now to send 3 messages (21, 22 and 23)  while the client (ID = 2) is disconnected, but this time only one of them is with QoS>0.

 

 

Retained Message and Last Will

 

Retained message is a message for each topic to be sent whenever a subscriber subscribed to the topic. For example, for the ‘rooms/room1/sensors/temp topic’, if the temperature sensor stopped working properly, a special value like NaN can indicate to every new subscriber that this sensor is not working. So whenever the publisher detects malfunctioning in the sensor, it can set NaN message as a retained message. The ‘-r option’ sets the message as a retained message.

Even if the subscriber has the ‘clean session’ feature and new id, it gets the ‘NaN’ message once it subscribes to the topic.

 

 

Back to MQTT protocol bits, the retained message is a bit field in the publish packet header.

 

 

Now, what if the sensor device was tempered by someone not authorized which lead to disconnection. How will the subscriper know? Here the ‘last will’ come into play!  Last will is a message published on a specific topic when the broker losses the connection with the client.

 

 

To view what’s going on in more detail from the protocol perspective, you can enable the debug option using ‘-d’ argument.

 

 

Lastly, if you want to test other feature of MQTT protocol, then the official documentation describes all options available with mosquitto_sub and mosquitto_pub commands.

 

References & Read More

 

After this introduction, scanning the protocol specification should be in your priorities. You can review the  HiveMQ – MQTT essentials series and this paper Tutorial: MQTT (Message Queuing Telemetry Transport) too. Also , the Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ Telemetry is a good book talking about MQTT. Last but not least, you can read more about security using TLS and MQTT and MQTT over websockets, and if you’re looking to use this protocol in you device, then you need to choose one of many, many available implementations. In a coming article we’ll see this protocol in action between ESP32 and an MQTT online server.
Exit mobile version