The cheapest way to get a Wi-Fi microcontroller, a power supply, a driver and an enclosure is to buy a smart bulb. The manufacturer subsidises the hardware and expects to make it back on the app.
You can decline the app. But a mains-powered consumer device is the least forgiving place to learn this, so the order of operations matters more here than in most projects.
Rule one: never open a mains device that is connected
This is not boilerplate. Inside a screw-in bulb or a wall plug, the board sits downstream of a mains AC-DC converter, and parts of it are at line voltage with no isolation. The capacitors stay charged after you unplug it.
Everything below is organised around not opening the enclosure, because the moment you need UART access on a mains device you have taken on a genuinely different risk. Low-voltage devices — 5–24 V LED strip controllers, USB-powered sensors — are a different matter, and are where you should learn.
Rule two: find out what chip is in there before you buy
The single most common failure is buying the wrong revision. Vendors change the silicon inside a product without changing the model name or the box, and firmware built for an ESP32 will not run on an ESP8285.
- ESP8266 / ESP8285 — Tensilica, single core, no Bluetooth. The ESP8285 has flash on-die, so no separate flash chip is visible.
- ESP32 — Tensilica, dual core, classic Bluetooth and BLE.
- ESP32-C3 — RISC-V, single core, BLE only. Very common in recent cheap bulbs.
- ESP32-S2 — no radio for Bluetooth at all. Catches people out.
- ESP32-S3 — dual core, BLE, more RAM, common in displays and cameras.
How to find out without opening anything: search the exact model number plus “teardown” or plus the name of the firmware project you want to use. Community firmware projects maintain device databases, and the good ones state the unsupported revisions explicitly. Hardware-identification data in these databases, and the fact that two near-identical SKUs from one vendor can use different chips, is the reason to check before the order rather than after.
A second trick: most of these devices announce themselves. If it has already been on your network, look at its MAC address OUI — Espressif’s ranges are well documented — and at the HTTP headers or mDNS records it serves.
Rule three: use the over-the-air route
Many consumer ESP devices can be converted without ever being opened, because the stock firmware’s own update mechanism can be persuaded to accept a different image. The general shape:
- Put the device into its pairing mode, where it brings up its own access point to be configured.
- Join that access point from a laptop.
- Use a conversion tool that speaks the stock firmware’s provisioning protocol and pushes an intermediate image.
- From that intermediate, flash the firmware you actually want.
Whether this works depends entirely on the stock firmware version, and vendors patch it. This is why you check before you buy, and why batches matter: the same product bought six months apart may not be convertible.
If the over-the-air route is closed and the device is mains-powered, the honest answer is to stop. A cheap bulb is not worth a mains incident.
Rule four: keep a way back
Before you write anything, read the existing flash out and save the dump. esptool.py read_flash 0 ALL backup.bin over UART, or whatever your conversion tool offers. If you skip this, the stock firmware is gone permanently — some of these devices have no publicly available factory image.
Then prefer firmware that fails safe. The feature to look for is an automatic rollback: a firmware that counts boot failures and reverts to the previous image after a few consecutive crashes. Etherbulb, a recent ESP32-C3 bulb project, reverts after three — and that single behaviour is what makes an in-ceiling device recoverable without a ladder and a screwdriver.
ESP-IDF supports this natively through its OTA partition scheme: two app partitions plus an otadata partition that records which is active and whether the new one has been confirmed. Your application must call the “I booted successfully” function; if it never does, the bootloader goes back. Build your own firmware with that enabled from the first flash, not after the first scare.
Rule five: respect the power envelope
The LED driver in a bulb is sized for the manufacturer’s firmware, not yours. On an RGBCW bulb, the colour channels and the white channels are typically not designed to run at full duty simultaneously, because the total current exceeds the driver’s rating. The stock firmware enforces that; your firmware will not unless you make it.
So either find firmware that enforces an interlock in software with a check on the PWM duty cycles, or write one. Getting this wrong does not throw an error. It cooks the device slowly, or quickly.
The four ways people brick these
Wrong chip. Covered above. Flashing an ESP32 image to an ESP8285 gives you a device that never boots and no UART to talk to it with.
Wrong flash size or wrong partition table. The image writes, the bootloader finds nothing where it expects the app, and you get a boot loop. Read the actual flash size with esptool.py flash_id rather than trusting the datasheet for the module family.
No rollback and a bad first image. Self-explanatory, and the reason rule four exists.
Flashing while it is in a ceiling. Flash on a bench, on a lamp base you can reach, with the device at eye level. Then install it.
Where to go next
Start with a low-voltage target — a USB-powered development board, or a 5 V LED strip controller — and do the whole loop there: read the flash out, build an image with OTA rollback enabled, flash over UART, then push a second image over the air and confirm the rollback works by deliberately shipping a broken one. Once you have recovered a device from a bad image on purpose, mains hardware becomes a reasonable next step. Before that, it is not.
Sources
- ESP-IDF OTA update documentation — Espressif
- esptool.py documentation
- etherbulb on GitHub
- ESP32-C3 Smart Bulb with Tasmota — digiblur DIY on YouTube
- Tasmota supported devices