The best bill of materials is the empty one
Every maker has a shelf of half-planned projects that stalled the moment the shopping list got long. Two sensors, a relay module, a buck converter, a case, some Dupont wire — and suddenly a weekend tinkering session has a lead time and a freight cost. That’s usually where the momentum dies. So there’s something quietly radical about the observation at the heart of a recent XDA roundup of ESP32 projects: there’s a whole class of genuinely useful builds where the parts list is one board and the USB cable already tangled in your drawer.
I want to take that idea seriously, because it’s more than a curiosity. When a project needs nothing you don’t already own, three costs disappear: the money, the wait, and — the expensive one — the decision fatigue. You can start on impulse and finish before dinner. Here are the four jobs that earn that status, and where I’d actually deploy each one.
A DNS sinkhole that fits in your palm
The first surprise: you can run a real ad-blocking DNS sinkhole on an ESP32. Projects like the ESP32_AdBlocker firmware hold a blocklist in memory and answer DNS queries directly, no Raspberry Pi or home server required. The catch is RAM — modern blocklists are chunky, so you want an ESP32-S3 with 8MB of PSRAM rather than the bare classic board.
My honest take: this is not a Pi-hole replacement, and you shouldn’t pretend it is. You lose the query logging, the pretty dashboards, and the group management that make Pi-hole feel like infrastructure. But as a disposable sinkhole it’s excellent — the DNS blocker you hand to a family member, drop on a guest network VLAN, or throw in a bag for travel. If it dies or gets replaced, you’ve lost a five-dollar board, not a server you have to rebuild.
Motion detection with no motion sensor
The cleverest trick in the bunch is ESPectre-style Wi-Fi sensing. Wi-Fi packets carry channel state information — a fingerprint of how the radio signal physically propagates through the room. Move around the room and the fingerprint shifts. An ESP32 sitting next to your access point can watch those shifts and turn them into a motion score, no PIR module anywhere in sight.
Treat this as a lighting convenience, not a security control. After calibration it’s surprisingly reliable for the low-stakes jobs: pantry lights, hallway LEDs, “did someone actually go into the server closet.” I’d still put a real presence sensor on anything where failure hurts — stairs, or anything that decides whether an alarm arms. But for automations where a false trigger costs you nothing, free motion detection from a board that’s already there is an absurdly good deal.
The watchdog that can’t die with your server
This is the one I’d push on every homelab and small business, because it solves a monitoring blind spot that bites people constantly. When your uptime monitor runs inside the stack it’s watching — a container on the same host, a check that depends on the same network path — it fails exactly when you need it. The fix is an out-of-band probe, and an ESP32 on the desk Wi-Fi is about as out-of-band as infrastructure gets.
Flash it with ESPHome, point it at your Proxmox UI or your NAS or the client portal, and let it report connectivity to Home Assistant as a binary sensor. A trimmed version of the config looks like this:
http_request:
useragent: esp32-watchdog
timeout: 5s
binary_sensor:
- platform: template
name: "Proxmox Web UI"
id: proxmox_up
device_class: connectivity
lambda: return {};
globals:
- id: failures
type: int
restore_value: no
initial_value: '0'
interval:
- interval: 30s
then:
- http_request.get:
url: https://192.168.1.50:8006/
capture_response: true
on_response:
then:
- lambda: |-
id(failures) = 0;
id(proxmox_up).publish_state(true);
on_error:
then:
- lambda: |-
id(failures) += 1;
if (id(failures) >= 3) {
id(proxmox_up).publish_state(false);
}The three-strike counter matters: one dropped packet shouldn’t page you, three in a row should. And note what this enables beyond alerts. Because the probe is independent of your servers, it can be the trigger half of a dead man’s switch — if the ESP32 can’t reach the VPS for N minutes, it shuts the VPS down (or fires a webhook, or toggles a smart plug). That’s the shape of real failover logic, running on hardware that costs less than the coffee beside it.
A radio you’re not using yet
The fourth job depends slightly on which board you grabbed. Any ESP32 can act as a Bluetooth proxy, relaying BLE devices to Home Assistant — passive listening, or active control if you want to drive lights and blinds through it. If it’s a C6, the onboard 802.15.4 radio adds two more roles: a Zigbee router extending your mesh, or a Thread radio co-processor. Add a U.FL antenna and it’ll cover more than a room or two.
This is the least glamorous item and the one I’d bet gets the most daily use. Radio coverage problems are the silent tax on every smart-home rollout — pairing fails in the far bedroom, devices drop off the mesh, and the fix is usually “buy another hub.” A spare ESP32 plugged into a wall socket near the dead zone is the fix that’s already in the drawer.
The constraint is the feature
What ties these together isn’t the ESP32 specifically. It’s that each build works because it refuses to accrete parts. No sensors to mount, no modules to wire, no enclosure to print — flash, plug in, done. That’s why they escape the project graveyard: there’s no gap between deciding to do it and having it running.
So the next time you clear out a drawer and find a couple of ESP32s from an old order, don’t bin them and don’t “save” them. A spare board isn’t inventory, it’s unbuilt infrastructure: a travel DNS filter, a closet motion trigger, an independent pair of eyes on your Proxmox node, or a radio bridge for the far end of the house. The only thing you need to add is the cable — and you have that too.