Back to all builds

Embedded and offline-first firmware

Paused Open source

ESP32 NFC Security System

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 need

The workshop needed a control system with clear operating states, local interfaces, and useful event records without depending on a cloud service.

What made it nontrivial

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.

What I took responsibility for

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

Decisions that shaped the work

Keep essential behavior offline

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.

Make states and failures visible

The firmware uses named operating states, deterministic transitions, safe output defaults, structured event records, and explicit responses when time or storage is unavailable.

Separate compile evidence from physical evidence

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

What exists now

  • A PlatformIO firmware project with flash partitions, LittleFS assets, version reporting, and configuration persistence.
  • Time and storage layers with visible missing-device states, flash fallback behavior, JSONL event records, and optional hash chaining.
  • An explicit DISARMED, ARMED, TRIGGERED, SILENCED, and FAULT state model with output and sensor modules through the documented M0-M5 boundary.
  • Local interface and NFC source code that remains inside later milestones the repository does not yet describe as complete.

Checks and demonstrations

How I checked it

  • The reviewed public revision passed its GitHub Actions build job, which compile-checks the configured ESP32 DevKit and ESP32-S3 environments.
  • The workflow performs no hardware flashing. Its successful result establishes compilation only.
  • The implementation plan maps each technical contract to a milestone and to physical checklist sections, which makes the remaining test work explicit instead of silently treating it as done.

Current limits

What this does not establish

  • The repository status counts M0-M5 as implemented. M6-M8 are paused, so NFC completion, the full web control surface, OTA work, bench testing, and release readiness must not be inferred from planned contracts or later-looking source files.
  • The bench checklist has not been completed. The system is not physically proven, production-ready, deployed, or shown to protect a workshop effectively.
  • A successful compile does not establish wiring, board behavior, sensor behavior, output safety, NFC behavior, or recovery under real power and storage faults.

Status and reuse

Where the project stands

Paused Open source

Licensed under Apache-2.0. Later milestones are paused before bench testing resumes.

View the firmware repository

Related conversations

Problems this work gives us a starting point for

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.

  • Offline-first devices that need a local interface and understandable operating states.
  • Firmware designs that must degrade visibly when optional hardware is missing.
  • Hardware projects that need a clear line between specification, implementation, compile checks, and physical bench work.
Back to all builds

A real conversation

Tell me what you have in mind

I read these emails myself. Tell me what you are making, changing, exploring, or trying to repair. It helps to include:

  • what already exists and what is not working
  • what you want to change or make possible
  • the timing and approximate budget or exchange you have in mind
  • whether location, travel, shipping, or access to a hardware bench matters

Reaching out does not commit either of us to working together. It simply gives us a place to begin.