Open Source Projects

« Back to Homepage

Tweet

Smart Buildings are Thrifty Buildings

Once the realm of science fiction, building automation is expected to reach a market value of approximately $100 billion in five short years. That’s up from just over $50 billion in 2016 according to a MarketsandMarkets report. The explosive, $10 billion per year growth in the building automation market is being fueled by an unprecedented availability of inexpensive sensors, a proliferation of nearly ubiquitous Internet connectivity, and easy-to-use yet powerful microcontroller platforms.

For facility managers, one of the major appeals of Building Automation Systems (BAS) is monitoring and controlling Heating, Ventilation, and Air Conditioning (HVAC) systems. Energy costs associated with heating and cooling a building are a major component of a facility’s operational and maintenance costs. While new construction has the advantage of incorporating the latest in HVAC and control technologies from the get go, existing facilities can still take advantage of emerging building automation systems through retrofits. For engineers and facilities professionals looking for more information on specifying building automation systems with respect to HVAC systems, the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) publishes ASHRAE Guideline 13-2015, Specifying Building Automation Systems.

To demonstrate just how easy it is to connect building systems to the Internet of Things (IoT), we are going to design a solution that allows us to retrofit a manual damper, one you might find as part of a HVAC system, with automated intelligence (Figure 1). By doing so, we can help reign in the energy costs associated with heating and cooling a building. Dampers allow us to adjust the airflow of an HVAC system so air only goes to the spaces that need heating or cooling at any given time.

Figure 1: Mockup of an HVAC Damper and the embeded hardware needed to add intelligence.

In this article, we will look at some of the products available to help you quickly prototype a custom solution for your existing HVAC ductwork system. Specifically, we will leverage the TE Connectivity Weather Shield, a device that incorporates five different sensor packages to monitor environmental conditions such as temperature, humidity, and atmospheric pressure. Then, using an ESP8266-based Wi-Fi solution, we will wirelessly transmit our weather data to the cloud where it can be stored and distributed to other smart devices. For the purposes of this demonstration, we will leverage temperature data to remotely control a damper that will be retrofitted with a microcontroller and servo to automatically open and close a damper inside the ductwork.

Materials

By utilizing Commercial Off-The-Shelf (COTS) components, we can rapidly prototype a working system using just a handful of components. Once we have proven the concept of operations, custom hardware could be built to help drive down the unit costs of our solution. Thus, our bill of materials for this project is listed in Table 1.
(or click here for our pre-built project shopping cart over at Mouser.com)

Project Overview

This project presents a two-part solution for a temperature control mechanism that will be automating an air duct damper, thus controlling the airflow into various rooms in a building. The first part is our weather sensor package that will monitor the environmental conditions in our spaces, including temperature, humidity, and atmospheric pressure (Figure 2).

Figure 2: Board stack for sensor package. From bottom: Arduino, Wi-Fi Shield, TE Connectivity WeatherShield

The sensors communicate with our microcontroller over the I2C bus. Once the sensors have digitized and transmitted weather data to the microcontroller, we can perform additional work on the data. For example, we could convert temperature measurements from Celsius to Fahrenheit if so desired. Once we are satisfied with our data format, we can send it to a cloud-based IoT backend using the ESP8266 hardware and an HTTP-based RESTful API. Of note, the latest update to BACnet standard (BACnet Standard ASHRAE 135-2016) includes support for such RESTful HTTP-based web service interfaces.

At the heart of the weather sensor shield are the following five sensors:

• HTU2xD(F) (Temperature and Humidity)
• MS5637 (Temperature and Pressure)
• MS8607 (Temperature, Humidity and Pressure)
• TSYS01 (Temperature)
• TSD305 (Temperature and Contactless Temperature)

The second portion of the system is a control unit for the damper. It will contain a second wireless microcontroller platform, Adafruit’s Huzzah Feather, which is equipped with a servo motor and the appropriate mechanical linkages to the manual hardware of the damper (Figure 3).

