mqtt (message queuing telemetry transport) has gained a lot of prominence in the context of iot devices. it is a protocol that runs generally over tcp/ip. instead of the server−client model that we saw for http, mqtt uses the broker−client model. wikipedia defines mqtt brokers and clients as −

an mqtt broker is a server that receives all messages from the clients and then routes the messages to the appropriate destination clients. an mqtt client is any device (from a micro controller up to a full−fledged server) that runs an mqtt library and connects to an mqtt broker over a network.

think of the broker as a service like medium. the topics would be the medium publications, and the clients would be the medium users. a user (client) can post to a publication, and another user (client) who has subscribed to that publication (topic) would be told that a new post is available for reading. by now, you would have understood a major difference between http and mqtt. in http, your messages are directly sent to the intended server and you even get an acknowledgment in the form of status codes. in mqtt, you just send messages to the broker in the hope that your intended server(s) will take it from there. several features of mqtt turn out to be a boon if you are resource−constrained. they are listed below −

with mqtt, header overheads are very short and throughput is high. this helps save time and also battery.
mqtt sends information as a byte array instead of the text format. this makes the message lightweight.
because mqtt isn't dependent on the response from the server, the client is independent and can go to sleep (conserve battery) as soon as it has transmitted the message.

these are just some of the points which have resulted in the popularity of mqtt. you can get a more detailed comparison between mqtt and http here.

code walkthrough

in general, testing mqtt requires you to sign up for a free/ paid account with a broker. aws iot and azure iot are very popular platforms providing mqtt broker services, but they come with a lengthy signup and configuration process. luckily, there is a free broker service from hivemq which can be used for testing mqtt without any signup or configuration. it is ideal for those of you who are new to mqtt and just want to get your hands dirty, and also lets you focus more on the firmware of esp32. therefore, that is the broker we will be using for this chapter. of course, because it is a free service, there will be limitations. you can't share sensitive information, because all your messages are public, anyone can subscribe to your topics. for testing purposes, of course, these limitations won't matter.

the code can be found on github

we will be using the pubsubclient library. you can install it from tools −> manage libraries.

once the library is installed, we include wifi and pubsubclient libraries.

#include <wifi.h>
#include <pubsubclient.h>

next, we will define some constants. remember to replace the wifi credentials. the mqttserver and mqttport are the once mandated by http://www.mqtt−dashboard.com/.the mqtt_client_name, mqtt_pub_topic and mqtt_sub_topic can be any strings of your choice. just make sure that you do change their values. if multiple users copy the same code from this tutorial, you will receive a lot of messages from unknown clients when testing.

we also define the wificlient and mqttclient object. the mqttclient object requires the network client as an argument. if you are using ethernet, you would provide the ethernet client as an argument. since we are using wifi, we have provided the wifi client as an argument.

const char* ssid = "your_ssid";
const char* password = "your_password";

//the broker and port are provided by http://www.mqtt−dashboard.com/
char *mqttserver = "broker.hivemq.com";
int mqttport = 1883;

//replace these 3 with the strings of your choice
const char* mqtt_client_name = "espys2111";
const char* mqtt_pub_topic = "/ys/testpub"; //the topic to which our client will publish
const char* mqtt_sub_topic = "/ys/testsub"; //the topic to which our client will subscribe

wificlient client;
pubsubclient mqttclient(client);

next, we define the callback function. a callback function is an interrupt function. every time a new message is received from a subscribed topic, this function will be triggered. it has three arguments− the topic from which the message was received, the message as a byte array, and the length of the message. you can do whatever you want to do with that message (store it in spiffs, send it to another topic, and so on). here, we are just printing the topic and the message.

void callback(char* topic, byte* payload, unsigned int length) {
   serial.print("message received from: "); serial.println(topic);
   for (int i = 0; i < length; i++) {
      serial.print((char)payload[i]);
   }
   serial.println();
   serial.println();
}

in the setup, we connect to the wifi like in every other sketch. the last two lines concern mqtt. we set the server and port for mqtt and also the callback function.

void setup() {
   // put your setup code here, to run once:
   serial.begin(115200);
   wifi.mode(wifi_sta);                    //the wifi is in station mode
   wifi.begin(ssid, password);
   while (wifi.status() != wl_connected) {
      delay(500);
      serial.print(".");
   }
   serial.println("");  serial.print("wifi connected to: "); serial.println(ssid);  serial.println("ip address: ");     serial.println(wifi.localip());
   delay(2000);
   mqttclient.setserver(mqttserver, mqttport);
   mqttclient.setcallback(callback);
}

within the loop, we do the following:

if the client is not connected to the broker, we connect it using our client name.
once connected, we also subscribe our client to the mqtt_sub_topic.
we then publish a message to mqtt_pub_topic
we then run the mqttclient.loop(). this loop() function should be called regularly. it maintains the connection of the client with the broker and also helps the client process incoming messages. if you don't have this mqttclient.loop() line, you will be able to publish to mqtt_pub_topic, but won't get messages from mqtt_sub_topic, because the incoming messages are processed only when this line is called.
finally, we wait for 5 seconds, before starting this cycle again.

void loop() {
   // put your main code here, to run repeatedly:
   if (!mqttclient.connected()){
      while (!mqttclient.connected()){
         if(mqttclient.connect(mqtt_client_name)){
            serial.println("mqtt connected!");
            mqttclient.subscribe(mqtt_sub_topic);
         }
         else{
            serial.print(".");
         }
      }
   }
   mqttclient.publish(mqtt_pub_topic, "testmsg");
   serial.println("message published");
   mqttclient.loop();
   delay(5000);
}

testing the code

in order to test the above code, you need to go to www.hivemq.com

follow these steps once you are on that webpage −

click connect

click on add new topic subscription and enter the name of the topic to which your esp32 will publish (/ys/testpub in this case)

once you flash your esp32, you will start receiving messages on that topic every 5 seconds.

next, to test reception of message on esp32, enter the name of the topic your esp32 is subscribed to (ys/testsub in this case), then type a message in the message box and click publish. you should see the message on the serial monitor.

congratulations!! you've tested both publish and subscribe using mqtt on esp32.

code walkthrough

testing the code

references

Save or share this article