Up next in 10
ESP32 IoT Project: ThingSpeak Data Logging Made Easy
0 views
Aug 7, 2025
Learn how to connect your ESP32 to WiFi in Station Mode using ESP-IDF, and send sensor data to ThingSpeak using HTTP GET requests. This video demonstrates how to create a real-time cloud-based data logging system, perfect for IoT projects like weather stations or smart meters. We'll walk you through setting up the WiFi connection, configuring ThingSpeak, and sending values to multiple fields using a clean, reusable code structure. 🔽 Download the complete project code here 👉 https://controllerstech.com/esp32-wifi-station-mode-with-thingspeak-data-logging-using-espressif-ide/ 📌 Stay tuned for the next tutorial where we’ll use the MQTT protocol to send data to ThingSpeak more efficiently. 📺 Don’t forget to Like, Share, and Subscribe for more embedded tutorials! #ESP32 #ThingSpeak #ESPIDF #ESP32WiFi #ESP32DataLogger #ESP32ThingSpeakTutorial #IoTProject #EmbeddedSystems #ESP32Cloud #IoTwithESP32 ________________________________________________________________________________________ ******* SUPPORT US BY DONATING****** https://paypal.me/controllertech *******Join the Membership******* https://www.youtube.com/channel/UCkdqtSMnhYuMsJkyHOxiPZQ/join
View Video Transcript
0:09
Hello and welcome to Controllers Tech.
0:11
In this video, we'll be working once
0:14
again with the ESP32
0:16
microcontroller using the Espressive
0:19
IDE. Today's focus is on how to log data
0:23
to the Things Speak Cloud Platform.
0:25
We'll begin by configuring the ESP32 to
0:28
operate in Wi-Fi station mode. This
0:31
means it will connect to an existing
0:33
Wi-Fi network just like your phone or
0:36
laptop connects to a home router. Next,
0:38
we'll configure the ESP32
0:41
to function as an HTTP client. It will
0:45
send HTTP get requests to the ThinkSpe
0:48
cloud to update data on a specific
0:50
channel. These get requests will carry
0:53
the sensor data or any value we want to
0:56
log and the data will be reflected on
0:58
the selected things channel. To make
1:00
things simpler, I'll be using the code
1:03
available from the template projects
1:04
that come bundled within the expressive
1:07
IDE. For this project, I'm using the
1:10
ESP32
1:11
Devkit Vroom 32 development board. If
1:14
you're located in India, you can easily
1:17
purchase this development board from the
1:19
controllers tech online shop. Let's
1:21
begin by launching the expressive IDE
1:24
and creating a new IDF project. Make
1:27
sure to check the option that allows you
1:28
to create a project from the available
1:30
templates. Now, in the search bar, type
1:34
espundershttp.
1:36
This will display the template project
1:38
that demonstrates the HTTP client. Once
1:41
you see the HTTP client template, click
1:44
okay to generate the project based on
1:46
it. We won't be using this project
1:48
directly. Instead, we'll copy the
1:51
contents of the main file and paste it
1:53
into a text editor for reference. Later
1:56
on, we'll use only the necessary
1:58
functions and parts from this file in
2:01
our actual project. After saving the
2:03
content, you can go ahead and delete
2:05
this template project. Then create a new
2:08
IDF project again. This time in the
2:12
search bar, type Wi-Fi and under the
2:14
getting started folder, choose the Wi-Fi
2:17
station example. This example is useful
2:20
because it helps configure the ESP32 to
2:23
operate in station mode, which we need
2:25
for connecting to an access point. Give
2:28
your project a name that is relevant and
2:30
then click finish to generate the
2:32
project. Now, here we have the main file
2:35
associated with this new project. Let's
2:38
build the project once to make sure
2:40
everything is set up correctly. The
2:42
project compiles successfully without
2:44
any errors. So everything looks good and
2:47
we're ready to move on. The main
2:49
function begins by calling another
2:51
function that is responsible for
2:53
initializing the Wi-Fi in station mode.
2:56
Within this initialization function, we
2:59
need to provide the SSID and password of
3:02
the Wi-Fi network or access point that
3:05
we want the ESP32 to connect to. By
3:09
default, the project retrieves these
3:11
credentials from the SDK configuration
3:14
files. However, we will modify this
3:17
behavior to use values that are defined
3:19
directly in our main source file
3:21
instead. For demonstration, I am using a
3:24
mobile hotspot created on my phone. Here
3:27
I am defining the SSID and password that
3:30
the ESP32 will use to connect to this
3:33
hotspot. We'll also define the maximum
3:36
number of connection attempts. And for
3:39
this example, I'm setting it to five.
3:42
Now, we need to go through the code and
3:44
update all the relevant definitions to
3:46
use the values we've defined manually.
3:49
Once the changes are made, let's build
3:51
the project again to ensure there are no
3:53
compilation errors. As mentioned
3:55
earlier, the main function calls the
3:57
wifi_init_sta
4:00
function to initialize the ESP32 in
4:04
station mode. Let's now look at what
4:06
happens inside this function. It starts
4:08
by creating an event group using the
4:11
Xevent group create function. This event
4:13
group will be used later to track the
4:15
connection status whether the ESP32
4:19
successfully connects to the network or
4:21
fails to do so. Next, we initialize the
4:24
TCP IP network interface stack using ESP
4:28
netifinet. After that, we set up the
4:30
default event loop by calling ESP event
4:34
loop create default which is required to
4:36
handle system events. We then create the
4:39
default Wi-Fi station interface using
4:42
the function ESP net of create default
4:44
Wi-Fi STA. This effectively sets the
4:48
ESP32 to operate in station mode,
4:52
preparing it to connect to a Wi-Fi
4:54
network. Following this, we define the
4:57
default Wi-Fi configuration by using the
4:59
macro wifi in nit config default. This
5:03
macro provides default settings that are
5:06
then passed to the ESP WFI init function
5:10
which initializes the Wi-Fi driver with
5:12
those configurations. If you're
5:14
interested, you can review the default
5:16
settings provided in the ESP Wifi.her
5:20
file. Next, we register two event
5:23
handlers to manage Wi-Fi events. The
5:26
first handler is set up to listen to all
5:28
general Wi-Fi related events while the
5:31
second one is specifically configured to
5:34
listen for the IP events. This
5:36
particular event notifies us when the
5:38
ESP32 has successfully connected to the
5:42
network and has obtained an IP address.
5:45
These event handlers play a key role in
5:47
monitoring the state of the Wi-Fi
5:49
connection. They allow us to detect
5:52
important changes such as when the
5:54
connection process starts, whether the
5:56
ESP32 successfully connects or if it
6:00
gets disconnected. Moving forward, we
6:02
define the Wi-Fi SSID and password using
6:06
the Wi-Fi config T structure. These
6:08
credentials were already defined earlier
6:11
at the beginning of the main file. So,
6:13
we'll now make use of them here. By
6:15
default, the Wi-Fi authentication mode
6:17
is set to WPA2PSK,
6:21
which is a common and secure method. We
6:24
will leave it unchanged since it matches
6:26
our use case. Now, let me clean up this
6:29
part by removing any unused or
6:32
unnecessary definitions to keep the code
6:34
neat and focused. After setting up the
6:37
configuration, we proceed to configure
6:39
the Wi-Fi mode. We use ESP WiFi set mode
6:43
to set the ESP32 to operate in station
6:46
mode. Then we apply the Wi-Fi
6:49
configuration by calling ESP wifi set
6:52
config and pass the Wi-Fi config T
6:55
structure to it. Finally, we start the
6:58
Wi-Fi driver using the ESP Wi-Fi start
7:02
function which begins the connection
7:04
process based on the defined settings.
7:06
Once the Wi-Fi is started, we wait for
7:09
the connection result by using Xevent
7:11
group weight bits. This function blocks
7:13
the execution until one of the
7:15
predefined event bits is set. Either
7:18
Wi-Fi connected bit or Wi-Fi fail bit.
7:21
These bits are updated by the event
7:23
handler depending on whether the ESP32
7:26
manages to connect successfully or fails
7:29
during the process. Let's go ahead and
7:32
build the project. Now the build process
7:35
completes without any errors which means
7:38
everything is working as expected. So
7:41
let's proceed to flash the code onto the
7:43
ESP32 board. Once the project has been
7:47
successfully flashed, you'll see the
7:49
logs appearing in the console. As shown
7:51
in the log output, the ESP32 has
7:54
successfully connected to the access
7:56
point and it has also obtained an IP
7:59
address. Even though we don't need the
8:01
IP address specifically for this
8:04
project, this confirms that the device
8:06
is now connected to the hotspot that was
8:08
created on the phone. With the Wi-Fi
8:11
connection working properly, the next
8:13
step is to integrate the HTTP client
8:16
code. This will allow us to send data to
8:18
the things cloud. But before diving into
8:21
the code, let's configure things to get
8:24
it ready for receiving data. Open your
8:26
browser and go to things
8:28
peak.mmathworks.com.
8:30
Click on the get started button to
8:32
begin. If you don't already have an
8:34
account, you'll need to create one. The
8:36
sign up process is straightforward.
8:39
Since I already have an account, I will
8:41
log into it directly. Now, we'll create
8:44
a new channel that will be used for this
8:46
project. Start by giving a meaningful
8:48
name to the channel, something that
8:50
reflects the purpose of your data
8:52
logging. Things allows us to define up
8:55
to eight fields in a single channel.
8:57
Each of these fields can store different
8:59
types of data. For example, one field
9:03
can hold temperature readings. Another
9:05
can store humidity values and a third
9:08
could be used for pressure data. For
9:10
this demonstration, I'll use two fields.
9:13
One will be used to store temperature
9:15
data and the second will store pressure
9:17
values. You can leave the rest of the
9:19
configuration settings as they are and
9:21
then click on save channel to proceed.
9:24
Once the channel is created, you'll see
9:26
two charts on the page, one for each of
9:29
the fields, temperature and pressure. At
9:32
the top of this page, you can find the
9:34
name of the channel you just created.
9:36
Click on the API keys section. This
9:39
section provides all the necessary
9:41
information for reading from or writing
9:44
data to this channel. Here you'll find a
9:47
write API key which is very important.
9:50
We'll use this key in our code to send
9:53
data to this thing channel. In case the
9:56
API key gets exposed or compromised, you
10:00
also have the option to generate a new
10:02
one easily. Let's begin by copying the
10:04
right API key from the things channel
10:08
settings and defining it as a constant
10:10
in our main file. We'll create a new
10:12
variable named things key to hold this
10:15
key so it can be easily reused in the
10:18
HTTP request. Next, we need to include
10:22
the required header files at the top of
10:24
the main file. Include ESP HTTP client.h
10:29
for handling HTTP communication and
10:32
ESP.NET.h
10:33
for managing the network interface. Now
10:36
let's define a new variable called is
10:38
connected and initialize it with a value
10:41
of zero. This variable will act as a
10:44
flag to indicate whether the ESP32 is
10:47
connected to the access point or not.
10:50
Ideally, this flag should be updated
10:52
inside the Wi-Fi event handler. Either
10:55
set when the device successfully
10:57
connects or reset when it disconnects.
11:00
I'll go ahead and update the code as
11:02
well as the article to reflect this
11:04
improvement for better reliability. Now
11:07
let's define a new function whose
11:09
purpose is to send data to the think
11:12
channel. This function will take two
11:14
parameters. The values that we want to
11:16
send to the two fields we created
11:18
earlier in our think channel. Inside
11:20
this function, we'll first configure the
11:23
ESP32 to operate in HTTP client mode.
11:27
Then we'll use it to send the formatted
11:29
data to the things server. To begin,
11:32
let's define a character array that will
11:34
be used to store the complete URL
11:36
string. We'll then use the sprint
11:38
function to construct the full things
11:41
URL and copy it into our array. This URL
11:45
is used to write data to the things
11:47
channel through an HTTP get request.
11:51
You'll notice that by default, the URL
11:53
structure only supports a single field.
11:56
So, we'll be modifying it in the code to
11:58
accommodate multiple fields. For now,
12:01
let's place the basic URL into our code
12:04
and change the protocol from HTTPS to
12:07
HTTP as it's simpler and doesn't require
12:10
certificate handling. Next, delete the
12:13
hard-coded API key from the URL.
12:16
Instead, we'll use a string format
12:19
specifier percent s to insert the key
12:22
dynamically at runtime. This key will be
12:25
taken from the things key variable we
12:28
defined earlier. Now remove the fixed
12:30
field value and replace it with an
12:32
integer format specifier percent d
12:35
allowing us to pass the actual data as
12:38
function parameters. Since we are
12:40
sending data to two fields, we'll add
12:43
one more field to the URL and include
12:46
another integer format specifier for the
12:48
second value. Finally, we'll pass both
12:51
the API key and the two data values to
12:54
the sprint function so they get inserted
12:56
in the correct places in the URL. With
12:59
this, our full URL is now properly
13:02
formatted and ready to be sent using the
13:04
HTTP client. Now, we will begin using
13:07
the relevant functions from the HTTP
13:10
client code that we copied earlier.
13:12
Navigate to the function named HTTP rest
13:15
with URL in that template. From this
13:18
function, let's copy the HTTP client
13:21
config structure and the code that
13:24
initializes this configuration. Let's
13:26
first take a look at what this
13:28
configuration structure includes. One of
13:30
the key members of this structure is a
13:32
pointer to the URL. When this field is
13:35
provided, it overrides several other
13:38
fields such as the host, username,
13:40
password, and path. So instead of
13:44
defining each of those fields
13:45
separately, we'll remove the predefined
13:48
ones and just define the URL field
13:50
directly. Paste the URL that we
13:53
constructed earlier into this
13:55
configuration structure. Next, set the
13:58
method field to configure the HTTP get
14:01
method since we're sending data using a
14:04
Git request. That's all we need. These
14:07
two fields, the URL and the method, are
14:10
sufficient for our project. Now we will
14:13
use the HTTP client functions relevant
14:16
to sending a GET request. Let's remove
14:18
the log function used for printing the
14:20
HTTP response since we're not using the
14:23
response data in this project. Finally,
14:26
after the HTTP request has been
14:28
processed, make sure to call ESP HTTP
14:32
client cleanup to properly delete and
14:34
free the HTTP client instance. Just like
14:38
the get method, the template code also
14:40
includes functions for other HTTP
14:42
methods like post, put, patch, delete,
14:46
and so on, which you can use depending
14:48
on your project requirements. That
14:50
covers the setup part. Now, let's define
14:53
a while loop so that we can continuously
14:55
send data to things at regular
14:58
intervals. Inside this loop, we'll first
15:00
check if the is connected flag is set.
15:03
This ensures that the ESP32
15:06
only sends data when it's connected to
15:08
the Wi-Fi access point. Let's define a
15:11
couple of integer variables to store
15:13
some dummy values for now. In a real
15:15
world project, you would replace these
15:18
with values read from actual sensors.
15:20
Once we've assigned or read the values,
15:23
we'll send them to the things speak
15:25
channel using the function we defined
15:27
earlier. After each data transmission,
15:30
we'll wait for at least 15 seconds
15:32
before sending the next set of data.
15:34
This is important because ThSpeak
15:37
enforces a minimum update interval of 15
15:40
seconds for free accounts. Let's also
15:43
log the values that are being sent so we
15:45
can see them on the serial console. All
15:47
right, let's now build the project to
15:50
make sure everything compiles. There are
15:52
no errors, so we can go ahead and flash
15:55
the project onto the ESP32 board. On the
15:58
serial console, you can see the data
16:00
being sent. The first values are 75 and
16:04
55. Now, if you check on the ThinkPe
16:07
cloud dashboard, you'll see that these
16:09
same values have been updated in the
16:11
corresponding fields. Next, we have
16:14
another set of values 49 and zero, which
16:17
are also reflected on the things graphs
16:19
in real time. Following that we get 35
16:23
and 81. Again the same values are
16:26
correctly displayed on the channel. This
16:29
confirms that our ESP32
16:31
is successfully logging sensor data to
16:34
the things speak platform. You also have
16:36
the option to make your things speak
16:38
channel public which means anyone with
16:41
the correct link can view the data
16:43
remotely from anywhere in the world. In
16:45
addition to line charts, you can add
16:47
various types of widgets to enhance the
16:49
visualization like gauges, numeric
16:52
displays, lamps, and more. Here I've
16:56
added a gauge widget that is configured
16:58
to display data from field one. The
17:00
gauges range is set from 0 to 100 to
17:03
match the expected values. As you can
17:06
see, the gauge updates in real time and
17:09
accurately reflects the value received
17:12
from field one. Everything is working
17:14
exactly as intended. So, I hope this
17:17
video helped you understand how to
17:19
configure the ESP32's Wi-Fi in station
17:22
mode, how to connect it to an access
17:24
point, and how to send data to the
17:26
Things Speed Cloud using HTTPG requests.
17:30
That's all for this video. In the next
17:32
one, we'll explore how to use the ESP32
17:36
in station mode to publish a topic to an
17:38
MQTT broker. You can download this
17:41
complete project from the link provided
17:43
in the description below. Feel free to
17:45
leave a comment if you have any
17:47
questions or doubts. Thanks for watching
17:49
and have a great day ahead.