Interface and Application Programming
This week was about learning how to connect a microcontroller to a user interface so we can control outputs like LEDs. I tried using the Blynk mobile app and also a web server hosted on the ESP32. The goal was to control an LED remotely through a screen (phone or browser).
What is Interface and Application Programming?
It’s how people interact with electronic devices using apps, websites, or dashboards. It connects the user to the hardware.
Examples:
- Controlling lights or fans from your phone
- Reading sensor data on a screen
- Tapping a button to activate a machine
Real-Life Applications
- Smart homes (controlling lights, AC, door locks)
- Hospitals (checking heart rate or temperature on screen)
- Industry (machine monitoring and remote control)
- Farming (controlling water pumps with a phone)
Group Assignment
Trying Out Different Networking Methods
For our group assignment, me, Sohan, and Mihir decided to try out different ways of connecting the ESP32 using Wi-Fi. Our goal was to explore and compare multiple tools and see how well they actually work. We split the work — one of us used a web server method, another tried using MAC address filtering and direct communication, and I tried using Blynk.
At first, was excited about Blynk because it looked like an easy way to control the ESP32 from a mobile app. But in reality, we ran into a bunch of issues. The ESP32 wasn’t connecting properly to the Blynk server — sometimes it wouldn’t even connect to the Wi-Fi, other times it would get stuck trying to authenticate. We tried everything from checking the auth token to updating the library, but it just didn’t work smoothly. Maybe it was a version mismatch or Wi-Fi issues, but eventually, we left Blynk and switched to other approaches.
Then
Instead, we focused more on the web server method and using direct IP communication. We set up a basic local server on the ESP32 and accessed it through a browser. This worked much better — we could control things through buttons on the web page, and it was easier to debug using the serial monitor.
We also learned about using IP addresses to send and receive data directly between devices. This was something I had explored earlier during the Networking and Communication week, where I tested IP-based communication and read some documentation to understand how it works.
What We Learned
-
Not all tools work the same way — even if they look simple at first.
-
Blynk can be helpful, but it depends a lot on proper setup and stable internet. It's also cloud-based, so if there's an issue with the server or network, it fails silently.
-
Web servers on the ESP32 are more reliable for testing because everything runs locally.
-
We understood the importance of stable Wi-Fi, supported security protocols (like WPA2), and getting a valid IP address for communication to work.
-
Devices like the ESP32 need clear and steady network conditions. Some Wi-Fi sources (like iPhone hotspots) can be unpredictable and make debugging really hard.
Overall, the assignment helped us understand not just how to connect devices, but also what kind of environment and setup is needed for a successful connection. It was a lot of trial and error, but we learned a lot through the process.
Individual Assigment
Checking the ESP32S3 Board
Plugged into laptop, opened Arduino IDE then Uploaded a simple code to check Serial Monitor. It worked, so moved forward.
Trying Blynk App
Signed into Blynk, created a dashboard
Added a LED widget
Then, added a gauge meter
Here, could find the Address, Name, Token for connecting esp32, which is needed for coding.
But... the ESP32 couldn’t connect to Wi-Fi
Troubleshooting:
- Tried different Wi-Fi networks
- Found out Apple hotspot doesn’t work with ESP32
- Switched to Android phone hotspot, still not connecting
- Tried different codes but no success
So I decided to try a different approach.
Web Server Method
What Is a Web Server?
A web server is something that hosts a web page so users can view and interact with it using a browser (like Chrome). Normally, websites are hosted on big internet servers, but ESP32 can act as its own tiny web server!
That means:
Your ESP32 can send a web page directly to your browser using Wi-Fi – no need for the internet or external servers.
LED Connection Table
| Component | ESP32 Pin |
|---|---|
| LED Anode (+) | GPIO 10 |
| LED Cathode (–) | GND |
| Resistor (220Ω) | In series with LED |
Wrote a basic HTML page in Arduino IDE that had buttons:
One for turning the LED ON and one for OFF
Included Wi-Fi credentials in the code
(My ESP32 needs to know which Wi-Fi to join)
Opened Serial Monitor – waited for the ESP32 to connect It showed a local IP address (This is the address of the ESP’s web server)
Typed that IP address into a browser on my laptop
(Laptop and ESP32 were both connected to the same Android phone hotspot)
Even after uploading, the buttons didn’t control the LED
I checked everything: correct pin, right IP, etc.
Finally, I restarted the ESP32 and reconnected to Wi-Fi
After that, it worked smoothly — likely a small glitch during the first boot
A simple web page opened!It looked like this
After testing basic connection, I made a few small changes in the code to actually control the LED using buttons from the web page.
These changes included:
-
Setting the correct GPIO pin number (I used GPIO 2)
-
Adding code to handle what happens when each button is clicked
-
Updating the HTML section in the code to show two clear switch buttons
I opened this in my browser (on the same Wi-Fi), and now... A new version of the page appeared!
How This Works Behind the Scenes
-
The ESP32 connects to Wi-Fi and acts like a mini server
-
When you visit its IP address, it sends a HTML web page to your browser
-
When you click a button, the browser sends a request back to the ESP32
-
The ESP32 reads that request and turns the LED on or off based on what was clicked
Mistakes I Made
-
Forgot to keep ESP32 and laptop on the same Wi-Fi network
-
Used Apple hotspot, which doesn’t work for ESP32
-
Didn’t restart board after making changes
-
Misconfigured pin numbers once
(click to play the video)
This week I explored different ways to control an LED using an interface. While Blynk didn’t work due to Wi-Fi issues, the web server approach was successful. It felt great to finally control the LED from my phone browser, and I understood how important interface programming is in making smart, user-friendly projects.
What I Learned
-
Begin with basics: check if the board works before anything else
-
Blynk is useful but depends heavily on Wi-Fi and correct tokens
-
Creating a web page on ESP32 is a good backup plan
-
Small bugs often get solved by restarting or re-uploading
-
programming adds a user-friendly layer to hardware
Things to Remember
-
ESP32 must be on same Wi-Fi as your phone or laptop
-
Apple hotspots usually don’t work, use Android hotspot or proper router
-
Always select the correct port and board in Arduino IDE
-
Use the right GPIO pin as defined in your code
-
Restart ESP32 if something doesn't work — it helps!
-
Try the web server method first if new to interfacing
-
the interface simple in the beginning
-
Don't forget to add a resistor in series with your LED
What Happened When Tried to Connect My Microcontroller to an iPhone Hotspot
While working on my project, I had trouble connecting my microcontroller (like an ESP32) to my iPhone’s hotspot. At first, I thought maybe I messed up — like a wrong password or a bug in my code. But after trying many things and researching, I found out it wasn’t my fault. The problem was how Apple hotspots work — they don’t play nice with microcontrollers.
Microcontroller could see the hotspot’s name (SSID), but when it tried to connect, one of these things happened:
-
It would just time out and fail.
-
It would say the password was wrong — even though it wasn’t.
-
It would hang, stuck trying to connect but never finishing.
This only happened with Apple hotspots. If I used a normal Wi-Fi router or an Android phone hotspot, everything worked fine.
Learned About Apple Hotspots
-
Apple hotspots change settings a lot: iPhones constantly switch Wi-Fi channels and use power-saving tricks. Microcontrollers like the ESP32 expect things to stay steady, so these changes confuse them.
-
They use newer security: Apple hotspots often use the newest Wi-Fi security (WPA3) and newer internet protocols (IPv6). Many microcontrollers only support older security (WPA2) and older internet protocols (IPv4), so they can’t connect properly.
-
Apple blocks unknown devices: iPhones might block devices they don’t recognize. Since microcontrollers often use random MAC addresses (their device ID on the network), the iPhone might just ignore them.
-
IP address issues: Even if the microcontroller connects, it sometimes doesn’t get an IP address. iPhones are slow to assign these, and microcontrollers give up waiting.
-
Apple disconnects idle devices: If the microcontroller connects but doesn’t send or receive data right away, the iPhone might disconnect it automatically without warning.
What Took Away
The problem wasn’t with my microcontroller or code. It was just that Apple hotspots are built for phones, tablets, and laptops—not for tiny embedded devices like microcontrollers. For steady Wi-Fi during development, it’s better to use an Android hotspot or a normal Wi-Fi router.
Knowing this saved me a lot of time and frustration because I stopped trying to fix something that wasn’t broken on my side.
What Was Different This Time?
-
The first version of the web page didn’t control anything
-
After adding the LED control logic in the code (handling /ON and /OFF URLs), the ESP32 knew what to do when each button was clicked
-
The web server now didn’t just show a page — it also performed an action based on what I clicked
Hero Shot
