A single cold room is a solved problem. Put a sensor in it, set a threshold, send an alert. The reason companies still struggle with refrigeration monitoring is that almost nobody has one cold room. They have ninety units spread across sites they do not own, on networks they do not control, maintained by contractors who do not work for them.
That is a different problem, and most of it has nothing to do with measuring temperature.
What actually goes wrong at fleet scale
The failures that cost money are rarely a compressor dying overnight. They are slower and quieter:
A door left open. The unit holds setpoint, works harder, and nothing looks wrong until the electricity bill or the compressor does. Temperature alone will not catch this reliably, because a healthy unit compensates.
A slow drift. Setpoint is correct, the unit is running, and the product is sitting two degrees warmer than it should because a probe moved or a fan stalled. Nobody notices for weeks.
A power event. The unit loses power at 02:00 and comes back at 04:00. By the time anyone opens the site, the temperature reads normal. The record of those two hours either exists or it does not.
A defrost cycle mistaken for a fault. Every unit warms during defrost. A monitoring system that does not know that generates alerts nobody reads, and an operator who ignores alerts is worse off than one who has none.
The pattern across all four is the same: the useful signal is an event with a duration, not a number at an instant.
What to specify
Measure the load, not the air. Return air responds first and recovers first, so it consistently under-reports how long product actually spent warm. A probe in a glycol bottle or placed with the load tracks thermal mass instead. When a customer disputes whether a shipment was compromised, this is the decision that determines whether you can answer.
Capture door and power state, not just temperature. Those two channels turn an unexplained warm period into an explained one. Without them every excursion looks the same and every investigation is a site visit.
Buffer on the device. Outages and failures correlate: the event that takes out the unit takes out the site network with it. A controller that only streams live data loses exactly the window that matters. Ours store readings through the outage and backfill on reconnect, so the timeline reconstructs.
Report faults as faults. A disconnected probe should produce a fault code, not a plausible looking number that averages quietly into a daily report. This sounds obvious and is the single most common defect we see in monitoring hardware, because a fabricated reading is invisible until an audit.
Decide connectivity by who owns the site. On your own site, WiFi is fine. Across an estate you do not control, WiFi is a support cost that scales with the fleet, and every credential change is a truck roll. Cellular makes the unit independent of the site, which is why it is the default on Genesis. Where a site network really is stable, Genesis Lite has WiFi and Bluetooth built in with 4G LTE available.
The part that is not about sensors
At fleet scale the hard requirement is access. Your service partner should see the units they maintain. Your customer should see theirs and nothing else. Your own team should see everything. None of that is a reporting feature, and it cannot be retrofitted onto a system that assumed a single operator.
This is a tenancy question, and it is the reason we build it at the platform layer rather than as a filter in a dashboard. Accounts nest, roles carry a ceiling, and a device belongs to one account and can be shared with another so the asset owner and the service company both see it without sharing a login. The multi-tenant platform page covers the mechanics.
The second requirement is the record. Not a live dashboard, which nobody watches, but an exportable history of excursions with their durations and causes, per unit, over a period somebody else chooses after the fact. That is what a customer asks for during a dispute and what an auditor asks for without warning.
Where OmnIoT fits
We ship a controller with four modular ports where each port takes any supported protocol, so the same unit handles the temperature probes, the door contact and the power sense without a different SKU per configuration. The cloud is included and the REST API covers what the dashboard covers, so a fleet operator who wants the data in their own system is not fighting the platform to get it.
If you are specifying a refrigeration monitoring deployment, the useful conversation is about the estate rather than the sensor: how many units, who owns the sites, who needs to see what, and what the record has to prove. Talk to us and we will tell you how that maps onto accounts, ports and alerting, and where it does not.