The need
The workshop needed a control system with clear operating states, local interfaces, and useful event records without depending on a cloud service.
Embedded and offline-first firmware
I approached this as a system whose states, faults, recovery paths, and local interfaces had to be defined before the hardware could be trusted.
The useful result at this stage is an inspectable architecture that names states and faults, keeps core operation local, and makes missing hardware visible. It is also a clear example of stopping short of a real-world effectiveness claim when physical work is unfinished.
The workshop needed a control system with clear operating states, local interfaces, and useful event records without depending on a cloud service.
Hardware-facing software has to keep behaving when a clock, storage card, sensor, reader, or network is unavailable. It also needs deterministic state changes, safe output defaults, useful records, protected configuration, and a way to recover without assuming the internet is present.
I organized the specification and build sequence, then implemented the M0-M5 firmware foundation: build and flash layout, configuration and setup, time and storage handling, event logging, the state machine and outputs, and sensor handling. I also configured automated compile checks and wrote the bench checklist that later physical work must satisfy.
My work spans requirements, system states, firmware structure, storage and recovery behavior, local UI contracts, hardware and wiring documentation, configuration rules, compile environments, and the distinction between what code can check and what must still happen on a bench.
Engineering choices
The design uses a device access point and an embedded local interface rather than requiring a cloud service. Any future remote integration must be explicit and optional.
The firmware uses named operating states, deterministic transitions, safe output defaults, structured event records, and explicit responses when time or storage is unavailable.
GitHub Actions can show that configured firmware environments compile. A separate bench checklist covers power faults, storage removal, sensors, NFC behavior, outputs, offline UI use, and negative paths that cannot be established by a compiler.
Current substance
Checks and demonstrations
Current limits
Status and reuse
Licensed under Apache-2.0. Later milestones are paused before bench testing resumes.
View the firmware repositoryRelated conversations
This project is a useful starting point for conversations about embedded systems where local operation, explicit states, recovery behavior, and honest test boundaries matter as much as the normal path.
A real conversation
I read these emails myself. Tell me what you are making, changing, exploring, or trying to repair. It helps to include:
Reaching out does not commit either of us to working together. It simply gives us a place to begin.