How to Build a Cold Chain Temperature Monitor

Last year, a mid-sized food distributor in the Midwest lost $38,000 in a single weekend. Not to theft, not to a truck accident, but to a walk-in cooler that drifted four degrees above safe range for 16 hours while nobody was watching. The product looked fine Monday morning. The temperature log told a different story.

Here’s the part that stings: a $35 device on a breadboard could have caught it in the first hour.

If you’re a supply chain or logistics manager who’s priced out commercial cold chain monitoring platforms, you already know the gap. You suspect you’re losing product, or at least losing sleep, to temperature excursions you can’t see. But the vendors want $10K+ for a pilot, and the sales cycle takes months. You can’t justify that spend on a hunch.

Don’t. Build a proof of concept for under $50 and a weekend of effort. Generate real temperature data from your actual environment. Then walk into that budget meeting with evidence instead of anxiety.

This isn’t a production deployment guide. It’s a proof-of-concept build that produces real data you can show your VP of Operations. Let’s get into it.

What You’re Actually Building

The end result is a small device, about the size of a deck of cards, that reads temperature at regular intervals and either pushes that data to a cloud dashboard you can check from your phone or logs it to a file you can open in Excel.

The architecture is deliberately simple:

Temperature Sensor → Microcontroller → Data Output (Cloud or SD Card)

The sensor reads the temperature. The microcontroller (a small, inexpensive computer) processes the reading and timestamps it. The data goes somewhere you can analyze it, either over WiFi to a free cloud service or onto a local storage card.

This setup does not replace a calibrated, regulatory-compliant monitoring system. It doesn’t generate audit-ready reports or send SMS alerts to your quality team at 2 a.m. What it does is prove, with real numbers from your own coolers, trucks, or storage rooms, whether IoT-based cold chain monitoring is worth investing in. That’s the only job it needs to do right now.

The Parts List: Exactly What to Buy

I’m not giving you ten options per component. Decision fatigue kills projects like this. Here’s the one recommended setup:

Total: $25–$45, depending on options.

Buy from Amazon for speed, Adafruit for better documentation, or AliExpress if you’re patient and want to save a few dollars. No affiliate links here; just search the part names.

Why the ESP32? WiFi is built in, it has plenty of processing power for this job, the Arduino community support is massive, and it costs less than a decent sandwich. If you’ve got a Raspberry Pi collecting dust in a drawer, that works too, but the ESP32 is cheaper and simpler for this specific project.

Why the DS18B20? The waterproof probe version is critical. You’re putting this in coolers, refrigerators, maybe next to frozen product. A bare chip on a breakout board won’t survive the condensation, let alone give you realistic readings. The DS18B20 is accurate to ±0.5°C out of the box, which is more than adequate for a proof of concept.

Step-by-Step Build Guide

Wiring the Hardware (15 Minutes)

No soldering. Everything goes on the breadboard.

The DS18B20 waterproof probe has three wires, typically red (power), black (ground), and yellow or white (data). Connect them to the ESP32 as follows:

• Red wire → 3.3V pin on the ESP32
• Black wire → GND pin on the ESP32
• Yellow/white wire (data) → GPIO 4 on the ESP32

The one step people skip and then spend two hours debugging: add the pull-up resistor. A pull-up resistor is a small component that keeps the data signal stable. Without it, you’ll get garbage readings or no readings at all. Place the 4.7kΩ resistor between the data wire (GPIO 4) and the power wire (3.3V) on the breadboard.

That’s it for hardware. Three wires and one resistor. If you’ve never used a breadboard before, watch a two-minute YouTube tutorial on how breadboard rows are connected. It’ll save you headaches.

[See wiring diagram: ESP32 + DS18B20 breadboard layout]

Loading the Software (30–45 Minutes)

Step 1: Set up the Arduino IDE. Download the Arduino IDE (free, runs on Windows/Mac/Linux). Then add ESP32 board support: go to File → Preferences, paste the Espressif board manager URL into “Additional Boards Manager URLs,” then install the ESP32 platform via Tools → Board Manager. There are dozens of guides for this exact process; it takes about five minutes.

Step 2: Install two libraries. In the Arduino IDE, go to Sketch → Include Library → Manage Libraries. Search for and install:

• OneWire (by Jim Studt and others)
• DallasTemperature (by Miles Burton)

These libraries handle all the low-level communication with the DS18B20. You don’t need to understand the protocol.

Step 3: Choose your data output path.

Path A, Cloud Dashboard (Recommended for showing stakeholders): Use ThingSpeak, a free IoT data platform from MathWorks. Create a free account, set up a channel with one field (temperature), and grab your API key. Your code will read the sensor, connect to WiFi, and push a reading to ThingSpeak via a simple HTTP request every 60 seconds. ThingSpeak gives you automatic charts, which means instant visual proof.

