Cold-Chain Temperature Monitoring and Excursion-Alert System for PHC Vaccine Storage

Cold-Chain Temperature Monitoring is an end-to-end IoT system that keeps watch over vaccine storage where a few warm hours silently destroy doses. In a typical primary health centre (PHC), vaccines sit in an ice-lined refrigerator (ILR) that must stay between +2 °C and +8 °C; a broken compressor or an overnight power cut can push it out of range, and the standard twice-a-day manual thermometer reading discovers the damage only after the doses are compromised.

Our system places ESP32 nodes with waterproof DS18B20 probes inside the ILR and in a vaccine-carrier demonstration box. Every 30 seconds each node publishes a reading over MQTT to an Eclipse Mosquitto broker; nodes buffer readings in flash when the network is down and backfill with their original timestamps on reconnect, so no gap is silently papered over. A Python ingestion service subscribes to the broker and writes every reading into MySQL. An alert engine applies the WHO range rules — instantaneous breach, breach persisting beyond a grace window, plus a rolling z-score check that flags slow sensor drift a fixed threshold misses — and drives a buzzer on the node, a banner on the dashboard and a webhook stub for an SMS gateway. A Flask + Chart.js dashboard shows live temperatures, device heartbeats and an exportable excursion log for the district immunisation officer.

The build costs under ₹3,000 per node and reuses skills the VTU CS syllabus already teaches, making it a strong, demonstrable major project.

Vaccines stored at a PHC must remain between +2 °C and +8 °C, but compliance is checked only twice a day by reading a thermometer and writing it in a register. An excursion caused by a failed compressor, an evening power cut or a door left ajar is therefore discovered late — often after the doses have lost potency — and there is no record to show how long the excursion lasted or which other doses were affected. Health workers are blamed for failures they cannot see, and the district office has no data to prioritise which ILRs need repair or replacement.

There is a need for a low-cost, continuously logging temperature-monitoring and alerting system — sensor nodes on an MQTT backbone, a durable database store, rule-based and statistical excursion detection, and a dashboard with an auditable excursion log — that a PHC can afford, that keeps working through network outages by buffering and backfilling readings, and that gives both the PHC staff and the district immunisation officer timely, evidenced alerts instead of a next-morning surprise.

Abstract

Vaccines are biological products that lose potency once warmed. The national immunisation programme keeps them in a strict +2 °C to +8 °C cold chain from manufacturer to arm, yet the last mile — the PHC ILR and the vaccine carrier — is monitored mostly by hand: a health worker reads a thermometer twice a day and writes it in a register. Excursions that happen between readings, or overnight, are simply not recorded. This project builds a low-cost MQTT-based monitoring and alerting system that closes that gap with continuous, timestamped, auditable data.

Introduction

The WHO's immunisation supply-chain guidance treats temperature monitoring as core cold-chain infrastructure, and India's Universal Immunisation Programme runs one of the largest such chains in the world. The failure mode is mundane: compressors fail, power fails, doors are left open. The technology to catch these failures early is now cheap — an ESP32, a DS18B20 probe and a Wi-Fi connection cost less than a thermal box of Hepatitis B vaccine.

Existing System

• Manual twice-daily thermometer readings entered in a register; no data between readings, no alarms, no history beyond the register itself.
• Some districts use data-loggers that must be physically carried to a PC to download; alarms, if any, are delayed by days.
• Commercial IoT cold-chain monitors (₹15,000–₹40,000 per point) exist but are rarely budgeted at PHC level.
• Limitations: late detection, no accountability trail, no way to correlate an excursion with power supply or door-opening events.

Proposed System

• Nodes: ESP32 + waterproof DS18B20, publishing JSON readings every 30 s over MQTT (QoS 1) with unique device IDs; a last-will message marks a node offline if it dies.
• Store-and-forward: when the broker is unreachable, up to 48 hours of readings are buffered in flash and backfilled with original timestamps on reconnect.
• Broker and store: Eclipse Mosquitto with password auth; a Python ingestion service writes to MySQL tables (devices, readings, excursions, acknowledgements) with indexed time-series queries.
• Alert engine: rule layer (below 2 °C, above 8 °C, breach persisting beyond 5 minutes) plus a rolling 24 h mean/standard-deviation z-score that catches slow drift such as a failing door gasket; alerts drive the node buzzer, dashboard banner and a webhook stub for SMS.
• Dashboard: Flask + Chart.js live view, excursion lifecycle (open → acknowledged → closed) with remarks, device heartbeat page and CSV export.

Feasibility Study

• Technical: all components are open-source and documented; the ML component is deliberately simple (rolling statistics) so it is defensible; a demonstration rig uses a mini-fridge and an insulated box, no real vaccines, hence no licence or biological-safety issues.
• Economic: node BOM ≈ ₹2,400–₹3,000; broker and services run on any existing lab PC; zero licence cost.
• Operational: firmware is pre-configured per device; a PHC staff member needs only to read the dashboard and hear the buzzer; data stays within the facility's own network.

