HVAC Overview

The main idea behind altering the temperature in a structure is to either put heat in or take heat out. Or, to put it another way, cold is just the absence of heat, and we can alter the amount of heat in a system to achieve a particular temperature. Adding heat to an environment can be accomplished with a furnace of some sort (natural gas, propane, oil, wood, or coal), electric heating elements, or solar energy. In a heat pump system the heat in the outside air is extracted and put back into the structure, which is similar to running an A/C unit in reverse. To remove heat from a structure, it is extracted using a refrigeration system that employs the condensation and evaporation cycle of a refrigerant fluid (ammonia, Freon, or any one of a number of modern coolants). The inside heat is absorbed by the refrigerant fluid, which then transfers it to the outside in a closed-cycle system. Some large-scale cooling systems use chilled water to achieve the same result, but the physical plant (the equipment and the building to house it) tends to be large and expensive to operate, so these types of systems are usually found only in university buildings, high-rise office structures, hospitals, and other large facilities. Chilled water systems aren’t commonly used in residential settings outside of large apartment buildings.

In many residential settings the heating and cooling are handled by two separate systems, but in other cases the heater and air conditioner may all be in the same large cabinet situated on the roof or along the side of the house. A heat pump does both heating and cooling, depending on how it is configured at any given time, and often consists of two units, one inside the house and one outside. In any case, in a conventional thermostat there will usually be a switch to select automatic or manual fan operation, and another to select the mode (heating, cooling, or off). A dial or lever sets the target temperature, or setpoint. The entire system, which incudes the heating unit, the cooling unit, and the thermostat, can be referred to as the heating, ventilation, and air conditioning, or HVAC, system. (Actually, the term HVAC is most often heard when referring to large commercial systems, but I will use it here because it’s more convenient than writing “heating and air conditioning system.”) With the possible exception of an active air-exchange ventilation function, a residential HVAC system does everything the large system can do, just at a smaller scale.

An important thing to note is that most HVAC systems can and do operate as closed-loop circulation systems. In other words, they work by continuously recirculating the air in the structure. While some systems might have the ability to draw in outside air or exchange inside and outside air (the V in HVAC), some don’t, and as a result the smell of last night’s burned dinner will tend to linger for a while before it finally dissipates. This is also why many homes have a distinct smell unique to that residence. As a child I noticed that the inside of a neighbor’s house always smelled like fried chicken in the summer when they ran their A/C, so I assumed that they really liked fried chicken. I never did learn the actual source of that peculiar smell.

Temperature Control Basics

Temperature control involves controlling the subsystems that will either heat or cool an environment to achieve a specific temperature (setpoint). In most cases this is an all-on or all-off type of operation; there are no intermediate heating or cooling rates in most residential HVAC systems. I say “most” because it’s possible that someone, somewhere, has a variable-output resistive heater system, but I’ve yet to see anything like that outside of a laboratory or industrial setting.

The “all-or-nothing” nature of an HVAC system means that the actual indoor temperature will never be exactly at the setpoint, except for brief periods as it either falls or rises. For example, let’s assume that we’re running the air conditioner, with a target setpoint of 72 °F (22 °C). If we were to record and plot both the inside and outside temperatures over the course of a day we might get something like Figure 12-2 (this is not real data, of course, it’s just for illustration purposes).

Figure 12-2. Temperature plot over the course of a day

In Figure 12-2 we can see where the air conditioner is active because the interior temperature drops. Early in the day it doesn’t cycle (turn on and turn off) as often as happens later in the day. It takes time for the heat outside to work its way through the structure, and the better the insulation is, the longer it takes for the inside to start to warm up. Later in the afternoon, the air conditioner is working hard to keep the inside at the setpoint temperature. Things don’t start to slow down until later in the evening as the outside temperature drops.

A controller with only two states, on or off, is called a hysteresis controller. It is also known as a bang-bang controller. The amount of hysteresis in the controller determines how often the cooling or heating equipment will turn on and for how long. You can think of hysteresis as the lag between when a system turns on, or turns off, based on a setpoint value somewhere in between. A physical example of this is the snap-action of a three-ring binder. It takes some effort to open the rings, and again to close them, but once in the open or closed state the rings will stay that way.