Path B, Local SD Card (Best for environments without WiFi): Wire up the SD card module to the ESP32’s SPI pins, and write each timestamped reading as a CSV row. You’ll pull the card later and open the file in Excel or Google Sheets.

The overall code logic, in plain English:

Connect to WiFi (Path A only)
Initialize temperature sensor
Every 60 seconds:
    Read temperature from sensor
    Get timestamp
    Send to ThingSpeak (Path A) OR write to SD card (Path B)
    Print to serial monitor for debugging

Rather than dumping 80 lines of code into this article, I’ll point you to tested, annotated example sketches. Look for “ESP32 DS18B20 ThingSpeak” tutorials on the Arduino project hub or RandomNerdTutorials. The code is essentially a mashup of the DallasTemperature library example and the ThingSpeak ESP32 example. Combine them and you’re done.

Set your logging interval to 60 seconds for the pilot. That’s 1,440 data points per day, plenty of resolution to catch excursions without overwhelming a free-tier cloud account.

Testing: The Refrigerator Trial (2–4 Hours of Waiting)

Plug in the assembled device. Open the Arduino IDE’s Serial Monitor to confirm readings are printing. You should see temperature values updating every 60 seconds.

Place the waterproof sensor probe inside your refrigerator or a cooler packed with ice. Leave the ESP32 outside (or inside, if you’re using the SD card path and don’t need WiFi).

Let it run for 2–4 hours. During that time, open the refrigerator door once or twice to simulate real-world disruption.

When you pull the data, verify three things:

1. Readings are in the expected range. A typical refrigerator runs 2–4°C (35–40°F).
2. No gaps. You should see a reading every 60 seconds without interruption.
3. Sanity check. Compare a reading to a kitchen thermometer placed next to the probe. They should be within 1°C of each other.

If all three check out, your DIY temperature monitor is working. You have real cold chain data.

Turning Raw Data into a Business Case

A CSV file or a ThingSpeak chart isn’t a business case yet. Here’s how to bridge that gap.

Pull your data into Google Sheets or Excel. Create a time-series line chart of temperature over your test period. What you’re looking for:

Baseline stability. How consistent is the temperature when the cooler stays closed? Wide fluctuations suggest equipment issues worth investigating.

Recovery time. When you opened the door, how long did it take to return to the safe range? This mimics loading dock scenarios, delivery handoffs, and shift changes.

Drift. Does the average temperature creep upward over time? That’s a red flag for compressor performance or insulation failure.

Then frame this as a business artifact. Label the chart. Annotate the door-open events. Add a horizontal line at your critical temperature threshold (e.g., 5°C for perishable food, 8°C for many pharmaceuticals, 2–8°C for vaccines per WHO guidelines).

This chart is what you show your VP of Operations. Not “we should buy a monitoring system,” but “here’s four hours of data from our own cooler, and here’s what it tells us about our exposure.”

That’s the difference between a request and a recommendation backed by evidence.

What This Proof of Concept Doesn’t Do

Be upfront with stakeholders about what this build lacks. It’s actually a strength, because it defines exactly what a commercial solution needs to provide.

No real-time alerts. You can add email triggers through ThingSpeak or IFTTT, but it’s fragile. A production system needs reliable alerting with escalation paths and acknowledgment workflows.

No regulatory compliance. This sensor isn’t calibrated to NIST standards. The data isn’t stored in a system that meets FDA 21 CFR Part 11 requirements for electronic records. For pharmaceutical or USDA-regulated applications, compliance isn’t optional, and it’s where commercial platforms earn their price tag.

No battery optimization or ruggedization. A USB power bank will die in 8–12 hours. A production cold chain sensor needs to run for months on a coin cell in subzero temperatures inside a sealed enclosure.

Single-point monitoring. You’re watching one location. Real cold chain visibility means dozens or hundreds of sensors across trucks, warehouses, and retail locations with centralized management.

These gaps aren’t failures. They’re your requirements list for the commercial RFP you’re now qualified to write, because you understand what the technology does and what your environment actually needs.

From Proof of Concept to Purchase Order

You now have something most people requesting cold chain monitoring budgets don’t: evidence. Real temperature data from your own facility, captured by a system you built and understand.

The next step isn’t another DIY iteration. It’s using this data to do three things:

1. Quantify the risk. If your pilot caught a temperature excursion in four hours of monitoring, what’s happening in the other 8,756 hours per year nobody’s watching?
2. Define requirements. Your pilot taught you what matters: alert speed, sensor range, connectivity constraints, compliance needs. Write those down.
3. Justify the investment. Show the data, show the gaps, show the cost of one preventable loss event versus the cost of a commercial monitoring platform.

You spent $40 and a weekend. You’ve proven the concept works. Go prove the budget.

Hubble Network connects Bluetooth sensors to satellite — enabling cold chain monitoring anywhere, with no gateways or cellular infrastructure to manage. See how it works →