Inspiration
The Gainesville Community Fridge provides free food to community members, but volunteers cannot be on site all the time. If the refrigerator becomes too warm, its door is left open, or the monitoring system stops reporting, someone needs to know quickly.
We built CommunityChill to answer one practical question:
Does someone need to check the community fridge right now?
Our goal was to create an affordable, offline-friendly system that gives non-technical volunteers a clear answer instead of overwhelming them with raw sensor data.
What it does
CommunityChill continuously monitors:
- The fridge temperature
- Whether the door is open or closed
- How long the door has remained open
- When the latest sensor reading was received
- Whether the monitoring system may be offline
The dashboard converts these readings into four volunteer-friendly states:
- All good
- Attention soon
- Needs attention
- Status unknown
If readings become stale, the dashboard stops presenting the fridge as healthy and warns that CommunityChill may be offline.
For our room-temperature demonstration, we use a configurable threshold of 80°F. A deployed refrigerator would use the food-safety threshold of 40°F.
How we built it
CommunityChill uses the following pipeline:
TMP117 temperature sensor + reed switch
↓
ESP32
↓ USB serial JSON
Raspberry Pi 5
↓
SQLite
↓
FastAPI
↓
CommunityChill web dashboard
The ESP32 reads a TMP117 temperature sensor and a magnetic reed switch. It sends a newline-delimited JSON reading to the Raspberry Pi over USB serial once per second.
The Raspberry Pi 5 validates each reading and stores it locally in SQLite. Keeping SQLite as the first destination allows the system to retain readings even when internet connectivity is unavailable.
We built a read-only FastAPI service that exposes health, status, and recent-reading endpoints from the Pi’s local database.
The dashboard was built with Next.js, React, TypeScript, and Tailwind CSS. It polls the Pi API every five seconds and derives its status from the latest temperature, door state, and timestamp. Recent readings allow the dashboard to calculate a live door-open timer.
We designed the interface to resemble the Florida Community Resource Map, using an ice-blue background, deep navy typography, accessible status colors, and a mobile-readable civic design.
Challenges we ran into
One major challenge was connecting several different layers reliably: physical sensors, ESP32 firmware, USB serial communication, Python, SQLite, FastAPI, and the React dashboard. We reduced integration problems by keeping each responsibility separate and using a small, consistent JSON contract between the ESP32 and Pi.
Stale data was another important challenge. A monitoring dashboard can be dangerous if it continues showing a green status after the sensor stops reporting. CommunityChill checks the reading timestamp and changes to Status unknown after two minutes without fresh data.
We also needed to demonstrate refrigerator safety rules without having a full refrigerator at the event. We made the temperature threshold configurable and used an 80°F room-temperature demo limit so we could trigger visible state changes during judging.
Finally, we had to design for volunteers rather than engineers. Raw timestamps, database IDs, and boolean values are useful for debugging, but the main interface needed to communicate the required action within seconds.
Accomplishments that we're proud of
We are proud that CommunityChill uses real hardware and real sensor readings throughout the complete pipeline.
Our working prototype includes:
- Live TMP117 temperature readings
- Physical reed-switch door detection
- Reliable ESP32-to-Pi USB serial communication
- Local SQLite storage
- A read-only Raspberry Pi API
- A responsive live dashboard
- A door-open duration timer
- Automatic stale-data and offline protection
- Clear green, yellow, red, and gray operational states
We are especially proud that the system does not depend on internet access to collect and retain sensor readings. The dashboard also avoids presenting old information as current, which makes its recommendations more trustworthy.
What we learned
We learned that an IoT project is not just about collecting sensor values. The real challenge is turning those values into a reliable and understandable decision.
We also learned:
- How to maintain a dependable newline-delimited serial protocol
- Why local-first storage improves resilience
- How to expose SQLite data through a read-only API
- Why stale-data handling is as important as temperature monitoring
- How to keep hardware, storage, API, and interface responsibilities separate
- How to design technical information for non-technical users
- How to build configurable rules for both demonstrations and real deployment
What's next for CommunityChill
Future versions of CommunityChill could include:
- Discord webhook alerts for volunteers
- Alert cooldowns and recovery notifications
- Offline alert queues
- Secure remote access outside the local network
- Camera-based food stock estimation
- A latest-fridge-image view
- Power monitoring for an off-grid installation
- Lower-power hardware for permanent deployment
Our immediate next step is to test CommunityChill inside a real refrigerator using the production 40°F threshold and gather feedback from Gainesville Community Fridge volunteers.
Log in or sign up for Devpost to join the conversation.