A bad thermostat doesn't just make a room uncomfortable—it reveals the fundamental mathematics of control. This episode uses the humble thermostat as a window into feedback loops, sampling theory, and the art of pulling levers based on measurements. The naive "bang-bang" controller, which simply turns cooling on when the temperature is above a set point and off when below, creates rapid cycling and destroys compressors. The universal fix—hysteresis—adds a dead band to prevent that, but still produces visible oscillation because it ignores thermal inertia. A room's thermal mass introduces delay into the feedback loop, causing the controller to oversteer constantly by acting on stale information. The deeper fix involves phase-lead compensation: using the rate of temperature change to anticipate where the system is headed and back off before overshoot occurs. The "take back half" algorithm elegantly learns the system's momentum in real time, iteratively adjusting its trigger point to coast into the set point without needing to measure the room's thermal properties upfront. This connects directly to statistics and sampling theory—a single temperature reading is a sample with unknown bias, and reacting to every sample is overfitting to noise. The broader engineering lesson is profound: good control often means knowing when to do nothing. Whether applied to thermostat algorithms, auto-scaling groups, or monitoring systems, the principles are the same—smooth the signal, look at the rate of change, and let the system's natural momentum do the work.
#4995: What a Bad Thermostat Teaches Us About Control
How phase lead, decay, and knowing when to do nothing fix the oscillation problem.
Episode Details
- Episode ID
- MWP-5177
- Published
- Duration
- 27:08
- Audio
- Direct link
- Pipeline
- V5.2
- TTS Engine
-
chatterbox-regular - Script Writing Agent
- deepseek-v4-pro
AI-Generated Content: This podcast is created using AI personas. Please verify any important information independently.
Downloads
Transcript (TXT)
Plain text transcript file
Transcript (PDF)
Formatted PDF with styling
You Might Also Like
Never miss an episode
New episodes drop daily — subscribe on your favorite platform
New to the show? Start here#4995: What a Bad Thermostat Teaches Us About Control
You walk into a room and you feel it before you know it. The air is clammy, the AC's been cycling on and off every three minutes, and somewhere in the back of your mind you register that the thermostat is bad. Not broken — just bad. And that visceral, skin-level awareness of a control system failing is the most intimate automation bug most people will ever experience.
Daniel's got a whole thing about this. He's been staring at thermostats — the simple kind, where you've got a sensor, a set point, and a climate device, and you're binding them together in Home Assistant. The premise looks trivial: if the room's too warm, cool harder. If it's too cold, back off. But the moment you try to code that, you discover failure patterns that weren't obvious on paper. The algorithm gets overzealous, shoots past the set point, and now you're forever oscillating — like a car where the only options are floor the accelerator or floor the brake. He's asking about the deeper fix: the phase operations and decay understanding that let a well-designed thermostat achieve stable operation with coarse levers. And the bigger question underneath — what does a thermostat teach us about statistics, sampling, and the mathematics of not overcorrecting?
And we're not fixing a thermostat today. We're using it as a window into how to think about control, sampling, and the art of pulling levers based on measurements. This is the simplest feedback loop most people interact with daily, and it exhibits every failure mode of more complex systems — overshoot, oscillation, instability, the whole catalog.
The naive algorithm is simple to describe and disastrous to run. Let's walk through exactly what goes wrong.
So the simplest thing you can build is what control engineers call a bang-bang controller. Temperature above set point? Full cooling on. Temperature below? Full cooling off. That's it. No memory, no prediction, no sense of momentum. And the first thing you discover is that your compressor will destroy itself cycling on and off every few seconds, because the temperature at the sensor bounces across the set point almost immediately when the cold air hits it.
So you add hysteresis. The universal first fix.
Right. You say cool until the temperature drops half a degree below the set point, then stop. Don't start again until it rises half a degree above. That dead band prevents the rapid cycling, and it's what virtually every dumb thermostat on the planet does. And it still produces visible oscillation — half a degree to a full degree swings — because it ignores thermal inertia entirely.
Walk me through the inertia problem. What's actually happening in the room?
A typical room has a thermal time constant of ten to twenty minutes. When you turn the AC on, the air near the unit gets cold fast, but the walls, the furniture, the floor — all that thermal mass — takes time to cool down. And when you turn the AC off, the temperature keeps dropping for another five minutes or more as that mass continues to give up heat to the air. The sensor reads the air temperature near it, not the average room temperature, and certainly not the thermal mass temperature. So you've got a delay in the feedback loop — control engineers call it dead time — and delay is the enemy of stability.
So the sensor says "still too warm" and the controller keeps cooling, but the cooling that's already happened hasn't even registered yet.
It's like steering a boat where the rudder response lags by ten seconds. You turn the wheel, nothing happens, so you turn harder, and then the first turn catches up and you've oversteered. The naive thermostat is oversteering constantly because it's acting on stale information.
And this is where the statistics angle Daniel mentioned comes in. A single temperature reading is a sample with unknown bias.
The sensor near the AC vent is reading air that just got chilled. The sensor across the room hasn't felt it yet. Which one represents the room? Neither, really. A thermostat that acts on every sample is overfitting to noise — it's reacting to the turbulent eddy of cold air that just happened to wash over the sensor, not to the underlying thermal state of the room. This is sampling theory in its most tangible form. You need to estimate the state, not react to the latest measurement.
And the fix Daniel's pointing at — phase operations and decay — that's where the mathematics gets interesting.
The core concept is a lead compensator. In a normal feedback loop, you measure the error — how far you are from the set point — and you apply a correction proportional to that error. That's proportional control, and by itself it still oscillates because of the delay. The lead compensator adds a term that looks at the rate of change of the temperature — the derivative — and uses that to anticipate where you're headed. If the temperature is dropping fast, the controller backs off the cooling before you reach the set point, because it knows momentum will carry you the rest of the way.
So it's not just asking "where am I," it's asking "how fast am I moving and where will I be in five minutes."
That's the phase lead. The thermal mass of the room introduces a phase lag — the temperature response lags behind the control action. The derivative term introduces a phase lead that counteracts it. You're shifting the timing of the controller's response so it acts before the overshoot happens, not after. The decay part is about understanding the room's natural time constant — the rate at which it dissipates energy. If you know the room cools by roughly one degree per ten minutes when the AC is off, you can calculate exactly when to cut power so you coast into the set point.
There's a beautiful algorithm some smart thermostats use called "take back half." When the temperature crosses the set point, the controller doesn't just reverse — it backs off by half the distance it overshot.
It's effectively learning the system's momentum in real time. Say you set the AC to full cooling, and the temperature drops through the set point and keeps going to one degree below. The algorithm says: I overshot by one degree. Next cycle, I'll cut cooling when I'm still half a degree above the set point, because I know momentum will carry me the rest of the way. It's an iterative learning process that converges on the right timing without needing to know the room's thermal properties in advance.
Which is remarkably elegant for something that fits in a thermostat.
And it connects directly to the statistics lesson. The take-back-half algorithm is essentially building a running estimate of the system's impulse response — how much temperature change follows from a given amount of cooling — but it's doing it with a dead-simple heuristic rather than a full system identification. It's a reminder that you don't always need a complex model. Sometimes a simple learning rule that converges on the right answer is more robust than trying to measure everything upfront.
The thing I keep coming back to is that a bad thermostat feels bad. You can sense the overcorrection on your skin. And the reason it feels bad is that the controller is working harder than it needs to. More cycles, more fan speed changes, more beeping — and worse results.
That's the illusion that more effort equals better outcomes. The naive algorithm thinks "I'm still above the set point, therefore I must keep cooling." It confuses activity with progress. A well-tuned thermostat does less — fewer cycles, longer off periods — and holds temperature tighter.
So phase and decay fix the thermostat. But the real payoff is what this teaches us about any system that pulls levers based on samples.
Let's talk about levers. The thermostat's actuator is coarse — it's on or off, full cooling or nothing. The only way to modulate output is through timing and duty cycle — how long you run and how long you rest. This is pulse-width modulation in spirit, but applied to a system with significant delay. And here's the thing: almost every interesting control problem has coarse levers. Your server auto-scaler can add instances or remove them — there's no "add three-quarters of an instance." Your inventory management system can order more stock or not.
The heating and cooling crossover question Daniel raised is a perfect illustration of what good control looks like. Do you ever add heat to correct overcooling?
Mathematically, a well-tuned system never needs to. The phase-lead compensation ensures you back off the cooling early enough that you coast to the set point from above. If you cross the set point and engage heat, you've tuned wrong — you're now burning energy to undo what you just did, and you'll probably overshoot in the other direction and start the cycle again. This is a profound lesson: good control means knowing when to do nothing, not just when to act.
The most important control action is often inaction.
And that's counterintuitive. The instinct is "the temperature is still wrong, I must do something." But doing nothing for five minutes while the thermal mass equilibrates is often the correct move, and the algorithm that can't sit still will always perform worse than the one that can.
Let's pull this into software engineering, because that's where Daniel lives. What's the equivalent of a bad thermostat in the systems we build?
The most direct analog is a monitoring system that pages on every spike. CPU jumps to ninety percent for three seconds — page. Latency blips on one request — page. The system reacts to every sample, generates a flood of alerts, and the on-call engineer starts tuning out the noise. That's bang-bang control with no hysteresis and no derivative term. The fix is the same: smooth the signal, look at the rate of change, and only alert when the trend says something real is happening, not when a single sample crosses a threshold.
Auto-scaling is even closer. You've got a group of servers, and you're watching CPU utilization. Naive auto-scaler sees CPU hit seventy percent, spins up two more instances. Three minutes later the instances are booted, but by then the traffic spike passed, and now you've got excess capacity. Then it scales down, traffic returns, and you're in the same oscillation the thermostat was in.
AWS Auto Scaling groups that use predictive scaling are the phase-lead equivalent. They look at the rate of change of load, not just the current value, and they anticipate the need for capacity before the threshold is crossed. They also impose cooldown periods — hysteresis — to prevent flapping. It's the thermostat algorithm, just with instance counts instead of compressor run time.
The Nest thermostat's early learning algorithm did something similar. It observed that users set back the temperature at night, and it learned the house's thermal envelope — how fast it cooled down, how long it took to warm up. It built a model of the system's time constant rather than just reacting. And then it would start cooling earlier in the evening, more gently, so the house was at the target temperature when you went to bed without ever slamming the compressor.
That's the difference between a reactive controller and a predictive one. The reactive controller waits for the error and then corrects. The predictive controller says "I know this house takes forty-five minutes to drop three degrees, so I'll start forty-five minutes early and run at a moderate pace." Same coarse lever — the compressor is still on or off — but the timing is informed by a model.
So the broader engineering lessons. If I'm building any system that pulls levers based on sensor readings, what are the rules?
First: measure the system's time constant before you design the controller. How long does it take for an action to fully propagate? In a room, it's the thermal time constant. In a server fleet, it's the instance boot time plus the load balancer health check delay. In a supply chain, it's the order-to-delivery lag. If you don't know that number, you can't design a stable controller.
Second: use the rate of change, not just the current value.
The derivative term. Where is the system headed? If temperature is dropping at half a degree per minute and you're still half a degree above the set point, you're about thirty seconds from crossing — start backing off now. The equivalent in software: if error rates are climbing at a steady slope, don't wait for the threshold — the slope itself is the signal.
Third: coarse actuators need smarter timing, not finer granularity.
You don't need a variable-speed compressor to get stable temperature control. A simple on-off AC with a smart algorithm that understands thermal lag will outperform a variable-speed unit with a naive controller. The intelligence is in when you act, not in how many gradations of action you have available.
And fourth: a single sensor is a liability. You need to estimate state, not react to samples.
The temperature sensor near the AC vent is measuring a local artifact, not the room. The CPU sensor on one server is measuring that server's load, not the fleet's capacity. In both cases, you need to combine multiple measurements — spatially, temporally, or both — to estimate the true state before you act. This is a Kalman filter in the fancy case, a moving average in the simple case, but the principle is the same: the raw sample is not the truth.
The failure pattern Daniel described — the room that's always slightly too cold or slightly too hot, the system forever beeping with adjustments — that's the signature of a controller that's sampling too fast and acting on every tick.
And this is where the Nyquist sampling theorem enters in a surprising way. A room's temperature changes at frequencies well below zero point zero one hertz — the fastest meaningful change might be a door opening, which is still on the order of seconds. Sampling once per minute is more than adequate to capture every real temperature change. Sampling faster than that — say, once per second — captures mostly sensor noise. The naive algorithm that samples continuously and acts on every reading is overfitting to noise, and the overshoot is the direct result.
More data, more action, worse results. That's the paradox.
It's the same reason a PID controller with too much gain oscillates. The proportional term is too aggressive — it sees a small error and applies a large correction. The integral term winds up while the system is delayed. The derivative term amplifies sensor noise if you don't filter it. Every term in the controller can become a liability if you tune it to react too fast to too little information.
Let's talk about the integral term for a second, because it's the sneaky one. Integral windup is what happens when the controller accumulates error over time — "I've been above the set point for ten minutes, I must need more cooling" — but the reason it's been above the set point is that the cooling it already applied hasn't reached the sensor yet.
And when it does reach, the temperature plummets, and now the integral term is saturated with accumulated error and takes forever to unwind. This is exactly the thermostat that overshoots by two degrees and then sits there freezing the room while it slowly figures out it overdid it. The fix is integral anti-windup — you cap the accumulated error or zero it out when the actuator saturates — but the deeper lesson is that memory in a controller is dangerous when the system has delay.
So we've got a set of principles that transfer directly from HVAC to software. But before we get too confident in our digital solutions, Hilbert's been making a face over there for the last ten minutes.
Hilbert: You've got the time constant wrong on that commercial building. It's not ten to twenty minutes. It's forty-five to ninety minutes for a concrete-and-steel structure with a full floor of thermal mass. I ran a twelve-story office tower in Cleveland from nineteen eighty-three to nineteen ninety-four.
Hilbert: The system was pneumatic. Bimetallic strip in the thermostat, a tiny air bleed valve, and copper tubes running compressed air at fifteen PSI down to the damper actuators in the VAV boxes. No sampling, no quantization, no digital logic of any kind. The thermal expansion of the metal directly controlled the air pressure that moved the damper. It was analog all the way down.
Hilbert: Held temperature within half a degree Fahrenheit for twenty years. The secret wasn't an algorithm. The secret was that the physics of the sensor and the physics of the actuator were the same physics. Thermal expansion. There was no conversion step, no analog-to-digital, no discrete measurement, no delay between measurement and action. The control loop was continuous.
Hilbert: You're talking about solving problems that analog didn't have.
Hilbert: You've got the time constant wrong on that commercial building. It's not ten to twenty minutes. It's forty-five to ninety minutes for a concrete-and-steel structure with a full floor of thermal mass. I ran a twelve-story office tower in Cleveland from nineteen eighty-three to nineteen ninety-four.
Hilbert: The system was pneumatic. Bimetallic strip in the thermostat, a tiny air bleed valve, and copper tubes running compressed air at fifteen PSI down to the damper actuators in the VAV boxes. No sampling, no quantization, no digital logic of any kind. The thermal expansion of the metal directly controlled the air pressure that moved the damper. It was analog all the way down.
Hilbert: Held temperature within half a degree Fahrenheit for twenty years. The secret wasn't an algorithm. The secret was that the physics of the sensor and the physics of the actuator were the same physics. Thermal expansion. There was no conversion step, no analog-to-digital, no discrete measurement, no delay between measurement and action. The control loop was continuous.
Hilbert: You're talking about solving problems that analog didn't have.
Hold on.
Say more about that continuity. You're claiming the absence of sampling is what made it stable?
Hilbert: I'm not claiming it. I'm telling you the thing ran for two decades with a maintenance visit twice a year to check the air compressor. The bimetallic strip bends as the temperature changes. The bending moves a flapper that covers or uncovers an air bleed port. The air pressure in the control line changes proportionally — not in steps, proportionally. The damper moves proportionally. At no point does anything say "the temperature is seventy-two point three degrees." The system doesn't know the temperature as a number. It just responds to it.
Hilbert: Your digital thermostat samples the temperature, quantizes it to a tenth of a degree, runs it through an algorithm that outputs a binary on-off decision, and then wonders why it oscillates. You introduced the quantization. You introduced the sampling delay. You turned a continuous physical process into a discrete computational one, and now you're trying to fix the artifacts with more computation.
Hilbert: I'm not claiming it. I'm telling you the thing ran for two decades with a maintenance visit twice a year to check the air compressor. The bimetallic strip bends as the temperature changes. The bending moves a flapper that covers or uncovers an air bleed port. The air pressure in the control line changes proportionally — not in steps, proportionally. The damper moves proportionally. At no point does anything say "the temperature is seventy-two point three degrees." The system doesn't know the temperature as a number. It just responds to it.
Hilbert: Your digital thermostat samples the temperature, quantizes it to a tenth of a degree, runs it through an algorithm that outputs a binary on-off decision, and then wonders why it oscillates. You introduced the quantization. You introduced the sampling delay. You turned a continuous physical process into a discrete computational one, and now you're trying to fix the artifacts with more computation.
He's not wrong about the physics. A pneumatic thermostat is a proportional controller by its nature — the further the temperature is from the set point, the more the damper opens. There's no bang-bang, no hysteresis, no dead band. It's continuous control with a mechanical gain set by the geometry of the bimetallic strip and the air bleed port.
So the question becomes: is digital control introducing fundamental instability that no algorithm can fully compensate for?
The sampling theorem says no — if you sample at least twice as fast as the highest frequency in the signal, you can reconstruct the continuous signal perfectly. A room's temperature has no meaningful frequency content above maybe zero point zero one hertz. Sampling at one hertz — once per second — is fifty to a hundred times the Nyquist rate. The information is all there.
But Hilbert's point isn't about information loss. It's about the conversion step itself. The act of turning a continuous phenomenon into a discrete measurement, then computing a discrete decision, then turning that back into a continuous physical action — each conversion introduces delay and quantization error.
Hilbert: The pneumatic thermostat doesn't convert anything. The temperature is the position of the strip. The position of the strip is the air pressure. The air pressure is the damper position. It's all one thing, just expressed differently.
Hilbert: The pneumatic thermostat doesn't convert anything. The temperature is the position of the strip. The position of the strip is the air pressure. The air pressure is the damper position. It's all one thing, just expressed differently.
There's a deep point here about impedance matching between sensor and actuator. In the pneumatic system, the sensor and actuator speak the same physical language — mechanical displacement translated through air pressure. In a digital system, the sensor speaks voltage, which gets converted to bits, which get processed by logic, which outputs bits, which get converted back to voltage, which drives a relay. That's four domain crossings — thermal to electrical, electrical to digital, digital to electrical, electrical to mechanical. Each crossing adds delay and noise.
The pneumatic system crosses zero domains. It stays in the physical the whole way.
Hilbert: We had a saying in the building trades. The best control system is the one where you can see why it's doing what it's doing just by looking at it. You open the thermostat cover, you see the bimetallic spiral, you see the flapper, you see the air port. There's no code. There's no sensor calibration drift. If it's off, you bend the strip a little with a screwdriver and you're done.
Hilbert: I've got four of those thermostats in a box in my garage. Honeywell TP-seventy series. Pulled them out of the Cleveland building during the retrofit to digital in ninety-four. They still work. I test them every few years with a heat gun and a pressure gauge.
Hilbert: We had a saying in the building trades. The best control system is the one where you can see why it's doing what it's doing just by looking at it. You open the thermostat cover, you see the bimetallic spiral, you see the flapper, you see the air port. There's no code. There's no sensor calibration drift. If it's off, you bend the strip a little with a screwdriver and you're done.
Hilbert: I've got four of those thermostats in a box in my garage. Honeywell TP-seventy series. Pulled them out of the Cleveland building during the retrofit to digital in ninety-four. They still work. I test them every few years with a heat gun and a pressure gauge.
The calibration mechanism is literally bending the metal. That's not a bug — it's the set point adjustment. You turn the dial, it changes the tension on the bimetallic strip, and the equilibrium point shifts.
The digital world introduced a problem — sampling artifacts, quantization noise, conversion delays — and then invented an entire field of control theory to solve it. And the analog world just... didn't have the problem.
Well, it had different problems. Pneumatic systems leak. The air compressor runs constantly. The copper tubing corrodes. You can't zone a pneumatic system easily — every thermostat needs its own air line run back to the mechanical room. And you can't do any of the smart things we talked about — predictive cooling based on weather forecasts, occupancy-based setbacks, learning the thermal envelope. The analog system is stable but dumb.
Stable but dumb versus smart but twitchy. That's the tradeoff.
The right answer is probably that digital control can match analog stability if you design it with an understanding of what analog did naturally. Sample fast enough that the quantization is below the noise floor. Use a control loop frequency high enough that the delay through the digital system is negligible compared to the system's time constant. And for the love of everything, filter your sensor input so you're controlling on the estimated state, not the raw sample.
The pneumatic thermostat's genius was that it was a proportional controller by physics, not by algorithm. The digital equivalent is a PID loop with the integral and derivative terms tuned to match the system's time constant — which is exactly what we've been describing.
Tuned well, it should match or exceed the pneumatic system's performance. But the default — the out-of-the-box digital thermostat with bang-bang control and fixed hysteresis — is worse than what we had in nineteen fifty.
Hilbert: Nineteen thirty. The Honeywell T-eighty-seven round thermostat shiped in nineteen thirty-eight and was still in production when I started in the trades. Bimetallic strip, mercury bulb switch. No air compressor needed. Held temperature to within half a degree. The mercury bulb was the hysteresis — the tilt angle of the bulb determined the dead band, and it was smooth enough that it didn't click on and off rapidly. They sold tens of millions of them.
Hilbert: Your smart thermostat with the color screen and the Wi-Fi costs three hundred dollars and can't hold temperature as well as a forty-dollar round thermostat from the Roosevelt administration.
Hilbert: Nineteen thirty. The Honeywell T-eighty-seven round thermostat shiped in nineteen thirty-eight and was still in production when I started in the trades. Bimetallic strip, mercury bulb switch. No air compressor needed. Held temperature to within half a degree. The mercury bulb was the hysteresis — the tilt angle of the bulb determined the dead band, and it was smooth enough that it didn't click on and off rapidly. They sold tens of millions of them.
Hilbert: Your smart thermostat with the color screen and the Wi-Fi costs three hundred dollars and can't hold temperature as well as a forty-dollar round thermostat from the Roosevelt administration.
That's a devastating sentence.
It's also a fair one, if we're comparing basic temperature holding. Where the smart thermostat wins is everything else — the scheduling, the occupancy detection, the energy savings from knowing when you're away. But Hilbert's right that on the single metric of holding a steady temperature, the analog solutions were remarkably good.
Maybe the question isn't just how to tune a better algorithm. It's whether the algorithm is the right tool at all for the narrow problem of steady-state temperature holding.
The algorithm is the right tool when the problem is more than steady-state holding. When you want the house to be sixty-eight degrees when you wake up but sixty-two while you sleep, and you want it to pre-cool before the peak electricity rate kicks in, and you want it to know you're away and stop conditioning an empty house — that's when the digital controller earns its keep. The pneumatic thermostat can't do any of that.
But the lesson for anyone building a control system is: solve the basic stability problem first, before you add features. If your thermostat can't hold a steady temperature without oscillating, no amount of machine learning on top will fix it. You've got a bad control loop, and the features are just masking it.
The way you solve the basic stability problem is the same whether you're controlling a room, a server fleet, or a supply chain. Know your system's time constant. Filter your measurements. Use the rate of change, not just the current value. And accept that the best control action is often no action at all.
If you take one thing from this, it's that last point. The thermostat that does less — fewer cycles, longer rests, less frantic adjustment — holds temperature better than the one that's constantly reacting. The instinct to act on every measurement is the enemy of stability.
That instinct shows up everywhere in software. The monitoring system that pages on every spike. The auto-scaler that chases every load blip. The circuit breaker that trips on the first timeout. All of them are the naive thermostat, and all of them would be improved by understanding the system's natural frequency and damping the response accordingly.
The open question Hilbert left us with — whether digital sampling inherently loses something that analog continuity had — that's going to become more relevant, not less. We're putting sensors and actuators into everything. Homes, cars, cities. And the thermostat's lesson is that acting on every sample creates instability. The best control might be the one that acts least, that smooths the most, that trusts the physics more than the data.
It's a weird conclusion to reach in an era of ever-faster sampling and ever-more-granular data. Sometimes the smartest algorithm is the one that throws most of the data away.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping us honest — and for the box of Honeywells in the garage.
If you enjoyed this episode, rate and review My Weird Prompts wherever you listen. It helps other people find the show, and it helps us know what kind of weird prompts you want us to explore.
We'll be back soon.
This episode was generated with AI assistance. Hosts Herman and Corn are AI personalities.