Overview of the MQTT Protocol
Tags: iot, mqtt
Published: 2017-05-24 14:50:31

---
title: Overview of the MQTT Protocol
published: true
description: 
tags: Iot, MQTT
---

There are several different ways one can utilize to connect an Internet of Things (IoT) device to a network. I have <a href="https://www.kenwalger.com/blog/iot/network-access-micropython/">previously</a> discussed some of the setup for a <a href="https://www.amazon.com/gp/product/B01N0B48NI/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=B01N0B48NI&amp;linkCode=as2&amp;tag=kenwalgersite-20&amp;linkId=0046d38f856ec3e7daa13be68ab68b3b" target="_blank" rel="noopener noreferrer">NodeMCU development board</a><img style="border: none !important; margin: 0px !important;" src="//ir-na.amazon-adsystem.com/e/ir?t=kenwalgersite-20&amp;l=am2&amp;o=1&amp;a=B01N0B48NI" alt="" width="1" height="1" border="0" /> to connect to a WiFi network. In an IoT environment full blown network protocols such as HTTP can be a bit heavy. A popular, lighter weight, solution I'd like to discuss the basics of isÂ MQTT.
<h3>MQTT</h3>
While MQTTÂ <em>used</em> to stand for MQ Telemetry Transport, itÂ is now classified asÂ <strong>not</strong> being an acronym. So what is it? What does it do? Well, it is a messaging protocol using <a href="https://en.wikipedia.org/wiki/Transmission_Control_Protocol">TCP</a> of TCP/IP fame to provide publish/subscribe services. It was, and is, designed for small, constrained devices and makes design decisions based on those constraints. Concepts which are important in the IoT world, such as memory, bandwidth, latency, power consumption, and network reliability. Let's focus in on one of the main MQTT concepts, the publish/subscribe pattern.
<h3>MQTT Publish/Subscribe Pattern</h3>
In a publish/subscribe pattern a client publishes information and another client canÂ <em>subscribe</em> to the information it wants. In many cases there is a broker between the clients who facilitates and/or filters the information. This allows for a loose coupling between entities.

The decoupling can occur in a few different ways, space, time, and synchronization.
<ul>
 	<li>Space - the subscriber doesn't need to know who the publisher is, for example by IP address, and vice-versa</li>
 	<li>Time - the two clients don't have to be running at the same time</li>
 	<li>Synchronization - Publishing and receiving doesn't halt operations</li>
</ul>
Through the filtering done on the broker not all subscribers have to get the same messages. The broker can filter on subject, content, or type of message. A client, therefore could subscribe to only messages about temperate data. Or only messages with content about centrifuge machines. Or, perhaps, we only want to receive information about specific types of errors.

Thinking about an IoT situation with, for example, a NodeMCU device with some environmental sensors connected to it such as a <a href="https://www.amazon.com/gp/product/B00JYQAIBM/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=B00JYQAIBM&amp;linkCode=as2&amp;tag=kenwalgersite-20&amp;linkId=8821b4ca99905bdc27b91f31a6cf6025" target="_blank" rel="noopener noreferrer">TMP36 temperature sensor</a><img style="border: none !important; margin: 0px !important;" src="//ir-na.amazon-adsystem.com/e/ir?t=kenwalgersite-20&amp;l=am2&amp;o=1&amp;a=B00JYQAIBM" alt="" width="1" height="1" border="0" /> and a <a href="https://www.amazon.com/gp/product/B00AFCNR3U/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=B00AFCNR3U&amp;linkCode=as2&amp;tag=kenwalgersite-20&amp;linkId=6ec157d39e27d84ac9e6ede2c459c641" target="_blank" rel="noopener noreferrer">moisture sensor</a><img style="border: none !important; margin: 0px !important;" src="//ir-na.amazon-adsystem.com/e/ir?t=kenwalgersite-20&amp;l=am2&amp;o=1&amp;a=B00AFCNR3U" alt="" width="1" height="1" border="0" /> we could be publishing that data. Some clients that are connected to our broker may be interested in that, others may not. They would subscribe to the information they wanted.

<a href="https://www.kenwalger.com/blog/wp-content/uploads/2017/05/pub-sub-model.png"><img class="alignnone size-full wp-image-325" src="https://www.kenwalger.com/blog/wp-content/uploads/2017/05/pub-sub-model.png" alt="MQTT Publish-Subscribe Model" width="611" height="396" /></a>

&nbsp;

Once connected to the broker the publishing client simply sends its data to the broker. Once there, the broker relays the appropriate data onto the clients who have subscribed for that data. Again, those subscriptions can be filtered. All of this data transferring is done in a light weight fashion designed for small, resource limited devices.
<h6>Message Packet</h6>
The message packet shown in the above diagram is just an example. Along with the message, or payload, a real packet would include additional information such as a packet ID, topic name, quality of service (QoS) level. Also included in the packet would be flags so the broker knows how long to retain the message and if the message is a duplicate.
<h3>Wrap Up</h3>
This is just the tip of the iceberg for MQTT, there are several other features of interest as well. Features such as Retained Messages, Quality of Service, Last Will and Testament, Persistent Sessions, and SYS Topics. It should also come as no surprise given the importance of security in today's world, that MQTT has security features as well.

<hr />

Follow me on Twitter <a href="https://www.twitter.com/kenwalger">@kenwalger</a> to get the latest updates on my postings on IoT topics. If you enjoyed this article, or have questions, leave comments below. Or see the original post on my <a href="https://www.kenwalger.com/blog" target="_blank">blog</a>.</em>