The idea
A battery-powered probe you tape inside a walk-in cooler, a reach-in fridge, or a prep table, and a small gateway that sits in the back office. Each probe reads temperature every minute, buffers locally, and radios to the gateway, which signs the readings and pushes them to a server. The kitchen gets a phone alert when something drifts. The owner gets a PDF that shows, hour by hour, that every unit stayed in range for the last six months.
Why build this
Small food businesses are required to keep temperature records, and almost all of them do it with a clipboard on the wall — filled in twice a day, often from memory, often on the way out the door. Nobody trusts the log, including the person who wrote it. A real failure looks the same on paper as a normal day, so a compressor that quits on a Saturday night gets discovered by smell on Monday, and thousands in inventory goes in the bin with no way to make an insurance claim stick.
The commercial answer to this is a service contract from a refrigeration monitoring vendor, priced for a supermarket chain, with hardware you don't own and data you can't export. Meanwhile the components got cheap: a Dallas DS18B20 or a Sensirion SHT45 on an ESP32-C6 runs for a year on a couple of AA cells, LoRa or Zigbee gets you through the steel walls that kill Wi-Fi, and the whole gateway is a Raspberry Pi. The gap is not the sensing. It's the record — a log with signed timestamps, gap detection, and a defensible export.
Stack sketch
- Probe: ESP32-C6 or nRF52840, DS18B20 stainless probe on a short lead, Zigbee or LoRa (SX1262) uplink, deep sleep between reads, CR123A or 2×AA
- Gateway: Raspberry Pi Zero 2 W, Zigbee2MQTT or ChirpStack, Mosquitto, local SQLite ring buffer so a dead internet link doesn't lose a week
- Backend: Go service, TimescaleDB for the series, Ed25519 signature per batch with the probe's key burned in at provisioning
- Alerting: Twilio for SMS, ntfy for push, escalation ladder so a 3 a.m. alert reaches a second phone
- Reports: server-side PDF via Typst, one page per unit per month, gaps rendered as gaps and not smoothed over
Scope for v1
- In: up to eight probes per gateway, one-minute sampling, configurable high/low thresholds with a dwell time so a door opening doesn't page anyone, SMS and push alerts, a live web dashboard, monthly PDF export, battery level per probe
- In: gap detection — the report says "no data 14:02–14:39" rather than interpolating, because a quiet interval is exactly what an inspector asks about
- Out: humidity, door sensors, multi-site rollups, HACCP checklist workflows, integration with POS or inventory
- Out: any control. V1 reads and reports; it never switches a compressor
Where it could go
The obvious next layer is prediction rather than alarms. A compressor rarely fails without warning — duty cycle creeps up, recovery after each door opening takes longer, the floor of the sawtooth drifts by half a degree a week. With a year of minute-resolution data per unit you can fit a simple regression per compressor and tell an owner that the walk-in is going to need service in about three weeks, which is worth far more than a 3 a.m. text.
The second path is the paperwork around the paperwork. Once you hold a trustworthy series, you can generate the whole compliance pack: delivery-temperature records if you add a probe to the van, cook-and-chill logs if you add a handheld, and a signed export an insurer or an inspector can verify independently. The third, slower path is selling to the people who visit many kitchens — pest control routes, refrigeration contractors, franchise auditors — who would happily bundle probes into their own service call.
Watch out for
Certification is the trap: the moment you market this as meeting a specific food-safety regulation, you inherit calibration traceability, accuracy claims, and in some jurisdictions device approval. Ship it as an accurate, exportable logger with a documented calibration procedure, and let the customer's own auditor decide what it satisfies.