Figure 12-2 is estimated, but it is representative of the effect of a conventional thermostat on the temperature in a typical residential structure. When the inside temperature reaches about 73 °F the air conditioner is powered on, and it continues to run until the temperature drops to just below 71 °F. That means there is about 2 degrees of hysteresis in this hypothetical system. This range is referred to as the “hysteresis band” (actually, the hysteresis band in this system is too tight, and the A/C is cycling far too often later in the day).

Each on/off action of the HVAC system is referred to as a cycle. Figure 12-3 shows what happens when the difference between the on and off points becomes smaller (less range between H_max and H_min, which define the hysteresis band). The system is able to maintain the setpoint temperature better with a tighter hysteresis, but at the expense of cycling the power much more often. We would ideally want to make the hysteresis band as wide as possible, because each time the heater or A/C unit cycles brings it one step closer to wearing out and failing. It also drives up the electric bill.

Figure 12-3. Effect of hysteresis

While the 5° hysteresis band is more energy-efficient and doesn’t beat up the equipment with as much cycling as the 3.5° band, it also means that the actual temperature can swing as much as 7° between hot and cool. (Remember that these graphs are illustrative, and do not reflect real data.)

There are multiple factors that affect how often a heating or cooling system will cycle, the most obvious being how quickly heat is being removed when running the A/C, or how quickly heat is being introduced when running the heater. Less obvious, but also important, are things like humidity and interior air flow. As the humidty increases air will retain more heat, which can help when heating. An A/C unit also acts as a dehumidifier, condensing and removing moisture from the air passing over the cold evaporator coils in the system, and dry air evaporates sweat more readily, which allows us to cool off faster. Stagnant air (that is, air that’s not moving unless the HVAC system is active) can lead to “hot spots” or “cold spots” in a structure, and it’s possible that the thermostat will end up regulating just one part of an interior space if the rest of the air isn’t passing by it.

Ideally a temperature control system should be able to sense the temperature in all parts of a structure, but in the real world this often isn’t the case. There will invariably be a room that gets direct sunlight most of the day, while other areas are shaded, or perhaps a room that has poor air flow. So even though the thermostat is doing its job and working to keep the temperature in the immediate area where it is located at the desired setpoint, other parts of the structure will not be heated or cooled correctly. Just moving the air around can help avoid this, and monitoring the humidity will also help to determine when to run the fan or when to use the heating or cooling. Running the fan alone is a lot less expensive than running the heater or A/C unit.

Smart Temperature Control

The main idea behind a smart thermostat is to reduce the amount of energy wasted and achieve a more even temperature distribution within the structure. This might involve altering the cycle time (i.e., adjusting the hysteresis), only running the system when someone is in the house, altering the setpoint based on the time of day and/or day of the week, and taking advantage of the built-in fan in the HVAC system.

Some common features of modern commercial digital thermostats include adjustable cycle times, automatic heating/cooling mode changeover, and day-by-day programmability. We’ll briefly review these capabilities to see which ones make sense for a small project like the one described here.

Adjustable cycle times can be used to reduce frequent on/off heating or cooling cycling. This can occur when the temperature is at or near the setpoint and varies just enough to cause the heater or air conditioning (A/C) to turn on. What it does, in effect, is increase the hysteresis in the system, so that it takes longer to cycle when the temperature is hovering around the setpoint, but the amount of hysteresis is reduced when the temperature rapidly changes one way or the other over a short period of time.

Auto-changeover allows the system to switch between cooling and heating as necessary. If, for example, you are experiencing warm days and cold nights, then the thermostat will automatically switch from cooling to heating at night to maintain a relatively constant average indoor temperature. The Arduino thermostat will support auto-changeover and adjustable cycle times as well.

Profile scheduling is a big feature with smart thermostats. Most programmable digital thermostats have the ability to schedule heating or cooling for specific days of the week, so if your house is empty during weekdays you can trim some expense from your electric bill by not running the heater or A/C when there is no one home to appreciate it. By the same token, some models allow you to automatically “dial down” the heating or cooling at night, while the home’s occupants are asleep. Our controller will have the ability to create profiles (also sometimes called programs) for day, night, and weekend operation.

A digital thermostat can be packaged in a slick-looking enclosure with a high-tech glowing faceplate and a numeric display behind frosted plastic, but that’s just marketing razzle-dazzle. It can also be housed in a commonly available plastic enclosure. It may not look as flashy and high-tech as the commercial units, but that has no bearing on how well it works, or how easily someone can use it. You can save money and time by using a low-budget enclosure for this project, and what I decided to use is definitely low-budget.

