Up next in 10
ESP32 MQTT in Action ā How to Subscribe & Publish with ESP-IDF
Aug 12, 2025
Learn how to implement MQTT communication on the ESP32 to enable seamless message exchange between IoT devices. š Download project files & article: ESP32 MQTT Tutorial ā https://controllerstech.com/esp32-mqtt-using-espressif-ide/ š ESP32 Tutorials ā https://controllerstech.com/esp32-tutorials/ š ControllersTech Home ā https://controllerstech.com/ š MQTT Documentation ā https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/mqtt.html š Subscribe for more ESP32 tutorials! š Like & share to help others. š” Share this video for ESP32 IoT tips! #ESP32 #MQTT #IoT #ESP32Tutorial #MQTTSubscribe #MQTTPublish #Controllerstech ________________________________________________________________________________________ ******* SUPPORT US ******* š Donate: https://paypal.me/controllertech š Join Membership: https://www.youtube.com/channel/UCkdqtSMnhYuMsJkyHOxiPZQ/join š Connect: Facebook: https://www.facebook.com/controllerstech
View Video Transcript
0:09
Hello and welcome to Controllers Tech.
0:12
This video is part two in our IoT
0:14
project series using the ESP32.
0:17
In the previous project, we learned how
0:19
to configure the ESP32's
0:22
Wi-Fi and station mode and connect it to
0:24
a known network. After that, we set up
0:27
the ESP32 as an HTTP client and send
0:32
data to the things cloud. Today, we will
0:35
take this project a step further. In
0:38
this tutorial, we'll see how to
0:39
configure the ESP32 as an MQTT client
0:43
and learn how to both subscribe to a
0:46
topic and publish data to it. We'll
0:48
continue directly from where we left off
0:50
in the previous video. That means the
0:52
ESP32's Wi-Fi is already set up in
0:56
station mode, and all we need to do now
0:58
is replace the HTTP client code with the
1:01
MQTT client code. Before we start
1:04
configuring the ESP32,
1:06
it's a good idea to test the MQTT
1:09
protocol using some well-known software
1:12
tools. For this tutorial, I'll be using
1:14
the HivemQ broker as our MQTT broker.
1:19
First, go to hiveq.com.
1:21
Under the MQTT section, open the public
1:24
MQTT broker page. Then, click on view
1:27
MQTT broker. This broker is completely
1:31
free and perfect for testing small
1:33
projects like ours. Click connect and
1:36
you will see all the details required to
1:38
connect to this broker. Next, we also
1:41
need an MQTT client, a tool that can
1:44
subscribe to topics and publish
1:46
messages. The ESP32 will act as one
1:50
client, but for testing purposes, we'll
1:53
use a second client on our computer. I
1:56
recommend downloading MQTT Explorer for
1:59
this. Since I am using a Mac with the M2
2:02
Core, I'll download the version meant
2:04
for the ARM processor. You can choose
2:06
the one that matches your operating
2:08
system. Once downloaded, you can either
2:10
install it or run the standalone
2:12
version. Inside MQTT Explorer, we need
2:16
to enter the broker's details. Start by
2:18
copying the host address from the HiveMQ
2:21
broker page. We're not going to use a
2:23
certificate for this test, so make sure
2:25
to uncheck that option. Paste the host
2:28
address into the host field. For the
2:30
port, use 1883, which is the default TCP
2:35
port for MQTT communication. Now, go to
2:39
the advanced section to add the topic
2:41
you want to subscribe to. This topic
2:43
name should be unique. Since we're using
2:45
a public broker, many common topic names
2:48
are already taken, which could cause
2:50
interference with our data. Using a
2:52
unique name ensures that only your
2:55
messages appear. Once the topic is
2:57
added, return to the main screen and
2:59
connect to the broker. At this point,
3:02
you won't see anything in the subscribe
3:04
topic unless a message is published to
3:06
it. To test, we can publish a message
3:09
ourselves. Go to the publish section in
3:11
MQTT Explorer and enter the exact same
3:15
topic name you subscribed earlier. Now
3:18
publish a random value to it.
3:20
Immediately you should see a new message
3:22
appear onto the subscribe topic. This
3:25
confirms that the publish subscribe flow
3:27
is working. Let's publish another value.
3:30
And again it appears instantly in the
3:33
subscribe topic. If I try publishing to
3:36
a completely different topic, that value
3:38
will not appear here because it's
3:40
outside of our subscription. With MQTT,
3:44
you're not limited to just numbers. You
3:46
can publish text strings, XML data, or
3:49
even JSON formatted data. All right, so
3:52
we have successfully tested the MQTT
3:55
broker and client. And now we are ready
3:57
to proceed with the ESP32
3:59
implementation. As I mentioned earlier,
4:02
we will be continuing from the project
4:04
created in the previous video. To keep
4:06
things organized, let's start by
4:08
renaming the project.
4:11
Next, open the Espressive IDE and import
4:15
this newly renamed project. Once the
4:17
project is loaded, make sure the correct
4:19
target MCU is selected. It's always a
4:22
good practice to build the project at
4:24
this stage to ensure there are no
4:26
compilation issues. The project compiles
4:29
without any errors, which means we're in
4:32
good shape to move forward. Now, since
4:35
we're switching from HTTP to MQTT, the
4:38
first step is to remove all the code
4:40
related to the HTTP client. This
4:43
includes deleting any header files,
4:46
macro definitions, and functions that
4:48
are specific to the HTTP client and the
4:51
things implementation. Inside the while
4:54
loop, we'll also remove the existing
4:56
HTTP client code in its place. We will
5:00
simply insert a delay for now so that
5:02
the loop remains functional until we add
5:05
the MQTT logic. Once these changes are
5:07
made, let's build the project again. The
5:10
build completes without errors. So, the
5:12
next step is to flash the firmware to
5:15
the ESP32 board and verify that the
5:18
Wi-Fi connection is still working as
5:20
expected. On the serial console, you can
5:23
see that the ESP32 successfully connects
5:26
to the mobile hotspot and even receives
5:28
an IP address. For this particular
5:31
project, we don't actually need the IP
5:33
address, but it's a good sign that the
5:35
connection is stable. With the ESP32 now
5:39
able to connect to the hotspot reliably,
5:42
we are ready to proceed with adding the
5:44
MQTT client functionality. We will once
5:47
again make use of functions from the
5:49
example projects provided by the
5:51
expressive IDF. Here is the GitHub
5:54
repository for these projects. I'll
5:57
include the link in the description of
5:58
this video so you can easily access it.
6:01
Inside the repository, go to the
6:04
examples section. Then open the
6:05
protocols folder and navigate to the
6:08
MQTT examples. You can choose any MQTT
6:12
example to start with. For this
6:14
demonstration, I am selecting the SSL
6:16
example. Open the main file of the
6:19
selected example project. We will begin
6:21
by including the MQTT client header file
6:24
in our project.
6:28
Next, copy the MQTT event handler
6:31
function and the MQTT app start function
6:33
from the example and paste them into the
6:36
main file of our project. Now let's take
6:39
a moment to understand and then modify
6:41
these functions to suit our needs. The
6:43
MQTT event handler is responsible for
6:46
managing all MQTT related events. These
6:50
include events such as MQTT connected,
6:53
MQTT disconnected, subscribed to a
6:57
topic, unsubscribe from a topic,
6:59
receiving data on a subscribed topic.
7:02
When the ESP32
7:05
acting as an MQTT client connects
7:07
successfully to an MQTT broker, the
7:10
connected event is triggered. In this
7:13
event, we will call the function ESP
7:16
MQTT client subscribe to subscribe to
7:19
our chosen topic. Here we will specify
7:22
the topic name we want to use. Once the
7:24
subscription request is made, we will
7:27
log a success message to the console to
7:29
confirm it. We can delete all other
7:32
unnecessary functions from this event
7:34
section to keep our code clean and
7:36
focused. If the connection to the broker
7:39
is lost, the disconnected event will be
7:42
triggered. In that case, we will simply
7:44
log a message to the console indicating
7:47
the disconnection. When the ESP32
7:50
successfully subscribes to a topic, the
7:52
subscribed event will run and again we
7:56
will log a confirmation message to the
7:57
console. Other events will similarly log
8:00
their respective messages. One of the
8:03
most important events is the data event
8:05
which is triggered when the client
8:07
receives some data on a subscribe topic.
8:10
In this event, we will first print the
8:12
topic name to the console followed by
8:15
the actual data received. All other
8:18
unrelated functions from this section
8:20
can be removed to simplify the code. The
8:23
MQTT error handling section is already
8:26
well defined in the example. So we will
8:28
leave that part unchanged. Next we have
8:31
the MQTT start function which we will
8:34
call later from the main function.
8:36
Inside this function we begin by
8:38
configuring the MQTT broker details.
8:41
Then we call ESP MQTT client init to
8:45
initialize the MQTT configuration. After
8:49
that we register our MQTT event handler
8:52
and finally we start the MQTT client.
8:55
For the broker configuration we need to
8:58
provide the MQTT broker address. In our
9:01
case since we are using the HYMQ public
9:04
broker the full address will be
9:06
MQTT/broker.him.com.
9:12
We also need to specify the MQTT port,
9:15
which is 1,883
9:18
for TCP connections. That's all we need
9:21
for basic broker setup. Inside the main
9:24
function, right after the ESP32 has
9:27
successfully connected to the access
9:29
point, we will call the MQTT start
9:31
function. Let's now build the project.
9:34
There are no errors, so we can flash the
9:37
firmware to the board. On the serial
9:39
console, we can see that the ESP32 first
9:42
connects to the network and then begins
9:44
attempting to connect to the broker. The
9:47
first event we see is connected, which
9:50
indicates that our ESP32 client has
9:53
successfully connected to the MQTT
9:55
broker. Immediately after, the log shows
9:58
that a subscription request has been
10:00
sent. This is generated after the client
10:03
sends a subscription request for our
10:05
topic. Finally, once the broker confirms
10:08
the subscription, the subscribed event
10:11
is triggered and we can see this success
10:13
message clearly logged on the console.
10:16
Now I will use MQTT Explorer to publish
10:20
a message to the same topic we have
10:22
configured. Since both the ESP32
10:25
and MQTT Explorer are subscribed to this
10:28
same topic, we should see the publish
10:30
data appear on both the ESP32 console
10:34
and within MQTT Explorer. Let's go ahead
10:36
and publish some data to this topic. As
10:39
soon as we publish, you can see that the
10:41
data is immediately received by the
10:44
ESP32 client. On the console, the topic
10:48
name and the data are printed clearly
10:51
confirming that the message has been
10:53
received. Let's try publishing some
10:55
different data to the same topic. Again,
10:58
the message is instantly received by
11:00
both the ESP32
11:02
and MQTT explorer. This shows that our
11:05
ESP32
11:07
acting as an MQTT client is successfully
11:11
able to receive any data published to
11:13
the topic it has subscribed to. In other
11:16
words, the subscription mechanism is
11:18
working perfectly. The ESP32 can listen
11:22
for messages, capture them, and display
11:24
the details in real time. Now that we
11:27
have confirmed the ESP32 can receive
11:30
messages, the next step is to use it to
11:32
publish data to the topic as well. This
11:35
will allow our ESP32 to act as both a
11:39
subscriber and a publisher, enabling
11:42
full two-way communication with the MQTT
11:44
broker. Let's revisit the MQTT example
11:47
from earlier. Here we can see the MQTT
11:51
client publish function which is used to
11:53
send a message to a topic. In the
11:55
example code, this function is called
11:57
inside the subscribed event, meaning it
12:00
runs as soon as the ESP32 successfully
12:03
subscribes to a topic. However, we are
12:06
not going to follow that approach.
12:08
Instead, we will create a separate
12:10
freeer to task dedicated to publishing
12:14
messages to the topic. This way, our
12:17
publishing logic runs independently and
12:20
at a defined interval. Since the MQTT
12:23
publish function requires the message to
12:25
be in character format, let's first
12:27
create a character array to store data.
12:30
For this demonstration, we will send
12:32
random integer values between 0 and 99
12:36
as our message data. To convert these
12:38
integer values into character format, we
12:41
can use the sprint function. Once the
12:44
data is formatted, we call MQTT client
12:47
publish to send the message to our
12:49
chosen topic. Here we will specify the
12:52
topic name and use the array we just
12:55
created as the message data. We can set
12:58
the length to zero which allows the API
13:01
to automatically calculate it. If the
13:03
message is successfully published, the
13:06
function will return zero and in that
13:08
case we will log a success message to
13:11
the console. If it fails, we will log an
13:14
error message along with a message ID to
13:16
help with debugging. We will configure
13:18
this task to run every two seconds so
13:21
that data is sent continuously at a
13:24
regular interval. Now there's one detail
13:27
to take care of. The client parameter
13:30
used in our publish task is not defined
13:33
within this task scope. Since the client
13:35
is created inside the MQTT start
13:39
function, we need a way to access it
13:41
globally. To do this, we define a global
13:44
MQTT client handle. Let's call it MQTT
13:48
client at the top of the project. When a
13:50
client is created in the MQTT star
13:53
function, we assign it to this global
13:55
variable, allowing us to use the same
13:58
client instance in other functions,
14:00
including our publish task. With this
14:02
setup, our MQTT publish task is ready.
14:06
Now, we need to decide when to start it.
14:09
The ideal place is when the MQTT event
14:12
connected event is triggered which means
14:15
the client is connected to the broker
14:17
and ready to send data. Since our
14:19
current goal is to test publishing, we
14:22
will comment out the subscription part
14:24
for now. Instead, in the connected
14:26
event, we will create a new task with
14:29
following parameters. The task function
14:31
is MQTT publish task and also give the
14:35
same name to it. Keep the stack size at
14:38
4 kilobytes. There are no parameters for
14:41
the task and make sure the priority is
14:43
set to five. This ensures that as soon
14:47
as the client connects to the broker,
14:49
the publish task starts and sends a new
14:51
message to the topic every 2 seconds.
14:54
Let's build the project. The compilation
14:56
is successful, so we can now flash it to
14:59
the ESP32 board.
15:06
Opening MQTT Explorer, we can
15:08
immediately see the messages published
15:10
by the ESP32 client appearing every 2
15:14
seconds. An added bonus is that MQTT
15:17
Explorer can plot these incoming values
15:20
on a chart, letting us visualize the
15:22
data changes over time. With this, we
15:25
have successfully demonstrated how to
15:27
use the ESP32 as an MQTT client that can
15:31
both subscribe to a topic and publish
15:34
messages to it. That's all for this
15:36
video. I hope the explanation was clear
15:38
and easy to follow. We will continue
15:41
exploring more ESP32
15:44
IoT related projects in the upcoming
15:47
tutorials. You can download the complete
15:50
project from the link provided in the
15:51
description. If you have any questions
15:53
or run into issues, feel free to leave a
15:56
comment. Thank you for watching and have
15:59
a great day ahead.
#Computers & Electronics