How Control Loops Work: Setpoints, Feedback and Closing the Loop

The one idea the whole course rests on

If you remember nothing else from this course, remember this: a building automation system works by doing the same three things, over and over, forever. It measures something, compares that measurement to a target, and acts to shrink the difference. Then it does it again a second later. And again. And again.

That endless cycle — measure, compare, act — is called a control loop, and it is the beating heart of every thermostat, every chilled-water valve, and every "smart" building on the planet. Once you can see the loop, a Building Management System (BMS) stops looking like magic and starts looking like a very patient, very fast version of something you already do without thinking.

Because you do this yourself. When you take a warm shower, you nudge the tap, feel the water, and nudge again until it's right. You are the measurement. Your hand is the actuator. "Comfortably warm" is your setpoint. You are running a control loop with your own skin as the sensor. A BMS just does the same thing with a temperature sensor and a valve — and it never gets bored.

The three words you need: setpoint, process variable, error

Let's put real names to the parts, using the most common example in any tropical building: cooling a room.

- The setpoint is the target — the value you want. In a typical Malaysian office, the cooling setpoint sits around 24 degC.
- The process variable is what you're actually measuring right now — the real room temperature. Say it's 26 degC because the room just filled with people and afternoon sun.
- The error is simply the gap between them: setpoint minus process variable. Here that's 24 minus 26, an error of 2 degC too warm.

That single number — the error — is what the whole loop is chasing. The controller's only job is to make the error smaller. A positive-or-negative gap of two degrees tells it: the room is too warm, open the chilled-water valve, let more cold in. As the room cools toward 24 degC, the error shrinks toward zero, and the controller eases the valve back. When the error is zero, the room is exactly on target and the system can relax.

Notice how little the controller needs to "know." It doesn't understand sunshine, or bodies, or the weather forecast. It only needs two numbers — where you are and where you want to be — and the discipline to keep nudging until they match. That simplicity is the whole trick.

Open-loop: acting blindly

To really appreciate feedback, it helps to see a system that doesn't have it.

Imagine a fan wired to a simple timer: run for one hour, then stop. That's open-loop control — the system acts on a fixed instruction and never checks whether the instruction is working. The timer has no idea if the room is pleasantly cool or stiflingly hot. It runs the fan for exactly one hour whether the space is empty, packed, sunny, or shaded. It follows the plan and hopes the plan happens to be right.

Open-loop control isn't useless — it's cheap, simple, and fine when the outcome is predictable and nobody's counting. A toaster runs on a timer. So does a basic irrigation sprinkler. But the moment reality drifts from the assumption — the room fills with people, the sun swings around the building — an open-loop system has no way to notice and no way to correct. It's driving with your eyes closed, steering by memory of the road.

Closed-loop: acting, then checking

Now swap the timer for a thermostat.

A thermostat measures the room, compares it to the setpoint, and adjusts — then measures again to see if the adjustment worked, and keeps adjusting until the room actually reaches target. That feedback — measuring the result of your own action and using it to decide the next action — is what makes it closed-loop control. The loop is "closed" because the output (cooler air) feeds back to the input (the sensor), completing a circle.

This is the difference between a system that hopes and a system that knows. The open-loop timer assumes one hour of fan will do the job. The closed-loop thermostat doesn't assume anything — it looks at the real room temperature and responds to what's genuinely happening. If the room heats up faster than expected, it simply cools harder. If the room is already cool, it backs off. It self-corrects, continuously, without anyone touching it.

This is the honest reason people call a BMS "smart." It isn't clever in the way a person is clever. It's smart because it reacts to reality instead of to assumptions. It doesn't run cooling because the schedule says so; it runs cooling because a sensor says the room is warm. Feedback is the entire difference, and feedback is native to building automation — almost everything a BMS does, from a single room to a whole chiller plant, is some version of this same closed loop.

The problem with reacting to everything

Here's where a purely closed loop, left too eager, causes its own trouble.

Real sensor readings are never perfectly steady. A temperature sensor might read 24.0, then 24.1, then 23.9, then 24.05 — tiny wobbles from air currents, someone walking past, the sun flickering behind a cloud. If the controller reacted to every one of these tiny errors, it would be forever nudging the valve open a hair, closed a hair, open again — never settling. That constant twitching is called hunting, and it's exactly what you don't want. It wears out valves and actuators, unsettles the temperature it's trying to hold, and wastes energy fighting phantom problems.

The reader's instinct is right: a control loop shouldn't chase noise. So we give it permission to do nothing when the error is small enough not to matter.

Deadband: a small zone of "close enough"

A deadband is a small no-action zone around the setpoint — a band where the controller decides the error is trivial and simply leaves things alone.

With a 24 degC setpoint, you might set a deadband of one degree: do nothing between 23.5 and 24.5 degC. Inside that band, the room is close enough to target that acting would cause more harm than good, so the controller holds steady. Only when the temperature crosses outside the band — climbing past 24.5, or dropping below 23.5 — does the controller wake up and correct. This is the reason a well-tuned office feels reassuringly stable rather than lurching a fraction of a degree every few seconds.

Think of it as the tolerance you'd give a friend driving you somewhere: you don't shout "left! right! left!" for every centimetre of lane drift — you only speak up when they genuinely wander. The deadband is that same good sense, written into the controller.

A useful comfort target for a tropical office is roughly 24 degC and 50-60% relative humidity — cool enough to feel fresh, dry enough to feel comfortable, without over-cooling. A sensible deadband keeps the room sitting calmly inside that band instead of chasing an impossible, perfectly-exact number.

(One quick note to carry forward: a deadband stops the system reacting to noise, but it's a blunt tool. Later parts introduce a more refined way for the controller to judge how hard to act based on the size of the error — but the deadband is the foundation, and we'll call back to it.)

Why the loop is everything

Step back and look at what we've built up, because every later part in this course is a variation on it:

- A sensor reads the process variable — what's actually happening.
- The controller compares it to the setpoint — the target — to find the error.
- If the error is bigger than the deadband, the controller moves an actuator (a valve or damper) to shrink it.
- The action changes reality, the sensor reads the new reality, and the loop runs again — closed, self-correcting, forever.

Scale that idea up and you have a whole building. One loop holds a meeting room at 24 degC. Another holds the chilled water leaving a plant at the right temperature. Another holds the pressure in a duct steady. A large BMS is really thousands of these simple loops, each patiently measuring, comparing, and nudging — layered together into something that keeps an entire tower comfortable.

This feedback idea is so fundamental that it's the anchor other courses point back to. If you want to see the same loop expressed in electrical and mathematical terms — how a controller decides not just whether to act but how much — our Electricity Fundamentals course covers it in feedback and PID control explained. And it's why the wider Learn hub treats "closing the loop" as a shared foundation rather than a one-off trick: sense, compare, act is the grammar underneath almost every automated system in a building.

The takeaway

A control loop is the simplest powerful idea in building automation: measure the current value, compare it to the setpoint, and move something to shrink the error — then repeat forever. Open-loop control acts blindly and hopes; closed-loop control checks the result and corrects, which is what makes a BMS genuinely responsive rather than merely scheduled. And a deadband — a small no-action zone like 23.5 to 24.5 degC around a 24 degC target — keeps the system from twitching at every flicker of noise, so comfort stays steady.

Hold onto this loop. Everything ahead is built on it.

Next, we'll meet the physical muscle that actually carries out the controller's decision — the actuators and dampers that turn a "shrink the error" command into real movement of air and water.