The 19-month pause, and rebuilding Kamoji on ESPHome

The last photos and videos from Kamoji's first development phase are dated May 15, 2024. After that, the project went quiet for nineteen months — not abandoned, but paused while we rethought how we were actually building it.

What seven months of manual C++ got us, and what it cost

By May 2024, a small team — a handful of developers — had built an ESP32-S3 system with IMU-driven driving state detection, a working TFT display with animated faces, a custom PCB at Revision 4, audio output, touch sensing, and real in-car testing. Every driver, every state machine, every display routine, written by hand in C++.

It worked, but it was slow to extend. Adding a feature meant a deep C++ dive. Testing meant reflashing hardware. The iteration loop that felt fast in October 2023 had gotten heavy eighteen months later. Hardware stayed parked at PCB Revision 4.

Why ESPHome

Near the end of 2025, unrelated to Kamoji at first, we started exploring whether our decade-old custom IoT stack — the smart home and office automation systems Originally US runs internally — could move onto established open-source platforms: Home Assistant and ESPHome. Maintaining custom firmware at scale is a tax on a consultancy's time, and the open-source ecosystem had matured enough that moving made sense.

That exploration fed straight back into Kamoji. If the goal was maker-friendly and open-source, ESPHome was the better fit than Arduino: a broader community, declarative YAML configuration instead of raw C++ for the basics, and built-in OTA, WiFi provisioning and sensor abstractions that Kamoji needed anyway. The decision was made: when Kamoji restarted, it would be rebuilt from scratch on ESPHome.

Writing firmware with an AI toolchain

The other thing that had changed was how we wrote code. A few months before restarting Kamoji, the team had started using ChatGPT to help write ESPHome YAML for simpler IoT boards — single-file configs for basic switches and sensors. Low complexity, but it worked, and it was how we learned the ESPHome model in parallel with experimenting with AI-assisted development.

Then Google Antigravity launched, with the ability to reason across multi-file codebases and help design custom ESPHome components in C++. That made it possible to apply the same approach to something as complex as Kamoji — work that would have taken months by hand became tractable in days. The ESPHome migration and Antigravity as the tool for it are what unlocked the project's second phase.

What that pace actually looked like

The new ESPHome repository was created on December 24, 2025. We set up auto-commit so that every file save during development pushed to git, turning the log into a continuous trace of the work rather than milestone markers.

469 commits in the first week. Multiple YAML configurations ran in parallel from day one — different display setups, different microphone configurations, experiments that would have needed sequential weeks in the manual era running side by side instead.

January 2026 was the busiest month in the project's history: 718 commits, including 91 in a single day — January 19, a Sunday. kamoji-production.yaml appeared on January 10, the first config explicitly labelled for production hardware. Two of the more complex pieces of the system, kamoji_fft_audio_processor and kamoji_gif_player, showed up by late January — the audio processor analysing microphone input in real time to detect music and sound events, the GIF player rendering animated sequences on the display at high frame rate.

By February 12, kamoji-core.yaml — the 2,781-line master configuration that became Kamoji's brain — existed. In April the codebase was reorganised out of that monolith into 19 discrete custom components, each with its own interface and independent testing: kamoji_imu, kamoji_gforce, kamoji_dynamic_eyes, kamoji_espnow, kamoji_ui_navigation, and more. That's the kind of restructuring you do when you expect other people to maintain, extend and contribute to the code — which was the point of moving to ESPHome in the first place.

This is the third post in a series on how Kamoji got built. Next: why Kamoji works the way it does — no touchscreen, offline by default, and where the ferrofluid visualizer came from.