The project.
The team’s design connects sensing nodes to a gateway. The software takes incoming readings and keeps a record of where they came from and whether they were delivered.
Getting readings to the dashboard.
The serial bridge parses incoming sensor fields and queues delivery durably. It retries failed transmissions with event identifiers. A FastAPI service handles authenticated ingestion, storage and normalized responses for the dashboard.
What happens offline?
Send a sample packet, disconnect the bridge, then send another. Reconnect to see the queued packet get delivered.
The bridge is connected. Send a sample packet.
This browser demonstration illustrates the queue-and-retry pattern. It does not connect to a sensor or test the production implementation.
Handling missing data.
When a sensor disconnects, the dashboard needs to show that a reading is unavailable. It also needs to keep sample data separate from live readings, so someone using it knows what they’re looking at.
What still needs testing.
The software includes a simulator. Sensor accuracy, firmware, wiring and performance in the field still need independent testing. The prototype cannot establish that water is safe to drink.
A missing reading needs to stay visible as missing, rather than look like a normal measurement.
How should a low-cost monitoring system communicate uncertainty without becoming unusable?
Interface capture with sample data, not field readings.
Data path
Original diagram drawn from serial bridge and ingestion code.