In this final blog of the series about room temperature optimization, we show how, by adjusting the room temperature setpoint, the power demand can be kept in check. We continue to explore the capability of this optimization in simulated examples. For context, read the complete series:

→ **Simulation — A Safe Playground for Smart HVAC Control**

→ **Towards a Zero HVAC-Energy Building and Beyond**

→ **Optimize Room Temperature to Utilize Thermal Insulation and Thermal Capacity**

→ **Optimize Room Temperature to Based on Chiller Efficiency**

In this example, when the room temperature is optimized without demand ceiling, the peak power is in the afternoon when the Outside Air Temperature (OAT) is highest. Taking demand ceiling into account, the optimization tries to keep the peak power below 70 kW. This is achieved by precooling the building and then drifting the room temperature during the time of peak power. Note that the simulated peak power is actually slightly above 70 kW. This is due to the difference in sampling rate between simulation and optimization.

In this example, when the room temperature is optimized without demand ceiling, the peak power is in the morning —this is the result of optimizing for the Time of Use (TOU) tariff, (see **Towards a Zero HVAC-Energy Building and Beyond**). Taking demand ceiling into account, i.e., trying to keep the peak power below 70kW, the optimized room temperature setpoint is similar to Example 1. Both, examples 1 and 2, are successful in keeping the power demand in check. The morning cooling power in this example 2 is more than that in example 1 due to the additional TOU tariff. Note that the very sharp power peak at the start of the second day, which is not reduced, is an artifact of this simulation.

In this example, there is a Demand Response (DR) event from 1pm to 3pm. Taking this into account, the optimization precools the building just before the DR event. This is done in order to drift the room temperature and drop power consumption during the DR event.

This blog concludes our series on ** Room Temperature Optimization**. Here are a few take away points:

- Our optimized room temperature setpoint profile is not generated from a fixed set of rules but is the result of some mathematical (i.e., numerical) optimization (for example, constrained optimization, dynamic programming, and reinforcement learning.
- As a control strategy, there are many goals to achieve. In fact, each example in our blog series is a specific goal. As a mathematical optimization problem, there is only one cost function (a single number!) that must be affected by each of our goals.
- Before room temperature can be optimized in this way, we have to obtain a dynamic model that can map a room temperature profile to the corresponding power profile. This dynamic model can also be used for simulation. In fact, each iteration of our optimization can involve a simulation of a certain time period.
- As a control strategy, we are
*not*implementing a feedback control loop to achieve a specific room temperature setpoint. Instead, we are generating the room temperature setpoint itself, i.e., we are optimizing the most important goal of an HVAC system! - As a mathematical optimization problem, it should not make a difference in the result whether we pick ZT as our optimization variable or any other variable that has a deterministic relationship with ZT through the dynamic model, for example, the HVAC load. The only difference is in convenience in expressing certain constraints.

During testing and demonstrations, like we do here, we can go through each goal of our control strategy, verifying or showing that they are being achieved. In a real application, the optimization will try to achieve all these goals at the same time or balance the relative importance between them through the formulation of the cost function. For instance, taking example 3 further, the optimization can automatically combine a demand ceiling and a DR event, in which case, the precooling before the DR event can be done more gradually.

*Dr. Rui (Ray) Xu is Data Scientist at BuildingIQ. During his career, he has encountered many challenges in the transfer of human knowledge into machines, the interpretation of results of algorithms into human intuition, and the verification of evolving strategies. This experience has helped him to solve some of the most difficult and interesting problems in the industry. He describes himself as a bit quiet but also very energetic and assertive when there is a mathematical, simulated and/or experimental proof behind the scenes.*