I used HTTP for my first ESP32 project and it kind of worked
When I first started connecting ESP32 boards to the internet, I just used HTTP. It made sense — I already knew how APIs worked from building web apps with the MERN stack, so firing off a POST request from a microcontroller felt natural. The problem was that my sensor was hitting the server every second, reconnecting over TCP each time, and my battery-powered prototype drained in hours instead of days. That's when I actually sat down and studied IoT protocols properly. This post is what I wish someone had explained to me before I wired up that first circuit.
Why protocol choice matters more than most tutorials admit
Most beginner ESP32 tutorials just use HTTP or point you at MQTT without explaining why. But protocol choice affects battery life, reliability over bad connections, how much cloud infrastructure you need, and whether your project scales to 10 devices or 10,000. Getting this wrong early means rebuilding later. I've done that rebuild. It's not fun.
1. MQTT — the one you'll probably use most
MQTT (Message Queuing Telemetry Transport) follows a publish-subscribe model. Your ESP32 doesn't talk directly to your dashboard — it publishes a message to a broker (like Mosquitto), and anything subscribed to that topic receives it. The overhead is tiny: a minimal MQTT packet can be as small as 2 bytes. It handles spotty Wi-Fi gracefully with QoS levels that let you choose between fire-and-forget and guaranteed delivery. This is what I switched to after the HTTP disaster and never left.
ESP32 (publisher)
↓ publishes to topic: "home/sensor/temp"
MQTT Broker (Mosquitto)
↓ forwards to all subscribers
Next.js Dashboard + Mobile AppWhen MQTT makes sense
Use it for: real-time sensor dashboards, home automation, relay control, anything where you want bidirectional communication between devices and a server. I built an ESP32 relay controller connected to a Next.js dashboard using MQTT over WebSockets — the frontend subscribes to state changes and publishes commands back. It's clean and responsive in a way HTTP polling never was.
2. HTTP — you know it, but it has real costs on hardware
HTTP is request-response. Every time your device sends data, it opens a TCP connection, sends headers (which are surprisingly large), waits for a response, and closes the connection. That's fine on a server with plenty of resources. On a microcontroller running on two AA batteries, every one of those steps burns energy you don't have. The upside is you probably already know how it works and can integrate with any web service without extra infrastructure.
POST /api/temperature HTTP/1.1
Host: my-server.com
Content-Type: application/json
{ "value": 26.4, "humidity": 61 }When HTTP still makes sense in IoT
If your device is plugged in (not battery-powered), sends data infrequently (every few minutes), and you want to skip running a broker, HTTP is totally fine. I still use it for ESP32 projects that just need to send occasional readings to a REST API without building extra infrastructure.
3. CoAP — HTTP for tiny devices
CoAP (Constrained Application Protocol) is essentially HTTP redesigned for microcontrollers. It uses UDP instead of TCP, which removes the connection overhead. It has the same GET/POST/PUT/DELETE model you know from REST, but the message format is dramatically smaller. Most hobbyist projects won't need CoAP — but if you're designing something for mass deployment on coin-cell batteries, it's worth knowing exists.
4. Bluetooth Low Energy — short range, serious battery life
BLE is remarkable for what it achieves on power. A BLE device can run for months or years on a small battery because it sleeps most of the time and only wakes to transmit tiny bursts of data. The tradeoff is range — typically 10 to 50 meters in practice. BLE is perfect when you need a sensor to talk to a phone or nearby hub without any internet infrastructure.
Temperature Sensor (BLE)
↓ 15m range
Raspberry Pi / Phone (BLE gateway)
↓ Wi-Fi
MQTT Broker or Cloud5. Zigbee — how smart home devices actually talk
Zigbee is the protocol behind most Philips Hue bulbs, IKEA Tradfri, and many commercial smart home devices. What makes it interesting is the mesh topology — devices can relay signals through each other, so adding more nodes actually extends your network range. Each device is a potential repeater. It's low power and works well in dense home environments.
Sensor (Zigbee end device)
↓
Smart Plug (Zigbee router — relays signal)
↓
Zigbee Coordinator (e.g. Conbee stick on a Pi)
↓
Home Assistant / MQTT6. LoRaWAN — send data kilometers away on a tiny battery
LoRaWAN is the most extreme tradeoff in this list: you can send data 5-15 kilometers on a single charge, but the data rate is very low and messages must be short. It's used in agriculture, smart cities, and industrial monitoring where sensors are spread across wide areas with no reliable Wi-Fi infrastructure. I haven't built anything with LoRaWAN yet, but it's on my list for an outdoor environmental monitoring project.
7. Wi-Fi — the obvious choice, with obvious tradeoffs
The ESP32 has Wi-Fi built in, which is why it's the most popular microcontroller for hobbyists. Wi-Fi gives you direct internet access with decent throughput. The problem is power draw — Wi-Fi consumes 10-100x more energy than BLE or LoRaWAN. For plugged-in projects and prototypes it's perfect. For anything battery-powered that needs to last more than a week, you'll need to either use deep sleep aggressively or rethink the protocol.
How the protocols actually compare
No protocol wins at everything. The right choice depends on your constraints: range, power budget, data size, and whether you need a broker or gateway.
Protocol Range Power Best for
─────────────────────────────────────────────────
MQTT Internet Low Cloud dashboards, home automation
HTTP Internet Medium Simple APIs, plugged-in devices
CoAP Internet Very Low Constrained MCUs, mass deployment
BLE ~50m Very Low Phone-connected sensors, wearables
Zigbee ~100m mesh Low Smart home, commercial devices
LoRaWAN 5-15km Very Low Remote sensors, agriculture
Wi-Fi ~100m High Prototypes, plugged-in projectsWhat I'd recommend for your first project
Start with MQTT over Wi-Fi on an ESP32. It's the fastest path to a working connected device, the community support is massive, and it integrates cleanly with Node.js, Next.js, Home Assistant, or whatever backend you prefer. Run Mosquitto locally for development. Once that works, you'll understand the constraints well enough to decide if you need something different for your next project.
The lesson I wish I'd learned earlier
Protocols aren't just technical details — they shape the entire architecture of your project. Choosing HTTP first cost me a working prototype and a weekend of debugging. Ten minutes studying MQTT before writing a single line of firmware would have saved all of that. If you're just starting with IoT and ESP32, spend that time up front. You'll thank yourself later.
