Problem
A handheld with several radios is only useful when its software makes those capabilities accessible. On my LILYGO T-Embed, I wanted a practical everyday interface: control my lights locally, inspect supported NFC tags, and navigate without reaching for a computer.
The challenge was integrating those workflows into constrained hardware and an existing firmware stack. Network delays, limited memory, and differences between the NFC controller and the upstream software all affected what worked on the physical device.
My role and scope
I developed and tested custom firmware for the T-Embed CC1101 / CC1101 Plus hardware family, built around the ESP32-S3. The work includes an independent FieldKit prototype and later extensions to the Sor3nt Flipper Zero ESP32 Port v1.1.6. The upstream port provides the application framework and existing device features; my work centers on integration, debugging, and the handheld experience.
FieldKit explored a shared interface for Wi-Fi, BLE, passive CC1101 signal inspection, PN532 NFC reads, infrared, and saved captures. The later port work focused on a Govee LAN controller, NFC compatibility fixes, and a custom monochrome UI. These are separate firmware builds, with different feature coverage.
Approach
The Govee controller discovers my H612D and H612B light strips over local Wi-Fi and exposes power, brightness, color, white temperature, and a small set of device-generated effects. It uses local UDP messages without requiring a cloud account or API key.
Sending a command is only part of the interaction. The controller reads the lights’ reported state, retries unconfirmed changes, and displays partial results when only one strip responds. Rotary navigation keeps one control in focus, with distinct browse, edit, and apply states.
Three implementation details made the integration more reliable:
- Network work has one owner. Socket operations run on the port’s native Wi-Fi worker; rendering and input remain on the UI side. This resolved a threading compatibility problem between the port and ESP-IDF networking.
- Discovery respects memory limits. Directed probes are paced, the receive buffer lives in the controller context, and worker stack allocation is explicit. Physical-device logs helped diagnose stack overflow and Wi-Fi allocation failures.
- Connection stages have separate time budgets. Association and DHCP are reported separately so a slow address assignment does not look like an incorrect password.
Architecture
The Govee integration follows a small, explicit path:
- Rotary encoder and buttons update selection and editing state.
- Controller and view model translate input into actions and keep the screen informed.
- Wi-Fi worker owns discovery, UDP commands, reply parsing, and confirmation retries.
- Local light strips return state; the UI shows confirmed, mixed, or unavailable values.
The display uses the port’s existing 128 × 64 monochrome canvas. The graphical controller reduced its view model from 258 to 92 bytes without adding a framebuffer. Host preview tools render the production drawing code, making layout checks possible before flashing hardware. The gallery shows these software renders, rather than photographs of the device.
Outcome and validation
The Govee integration was built, flashed, and tested with both physical light strips. Device traces recorded discovery and confirmed color and white-temperature changes; hands-on testing also confirmed the controls worked. Parser tests exercise production C code against real replies, malformed packets, control ranges, and state confirmation.
The custom Wired theme adds consistent navigation and pixel animation. After a first build exposed input lag, reducing unnecessary redraws and verbose input logging led to confirmed prompt knob, menu, and Back response on the device.
NFC work corrected a write-response mismatch between the PN532 and the upstream protocol stack, with blank-tag writing subsequently confirmed on hardware. Phone-readable URL emulation remains an experiment: controller recovery improved, but successful URL transfer to the test iPhone was not established.
What remains experimental
Sub-GHz work in FieldKit is passive signal inspection. The nRF24 work is limited to hardware planning and a reserved capture format; this case study does not claim a completed nRF24 protocol integration. The Govee controller targets the two tested models, and its effects are approximately synchronized rather than frame-locked.
The result is a personal hardware prototype with demonstrated integrations and documented limits. The most valuable lesson was tracing failures across UI state, task ownership, memory, and the physical device instead of treating a successful build as proof that an integration works.