There are several different ways one can utilize to connect an Internet of Things (IoT) device to a network. I have previously discussed some of the setup for a NodeMCU development board 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.
While MQTTÂ used to stand for MQ Telemetry Transport, itÂ is now classified asÂ not being an acronym. So what is it? What does it do? Well, it is a messaging protocol using TCP 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.
MQTT Publish/Subscribe Pattern
In a publish/subscribe pattern a client publishes information and another client canÂ subscribe 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.
- Space - the subscriber doesn't need to know who the publisher is, for example by IP address, and vice-versa
- Time - the two clients don't have to be running at the same time
- Synchronization - Publishing and receiving doesn't halt operations
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 TMP36 temperature sensor and a moisture sensor 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.
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.
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.
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.