Functionality

The Arduino thermostat has three basic functions: heat, cool, and fan. Figure 12-4 shows a block diagram with the primary components. The secret to success lies in how those basic functions are used to achieve the most efficient operation.

A rotary encoder will be used for various functions such as setting temperatures, stepping through days of the week, and so on. The LCD shield also has a set of pushbuttons, but these will not be used.

Many older HVAC systems have only four wires, while some newer systems also have auxiliary power wiring. The Arduino thermostat can use this AC source if it is available if a small power supply is also mounted in the enclosure. For this version of the thermostat I will use an external wall power supply, or wall-wart. Ideally it would be better to draw power from the HVAC wiring, but many older systems don’t have a spare 24VAC line available.

Figure 12-4. Arduino thermostat block diagram

Figure 12-5 shows how a typical older thermostat might be wired internally. The actual internal details will, of course, vary from one type to another, but the basic idea is the same.

Figure 12-5. Typical old-style thermostat internal circuit

A key thing to note about this type of old-style thermostat is that the fan is wired so that it will always come on when either heating or cooling is enabled. It is not a good idea to run the A/C or the heater without the fan. In some systems the heater fan is separate from the A/C fan, and it will come on only when the internal temperature in the heater has reached a specific level.

Enclosure

For an enclosure, I’ve selected a plastic electrical junction box with a detachable cover suitable for wall mounting, as shown in Figure 12-6. After some finishing the box will be painted a neutral color to improve its appearance.

Figure 12-6. Arduino thermostat enclosure

Yes, the enclosure is really ugly. I won’t deny that. But for this project the main concern was wall mounting and having enough internal space for the components. The side mounting tabs will be removed and the front cover will be sanded and polished, which will help improve its appearance.

The controls are simple, with just an LCD display and a rotary encoder. It will all fit comfortably on the front cover panel. The planned layout of the front panel is shown in Figure 12-8.

The relay module will be mounted to the bottom of the enclosure, and the existing wires for the thermostat will enter through a hole in the bottom of the case. The RTC module will be mounted to the inside of the enclosure, and the DHT22 will be attached to the bottom so it will be exposed to the ambient environment. I elected to mount the DHT22 this way rather than put it inside because I didn’t want to drill an array of holes in the enclosure for air flow. An alternative would be to make a square hole just large enough for the DHT22 so it can mount inside but still have access to the outside air. Four screws will hold the thermostat to the wall.

Figure 12-7. Arduino thermostat schematic

Figure 12-8. Arduino thermostat front panel layout

Schematic

There is no significant difference between the prototype and the final unit, so there is only one version of the schematic. The prototype is electrically identical to the final thermostat, but it uses an Arduino Uno rather than a Nano board (the AVR MCU is the same for both), mainly because that is what is mounted in the prototype fixture.

Notice that every single pin on the MCU is in use. The Arduino programming interface, via D0 and D1, is shared with the rotary encoder. So long as the rotary encoder is not in use this will not create a conflict.

You may also notice that the analog inputs have been pressed into service as digital I/O pins. This is completely normal, and if you refer back to Chapter 2 and Chapter 3 you can see how the ATmega328 port used for analog input (the C port) is also a standard discrete digital I/O port. By referring to the pins as D14 through D19 we can access these like any of the other digital I/O pins. Of course, the analog inputs are now unavailable, but the thermostat doesn’t use any analog input (except for the A0 pin, which is used by the LCD shield), so it’s not a problem.

Software

This is a software-intensive project, but most of the software is involved with the user interface and the active profile. The actual control logic for thermostat operation is not all that complex.

On each iteration through the main loop the software will check for user input from the rotary encoder; update the current temperature and humidity data; and determine if the display should switch between screens, move to various settings, or change values. Interrupt handlers are used to capture the inputs from the rotary encoder. A high-level version of the software block diagram is shown in Figure 12-9.

Figure 12-9. Arduino thermostat software block diagram

The main function blocks in Figure 12-9 give an indication of what to expect in terms of actual source code. In addition to the Thermostat.ino main file, there will be source modules for handling user inputs using interrupts, processing schedules (daytime, evening, or weekend), and updating the display.