In scope

• Two to three sensor nodes covering one ILR and one demonstration vaccine-carrier box on a single Wi-Fi network.
• Temperature only (DS18B20 ±0.5 °C accuracy class); no humidity, door or power sensors in v1.
• MQTT transport (QoS 1, retained device-status messages, last-will offline detection), MySQL persistence, rule + rolling-statistics alerting, Flask dashboard, CSV export.
• Simulated-cold-chain testing with a mini-fridge and insulated box; no biological material, no medical certification.

Out of scope

• SMS/WhatsApp delivery through a real paid gateway (a webhook stub is provided and documented).
• Multi-PHC cloud deployment, GPS tracking of transport vehicles, and LoRaWAN for carrier-in-transit monitoring (future scope).
• Automatic control of the refrigerator; the system monitors and alerts, it does not actuate.
• Regulatory compliance documentation (WHO PQS device listing) — we follow the temperature guidance, not the procurement process.

The project follows an iterative-incremental SDLC with four working increments, each ending in a demonstrable, testable slice — appropriate because the alert rules and dashboard can only be designed sensibly once real node data flows.

Testing approach: unit tests for the alert rules (synthetic series); integration tests that publish fake MQTT readings and assert DB rows; scenario tests — warm-water bath for a fast breach, door-open test for a slow drift, Wi-Fi/Broker cut for store-and-forward; a 7-day soak test on the mini-fridge to quantify packet loss and timestamp continuity; every test recorded in a matrix (ID, input, expected, actual, status).

The system is a four-tier publish–subscribe architecture with durable storage and a rules engine:

1. Field tier — ESP32 nodes read DS18B20 probes over the 1-Wire bus every 30 s, wrap each reading in JSON (device_id, ts, temp_c, seq) and publish to topic coldchain/<device_id>/readings with QoS 1; a last-will message on coldchain/<device_id>/status marks a crashed node offline.
2. Broker tier — Eclipse Mosquitto with password-file authentication and a persistent store; it decouples nodes from the backend so the server can restart without touching firmware.
3. Service tier — a Python ingestion service subscribes to coldchain/#, validates each payload against the schema, de-duplicates by sequence number, and writes to MySQL. The same process hosts the alert engine: WHO threshold rules with a 5-minute persistence window, plus a rolling 24 h mean/σ z-score that flags slow drift; alerts update the excursions table and fan out to buzzer (MQTT command topic), dashboard banner and webhook stub.
4. Presentation tier — Flask serves the dashboard; Chart.js renders live series from a lightweight JSON API; a heartbeat page shows last-seen per device; CSV export serves the excursion log.

flowchart LR
  DS["DS18B20 probes (1-Wire)"] --> N["ESP32 node<br/>30 s cycle, flash buffer"]
  N -->|"MQTT QoS 1<br/>coldchain/id/readings"| B["Eclipse Mosquitto broker"]
  N -.->|"last-will status"| B
  B --> ING["Python ingestion service"]
  ING --> DB[("MySQL: devices, readings,<br/>excursions, acknowledgements")]
  ING --> AE["Alert engine: WHO rules +<br/>rolling 24 h z-score"]
  AE -->|"command topic"| BUZ["Node buzzer"]
  AE --> WEB["Webhook stub (SMS gateway)"]
  DB --> API["Flask JSON API"]
  API --> UI["Chart.js dashboard +<br/>excursion log + CSV export"]

flowchart TD
  OK["Normal: 2-8 °C"] -->|"reading outside range"| PEND["Breach pending"]
  PEND -->|"back inside within 5 min"| OK
  PEND -->|"breach persists > 5 min"| OPEN["Excursion OPEN + buzzer + banner"]
  OPEN -->|"staff acknowledges with remark"| ACK["Acknowledged"]
  ACK -->|"temperature back in range 10 min"| CLOSED["Closed: duration, min/max logged"]

Key design decisions: QoS 1 gives at-least-once delivery so the sequence-number de-duplication is what guarantees correctness; buffer-and-backfill preserves the true reading timestamps instead of shifting them to reconnect time; and both rule and statistical layers are kept because fast breaches (power cut) and slow breaches (worn gasket) have different signatures.

• SMS/WhatsApp delivery through a real gateway (the webhook stub already defines the payload contract).
• LoRaWAN carrier tag — a low-power node for vaccine carriers in transit, backhauling through a campus gateway.
• Door and power sensors (reed switch + mains monitor) so excursions can be attributed to causes automatically.
• Predictive alerting — replace the rolling z-score with a forecasting model trained on soak-test data to warn before the range is crossed.
• Multi-PHC cloud deployment with organisation logins, district-level fleet view and automatic monthly compliance reports.
• MQTT 5 features — shared subscriptions for hot-standby ingestion and message expiry for stale buffered data.