More Zones Did Not Automatically Mean More Savings
BUILDING ARDUIX
What happened when I expanded an HVAC controller from one floor to the full building
John Succo | Building Arduix | August 2026
I expected energy savings to roughly triple when I expanded control from one floor to all three. Instead, the first expansion used more total HVAC energy than the baseline.
01 / THE ASSUMPTION
The assumption seemed obvious
The first comfort-safe Arduix controller adjusted cooling setpoints for five zones on the bottom floor of a simulated three-story Denver office. It had repeatedly produced energy savings in the mid-single digits. The next step seemed straightforward: expand the same idea across the building's 15 occupied zones.
I expected the opportunity to grow with the controlled area. The upper floors were more exposed to outdoor conditions than the ground-adjacent first floor. The top floor also had the roof above it rather than another conditioned floor. If five bottom-floor zones could find approximately five or six percent, I expected three floors to find something closer to three times the opportunity—or at least a clear increase.
That expectation was not a sophisticated forecast. It was the intuitive story: more exposed zones, more adjustable setpoints and more chances to back away from unnecessary cooling should create more savings. The experiments broke that story almost immediately.
The result I did not believe
The first expansion controlled ten zones across the bottom and middle floors. Instead of increasing savings, it produced negative 1.74 percent. The policy reduced some cooling energy, but the building used more total HVAC electricity than the baseline over the evaluation window.
My first reaction was that I had a coding problem. Expanding the action vector touches zone ordering, observation construction, reward aggregation, trajectory storage and evaluation. A mismatch in any of those places could create a result that looked physical while applying the wrong action to the wrong zone.
I reran the revised harness using only the original five bottom-floor zones. That rollback recovered 6.16 percent savings. It ruled out the simplest explanation—that the expanded code path had broken the previously working controller. It did not prove that every multi-floor detail was correct, but it meant I had to take the energy result seriously enough to diagnose it.
Figure 1. Scaling the controller changed the optimization problem; it did not multiply the original savings.
02 / THE SYSTEM EFFECT
Cooling fell. Fan energy rose more
The component traces contained the first useful explanation. In the failed two-floor run, cooling electricity decreased by 9.48 kWh and delivered cooling also declined. At the same time, fan electricity increased by 32.99 kWh. The cooling reduction was real; it was simply overwhelmed by the additional air-moving cost.
That changed the question. The policy was not only deciding whether an individual zone needed less cooling. Its setpoints were changing how multiple zones requested air from shared systems. A locally reasonable setpoint adjustment could increase airflow or extend the time an air system had to satisfy dispersed cooling demands.
My working theory is that the dynamic zone actions created a coordination problem. As the controller changed setpoints for zones with different loads at different times, the air systems had to keep delivering cool air across a wider and less synchronized set of demands. The simulation traces support that theory through the fan-energy increase, but I treat it as an engineering interpretation—not a fully proven causal model.
Figure 2. The initial expansion shifted energy between HVAC components instead of reducing the total.
A building is not 15 independent thermostats
The mistake in my original expectation was treating the building as a collection of independent thermal boxes. The zones are separate in the model, but their HVAC consequences are coupled. Multiple zones share supply fans, coils, ductwork and air-loop operating conditions. Their setpoints influence common equipment.
This is why a simple setback argument can be misleading. Compared with a flat baseline, it is tempting to predict very large savings from relaxing setpoints whenever a zone appears to need less cooling. I even asked a general-purpose language model for a rough estimate and received a confident answer in the 40-to-50-percent range. That answer fell into the same trap I did: it reasoned about avoided cooling without accounting for how the complete HVAC system would respond.
A setback can shift load rather than eliminate it. It can create recovery demand later, change terminal airflow, alter fan operation and produce different results under different weather. The relevant outcome is not whether one component does less work at one moment. It is whether total HVAC energy falls while occupied comfort remains acceptable.
03 / THE OPTIMIZATION PROBLEM
More information was not the answer
My next instinct was to give the controller more information about airflow, fan behavior and zone cooling demand. Those experiments improved parts of the comfort result, but energy savings remained close to zero—0.67 percent in one test and 0.61 percent in another. A later terminal-airflow experiment was valid but weaker than the simpler configuration.
That was another useful correction to my intuition. A larger observation vector does not automatically make a better controller. New signals can increase model and deployment complexity without fixing the actual optimization imbalance. In a real BAS, every additional required point also creates another mapping, quality and maintenance burden.
For the public discussion, I am intentionally leaving out the exact observation construction, reward weights, setpoint limits and training configuration. The general lesson is enough: before increasing model complexity, verify that the objective still means the same thing after the control problem changes scale.
The comfort objective changed when the zone count changed
The more important issue was hiding in the comfort calculation. When the controller expanded from five zones to ten and then 15, the raw amount of possible discomfort grew with the number of zones. A building with twice as many measured zones can produce roughly twice as much aggregate comfort signal even when the typical experience in each zone has not changed.
That meant the relative balance between energy and comfort had changed simply because I added zones. The controller was no longer solving a directly comparable problem. Normalizing the comfort term by zone count converted the building-wide accumulation into a per-zone measure and restored a meaningful comparison across controller sizes. Worst-zone checks still remained important so an acceptable average could not hide a sacrificed space.
After that correction, the ten-zone controller recovered 6.34 percent savings while reporting comfort as hot degree-C-minutes per zone-day. A final controlled 15-zone confirmation run remained energy-positive at 5.26 percent. The result did not approach the threefold increase I had expected, but it showed that the expanded controller could operate without the reward scale silently changing underneath it.
ExperimentControlled scopeSavingsWhat it establishedRollback check5 zones6.16%Original result survived revised harnessInitial expansion10 zones−1.74%Cooling savings were erased by fan energyNormalized objective10 zones6.34%Comparable comfort scaling restored savingsFull-building confirmation15 zones5.26%Expanded controller remained energy-positive
04 / THE UNEVEN OPPORTUNITY
The top floor still bothers me
A top-floor-only test produced just 0.10 percent savings. A bottom-plus-top test produced 2.91 percent—less than the historical bottom-floor result by itself. Those numbers suggest that energy opportunity was not distributed evenly across floors under this cooling-only setpoint strategy.
I am not fully convinced that result tells the entire story. I expected the more exposed top floor to behave differently, especially overnight, when heat loss through the roof should allow zone temperature to fall farther below the baseline cooling setpoint. The behavior I expected did not appear clearly enough in the traces. That could reflect the envelope, thermal mass, schedules, air-system behavior, the evaluation windows or an implementation detail I have not yet found.
The honest conclusion is not that top floors contain no savings. It is that this model and control strategy did not demonstrate the opportunity I expected. I would want more targeted diagnostics before treating the floor-isolation result as settled physics.
The same policy did not have one savings number
Another result made the need for caution even clearer. I evaluated the same retained policy over three summer periods. Savings were 4.95 percent, 6.28 percent and 7.71 percent. The policy remained positive in all three windows, but the reported outcome varied materially with weather and evaluation duration.
A short evaluation can be useful for rapid comparison, but it is not enough to state expected annual savings precisely. Outdoor temperature, solar load, nighttime cooling opportunity and the length of the selected period all change the problem. Multiple windows—and eventually broader seasonal testing—are necessary before a result becomes decision-grade.
Figure 3. One retained policy remained energy-positive, but its measured savings varied across summer periods.
05 / THE BUSINESS LESSON
The business idea became harder—and more interesting
This experiment worried me more than I expected. Zone setpoints were supposed to be the low-risk entry point for Arduix: an existing BAS surface that could be adjusted gradually, bounded tightly and reversed immediately. If expanding that idea across the building did not expand the value, was the initial product simply too narrow?
The answer I took from the work was uncomfortable but useful. Arduix cannot become only a smarter schedule or a collection of independent thermostat resets. The larger opportunity is holistic supervisory control—coordinating zone setpoints with supply-air temperature and, over time, other system-level decisions so the controller accounts for how the equipment responds as a whole.
That direction is harder. It adds control surfaces, interactions, validation requirements and deployment risk. It also may be where the real technical moat exists. Issuing a setback is easy. Learning a coordinated policy that reduces total HVAC energy, protects every occupied zone, respects the existing BAS and can be rolled back safely is not.
The 'if' is real: if I can make that system work, validate it and close the gap between simulation and an operating building. But the experiment changed my view of the difficulty from a reason to stop into a clearer definition of the problem worth solving.
06 / WHAT THIS SERIES ESTABLISHED
What this series established
The first article explained why I built a simulation-based training system before allowing a learned controller near a real facility. The second showed how an apparent energy win failed when particular zones became too warm. This final article shows why scaling a controller is not a matter of copying the same action across more zones.
Together, the experiments point toward the kind of company I want Arduix to become: a bounded, transparent supervisory layer that learns how the whole HVAC system behaves, proves its decisions against repeatable energy and comfort gates, and works through the controls already in the building.
The most important result was not that one simulated policy saved a particular percentage. It was learning that local control freedom, system coordination and trustworthy evaluation have to be designed together.
METHOD NOTE
All percentages are historical EnergyPlus simulation results from specific evaluation windows, not measured field savings. The experiments used cooling-only, bounded zone-setpoint adjustments in one prototype Denver office model. Results should not be extrapolated directly to another building, climate or HVAC configuration.
