ESP32 + CM4/CM5: Our Hardware Architecture for Self-Hosted AIoT
My journey into hardware architecture began out of necessity: I needed a self-hosted AIoT system that could continuously monitor and control thermal telemetry without relying on third-party cloud servers. Having spent years building embedded systems and edge software, I wanted an architecture that was lean, sovereign, and reliable.
After years of real-world prototyping and commercial deployments, my answer has solidified into two components: ESP32 at the edge, and Raspberry Pi CM4/CM5 at the core. That is the architecture I rely on, whether for a home, a factory, an office building, a resort, or a school. In The Lean Stack I wrote about the software side, and in my Rust article I covered bare-metal binaries. This post answers the question underneath both: what hardware do you actually build on?
Where this came from: a balcony full of hot sand
This architecture was not designed on a whiteboard. It was forced into existence by the balcony sand battery experiment.
A sand battery is, at its heart, a data problem: temperatures at multiple depths, heater duty cycles, energy in versus energy out, logged reliably for weeks. My initial requirement was straightforward: a lean, reliable channel of data collection that would not die overnight or silently drop readings.
Commercial deployments meant interfacing with whatever was already installed: Zigbee sensors, Matter and Wi-Fi devices, Bluetooth meters on the residential side; SCADA systems and PLCs speaking Modbus on the industrial side. Every site is a collection of protocols, and none of them care about your preferred stack.
Year after year, the same pattern emerged: low-cost, low-power nodes collecting and controlling at the edge, with one trustworthy local machine collecting, storing, and deciding at the center. By early 2024 that shape had solidified into a software and firmware architecture layer we called second.brains. The repository is public at github.com/AlphaBitsCode/second.brains, dating from before the recent wave of local AI interest.
The edge: ESP32 everywhere
The ESP32 is the best value proposition in the embedded hardware industry.
For a few dollars you get Wi-Fi, Bluetooth, enough GPIO to interface with almost any sensor or relay, and power consumption low enough to run battery-powered nodes that sleep most of the time. That covers the majority of site requirements:
- Data collection and transmission: reading, timestamping, transmitting, and sleeping for sensor values like temperature, power, water flow, occupancy, and air quality.
- Basic control and automation at the local node: factory line interlocks, farm irrigation valves, and pump schedules. The ESP32 handles these decisions locally, so a network outage never halts the physical process.
- Protocol bridging: an ESP32 with an RS-485 transceiver talks Modbus to a 20-year-old PLC on one side and MQTT to our core on the other. Legacy hardware gets a second life instead of a complete replacement.
The discipline is knowing what not to put there: no databases at the edge, no complex business rules, and no cloud credentials. Edge nodes stay simple, inexpensive, and replaceable, which keeps them reliable.
The core: CM4/CM5 as the local brain
Every site gets one central platform: a Raspberry Pi Compute Module 4 or 5 on an industrial carrier board with clean power input, reliable Ethernet, an M.2 SSD, and an enclosure suited for a dusty electrical cabinet.
This is where everything the edge collects lands, and where it stays:
- Centralized, reliable, secured storage. Every sensor reading, every event, and every control decision lives in a database on hardware you own, in a building you can walk into.
- No mandatory cloud connection. Nothing goes out to third-party servers unless you explicitly configure an encrypted off-site backup. The cloud becomes an optional backup target rather than a dependency.
- Local dashboards and local AI. The CM5 has sufficient compute to run site dashboards, automation logic, anomaly detection, and compact local models directly where the data lives.
A resort's occupancy patterns, a factory's production counts, or a school's energy profile is operationally sensitive data. Why should any of it live on someone else's computer? This is the self-hosting governance argument in physical form.
Why this two-tier split works
The division of labor is clear and aligns with economics:
- An edge node failure costs a few dollars and a five-minute swap. So we deploy many, cheaply, across the site.
- The core is the single component worth engineering with redundancy (reliable storage, watchdogs, active monitoring) because there is exactly one per site.
- Both tiers are commodity hardware with mature community documentation. No vendor lock-in, and no proprietary gateways that disappear when a vendor pivots.
The pattern scales cleanly in both directions: a home runs one CM4 and a handful of nodes; a factory runs one CM5 and two hundred. For a home, office, building, farm, resort, or school, the topology remains identical while node counts scale to fit.
Hardware is stable, software compounds
By standardizing on a stable hardware baseline, innovation moves into software and firmware, where AI coding workflows provide steady leverage.
The ESP32 firmware improves continuously. The core's storage, automation, and AI capabilities expand over time. The hardware underneath can run undisturbed for years, and when future compute modules arrive, they drop into the same carrier boards and architecture.
Buy the hardware once, own the data permanently, and let the software compound over time.