Figure 3: The Huzzah Feather receives weather data and makes informed decisions on controlling HVAC dampers

The Huzzah will reach up to the Ubidots server and request the necessary data, in this case temperature. The demonstration code shows a single set point temperature (74°F) for determining whether to open or close the damper. It might be desirable to include two different set points so that as the ambient temperature fluctuates above and below the set point temperature that the damper is not repeatedly opening and closing. For example, open the damper when the temperature reaches 78°F and close it when it reaches 72°F.

The Build

One problem that can sometimes arise from using pre-built breakout boards is that there can be I/O pin hardware conflicts. This just happens to be the case for this project. However, it is possible to cleverly hack a solution together so that we can get the prototype up and running. If this were to become a finished product, the engineering team would likely create a custom circuit board and design out the pin conflict.

For this particular project, both the WRL-13287 Wi-Fi Shield and the TE Connectivity Weather Shield have hardwired GPIO pin D9 for their own needs. For the Wi-Fi shield, pin 9 is being used as the TX pin for the software-based serial port that connects the development board to the ESP8266 SoC. On the weather shield, the same pin is part of a chip select multiplexer design along with pins 10 and 11.

Looking through the software for both shields, it was decided to alter the weather shield code. From a software perspective, the chip select multiplexer inputs were moved from pins 9, 10, and 11 to pins 10, 11, and 12. The code change occurred in the file titled TEWeatherShield.cpp which is a part of the TE Weather Shield library. Then, on the physical weather shield itself, the male header for pin 9 was removed and jumper wire was inserted to connect pin 12 to pin 9. In the end, while the Arduino would toggle pins 10, 11, and 12 to cycle through the various sensors, the weather shield itself saw no difference. Removing pin 9 ensured that there would be no conflict between the two shields both trying to drive pin 9. The only other impact to the final design was that this solution necessitated the board stack to follow the strict order of Arduino dev board, Wi-Fi shield, and then the weather shield sitting on top (Figure 4).

Figure 4: Note that pin 9 on the TE Connectivity WeatherShield must be removed and a jumper wire is placed between pin 9 and 12.

The Huzzah has an operating voltage of 3.3V, but when powered via USB, it is possible to tap into the USB’s 5V via the V_USB pin. This allows us to power the 5V servo motor without a separate supply. The Pulse Width Modulated (PWM) signal wire of the servo can remain at 3.3V.

In the provided GitHub repository, we provide both a schematic and board layout that breaks out the Huzzah pins and provides some male header pins for easily connecting the servo to the Huzzah. One thing to note is that the GPIO pins of the Huzzah are not sequentially numbered; they are clearly labeled on the board itself, so be certain you are wiring to the correct pins. For this project, GPIO pin 2 is using to provide the PWM control signal to the servo.

Lastly, if you intend to mount this design permanently, we have provided STL files for enclosures that can be 3D printed to keep the electronic hardware protected (Figure 5).

Figure 5: STL files for the 3D printable project enclosure is available in the project repository.

Software

The software for this project was developed using Microsoft’s Visual Studio Code, an extensible code editor that supports a variety of languages including C/C++ and the derivative wiring language used in the Arduino IDE (Figure 6). Visual Studio Code offers more robust development features such as code completion and breakpoints. However, this project can be accomplished just as easily in the standard Arduino Integrated Development Environment (IDE) if so desired.

Figure 6: Visual Studio Code is a powerful code editor that adds professional programming features atop the standard Arduino IDE.

Libraries

First, we will grab the support libraries necessary to work with the chosen dev boards and shields. Thankfully, the hardware manufacturers for both the weather shield and the ESP8266 Wi-Fi shield provide the code on their respective GitHub repositories (Figure 7).

Figure 7: TE Connectivity provides all the needed software libraries on their GitHub repository.

The libraries we will be using include:

