Inspiration

When a home battery stops communicating, what actually happened? Did it fail, trip safely, or simply lose Wi-Fi?

That uncertainty becomes especially costly during a disaster, when operators must make decisions across hundreds of batteries. Sending a technician to every silent home wastes time, while assuming everything is fine can miss a real problem.

We took inspiration from flight recorders: preserve the evidence before something goes wrong, then use it to understand what happened.

QuietCheck: When batteries go silent, we tell you why—and what to do next.

What it does

QuietCheck helps battery-fleet operators investigate missing or suspicious telemetry by comparing four sources of evidence:

Battery black-box logs: recent temperature, charge, power and fault signals.
Smart-meter readings: whether the home’s power flow supports the battery’s reported behavior.
Neighboring batteries: whether the issue affects one device or a wider area.
Network patterns: whether silent devices share a carrier or gateway.

Our rule-based engine identifies likely causes and follows a progressive response ladder: Watch → Ping → Ask Owner → Hold → Dispatch. When evidence is insufficient, it can report uncertainty instead of forcing a diagnosis.

The dashboard displays the fleet, investigation tickets, evidence and action history. An integrated simulator lets us inject communication failures, battery faults, feeder outages and heatwaves, then observe the system’s response.

How we built it

Our three-person team combined two ECE backgrounds with one CS background.

We built the backend in Python with FastAPI, connecting a fleet simulator to a deterministic diagnosis engine. The frontend uses HTML, CSS, JavaScript and Leaflet to present the map and investigation workflow.

We also built an ESP32 hardware demonstrator. A potentiometer controls simulated battery output, while buttons trigger protective trips, overheating scenarios and communication loss. The device sends telemetry to the backend, buffers records during a connection interruption and uploads its backlog after reconnecting. The backend also supports phone notifications through ntfy.

The prototype combines a default fleet of 500 simulated batteries with a physical ESP32 running emulated battery behavior. It does not control a real home battery.

Everyday value and disaster resilience

On an ordinary day, QuietCheck helps investigate connectivity problems, identify abnormal behavior and prioritize maintenance.

During a widespread disruption, the same evidence helps operators separate communication failures from battery trouble. Our heatwave simulation also demonstrates preparation actions, including reserve charging and limiting output from unusually hot units.

The goal is to support a proportionate response before uncertainty leads to unnecessary shutdowns or service visits.

Making it global

We added regional simulation presets for Los Angeles, Shenzhen, Mumbai, Tokyo and Adelaide. These vary local districts, carrier groups and assumed meter availability while retaining the same diagnosis engine.

Our next step is to incorporate regional weather and utility data. Candidate sources include Open-Meteo, India’s IMD, QWeather and MET Norway.

Different environments need different policies: heat requires thermal context, snow and cold require equipment-specific charging limits, and remote terrain makes communication resilience and service prioritization especially important. Live weather integrations and local-language messaging remain future work.

Challenges we faced

Our central challenge was distinguishing conditions that initially look identical: a battery that stops reporting may still be operating normally.

We also had to connect asynchronous hardware telemetry with a continuously running simulation, handle delayed records after reconnection, and turn technical evidence into explanations an operator could understand.

Scoping was another challenge. We focused on a demonstrable investigation workflow rather than attempting production battery control.

What we learned

We learned that missing data is itself useful evidence—but only when interpreted alongside other signals.

We also learned why uncertainty must remain visible. A useful system should explain what it knows, what it inferred and what still requires human investigation.

Combining a physical device with a simulated fleet helped us demonstrate both individual failures and widespread disruptions within a hackathon.

What’s next

We want to connect real battery-management systems and independent meter feeds, validate diagnoses against labeled field incidents, and add live regional hazard data.

Further work includes durable device logging, authenticated telemetry, local-language contact and operator-approved actions that respect each battery manufacturer’s safety limits.

Responsible use

Incorrect diagnoses or malicious telemetry could lead to unsafe decisions or unnecessary interventions. QuietCheck is a decision-support prototype: battery-control actions and service dispatch are simulated, and real deployment would require authenticated data, validated operating limits and human approval for consequential actions.