Because it matters
Making things happen, making things right, because it matters.
The part of IoT projects nobody talks about
Imagine having a single portal to control every ESP32 device in your home — a unified way to manage all the custom gadgets you’ve built. This was the unexpected result of my journey. My goal wasn’t to build a general framework; I simply wanted to create devices.
But after the second ESP32 project, a pattern emerged. Not in the hardware, but in everything around them. Every new idea quietly pulled in what I called the “invisible plumbing”: provisioning, configuration, data collection, and some kind of interface to keep track of it all.
At first, I barely noticed. The first project was fun, but by the second, the repetition was obvious. I was spending more time rebuilding scaffolding than working on the devices that actually mattered.
The core issue wasn’t with building devices — it was the constant need to rebuild infrastructure for every project. Realising this revealed a broader opportunity: consolidating repeated work into a single system to streamline device management.
When a thermostat taught me about repetition
The first project I really noticed it with was a smart thermostat. I had a fleet of small ESP32 boards connected to temperature and humidity sensors. The device logic was straightforward: read the sensors, send telemetry, and allow a remote command to activate the central heating through a relay.
The hard part wasn’t reading the temperature or toggling the relay; it was keeping track of all the devices, storing telemetry in a database, and making it easy to adjust parameters from a web interface. I built the backend, the web UI, and the provisioning flow. It worked, but it felt like scaffolding — necessary, but tedious.
Two weeks later, I built another ESP32 project: a door sensor for an open-door alert system. Once again, I spent a couple of hours rebuilding the same provisioning flow, telemetry storage, and web interface. The code and infrastructure were nearly identical, with only the sensor type and command logic changing.
Extracting the boring parts
Instead of trying to generalise device behaviour, I decided to pull everything around it into a small, reusable device management portal framework. This portal eliminates project-by-project backend changes by handling device provisioning in a consistent way. By storing capabilities, pushing configurations, collecting telemetry, and issuing commands generically, it significantly reduces duplicated work. The portal abstracts repetitive infrastructure, allowing you to manage devices more efficiently across projects.
All application logic stays on the device itself. The ESP32-C3 boards run pure MicroPython, handling Wi-Fi, MQTT, and the custom behaviour unique to each project. The portal doesn’t care what a thermostat is or why a mailbox sensor exists. From its perspective, every device is simply a set of capabilities and data streams. All application logic stays on the device itself.
How it all fits together
The system is intentionally straightforward. The devices run pure MicroPython on ESP32-C3 boards, handling Wi-Fi, MQTT, and their own application logic. The backend, built with Python, FastAPI, and SQLModel, stores devices, parameters, and telemetry, while exposing a clean API. The web frontend, built with React, TypeScript, Refine.dev, and Redux Toolkit, provides a generic management UI that works across projects.
Both the backend and frontend are packaged as reusable libraries. A single application wires them together and manages multiple projects at once, without requiring changes to the underlying infrastructure.
The thermostat portal displays the temperature and controls central heating based on preset thresholds. The door sensor records open/close activity and allows remote resets. The mailbox sensor tracks mail arrivals and notifies users. The backend and frontend remain unchanged; only the MicroPython logic of the device differs.
Adding a new project
Supporting a new ESP32 device no longer requires touching the portal. By defining the device’s capabilities and parameters and implementing its MicroPython logic, I reuse the same backend and frontend unchanged. Most of the work stays on the device, where it belongs. This means faster setup and reduced maintenance, allowing for easier focus on device functionality rather than infrastructure.
When a new device goes online, it automatically registers with the portal, declares its capabilities, and begins sending telemetry. Everything else just works. The abstraction ultimately proves its value: it reduces repetitive effort while maintaining flexibility for each project.
Why does this matter beyond ESP32?
This wasn’t really an embedded problem. It’s the same challenge I’ve seen in many small projects: infrastructure quietly growing faster than the thing it supports. Rebuilding it multiple times doesn’t make you more productive — it just adds frustration.
By isolating the reusable management layer, I was able to focus on what actually mattered: the device logic, the sensors, and the behaviour that made each project unique. Even if you never build an ESP32 project, this pattern probably feels familiar: the first few copies of the same work are fine; by the third, you notice the repetition, and abstraction becomes your friend.
What this system is, and isn’t
It’s not a home automation platform. It doesn’t provide dashboards, rules engines, or visual automation. It doesn’t attempt to replace firmware with configuration.
Its purpose is simple: to make small, custom devices easier to manage without rebuilding the same scaffolding for every project.
The payoff
Today, one portal manages three very different ESP32 projects. Each new device reuses the same provisioning flow, backend APIs, and UI. The devices remain simple, the infrastructure remains straightforward, and new projects start faster. Which, in this case, was exactly the point.
References
- The reusable device management framework mentioned in this article: https://github.com/ayltai/espark
- The single project that supports three different ESP32 projects: https://github.com/ayltai/Espartan