The first thing the loop checks is the switch (SW) on the rotary encoder. This is the signal that indicates that the user wants to do something. The pushbutton switch in the rotary encoder is used to move between screens and between the fields in a screen. The type of action is determined by how long the switch is held down.

The interrupt handlers for the rotary encoder switch and the A/B inputs set flags in the global variables module. The main loop examines these to determine what display update action to take, if any. The interrupt handlers are not shown in Figure 12-9. They will be covered in “Software”.

The block labeled “Heat/cool/fan control” is the actual control logic of the thermostat. As stated earlier, this is a discrete-state hysteresis controller, also known as a “bang-bang” controller. Figure 12-10 shows the relationship between temperature, time, and hysteresis range in a timeline format for an A/C system. For heating, the operation is simply the inverse.

Figure 12-10. Time, temperature, and hysteresis range

Another way of representing this is shown in Figure 12-11. This graph shows hysteresis as a function of temperature. The message of both types of graphs is the same: a bang-bang control system (such as a thermostat) coupled with an on/off actuator (the heater or A/C unit) can never precisely hold a specific temperature. The system will always be at some point between the high and low ends of the hysteresis range.

Figure 12-11. Effect of hysteresis on control system response

In a real system the rate at which the temperature increases or decreases will depend on the rate at which heat is being put into or taken out of the system, and how efficiently the heating or cooling equipment can add or extract heat. The upshot is that the heating and cooling times will almost never be the same, although both Figure 12-10 and Figure 12-11 might seem to imply that they are.

The thermostat’s control logic is shown in Figure 12-12. Notice that the heating and cooling are simply inverse operations. In an old-style electromechanical thermostat the H (hysteresis) term is established using a set screw on the bimetallic coil assembly. In software we can set this dynamically if we wish.

Figure 12-12. Thermostat control logic for heating and cooling

User Input/Output

The control input consists of a single rotary encoder. This might seem odd, but the encoder also has an integrated switch that is engaged when a user presses on the knob. The switch is used to move between display configurations (or screens, as I’m calling them). Each screen contains fields that display data or settings, and the rotary encoder is also used to move between the fields in each screen. The length of time the pushbutton switch in the rotary encoder is held down determines which action the software will take. A short press is a selection, and a long press commands the software to move to the next screen.

The display is the same type of 16 × 2 LCD used with the signal generator in Chapter 11. In this project it is premounted on a shield PCB. This simplifies the internal wiring. The LCD backlight is not enabled unless the control inputs are active. The small pushbutton switches on the LCD shield are not used, but they could be if you are willing to drill more holes through the front panel and find some type of extensions that a user could press. I elected to just ignore them.

Normally two primary screens will be displayed that alternate when the control inputs are not active. The first shows the current temperature readings, the setpoint, the operation mode, and the active profile (if any). The second screen shows the current date and time. Figure 12-13 shows the screens during normal operation. The symbols ^, v, and – are used to indicate if a reading is increasing, decreasing, or holding steady, respectively, relative to the previous reading.

Figure 12-13. Normal operation screens

The fields shown in Figure 12-13 are defined in Table 12-1. In the second screen the “END” field shows the time at which the current profile will end.

The screens shown in Figure 12-13 are purely informational with no modifiable fields. The temperature units may be either Celsius or Fahrenheit. The default is Fahrenheit. I elected to use 24-hour format for the time. It can be modified to accommodate 12-hour format (AM/PM) without too much effort.

The settings screen, shown in Figure 12-14, allows the user to enable or display the profile, and if the profile is disabled the user may manually adjust the temperature setpoint, temperature scale, hysteresis, and operation mode.

Figure 12-14. Settings screen

The settings screen is the primary control point for the thermostat. It is intentionally arranged to appear only when specifically invoked by a user. The fields used in the settings screen are listed in Table 12-2.

The main form of preset control for the thermostat is the user-defined profiles. Profiles are defined with the screen shown in Figure 12-15.

Figure 12-15. Profile editing screen

There are profiles for daytime, nighttime, and weekends; these are labeled D, N, and W, respectively. Rotating the encoder when the profile editing screen is first selected will step through the three profiles. Each profile has a start time and end time. In the case of the weekend (W) profile, the default start time is Friday at midnight, and the end time is Sunday at midnight. If the end time of a profile overlaps the start time of another, then the end time of the preceding profile always takes precedence. The fields used in the profile editing screen are listed in Table 12-3.

