As in the hardware work, Codex and I used incremental, spec-driven development. We documented responsibilities, interfaces, and constraints before implementing and validating each stage, and recorded subsequent changes in the design documents. The basic stack consists of the following components.

Firmware tasks run on the FreeRTOS integrated into ESP-IDF. I organized the architecture around separate domains, first defining responsibilities, state ownership, and public interfaces, then arranging their interactions.

Explicit interfaces keep changes focused when adding pages or integrating data sources.

I covered the main logic with unit tests, used simulation to check interaction and the data path, and moved to hardware testing once the end-to-end flow broadly worked.

The first firmware design questions concerned the GUI and system menu. What should be visible every day, where should settings live, and how should navigation work? I used LVGL to draw the LCD interface and organized pages around those usage scenarios.

LVGL handles interface composition and rendering. The main metric, trend chart, and system menu are separate views. Menu rows, focus outlines, and status icons reuse common components so that visual changes and interaction feedback remain consistent.

Between the GUI and the screen, esp_lvgl_port and esp_lcd coordinate rendering with SPI DMA pixel transfers. LVGL produces regions to refresh, the driver submits transfers, and completion signals let the interface reuse the buffers. Coordinating drawing and transmission became an important part of the screen implementation.

The knob handles everyday metric selection, brightness adjustment, and self-tests. Requests go through a common control layer, and values retrieved over the network use the same output path.

During acceptance checks, I considered whether the interaction matched familiar devices, alongside layout, information hierarchy, and appearance, then refined it through use.

Part 1 described the mapping between digits and physical tube pins. Firmware uses that mapping to generate serial data on a dedicated SPI bus, while PWM on BLANK controls brightness. The LCD uses a separate SPI bus so that large screen transfers do not occupy the tube-update bus.

Metric values can remain unchanged for long periods. The firmware therefore cycles through the cathodes once an hour and also provides display rest and a digit-by-digit self-test.

The tubes show a two-digit integer from 00 to 99. The LCD supplies the complete value, name, unit, and status. Fractional values are converted to integers, and out-of-range values are limited to the two-digit display range. The original value remains on the LCD.

Failure to retrieve data must remain distinct from a zero value. For quota display, a temporarily unreachable service and an exhausted allowance require different states. An old value may be retained within the rule’s allowed interval, but its status must show that it has become stale.

Provisioning uses a conventional SoftAP flow. The device opens a temporary hotspot, a phone connects and submits home Wi-Fi credentials through a web page, and the device joins the target network. The LCD provides the setup entry point and status.

After a successful connection, the device saves the configuration and stops the hotspot. The phone rejoins the same Wi-Fi and opens the management page at the device’s new address. Failed attempts can be retried after correcting the settings. Routine disconnections trigger automatic reconnection, and changing networks starts provisioning again from the menu.

With network access available, I included OTA updates so that new firmware could be uploaded through a browser or the desktop app. The current flow selects a local file and uploads it over the LAN. USB flashing remains available for maintenance.

The design uses two application slots in flash. One runs the current firmware and the other receives the new image. The current version stays intact while the alternate slot is written and validated. Only then does the boot target change. An interrupted transfer or failed validation leaves the original version available.

On its first boot, the new firmware checks basic functions such as storage, control tasks, and the GUI before confirming the version. A failed trial boot uses the rollback mechanism to return to the valid older image. After confirmation, the slots exchange roles and the next update writes to the other slot. Reserving room for two images adds a practical constraint to the font-size budget discussed earlier.

Once on the LAN, the device provides a web interface for settings that are awkward to edit on a small screen. Page assets ship with the firmware and are accessible through the device address. A browser authorization request must be approved on the device before management access is granted.

The interface handles display preferences, data sources, firmware uploads, and PromQL configuration with result previews. A common management API carries the requests, while the device owns the configuration rules. The desktop companion reuses that API to keep the two entry points consistent.

The metric page places settings beside the preview. PromQL, display name, unit, and chart style are configured on the left. The current value and historical trend appear on the right. Editing a query and checking its result together makes it easier to verify that the intended information is being collected.

The companion focuses on collector configuration and quick device management, using Tauri 2, Rust, and TypeScript. The UI handles configuration and inspection. A Rust backend collects data, serves Metrics, and connects to the device. Collection runs separately from the window, allowing the tray application to continue working after the window closes.

Each source appears as a separate card, with its enable switch, collection state, and current values.

Returning to the original purpose, the Codex collector reads the quota on the computer and exports a remaining percentage for the returned quota window. The device consumes an ordinary metric. Application-protocol and account-related handling remain in the client. The displayed value is the remaining proportion of a quota window, rather than an exact token-by-token balance.

After pairing, the app lets me choose metrics from the local results, reorder them, select the primary metric, preview retrieval, and open device settings or firmware updates. Local collection settings and device settings are stored separately, with both available from the client.

The tubes can also be a small desktop toy. I added a “party mode” to the companion with simple random-number, countdown, and manual-value controls.

The modes share the same number-sequence playback capability. The client prepares the numbers and timing, and the device plays them. Leaving party mode restores the regular metric display. The device gains a way for friends to participate beyond simply glancing at a value.