ESP32 + Sensors
I’ve been tinkering with an ESP32, a motion sensor, and a simple "publish an event when something happens" loop.
The end state I’m building toward is a small fleet of ESP32-based nodes, each paired with one sensor (motion, contact, light, etc.), optimized for low power, and built to be reliable in the real world.
Each node emits events into an event hub and, via pub/sub, the following occurs:
- Sensors publish signals ("motion detected")
- Consumers subscribe and react ("turn on a light," "send a notification," "arm another node," "start a timed workflow")
The action layer is built in Go because I wanted the orchestration to be fast, observable, and evolvable without having to directly re-flash each hardware node every time I change a response to an event.
The C++ software on the sensor nodes was intentionally minimal, so most of the intelligence for IoT automation resides in the backend.
Why focus on "motion"?
Because motion is the perfect primitive:
- It’s noisy in the real world (false positives, warm-up behavior, signal jitter)
- It forces you to deal with edge detection ("publish once per event")
- It instantly touches power strategy ("always on" vs. "wake on interrupt")
- It’s the kind of signal you can use everywhere: presence, occupancy, entry/exit, and safety
The technical surface area (aka: why this isn’t just "IoT")
This project sits at an intersection that’s unusually valuable right now because it touches both physical systems and backend architecture:
Embedded + hardware fundamentals
- GPIO + pull-ups/pull-downs, signal polarity, debouncing
- Sensor behavior in real environments (warm-up, drift, noise)
- Power budgeting, battery modes, deep sleep strategy
- Serial debugging that doesn’t disappear the moment you unplug the USB
Network + distributed systems
- Event design (idempotency, deduping, ordering, "edge vs. level" events)
- Connectivity realities (Wi-Fi drops, reconnect loops, backoff, offline buffering)
- Pub/Sub routing patterns (topic naming, consumer groups, fan-out)
- Reliability and Observability (logs, metrics, tracing across the edge-to-backend boundary)
Go as the "automation engine"
Go is a strong fit because it allows for the following:
- Concurrency primitives that map nicely to event consumers and workflows
- Small, fast services that are easy to deploy and iterate on
- It scales from "single box at home" to "real distributed infrastructure patterns" cleanly
What’s next
The next steps are less about adding features and more about hardening the pipeline:
- Formalize the event contract for sensor payloads (timestamps, device identity, metadata)
- Intentionally design everything around Pub/Sub model (not "just publish a string and hope")
- Determine which events should be edge-triggered vs. stateful ("motion happened" vs. "occupied")
- Introduce more nodes and let the system prove itself under real load and real noise
The goal isn’t just to have an OOTB "smart home" solution. Instead, it’s to build a scalable system through a well-architected design: decoupled, event-driven, observable, and easy to extend.
┌───────────────────────────────┐
│ ESP32 Sensor Nodes │
│ - PIR / contact / light │
│ - low power + edge filtering │
└───────────────┬───────────────┘
│ events
v
┌───────────────────────────────┐
│ Event Hub (Pub/Sub) │
│ - MQTT topics / routing │
│ - event contract (JSON) │
│ - retries / offline behavior │
└───────────────┬───────────────┘
│ subscriptions
v
┌───────────────────────────────┐
│ Go Consumers │
│ - concurrency + fan-out │
│ - idempotent handlers │
│ - rules / workflows │
└───────────────┬───────────────┘
│ commands / side-effects
v
┌───────────────────────────────┐
│ Actions │
│ - automations │
│ - notifications │
│ - device control │
└───────────────────────────────┘