Navigating through the screens and fields does require some learning, but by using the length of the rotary encoder switch press and a tree structure the user can navigate the primary screens and the fields without getting lost. Figure 12-16 shows how the screens and fields respond to either a long or a short button press.

Figure 12-17 shows all four screens in one view. This might make it easier to visualize how the screens are arranged.

A long button press is defined as 1 second or longer. A short button press is 500 ms or shorter. The software uses an interrupt and a counter to monitor the button hold-down time.

Control Output

The control output consists of a quad relay module with four independent SPDT relays. It incorporates drivers for the relays and PCB terminal blocks, so connecting it to the existing thermostat wiring is straightforward. It can be seen in Figure 12-18. The common line is routed through the fourth (lower right in the diagram) relay.

In the block diagram in Figure 12-4 you will notice that the common line from the existing HVAC system is also routed through one of the relays. This is a fail-safe measure. If the thermostat loses power the relay with the common line drops out, and none of the other functions of the HVAC can be enabled. All the external HVAC control voltage lines, including the common return, are connected to the C and NO (common and normally open) terminals of the relays.

DHT22 Sensor

For temperature and humidity sensing we will use the DHT22 device, which is the same device used with the GreenShield in Chapter 10. In the final version the DHT22 sensor will be connected to the Arduino Nano with leads attached to screw terminals. The pinout of the DHT22 is shown in Figure 12-19.

Figure 12-19. DHT22 sensor pinout

A 1K ohm pull-up will be used on the data line, as recommended in the datasheet (available from Adafruit, SparkFun, and other locations). In the prototype, the DHT22 will be connected using a small solderless breadboard block on the wood base, as can be seen in Figure 12-18.

Rotary Encoder

The primary (and only) control input is a KEYES KY-040 module (see Chapter 9 for information about KEYES modules) with a Bonatech rotary encoder, similar to an Alps EC11 part. The module is shown in Figure 12-20, and the pinout is shown in Figure 12-21.

Figure 12-20. Rotary encoder module

Figure 12-21. Rotary encoder module pin functions

The rotary encoder module circuit is simple, as shown in Figure 12-22. The encoder contains an internal switch that is engaged when the shaft is pressed in, and the three signal lines use 10K pull-up resistors. The pins labeled CLK and DT correspond to the A and B signals (respectively) found in most software examples and descriptions of simple quadrature rotary encoders.

Figure 12-22. Rotary encoder module schematic

The rotary encoder’s integrated switch is used to change between display screens, and also for various user-modifiable items on each screen. It and the rotary encoder itself are the only two control inputs. The internal switch is normally open.

Real-Time Clock Module

The thermostat needs to be able to keep time in order to determine which thermal profile to use. A real-time clock (RTC) module based on a DS1302 IC is used for this purpose. The RTC module is really nothing more than a carrier for the DS1302 IC, a crystal, and a battery. Figure 12-23 shows a schematic of the RTC module. The pinout is self-explanatory.

Figure 12-23. RTC module schematic

A library for the DS1302 is available from the Arduino Playground. The thermostat will use this rather than create a new library from scratch.

LCD Shield

The LCD shield, which can be seen in Figure 12-18 and is described in Chapter 8, is a common and readily available shield. It is the largest consumer of digital I/O pins on the Nano. In this application the shield was selected because it incorporates a potentiometer for contrast and a control transistor for the display backlight. It also connects directly to the underlying Arduino, thus eliminating wiring like that used in the signal generator in Chapter 11.

Source Code Organization

As with the other projects in this book, the source code is organized as a set of source files (see Table 12-5). These include the primary module with the setup() and loop() functions, a module for global variables, and the logic for controlling the HVAC functions in accordance with user-defined heating and/or cooling “programs.” The display module borrows from work already done for the signal generator in Chapter 11, and the interface module, tstat_iface.cpp, also includes the interrupt handler for the rotary encoder.

Software Description

The software can be divided into three functional sections: user interface, control logic, and display management. The user interface functions, contained in the source module tstat_iface.cpp, provide the functionality to read the rotary encoder and navigate the display screens. tstat_lcd.cpp contains the LCD display handling functions. The source module tstat_ctrl.cpp provides the functionality for temperature and humidity sensing via the DHT22 sensor, the controller logic, and the user-defined programs.

