Supplier eBooks

12 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). 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). 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 Figure 3: The Huzzah Feather receives weather data and makes an informed decision on controlling HVAC dampers. Figure 2: Board stack for sensor package. From bottom: Arduino, Wi-Fi Shield, TE Connectivity Weather Shield. Jumper wire between GPIO pin 12 and pin 9 Weather Shield Wi-Fi Shield Arduino Bend or remove GPIO pin 9 on the Weather Shield. Figure 4: Note that pin 9 on the weather shield must be removed and a jumper wire is placed between pin 9 and 12.

• Cover