# How to Implement a Delay in Your Thermostat Simulation

June 30, 2016

Thermostats are used in most homes for controlling furnaces and air conditioners to maintain a comfortable interior temperature. A simple thermostat controlling a heater will have on and off setpoints. Such a control scheme is easy to implement within COMSOL Multiphysics using the Events interface, as presented in a previous blog post. Today, we will expand this technique to include a delay, a time lag between turning the heater on or off, in a thermostat simulation.

### Why Thermostats Use a Delay

The typical home thermostat for your furnace or heater has two temperature setpoints:

1. On, at which the heat is turned on at the maximum possible rate
2. Off, at which the heat is turned off

In practice, you may only directly control one of these setpoints, with the other setpoint automatically set to a few degrees different. Such a control scheme can be modeled with the approach developed in a previous blog post on thermostats. Today, we will include a time delay between switching the heater state in our thermostat simulation.

A delay can be implemented for many reasons, but one of the main reasons is to prevent short-cycling of the heater. Turning a device on and off repeatedly can lead to excessive wear on the system components, which will incur repair costs that we want to avoid.

There are various different delay schemes that we can use to prevent short-cycling. One common approach is to maintain the heater in either the on or off state for some defined minimum time before switching. Let’s look at how this control scheme is implemented within COMSOL Multiphysics.

### Implementing a Thermostat with Delay in COMSOL Multiphysics

Let’s suppose that you have a thermal model of a house or any other system wherein you want to control a heater using a thermostat with a delay. Within such a model, you can choose one point as the location of the thermostat temperature sensor, as described in our earlier blog post on modeling thermostats. As previously mentioned, we will use the Events interface to control the on/off state of the heater in our model.

A thermal model of a house. The thermostat monitors the sensor temperature and controls the heater’s on/off state.

Before we get to the implementation, let’s write out exactly how we want our thermostat to work. We have a thermostat with an upper and lower setpoint and we want the heater to maintain its current state, either on or off, for a specified delay time. We can write this as two separate statements:

1. If the heater has been in the off state for more than the specified delay time and if the temperature is below the lower setpoint, then turn the heater on.
2. If the heater has been in the on state for more than the specified delay time and if the temperature is above the upper setpoint, then turn the heater off.

These two statements can be implemented within the Events interface. We simply need to introduce a way to track the time that has elapsed since the last switching of the thermostat. The screenshots below show how to set up these conditions.

The Discrete States interface defines two discrete variables that determine the heater state.

The Events interface contains several features, starting with the Discrete States interface shown in the screenshot above. Two discrete variables are defined: `HeaterState` and `TimeOfSwitch`. The `HeaterState` variable is initially one, meaning that at the start of the simulation, the heater is turned on. This variable is used within the Heat Transfer in Solids interface as a multiplier on the applied heat load. To turn the heater off, the `HeaterState` variable is set to zero instead. The `TimeofSwitch` variable stores the time of the last switching event. For this problem, the initial value is zero, which means that at ` t=0`, the heater state was switched.

These two Discrete State variables are only changed when an event is triggered, and for this to happen, we need to check the elapsed time since the last switching event, and we need to check the temperature of the sensor against the upper and lower setpoints. This is done with the Indicator States interface, as shown in the screenshot below.

The Indicator States interface defines three different indicators that will trigger an event.

We can see in the above screenshot that three different indicators are tracked during the simulation. First, the `TurnOn` indicator evaluates the expression `T_bot-T_s`, which will go from negative to positive when we want to turn the heater on, where `T_bot` is a Global Parameter. The variable `T_s` is the sensor temperature and is defined using a Point Integration Coupling and a Variable Definition, as described in our earlier blog post on thermostats. Similarly, the `TurnOff` indicator evaluates ` T_s-T_top` and goes from negative to positive when we want to turn the heater off.

The `OkToSwitch` indicator evaluates `t-TimeOfSwitch-Delay` and goes from negative to positive after the heater is either in the on or off state for longer than the specified delay time, where ` Delay` is also a Global Parameter. These discrete and indicator states are used to trigger two Implicit Events, as shown in the following screenshots.

The first Implicit Event controls when the heater is turned on.

In the above screenshot, the first Implicit Event is used to turn on the heater. The Event Condition is: `(OkToSwitch>0)&&(HeaterState==0)&&(TurnOn>0)`. This logical condition can be read as: If the time since the last switching event is greater than the specified delay time, and if the heater is currently off, and if the sensor temperature is below the turn on setpoint, trigger an implicit switching event. When this event is triggered, the solver is restarted and reinitializes `HeaterState` to one, which turns on the heater. Additionally, `TimeOfSwitch` is reinitialized to ` t`, the current time. These two variables will remain unchanged until another implicit event is triggered.

The second Implicit Event controls when the heater is turned off.

The second Implicit Event, shown above, is almost identical to the first, but instead triggers a turn-off event. When the condition `(OkToSwitch>0)&&(HeaterState==1)&&(TurnOff>0)` is satisfied, this event reinitializes `HeaterState` to zero and ` TimeSinceSwitch` to the current time.

You may ask yourself why, in these two implicit events, we check if the heater is off before triggering it to turn on (and similarly check if the heater is on before we trigger it to turn off). This additional check is done to prevent any events from getting triggered and reinitializing `TimeOfSwitch` too often. The system may naturally (due to some change or fluctuation in the other boundary conditions) get into a state where the sensor temperature goes above the upper setpoint without any heating. Or, the sensor temperature could stay below the lower setpoint even though the heater is on. We do not want such cases to result in any events being triggered, hence these additional checks.

With these features as just described, we have implemented our thermostat with delay between switching. Before solving, make certain that the initial values of the Discrete States, the `HeaterState` and the ` TimeOfSwitch` variables, are appropriate for the initial heater state, and the last switching event. Also keep in mind that you may need to adjust the Event Tolerance, as demonstrated in our previous blog post on thermostats.

Let’s now look at some results.

The thermostat with delay can switch only every five minutes. The horizontal dashed lines represent the thermostat setpoints.

In the above plot, we can observe the thermostat delay behavior. The sensor temperature is initially below both setpoints and the heater is switched on at the time of zero. The system takes about seven minutes for the sensor temperature to reach the upper setpoint, at which time the heater turns off. The system starts to cool down quite rapidly, but the thermostat cannot switch back on until five minutes have elapsed. The thermostat temperature dips below the lower setpoint before the heater switches back on. After the heater is switched on, the system temperature rises above the upper setpoint, again due to the five-minute switching delay time. We can observe this over- and under-shoot behavior repeating in time.

### Closing Remarks on How to Implement a Delay in Your Thermostat Simulation

The technique we’ve outlined here will enable you to implement a thermostat model with a delay between any switching events and is representative of many real control schemes. The key difference for implementing a delay in your thermostat simulation versus a thermostat without delay is the introduction of an additional Indicator State variable that keeps track of the thermostat switching time.

Of course, this approach is useful far beyond just temperature control. Within COMSOL Multiphysics, we can use the Events interface whenever we solve a transient problem.