Interface and Application Programming
What is Interface and Application Programming?
At its core, interface and application programming is about creating a connection — not just wires and code, but a meaningful communication between humans and machines.
It’s one thing to make a microcontroller turn on a light or sound a buzzer — but can a person trigger that action through a button on a phone or laptop, even without writing a single line of code themselves? That’s where interface and application programming comes in.
It involves designing both:
-
The back-end logic (the code that runs on the board),
-
And the front-end experience (the UI a user interacts with).
Think of it as building the "face" of your project — a clean, intuitive space where users can interact with embedded systems in real-time, whether it’s through a touchscreen, a web interface, a mobile app, or even voice commands.
Group Assignment
Exploring Networking Methods with ESP32
For this week’s group assignment, Mihir, Devanshi, and I decided to divide the work and each try a different method to connect and communicate with the ESP32 using Wi-Fi. Our goal was to explore and compare different networking approaches, see what worked well, and understand the challenges that come with each one.
Hosting a Web Server on the ESP32
I worked on the web server method — where the ESP32 acts as a mini website host. The idea was to have the board connect to Wi-Fi and serve a webpage that could control a connected output device. In my case, that device was a buzzer.
I started by testing if the ESP32 was working and connecting to Wi-Fi properly. One thing I learned quickly: iPhone hotspots don’t always work well with the ESP32. The board would fail to connect or stay stuck during authentication. So I switched to an Android hotspot, and everything connected smoothly.
Once connected, the Serial Monitor showed the ESP32’s local IP address (e.g., 192.168.122.27). I entered that into my browser, and it loaded a simple web page hosted directly by the ESP.
To test, I started with just a message — “ESP32 is working!” — and once that worked, I added two buttons:
-
One to turn the buzzer ON
-
Another to turn it OFF
Each button was linked to an HTTP route (/on and /off), and clicking them would trigger a HIGH or LOW signal on GPIO D2, which controlled the buzzer.
It was incredibly satisfying to see this working — I could control a physical component in real time, directly from my browser. No app installs, no cloud server, just local communication over Wi-Fi. It also made debugging easier since I could see what was happening on the Serial Monitor in real time.
Problems
While I focused on the web server, Mihir explored MAC address filtering and direct device communication. He looked into how the ESP32 can recognize specific devices by their MAC addresses and experimented with filtering and targeting based on those unique IDs.
Devanshi tried using Blynk, a mobile-based IoT platform that lets you control ESP boards through a visual mobile app. It looked promising in theory, but in practice, it gave her a lot of issues:
1.The ESP32 often struggled to connect to the Blynk cloud server.
2.it wouldn’t connect to Wi-Fi at all.
3.Other times, it got stuck authenticating even though the token and code were correct.
After trying different versions and checking documentation, Blynk still remained unreliable — likely due to cloud-side issues or unstable Wi-Fi. Because of that, Devanshi shifted her focus to understanding why local options might work better.
What We Learned
1.This assignment showed us that not all networking methods are created equal, and things that look simple on the surface can be tricky in practice.
2.Web server hosting on the ESP32 was the most stable and easy to debug because everything runs locally.
3.Blynk can be powerful, but it depends on reliable internet, proper setup, and working servers — any issue in the chain breaks the connection.
4.MAC address filtering is useful for direct or selective communication, but it’s more complex and requires a deeper understanding of device-level networking.
5.We also realized how important it is to test in a stable Wi-Fi environment, especially when working with microcontrollers. Even something like the type of hotspot (Android vs iPhone) can make a huge difference.
In the end, the assignment wasn’t just about connecting devices — it was about understanding how communication happens, what tools give us the most control, and what kind of setups are actually reliable in real-world conditions.
Individual Assignment
This week, I explored how to control a hardware component (a buzzer) using a web interface hosted locally on an ESP32-S3 board. I essentially created a mini IoT application — a web switch that could turn the buzzer on or off from any browser connected to the same Wi-Fi network.
ESP32 Web Server – Basic to Follow
What I Built
I created a self-hosted web server using the ESP32-S3 that loads a minimal HTML interface. Through this interface, I can:
-
View the status of the buzzer (ON or OFF)
-
Turn the buzzer ON
-
Turn it OFF again — all via the browser
This web page is simple, responsive, and runs entirely from the ESP32’s memory.
How I Made the Web Page for the ESP32
The webpage I used wasn’t copied from a default ESP32 example — I actually built it myself with some help from ChatGPT. I wasn’t sure how to format the buttons or update the text at first, so I asked ChatGPT to give me a basic version of an HTML page that could be used inside the ESP32. It really helped me get started faster.
To begin, I just wanted to test if the ESP32 could host anything at all. added a line of HTML that simply said something like “ESP32 is working!” and loaded that in the browser. Once that part worked, I moved on to adding two buttons: one to turn the buzzer ON and one to turn it OFF.
I also made the webpage show whether the buzzer was currently ON or OFF, depending on what the user clicked. It wasn’t anything fancy — just plain text and buttons, all generated from inside the code on the board.
The page is fully self-hosted on the ESP32, so it doesn't need the internet or any app to work. As long as you're connected to the same Wi-Fi, you just type in the IP address of the board and the webpage appears instantly.
Let’s walk through the whole process step by step:
Testing the ESP32-S3 Board
Before anything else, I wanted to ensure my XIAO ESP32-S3 board was working. I ran a basic "blink" test — uploading a simple LED blink sketch to confirm that the board was functioning correctly and that my setup (drivers, port, board manager) was all set.
It was connected and working properly.
Connecting to Web
Once I confirmed that my ESP32-S3 board was functioning correctly via the serial monitor, I moved on to connecting it to Wi-Fi so it could host a web interface.
At this point, I hit my first roadblock — the ESP just wouldn't connect to Wi-Fi when I used my iPhone hotspot. After a bit of trial and error, I realized that some iOS hotspots have compatibility issues with ESP modules. So, I switched to using a mobile hotspot from an Android phone — and voilà, the ESP connected instantly.
To avoid any issues, I also made sure that:
My ESP32-S3 and laptop were connected to the same Android hotspot.
I had entered the correct SSID and password in the code.
Once connected, the ESP32 printed out a local IP address on the serial monitor, confirming the connection:
✅ Connected to Wi-Fi
🌐 IP Address: 192.168.122.27
🛰️ Web server started
I then uploaded a basic web server sketch that displayed a simple confirmation message on the browser — just to be sure the server was working
This was the first successful connection between the browser and the microcontroller, and it laid the foundation for building a fully functional interface.
Accessing the ESP’s IP address in a browser showed the message: "ESP32 is working!"
Connecting the Web Interface to Control a Physical Buzzer
make the buzzer react to web-based commands, I first needed to wire it correctly to the XIAO ESP32-S3. Since this is a simple output device, I used just three connections: power, ground, and signal.
I powered the buzzer using the 3.3V output from the ESP32, connected its ground pin to GND, and connected the signal line to GPIO D2, which I would control through code.
Buzzer to ESP32-S3 Pin Connections
| Component Pin | ESP32-S3 Pin | Description |
|---|---|---|
| Buzzer VCC | 3.3V | Power supply |
| Buzzer GND | GND | Ground connection |
| Buzzer Signal | D2 | GPIO pin to control ON/OFF |
This was done by making the ESP32:
-
Connect to Wi-Fi (Android hotspot in my case)
-
Start a web server
-
Serve a custom HTML page with control buttons
-
Interpret user input (button clicks) as commands to control the buzzer
The full setup required no external platform or cloud service. Everything — HTML, server, logic — was hosted on the ESP32-S3 itself.
I had a working setup where I could turn a physical buzzer ON and OFF straight from my browser — no extra software, no cloud services, just my ESP32-S3, a browser, and Wi-Fi.
Everything came together:
-
The ESP32-S3 connected to my Android hotspot, and I was able to access it using a local IP address.
-
It hosted a simple web page with two buttons — one to turn the buzzer ON, and another to turn it OFF.
-
When I clicked either button, the ESP sent a signal to GPIO D2, which controlled the buzzer in real time.
-
The page also updated live, showing whether the buzzer was currently ON or OFF.
Things to Keep in Mind
Working on this project taught me a lot about not just getting it to work — but also what to look out for along the way. Here are a few key takeaways and tips to remember:
1.Wi-Fi Compatibility Matters
What to avoid:
Don’t rely on iPhone hotspots. The ESP32 often fails to connect due to hidden security restrictions or lack of full DHCP support.
What to do instead:
Use an Android hotspot or a proper router.
Double-check that both your ESP32 and your laptop are on the same network.
How to solve:
1.If the ESP isn't connecting:
2.Try restarting your hotspot.
3.Recheck your SSID/password.
4.Watch the serial monitor for connection status messages.
2.Use the Right Pin Numbers
What to avoid:
Don’t guess pin names. On some boards (like XIAO ESP32-S3), the physical labels may not match Arduino pin numbers.
What to do instead:
1.Check the official pin mapping diagram for your board.
2.In my case, I used D2 for the buzzer signal, which worked correctly after confirming it matched the right GPIO.
3.Serving the Web Page
What to avoid:
Don’t assume the browser will always load the page. If the server code isn’t written or routed properly, you’ll just see a “connection failed” error.
What to do instead:
1.Make sure you define clear handlers for /, /on, and /off.
2.Always test your server response with server.send() for every route.
How to solve:
Add debug Serial.println() logs to verify which route is being triggered.
4.Refreshing the Interface
What to avoid:
Don’t expect your webpage to auto-update the status of the buzzer unless you’re dynamically rewriting the HTML.
What to do instead:
1.After every ON/OFF action, refresh the interface from the server side to reflect the current buzzer state.
How to solve:
Return to handleRoot() after executing the ON or OFF function so the UI updates immediately.
5.Code Upload Issues
What to avoid:
Don’t forget to choose the right board and COM port in the Arduino IDE. ESP32 boards won’t show up as expected if drivers aren’t installed.
What to do instead:
1.Use the ESP32 board manager and install CP210x or CH340 drivers if needed.
How to solve:
If upload fails, unplug and replug the board, press the BOOT/RESET button, or switch to another USB cable.