Overview of the MQTT Protocol

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.

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.

MQTT Publish-Subscribe Model

 

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.

Message Packet

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.

Wrap Up

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.


Follow me on Twitter @kenwalger to get the latest updates on my postings on IoT topics. If you enjoyed this article, or have questions, leave comments below.

Facebooktwitterredditlinkedinmail

Network Access with MicroPython on an ESP8266

In a previous post we have seen how to set up a WebREPL on a NodeMCU ESP8266 and create it’s own network. This is very handy in a lot of situations. In many other situations, however, there is already a network available for a device to join. With proper network access any machine on the network can use the NodeMCU. Let’s take a look at MicroPython networking and how we can leverage it to connect to the WebREPL interface from a different machine on the network.

Network Access

The first step is to get the NodeMCU ESP8266 connected to our network. We will need to do this from the serial connection since our WiFi settings will soon change. See my post here for how to setup a serial connection with the NodeMCU ESP8266. In taking a look at the networking documentation on the MicroPython site, we see that there is a network module available. MicroPython has made our lives easier, very nice!

With ssid as the name of the network, and password being the network password, we can get network access with the following commands:

import network
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect('ssid', 'password')

Entering each of those commands into the REPL should allow the NodeMCU ESP8266 to connect to the network.

Network Access

 

Test the Connection

If we give the device a moment or two to connect we can get the network configuration for the device with the ifconfig function.

wlan.ifconfig()

 

NodeMCU Network Config

Great! The ESP8266 is now has network access on the 10.0.0.31 network. The other numbers there are the network mask, gateway, and the DNS address, respectively. With the board connected we can enable the WebREPL interface and start the service.

Start WebREPL

Notice the two different IP addresses there. The 192.168.4.1 is the WiFi network the ESP8266 is generating and the 10.0.0.31 address is for the external network. The addresses themselves may be different on your own device based on your network.

Network Connection to WebREPL

Open the WebREPL client, as discussed in this post and use the IP address of the local network instead of the ESP8266 default 192.168.4.1 address. In this example I’ll input ws://10.0.0.31:8266/ into the address box to connect. Enter the password for the WebREPL that you created earlier and start entering Python commands!

WebREPL connection

Over in the terminal window you should also see a notification that there is a WebREPL connection.

Showing WebREPL Connection

Wrap-Up

In this short post we have seen here how we can obtain network access for our NodeMCU ESP8266 to an existing network and access it through the WebREPL client. Now you can access it through the serial interface, it’s own network, or a device on the same network. With this variety of ways to access an ESP8266 device


Follow me on Twitter @kenwalger to get the latest updates on my postings on MicroPython and IoT.

Facebooktwitterredditlinkedinmail