How to use Claude to build an E-Ink usage dashboard
Claude Code and Codex built a desk E-Ink quota screen. Tests caught false zero readings, and the maker required offline, stale and last-good-value states.
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
Build an ESP32 E-Ink dashboard backed by my local usage JSON service. Preserve the last valid quota values, distinguish Wi-Fi offline from stale server data and ignore null non-Codex log records. Redraw only when rendered fields change; give me physical checks for each failure state.
Reach people exploring AI agents
See placements →What happened
The maker reports daily use of the E-Ink screen after correcting false zero readings and defining honest data states. Individual contributions of the two agents are not separated.
Reported by PerspectiveWorking50 — RedditHow the agent did it
- The maker defined offline, stale and last-good-value behavior before accepting the dashboard.
- Claude Code and Codex implemented the Python data service and ESP32 display.
- Hardware tests exposed null log records, and the parser was corrected to select valid Codex limits.
Where a person stepped in
The maker tested hardware, found incorrect values, changed requirements and checked refresh behavior and driver details.
PerspectiveWorking50 used Claude Code and Codex to build an always-visible E-Ink dashboard for coding-agent usage limits. The hardware was a Heltec Wireless Paper board with an ESP32-S3 and integrated display, so the project did not need a custom circuit.
A Python service on Ubuntu exposed usage as JSON. The board fetched it over Wi-Fi and drew progress bars for the reported quota windows. The maker imposed specific failure behavior: lost Wi-Fi should show offline, an unresponsive server should show stale, and missing data must never overwrite the last good reading with a convincing zero.
That rule caught a real parser bug. Recent Codex logs could include a later premium record with null values, which the initial parser interpreted as zero usage. The correction selected valid Codex records explicitly. Display updates compared rendered content rather than raw JSON so incidental timestamps would not force redraws.
The author reports using the completed screen at the desk and published setup and hardware notes. Human testing and changing requirements shaped its reliability behavior. The account also distinguishes implemented full refreshes from possible future partial refreshes, avoiding a claim that every proposed display improvement had already shipped.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Reddit · PerspectiveWorking50
Frequently asked questions
Why preserve the last good value?
Missing data should not become a false zero-usage reading.
What caused the incorrect zero?
A later premium log record contained null values.
What triggers a redraw?
The author says rendered screen content is compared rather than the entire JSON document.
More details
About this account
The maker defined offline, stale and last-good-value behavior before accepting the dashboard. Claude Code and Codex implemented the Python data service and ESP32 display.
Original post and author replies opened. Both Claude Code and Codex built the project; their individual contributions are not apportioned. Actual daily use is self-reported, without long-term reliability measurements. Suggested prompt written by Agents In Use; no original task prompt was published in the verified account.
Credit: PerspectiveWorking50 — Reddit
Source published 1 Sept 2026
Source checked 14 Oct 2026
Tools and topics
Claude Code · Codex · Heltec Wireless Paper · Python · Ubuntu
E-Ink display · Honest data states
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.