The brief was unusual: turn a motorized smart vent into a room thermostat, without a room temperature sensor. The product would know the temperature in the duct and very little about the room it was supposed to control. Before writing control code, we instrumented a test home with more than 100 sensors across eight zones.
That ratio, far more sensors in development than in the product, is the lesson worth borrowing. You cannot tune what you cannot see, and you cannot validate an estimate without the truth to compare it against.
What we measured, and with what
The test home measured temperature, pressure, humidity, airflow, ambient light, presence and power across its zones. On top of the installed sensors, flow hoods, anemometers, thermal cameras and current clamps let us verify the standard ACCA, ANSI and ASHRAE load and flow calculations against what the house actually did.
Those calculations are good predictions. ACCA’s Manual J, for example, is the ANSI-recognized standard for HVAC equipment sizing loads, and Manual D sets out ANSI-recognized duct sizing principles. But a prediction is not a measurement. A test house tells you how good the prediction is for your building, your hardware and your control strategy.
Three reasons to over-instrument
The model needs the truth. The product’s job was to estimate room temperature from duct temperature. The test house had the room sensors the product would never ship with, which gave us ground truth to build that estimator against and to measure its error.
The model needs excitation. System identification is a methodology for building mathematical models of dynamic systems from measured inputs and outputs, and MathWorks’ guidance is direct: use inputs that excite the system dynamics adequately, because a single step is usually not enough. Dense sensing lets you watch every zone respond while you drive the system on purpose, instead of waiting for the weather to do it.
Some features only appear once you measure. Because airflow was measured, the air that had actually passed through the filter could be counted. That became a patented algorithm that calculates remaining air-filter life from flow odometry instead of runtime estimates.
What the data turned into
- A thermodynamic model of the house
- An algorithm that estimates room temperature from duct temperature
- A distributed control system that stabilizes zones using the vents
- Server-side machine learning that processes control requests from many rooms at once, behind a virtual-thermostat mobile app
- API integrations with major thermostat, ceiling-fan, smart-hub and energy-monitoring platforms
The same habit paid off at smaller scale. Server latency fell 75% through memoization, and device battery life rose 20% through hardware-in-the-loop kinematics modeling. Measure first, then optimize what the measurement says matters.
How to apply it to your product
| Question | What to build into your development rig |
|---|---|
| What does the controller need to know that the product cannot sense? | Reference instruments that measure it directly |
| What drives the system? | A way to vary those inputs deliberately |
| What will you compare against? | Time-synced logging of every channel, product and reference alike |
| How will you catch regressions after launch? | A smaller version of the rig you keep running |
The reference instruments never ship, so they do not have to be cheap or pretty. They have to be accurate, calibrated, and logged on the same clock as the product. A sensor whose timestamps drift against the product’s is a sensor you cannot use for estimation.
Keep the rig after launch, too. When a firmware update changes how the controller behaves, replaying the same conditions against the same reference instruments tells you whether the product got better or just got different. Without it, your customers become the test rig, and they report results far less precisely than a thermal camera does.
What to do this week
- List what your control loop needs to know, and mark which of those quantities the product actually senses.
- For each quantity it cannot sense, pick a reference instrument you can put in the development rig, even temporarily.
- Log one day of product and reference data on a shared clock, and look at the estimation error before you tune a single gain.
If you want a second pair of eyes on your control architecture or test rig, send us a brief.