Inspiration
I work as a greenkeeper, not as a professional software developer. Battery-powered equipment is part of real daily operations, and a failed or neglected battery can waste time, interrupt work, and shorten equipment life.
Inexpensive BLE battery monitors already measure useful data, but their information is usually isolated inside a phone application. I wanted to explore whether a Raspberry Pi Pico W could collect that telemetry autonomously and turn it into evidence that can be inspected, validated, and eventually used across a working fleet.
What it does
Fleet Battery Sentinel turns a low-cost BLE battery monitor into an auditable edge-telemetry source.
The Pico W starts an autonomous sampling session, disconnects while the monitor works, makes an independent live request between scheduled samples, reconnects, recovers the complete history, validates its protocol CRC, and persists the result safely.
The captured hardware run demonstrates:
15 unique scheduled readings at four-second intervals; an independent live request initiated at second 33; a response received 735 milliseconds later; complete history recovery with a valid CRC; a final DONE state with zero pending sessions.
A dependency-free browser dashboard replays sanitized captured evidence. It works directly through file:// and is also published as a live GitHub Pages demo.
How we built it
The firmware is written in MicroPython for Raspberry Pi Pico W. It separates BLE transport, protocol decoding, configuration, collection, validation, and durable storage.
The public repository contains genericized firmware, sanitized evidence, a self-contained replay, documentation, and host-side tests. Private hardware identifiers and original audit inputs are excluded from version control.
During Build Week, I used Codex with GPT-5.6 Sol as an engineering auditor and implementation partner. Codex compared the private source material with the public release, found a manifest-generation defect, removed dead code, strengthened placeholder-address validation, rejected duplicate sample IDs, verified persistence idempotence, and expanded negative-path, evidence, demo-integrity, and privacy testing.
The final release runs 32 tests successfully with the private audit inputs present. A fresh tracked-only public archive also passes all 32 tests, with private-only checks skipped cleanly.
Challenges we ran into
The most difficult part was preserving a truthful link between real hardware evidence and a safe public submission.
The public package needed to retain measured values, timestamps, protocol behavior, and CRC evidence without exposing device identities. It also needed to remain testable after the private audit material was removed.
Another challenge was timing precision. The recorded 33.001 second value is an application timestamp immediately before the BLE write, not independently measured radio timing. The documentation was corrected to state that distinction explicitly.
The replay originally depended on loading a JSON file through a local server. Codex helped make the evidence embedded and self-contained, so judges can open it without Python, packages, a server, or network access.
Accomplishments that we're proud of
I am proud that a practical idea from outside the software industry became a working, testable hardware system.
The strongest accomplishment is not only collecting battery readings, but producing evidence that survives independent validation: complete scheduled history, a live request during the active session, valid CRC recovery, durable persistence, and zero pending sessions.
I am also proud that the public release is reproducible and privacy-safe. It contains no private device identifiers, runs 32 tests from a fresh archive, and provides a dependency-free demo that judges can open immediately.
Finally, as a non-technical builder, completing a repository-level audit with Codex and GPT-5.6 Sol—and turning every discovered issue into a tested correction—was a major personal achievement.
What we learned
I learned that trustworthy telemetry is not just a graph. It requires explicit state, reproducible evidence, CRC validation, duplicate protection, recovery behavior, privacy boundaries, and documentation that distinguishes measured facts from inference.
I also learned how useful Codex can be beyond code generation: as a persistent reviewer that can inspect a repository, compare evidence, reproduce failures, add regression tests, and continue until the release checks pass.
What's next for Fleet Battery Sentinel
The next step is multi-sensor field validation across real equipment, followed by configurable alert thresholds, longer-term trend analysis, and fleet-level reporting. The current project deliberately stays focused on the single-device workflow that was actually demonstrated and verified.
Log in or sign up for Devpost to join the conversation.