A forty-site retail portfolio, connected thermostats at every location, one dashboard, everything green. Thursday afternoon, three stores lose cooling within four hours of each other. Somebody pulls the previous two weeks of reporting looking for the warning nobody caught, and there isn't one. Runtime stayed inside normal bounds. Setpoint held. The data was clean right up to the moment three compressors weren't.

That result confuses people, so it helps to be blunt about where the thermostat sits in the chain. It measures the outcome of the equipment doing its job, after the control loop has already absorbed whatever degradation was happening by running the machine longer. Compensation hides the problem. By the time a number crosses a threshold, the failure has occurred.

The gap costs money twice. Once in downtime, then again on the return trip, because an alert reading "cooling failure" tells a dispatcher nothing about what to load in the van. Telemetry narrows the diagnosis, and it does that well, but HVAC system repair stays physical work performed by somebody standing on a roof with a meter, and the value of your data layer comes down to one question: did the tech arrive with the right part the first time?

What follows is what the thermostat layer genuinely measures, four failure modes it cannot detect by design, where the week of lag actually comes from, and the sensor set that closes it.

What the Thermostat Layer Actually Measures

The list runs shorter than the dashboard implies.

Space temperature. Humidity on some models. Deviation from setpoint. Runtime and cycle count over a period, plus time-to-setpoint. Outdoor temperature, which on most consumer and light-commercial units gets pulled from a weather API by postal code rather than read off a sensor anywhere near the building. And the state of the Y, W, and G calls at the terminal block, meaning the command that went out to the equipment.

Every item on that list belongs to the control loop. The thermostat knows what it asked for and knows what happened in the room. Sitting between those two points is a compressor, a condenser coil, a metering device, a blower and roughly two dozen electrical components, and about the condition of any of them the device holds no information whatsoever.

The Failure Modes It Cannot See

Four of the most common causes of emergency service calls leave no trace in thermostat data until the day they take the system down.

Run capacitor degradation

Capacitance drifts downward over years and shows up in the startup current signature, nowhere else. As long as starting torque stays sufficient, cycle times look identical to last summer. A clamp meter catches this on the first reading. A dashboard built on runtime never catches it at all.

Coil fouling and airflow restriction

A dirty condenser and a loaded filter both register as changes in pressure differential and in the temperature split between supply and return. Thermostat data will eventually show runtime climbing, though only once capacity loss passes somewhere around ten to fifteen percent, and at that point the analytics layer usually attributes the increase to warmer weather. Which it partly is.

Refrigerant loss

Diagnosis here depends on superheat and subcooling, calculated from pressures and line temperatures. A system down twenty percent on charge still reaches setpoint comfortably in mild conditions. The first deviation appears on the first hot day of the season, when there's no margin left to spend, and by then the leak has been running for months and the compressor has been operating with poor motor cooling that whole time.

Contactor wear

No electrical signature exists at all. Contacts pit through several thousand cycles a season and then either weld closed or stop making contact. Both states arrive instantly. Nothing in runtime history predicts either one, and no amount of model tuning changes that.

Where the Week of Lag Comes From

The delay decomposes cleanly, which makes it easier to argue about with a vendor. Take a single capacitor failure and lay it out day by day.

• Day 0. Capacitance falls below tolerance. A clamp meter reads the deviation immediately. Runtime doesn't move.
• Days 1 through 20. The control loop compensates by extending cycles. Setpoint gets reached, a bit later each week. Dashboard stays green.
• Day 21. Outdoor temperature runs five degrees above seasonal norm. Compensation runs out. The space misses setpoint by late afternoon.
• Day 21, evening. The thermostat logs its first deviation and fires an alert, if anyone configured one. The compressor has by then spent three weeks starting under elevated current.

The thermostat behaves as a lagging indicator on a self-correcting loop, which is exactly what it was designed to be. One consequence deserves stating plainly: predictive analytics built on runtime data forecast weather more accurately than they forecast equipment failure, because weather is most of the signal in that dataset.

Where Runtime Analytics Still Earn Their Keep

None of this makes the thermostat layer worthless. It solves a different class of problem, and portfolio operators get real money out of it.

Cross-site comparison. Twenty locations with matched equipment and matched schedules produce a usable baseline. A store running thirty percent longer than its cohort goes on the inspection list without a single additional sensor installed anywhere.

Schedule waste. Cooling an empty sales floor overnight, fighting setpoints between zones, manual overrides left in place since last August. Fastest payback in the entire stack, and it needs nothing beyond what's already installed.

Filter changes on actual hours. Runtime-based intervals beat calendar intervals, especially across sites with wildly different occupancy.

Post-repair verification. Did cycle time return to its previous profile after the contractor left. Simple question, and thermostat data answers it well.

The boundary worth writing down somewhere: the layer compares assets against each other and against their own history. It does not diagnose an individual machine.

What a Minimal Monitoring Stack Adds

Closing the four blind spots takes less hardware than most platform vendors propose during a sales cycle.

Current transformers on the compressor and fan circuits. One line item that covers capacitor degradation, bearing wear, locked rotor and motor faults. Highest return per dollar in the whole build, and installation runs under an hour per unit.

Pressure transducers on liquid and suction lines. These give you the differential that exposes fouling and restriction while there's still time to schedule cleaning rather than dispatch an emergency.

Line thermocouples for superheat and subcooling calculation, which is how refrigerant loss becomes visible months before a hot afternoon exposes it.

A float switch in the condensate pan. Cheapest sensor on the list and the one that prevents water from coming through a ceiling onto merchandise.

Vibration sensing on the compressor sits in optional territory, justified on individual critical assets rather than fleetwide.

On cost: instrumenting one rooftop unit lands somewhere near the price of a single after-hours emergency call with the associated surcharge. Which sites get done first should follow consequence of downtime rather than square footage. A server closet, a pharmacy cold room, and any location with no redundancy all outrank a large office with a spare unit.

Data That Ends in a Work Order

The analytics layer generates value at exactly one moment, when an alert becomes a work order with the correct part already in the truck.

A useful alert carries the asset model and serial, the measured value against spec (not "anomaly detected" but "45 µF nominal, reading 32.4"), a part number the parts desk can act on, the last three service events for that unit, and site access conditions with the permitted work window.

For anyone integrating building systems into a ticketing platform, that field set matters more than detection accuracy. An alert landing in a ticket with a part number cuts repeat visits harder than any improvement to the underlying model, because the bottleneck was never detection. It sits between the analytics layer and dispatch, and it's a data plumbing problem rather than a machine learning one.

A Deployment Order That Survives the First Season

Monitoring programs die of false positives, usually before Labor Day of year one.

Phase one covers the electrical side on the ten or fifteen percent of sites with the highest cost of downtime. Phase two adds the refrigerant circuit at those same locations, once current data has accumulated enough history to mean something. Phase three brings analytics on top, and not one day earlier.

Baseline requirement: one full cooling season. Thresholds shipped by a vendor and derived from averaged fleet data will generate noise on your specific equipment, and a facilities team that gets paged six times about nothing stops reading the alerts entirely. Retraining after equipment replacement belongs in the runbook too, since a new unit reads as an anomaly against its predecessor's profile for months if nobody resets the baseline.

The distance between a data layer and a repair layer doesn't close with another platform. It closes when the alert carries a part number.

Field documentation on component failure and diagnostics tends to be thinner than platform documentation, and it's worth reading before anyone writes alert thresholds. Region Home Services, a Bensalem, Pennsylvania contractor that has worked on commercial and residential systems since 1974, keeps material of that kind at regionserviceco.com.