Board Selection
Is ESP8266 Still Useful?
Yes, ESP8266 is still useful, but not because it is the newest or most capable board. It is useful when the job is small, Wi-Fi-only, and clearly defined. For many new projects ESP32 is the safer default, but for simple sensor nodes, relay controllers, MQTT publishers, and small status displays, ESP8266 can still be a practical choice.
Why people still use it
ESP8266 remains common because it solves a narrow problem well. It connects to Wi-Fi, reads a few pins, talks HTTP or MQTT, and runs from inexpensive development boards such as [Part 3] Stop guessing room comfort. The ecosystem is mature, examples are everywhere, and most beginner problems have already been discussed by someone else.
That matters in real builds. A board with more features is not automatically better if the project only needs to send one temperature value every five minutes. If you already have ESP8266 boards, existing cases, tested wiring, or old Arduino sketches, reusing them can be more practical than redesigning everything around ESP32.
Where ESP8266 fits well
- Temperature and humidity nodes: DHT22, SHT, or DS18B20 readings sent to a server.
- Door and window sensors: Reed switch events published over MQTT.
- Small relay controllers: One or two outputs where safety isolation is handled correctly.
- Status displays: OLED or LED matrix devices showing simple server or sensor states.
- Webhook buttons: A physical button that calls a local API or automation endpoint.
- Simple MQTT nodes: Publish sensor data, subscribe to one or two commands, report online status.
Where it is the wrong tool
Avoid ESP8266 when the project needs BLE, camera input, audio processing, many GPIOs, complex local web UI, frequent TLS connections, or a long product lifecycle. These jobs need more memory, more peripherals, and more headroom. ESP32 is not just faster; it gives you room to add features without fighting the board.
| Requirement | ESP8266 | ESP32 |
|---|---|---|
| One or two Wi-Fi sensors | Good fit | Also fine |
| BLE setup or scanning | Not suitable | Good fit |
| Simple MQTT publish | Good fit | Good fit |
| Rich local web interface | Tight | Better |
| Future expansion | Risky | Better |
The hidden issue: power quality
Many ESP8266 problems are power problems. A sketch may work over USB on the desk but reboot in the field when Wi-Fi transmits or a relay switches. Weak 3.3V regulators, long wires, shared relay power, and noisy loads can all look like software bugs.
Before rewriting code, check the 3.3V supply, common ground, boot strap pins, relay isolation, and cable length. If the device resets when Wi-Fi reconnects or when a load turns on, the power design is the first suspect.
Minimum requirements for long-running devices
- Reconnect Wi-Fi without blocking the whole loop.
- Track MQTT failures and last successful publish time.
- Reject impossible sensor values and retry before publishing.
- Avoid long delays that starve watchdog behavior.
- Expose a simple status page or LED pattern for field diagnosis.
- If remote updates are planned, check flash size and firmware size early; see the OTA firmware update strategy.
Practical decision rule
Use ESP8266 when the device is Wi-Fi-only, small, stable in scope, and easy to replace. Choose ESP32 when the device needs BLE, more memory, stronger security, more peripherals, or a future you cannot fully predict yet.
ESP8266 is no longer the exciting default board. Its value is different: it is a small, proven Wi-Fi node for simple jobs. Used with that boundary in mind, it is still useful.