Sensors, Controls & Feedback

Every responsive system, from a self-tinting window to a sun-tracking facade to a room's climate control, runs the same four-stage loop, and naming the stages clearly is the first step to reasoning about any of them.

Stage one: the sensor detects. A sensor is a device that measures some condition and turns it into a signal the system can use - light level, temperature, the sun's position, wind speed, rain, occupancy, air quality, the position of the moving element itself. The sensor is the system's sense organ; everything the controller knows about the world, it knows through sensors, which is why a system is only ever as good as what it can sense, and why a missing or badly placed sensor blinds it.

Stage two: the controller decides. The controller is the system's brain (the subject of the next lesson). It takes the sensor signals, applies its logic - which can be as simple as a single threshold or as elaborate as a learning algorithm - and decides what, if anything, should happen. Decide is the pivotal verb: the controller converts raw measurement into a considered command.

Stage three: the actuator acts. The command goes to the actuator - the motor, ram or cylinder of the previous lesson - which physically carries it out: the louvre pivots, the vent opens, the glass tints. This is the stage where the decision meets the real, resisting world of weight, friction and wind.

Stage four: feedback confirms. The system senses the result of its own action - typically the new position or state of the element - and reports it back to the controller, which compares what actually happened against what it intended. If a facade was told to move to forty-five degrees, a feedback sensor reports the angle it actually reached, and the controller can see whether the command succeeded, fell short, or achieved nothing because the mechanism jammed.

These four stages - detect, decide, act, confirm - are universal. What separates a crude responsive system from a dependable one is almost entirely about that fourth stage, and whether the loop it would close is actually closed.

The single most important concept in control - and the one a designer most needs - is the difference between an open loop and a closed loop. It is the difference between a system that hopes and a system that knows.

An open-loop system issues a command and never checks the result. It has stages one to three - it may sense a condition, decide, and act - but it lacks stage four: nothing measures the outcome and feeds it back. A wall switch driving a motor is pure open loop: you press it, the motor runs for a set time, and the system simply assumes the louvre moved. It has no idea whether the louvre actually reached its position, stopped halfway, or never moved because something was in the way. Open-loop systems are cheap and simple, and for undemanding, low-consequence tasks they are perfectly adequate - but they are blind, and blindness makes them brittle: when something goes wrong, the system does not know, does not correct, and carries on as if all were well.

A closed-loop system adds the feedback arrow. It measures the actual outcome, compares it against the target, and keeps correcting until the two match. A facade under closed-loop control does not just command forty-five degrees and assume; it reads the angle actually achieved, sees any error, and drives the actuator until the real angle matches the intended one - and if the element jams, the feedback shows the target is never reached, so the system can raise an alarm instead of silently failing. Closed-loop control is the foundation of reliable automatic response; it is what makes a system self-correcting rather than merely hopeful.

The cost of closing the loop is real - more sensors, more wiring, more control complexity - so it is not automatically right for everything. But the decision of open versus closed is one of the most consequential in any responsive system, and it maps directly onto how much you can trust the system to run unattended. The more autonomous, the more consequential, and the more out-of-reach a moving element is, the more its loop needs to be closed - so that when it fails, as one day it will, the system knows.

Feedback deserves its own reckoning, because it is the quiet hero of every responsive building and the thing most often missing when one fails. Feedback is simply information about the result of an action fed back to the thing that took the action, and its power is that it lets a system compare intention against reality and act on the difference. Without it, a system is forever acting on assumption; with it, a system acts on truth.

Consider what feedback buys you. It buys accuracy: a closed-loop element reaches the position it was actually asked for, correcting for the friction, sag, wind and wear that would otherwise leave an open-loop element short or long. It buys fault detection: when a mechanism jams, a cable stretches, or a motor weakens, feedback reveals that the commanded state was not reached, turning a silent failure into a reported one - the difference between a facade that quietly stops working for months and one that raises an alarm the day it fails. It buys safety: feedback that an element has not fully closed, or that something is obstructing it, lets the system stop rather than force. And it buys trust: a building operator can believe a system that confirms its own actions in a way they can never quite believe one that merely issues commands into the dark.

This is why feedback, not the motor and not the clever algorithm, is often the real dividing line between adaptive architecture that endures and adaptive architecture that becomes the maintenance graveyard. A great many celebrated kinetic facades fail not because the motors were weak but because nothing was watching: an element seized, no feedback reported it, the fault went unnoticed until it was widespread and expensive, and confidence in the whole system collapsed. A humbler system that always knows its own state - that can always answer did it actually happen? - is worth more in service than a cleverer one that cannot.

The design lesson is not that everything must be closed-loop; simple, low-stakes, easily-seen movements can be open-loop and fine. The lesson is to treat feedback as a first-class design question - to ask of every responsive element, how will this system know whether it actually did what it was told, and who will find out when it did not? - and to insist the loop closes wherever the answer matters.

Understanding the loop equips you to ask the right questions and set the right intent, without designing the control electronics yourself. As with the actuator, there is a clear line between what the designer owns and what the controls engineer is bound by.

What you own is the intent and the demands you place on the loop. You decide what the system should respond to - which is really a decision about what it must sense, and therefore what sensors must exist and where they belong (a light sensor in shadow, a rain sensor sheltered from rain, a temperature sensor over a radiator all lie to the system, so sensor placement is a genuine design concern). You decide how the element should behave, which sets the controller's goals. And you decide how much the system must be trusted to run unattended - which is really a decision about whether its loops need to be closed, and how failures must be made visible. Insisting that a consequential, out-of-reach moving element has feedback and reports its own faults is a design requirement you can and should set, in plain language, without touching a wiring diagram.

What you defer is the binding engineering of the loop: the selection and rating of specific sensors and controllers, the design of the control circuitry and its logic, the tuning that makes a closed loop stable rather than oscillating, the electrical and network design, and the safety-critical control functions - all of this belongs to qualified controls, electrical and systems engineers and to tested, rated products, working to the governing codes and safety regulations including the National Building Code of India and local rules. A poorly tuned closed loop can hunt, overshoot or oscillate, and getting it stable is real control engineering, not a setting a designer adjusts. So your posture is this: understand the loop deeply enough to demand that it closes where it matters, to place the sensing intelligently, and to insist that failures become visible - and hand the binding design of the control system to the specialists who will be accountable for it.