A fictional regional distributor of meat, poultry, seafood, and frozen processed foods based in Madurai, Tamil Nadu. They supply 140+ hotels, supermarkets, and restaurants across southern Tamil Nadu from a 1,200 m² warehouse operating 24 hours a day.
At any given time, approximately ₹42 lakhs of perishable stock sits across 4 refrigerated rooms (2°C–8°C) and 2 deep freezers (−18°C to −22°C). Every degree of temperature exceedance is a direct financial risk. The margin between "safe" and "condemned" is measured in minutes, not hours.
Cold chain operations are unforgiving. A refrigeration failure at 2 AM that goes undetected until the morning inspection is not a minor inconvenience — it is stock destruction. Priya Foods had built their operations around three assumptions: that someone would notice a failure quickly, that two temperature logs a day was enough for compliance, and that staff awareness alone would keep doors properly sealed.
"We knew something had gone wrong when the morning shift arrived. By then the damage was already done. There was no way to know sooner."
The real issue was that the operation had no continuous signal. Temperature data existed in a notebook twice a day. A power failure was only detectable if someone happened to notice the lights go out. The cold chain — the single most critical thing keeping the business running — was effectively unmonitored between manual checks.
Total annual loss before ColdGuard was estimated at ₹21+ lakhs across power events, door incidents, compliance admin, and penalty risk — modelled from degradation curves at Tamil Nadu ambient conditions (~30°C outside), with ₹10,000–₹12,000 loss per minute in a full deep-freeze failure.
ColdGuard is an IoT monitoring and alerting system built in partnership with NexSense IoT Solutions, a Chennai-based industrial IoT integrator. It monitors temperature, humidity, door seal status, and three-phase power on every unit, every 60 seconds, and gets an alert to the on-duty technician's phone within 90 seconds of a sustained breach.
The thinking behind it was simple: close every gap in the continuous signal. If the data is there, the problem gets caught before it becomes a loss event. The alert, the response, and the FSSAI log are all just downstream of having reliable data flowing without interruption.
Not familiarity or preference. Each component earns its place against a specific requirement.
| Layer | Technology | Why this choice |
|---|---|---|
| Sensor node | ESP32 + Sensirion SHT40 | Industrial-grade MCU with built-in Wi-Fi. ±0.2°C accuracy exceeds FSSAI requirement. ~₹500/unit, runs for years. Honeywell 5816WMWH magnetic contact on each door. |
| Power monitoring | PZEM-004T v3.0 | Monitors all three phases. Detects voltage drop before the compressor trips, giving the ATS context and flagging power events for the alert engine. |
| Edge gateway | Raspberry Pi 4B + Mosquitto | Runs locally on a UPS. If internet goes down, gateway keeps logging locally and buffers 24 hours of data. Alerts fire locally too — system doesn't depend on cloud to protect stock. |
| Sensor → cloud | MQTT → AWS IoT Core | ISO-standard IoT protocol. Lightweight, low-latency, handles hundreds of concurrent sensor streams. AWS IoT Core manages device certificates and scales without infrastructure management. |
| Database | TimescaleDB | Sensor data is time-series by nature. Auto-partitions by time chunk, so a query for "last 24 hours on Unit 05" scans one chunk instead of millions of rows. ~90% compression on older data. |
| Alert engine | Python on AWS Lambda | Stateless, runs on every incoming reading. Implements the 10-minute rule. Calls Firebase Cloud Messaging for push notifications. |
| App + dashboard | React Native + React.js | Single codebase for iOS and Android. Technician app focused on alert response. Web dashboard for operations manager: live heatmap, trend charts, monthly compliance view. |
One reading per minute across 7 units: 10,080 rows a day, 3.7 million a year. TimescaleDB handles this through automatic time-based partitioning — the application just writes and reads ordinary SQL.
-- Core sensor readings table, converted to a TimescaleDB hypertable
CREATE TABLE sensor_readings (
time TIMESTAMPTZ NOT NULL,
unit_code VARCHAR(10) NOT NULL,
temp_c NUMERIC(5,2) NOT NULL,
humidity_pct NUMERIC(5,2),
door_open BOOLEAN DEFAULT false,
power_on BOOLEAN DEFAULT true,
voltage_v NUMERIC(6,2),
PRIMARY KEY (time, unit_code)
);
-- Partition by 7-day time chunks
SELECT create_hypertable('sensor_readings', 'time',
chunk_time_interval => INTERVAL '7 days');
-- Compress chunks older than 30 days (~90% storage reduction)
SELECT add_compression_policy('sensor_readings', INTERVAL '30 days');
-- FSSAI daily compliance — was each unit in range all day?
SELECT unit_code,
MIN(temp_c) AS min_temp,
MAX(temp_c) AS max_temp,
ROUND(100.0 * COUNT(*) FILTER (
WHERE temp_c BETWEEN su.temp_min_c AND su.temp_max_c
) / COUNT(*), 1) AS compliance_pct
FROM sensor_readings sr
JOIN storage_units su USING (unit_code)
WHERE DATE(time) = CURRENT_DATE - 1
GROUP BY unit_code, su.temp_min_c, su.temp_max_c;Across prevented stock loss, door incidents caught early, power events neutralised by ATS, and compliance admin time recovered.
Total system cost including hardware, installation, and first year of cloud infrastructure: ₹5.6 lakhs. Recovered in under one quarter.
From 2 manual readings per unit to 1,440 automated readings. Every minute of every day is now in the compliance record.
ATS switches grid to generator before most compressors register a voltage drop. The 8–15 minute manual window is eliminated entirely.
The compliance officer's 4 hours per week on log management, data entry, and FSSAI report preparation is fully automated.
From breach detection to technician acknowledgement. Previously unmeasurable — there was no alert system at all.