Why the ESP32-CAM specifically
It's cheap, it has just enough processing power to be genuinely interesting, and it forces you to think about resource constraints in a way a Raspberry Pi mostly doesn't. Streaming video, running motion detection, and writing to an SD card all have to share a chip with a fraction of the RAM a normal computer takes for granted — every feature has a cost, and you feel that cost immediately.
The core build: an ESP32-CAM handling video capture and a basic web interface, an INMP441 I2S microphone for audio, motion detection to trigger recording instead of running constantly, and Wi-Fi to get footage off the device without physically pulling the SD card each time.
From idle to recorded clip
Click through each stage to see what's actually happening at that point in the pipeline.
Idle Monitoring
Low-frequency frame comparison running continuously, deliberately lightweight so it doesn't compete with anything else for CPU time.
Motion Detected
Frame delta crosses a threshold, switching the device into active recording mode rather than running full capture around the clock.
Record to SD
Video and I2S audio get written locally — relying on Wi-Fi for real-time transfer during the event risks dropped frames if the connection wobbles.
Wi-Fi Transfer
Once recording stops, the file gets pulled off over the local network — decoupling "recording" from "transferring" avoided most of the resource conflicts I ran into early on.
Brownouts mistaken for bugs
Random resets under load looked like a software crash — it was actually the power supply sagging under peak current draw.
I2S pin mapping trial and error
Small pin-mapping mistakes produce garbled or silent audio with no obvious error message pointing at the cause.
Streaming and recording fighting
Trying to do both at full quality at once caused frame drops in both — the fix was degrading stream quality specifically during active recording.
Lessons learned & what's next
Power supply quality is not optional. A properly rated 5V supply with adequate current headroom fixed more "mystery bugs" than any code change did.
Decouple features that compete for resources. Recording and streaming don't have to happen at identical quality simultaneously — degrading one gracefully beats both failing together.
Next: offloading to a Raspberry Pi. Using the ESP32 purely for capture and motion triggering, then handing heavier processing to a Raspberry Pi on the same network — playing to each device's actual strengths instead of asking one chip to do everything. This is the direction the Klipper/CB1 project already pushed me toward.
Working on a hardware project of your own?
Get In Touch