Various libraries are used with this project for the DS1302 RTC, the rotary encoder, time and date functions, and the AVR’s timer 1 peripheral. These are listed in Table 12-6. This is one of the nice things about working with the Arduino: if you need a library to use a particular module, sensor, or shield, chances are someone, somewhere, has taken the time to create it so that you don’t have to.

These libraries can be found in the Arduino Playground and on GitHub. Be sure to read the included documentation and the source code to gain a better understanding of what the code is doing and how to configure it if necessary. The DHT22 library is the same one that was used with the GreenShield in Chapter 10.

The file tstat.h contains the global definitions used by the other modules. These follow the pin assignments shown in Figure 12-7, illustrated in Example 12-1.

#define ROTENC_A    0
#define ROTENC_B    1
#define ROTENC_SW   2

#define LCD_D4      4       // Predefined by the LCD shield
#define LCD_D5      5       //
#define LCD_D6      6       //
#define LCD_D7      7       //
#define LCD_RS      8       //
#define LCD_E       9       //
#define LCD_LED     10      //
#define LCD_SW      A0      //

#define RTC_SCLK    11
#define RTC_IO      12
#define RTC_CE      13

#define RY1         15      // A1
#define RY2         16      // A2
#define RY3         17      // A3
#define RY4         18      // A4

#define DHT1        3       // Internal DHT22
#define DHT2        19      // A5, external DHT22

The function setup() in Thermostat.ino, shown in Example 12-2, initializes the LCD, displays some startup messages, checks the RTC module, and displays the first screen.

void setup()
{
    lcd->begin(16, 2);  // Set the dimensions of the LCD

    TitleDisp("Initializing...", "", 1000);

    lcd->clear();

    if (rtc->haltRTC())
        lcd->print("Clock stopped!");
    else
        lcd->print("Clock working.");

    lcd->setCursor(0,1);
    if (rtc->writeEN())
        lcd->print("Write allowed.");
    else
        lcd->print("Write protected.");

    delay (2000);

    // Setup time library
    lcd->clear();
    lcd->print("RTC Sync");
    setSyncProvider(rtc->get); // The function to get the time from the RTC
    lcd->setCursor(0,1);
    if (timeStatus() == timeSet)
        lcd->print(" Ok!");
    else
        lcd->print(" FAIL!");

    delay (1000);

    TitleDisp("Initialization", "complete", 1000);

    curr_screen = 0;
    Screen1();
    disptime = millis();
}

The loop() function in Thermostat.ino isn’t complicated, as you can see from Example 12-3. Most of the work takes place when the rotary encoder is in use and when the software is retrieving temperature and humidity data and executing the control functions in tstat_ctrl.cpp.

void loop()
{
    // Get current date and time from RTC
    RTCUpdate();

    if (input_active) {
        HandleInput();
    }
    else {
        // Toggle between screen 1 and screen 2
        if ((millis() - disptime) > MAX_DISP_TIME) {
            if (curr_screen) {
                Screen1();
                curr_screen = 0;
                disptime = millis();
            }
            else {
                Screen2();
                curr_screen = 1;
                disptime = millis();
            }
        }
    }

    GetTemps();
    SystemControl();
}

When the encoder is not in use the display will alternate between screens 1 and 2, which show the current conditions and operating state and the date and time, respectively. When the encoder is used the input_active flag is set to true, and it will remain true until the user returns to screen 1 by pressing the encoder knob to engage the pushbutton switch. Notice that the system control is still active while the input screens are in use.

Testing

Testing is a three-step process, and this section applies to both the prototype and the final unit. The first step involves setting the date and time in the RTC. This is done by changing to the time and date setup screen using the encoder pushbutton. After returning to the main displays, the correct time and date should appear. The next step involves setting the target temperature, the hysteresis range (the C parameter in the display), and the operation mode. I started by verifying that I could manually enable the system fan, and then entered a temperature setpoint and set the mode. You will want to watch the display and verify that the system stops heating or cooling when it has reached a temperature equal to the setpoint plus or minus one-half of the cycle (hysteresis) range.

Lastly, you should step through the profiles and set each one up the way you think is best for your situation. Remember that a conflict between the end time of one profile and the start of another is resolved by honoring the end time of a preceding profile, not the start time of a subsequent profile.