• TE Connectivity Weather Shield
• HTU2xD(F) (Temperature and Humidity)
• MS5637 (Temperature and Pressure)
• MS8607 (Temperature, Humidity and Pressure)
• TSYS01 (Temperature)
• TSD305 (Temperature and Contactless Temperature)
• ESP8266 Wi-Fi Shield

In addition to these libraries, we will also be using two standard libraries included as part of the Arduino IDE: SoftwareSerial.h and Servo.h.

Getting Some REST

RESTful APIs are an increasingly popular mechanism for allowing devices to communicate on the Internet, sans human involvement. For Web-based services, RESTful API is realized through HTTP methods such as POST, GET, PUSH, and DELETE.

In a nutshell, a RESTful API leverages what looks like a website address (URL) to exchange requests with a Web server. It is a simple yet elegant method to achieve autonomous communication between the Internet and the “Things” that comprise the IoT. Every Web service will provide their own API, but in general the format is fairly consistent. For this project, the Ubidots IoT backend service was selected (Figure 8). They have a well-documented API that is very easy to use. The documentation can be found here.

Figure 8: Ubidots provides for a simple yet powerful and inexpensive IoT backend.

In both devices, when uploading or downloading the sensor readings, the data itself is passed as a JSON message (JSON is short for JavaScript Object Notation), which is an open standard file format that has the benefit of being both efficient for digital transmission but also is humanly readable. For uploading the weather data to the Ubidots server, we use the POST method:

Where <TemperatureVariableID>, <PressureVariableID>, and <HumidityVariableID> would be replaced with a unique alphanumeric string for each variable that is generated by Ubidots for your particular account. <Your Token> will be replaced with a unique, account-based token from the Ubidots service. Think of the token as a random, very hard to guess account name. Lastly, <String Length of JSON Message> must be calculated for each message. It is the number of characters, including the letters, numbers, spaces, and special characters.

There are software libraries to parse JSON messages or a custom lightweight function can be created that is application specific. For embedded developers that are accustomed to total control of their device, RESTful APIs present a paradigm shift in that the API provider can (and often will) update their API occasionally. This means the embedded system developer must respond with firmware updates to ensure the devices and IoT backend can continue to communicate.

To download the temperature data into the servo-connected Huzzah, we use GET:

In this example, <Your Device Name> would be replaced with the name you created for your device on the Ubidots website. Also, the part of the GET request that reads “?page_size=1” means that we are only interested in getting the most recent sensor readings. If it read “?page_size=5” then the server would return the data from the five most recent sensor readings.

Use

To simplify the mechanical aspects of this design, we are using a simple linkage that translates the move of the servo arm directly to the manual lever of the damper.

The sensor device can be placed anywhere in the room since it is a standalone device. This is helpful so that it can be placed away from air registers or windows that might inadvertently affect sensor readings for the purpose of regulating room temperature.

The Huzzah is powered with a standard micro-USB DC power supply—the same kind that power many of today’s smartphones and other portable electronics. The weather shield stack is powered with a 5V DC barrel jack power supply. Power supplies that provide sufficient power are included in the project shopping cart for your convenience.

Of course, this project could be altered to fit any number of scenarios or system configurations. For example, instead of opening and closing dampers, the system could be repurposed to open and close window blinds based on temperature. Or this could be done in addition to the damper control by simply adding a second control unit. The possibilities are endless.

Other Resources

Are you interested in building this project yourself or using it as a starting point for further development? If so, we have put together a few resources to help.

• Building Automation GitHub
• YouTube Video
• Mouser.com Shopping Cart

If you do build this project or make modifications to it, we would love to see the results. You can find us on Twitter, Facebook, and Google+.

Michael is an embedded software and IoT consultant with 30 years as a software engineer and technical manager. He previously worked at Freescale Semiconductor, where he was responsible for the Freescale Linux distribution for embedded devices. Michael also worked at Nokia Mobile Phones where he was part of the Bluetooth SIG software working group, and a contributor to the original specifications. Michael has a BS in Computer Science from LSU Shreveport and MBAs from Cornell University and Queen's University of Canada.