You should keep an eye on the operation of the thermostat over a period of a couple of weeks. It will probably require some fine-tuning to get the times and setpoints established for the most efficient operation. If you have built a GreenShield you can use it to log the temperature and humidity to capture performance data for the thermostat. A simple Python script will work nicely to query the GreenShield at regular intervals to collect data.

Assembly

The final assembly mainly consists of mounting the components in and on the enclosure. But before that, the enclosure itself went through some changes. The embossed lettering was sanded off the top cover, the side mounting tabs were removed, and holes were cut and drilled for the display and the rotary encoder. Holes were also drilled into the bottom of the enclosure for mounting screws and the existing heater and A/C control wires. The case was painted a nice neutral shade of ivory after all the sanding, drilling, and cutting was done.

I used a screw terminal prototype shield to hold the Nano board, and wired the Nano’s pins to the appropriate terminals and pin headers. Figure 12-24 shows the topside view of the Nano’s prototype shield, along with the LCD shield, the rotary encoder, and the RTC module. The RTC module will be mounted to the inside of the enclosure.

Figure 12-24. Nano prototype board and other top cover components

As I elected to keep all the wiring on the top of the prototype shield, the bottom of the shield is nothing but soldered pads. I used the smallest gauge of insulated stranded wire that I had available (28-gauge 7-strand) without resorting to wire-wrap wire. Solid 30 AWG wire with Kynar insulation is great for wire-wrap construction, but it can be less than ideal for something like this.

The big advantage of the screw terminal prototype shield is the ease with which wires to or from other components may be connected to the terminals. In the case of the thermostat this includes the DHT22 sensor, the real-time clock module, the relay module, and the rotary encoder.

Figure 12-25 shows what the enclosure looked like after its makeover. The LCD shield and the rotary encoder are already mounted. What isn’t shown is the DHT22 sensor, which is mounted on the outside of the bottom of the enclosure. You might also notice that the cover screws aren’t installed.

The small hole to the upper left of the LCD window is an access hole for the trim potentiometer on the LCD shield to set the display contrast. The LCD window will get some edge trim as the very last step, and a clear plastic cover might also be a good idea. Yes, it looks like something from an industrial plant, but as I said before, how it looks has no bearing on how it works. The gold knob is there (if you can see the image in color) because that was the only knob I had available at the time that didn’t have a pointer molded into it.

Figure 12-25. Almost finished thermostat enclosure

The quad relay module is mounted to the bottom of the enclosure. The RTC module is mounted to an interior side of the box. Figure 11-25 shows how things are arranged in the enclosure. The existing HVAC wiring is brought in through an access hole in the bottom of the enclosure. Note that the hole is offset vertically from center to allow clearance for the relay module.

It’s a tight fit, to be sure, but it does all fit. There are still several steps necessary before closing it up and turning it loose:

1. Locate the mounting screw locations on the wall and drill holes.

2. Pull the existing HVAC control wires through the bottom hole and mount the enclosure to the wall.

3. Connect the HVAC wires to the relay module.

4. Connect the power source and check the display.

5. Attach the cover to the enclosure.

Assuming that the software was already loaded onto the Nano, the thermostat should now be operational. There is no power switch, so it will start functioning as soon as the power is connected. The display backlight should remain active for 15 seconds after power is applied, so you may need to turn the encoder knob slightly if it has timed out and turned off.

Figure 12-26. Thermostat internal components

The enclosure comes with a rubber gasket, which you can use if you think it is necessary. I used it simply because it allows for a snug fit of the cover and gives a bit more space inside for the components, but I’m not worried about rain getting into the unit.

Testing and Operation

Testing consists of using the encoder to step through the display screens and verify that the long and short switch sensing is working correctly. You will need to set the parameters again, since loading the software doesn’t load the EEPROM, just the flash program memory. If the installed unit appears to operate correctly then you can start setting it up for your particular environment and preferences.

I would suggest something simple to begin with. Just controlling the heating or cooling is a good place to start. After you are satisfied that the unit is working as it should, then you might want to try setting up daytime/nighttime profiles and see how that works. As you gain more experience with the unit you can incorporate the humidity and cycle time settings. A device like this requires some amount of “tuning” to get it set so it will integrate effectively with your environment.