Welcome to installment number twenty-five of the Design Challenge Project Summary series here at Element14. For those of you who are new to my content, in this series, I will pick a single Design Challenge project from the current challenge, and write a short summary of the project to date. Over the course of each challenge, I try to revisit each project that I cover at least once, and I am sure that some project summaries will get more than one update if they themselves are updated frequently. Unfortunately, projects that stall out, or get abandoned, will not receive any updates. Some project creators like to keep their own project summary going, and this series is not meant to overshadow those post, but designed to highlight each project from an outsider's perspective.
The subject of this installment is project DomPi by Sergio Martinez (mg.sergio), a project that is aimed at creating a custom integrated alarm system and automated home. Sergio detailed his plans for this project in his initial PiIOT application post, and he left no detail untouched. This is honestly one of the most well-written Design Challenge applications I have ever read, and I highly recommend that you read it for yourself before continuing with this summary post.
In the project’s introductory post, Sergio further laid out his plans to create the ultimate smart home and broke the large project down intro three separate phases which made things a bit more manageable. The first phase includes development on things like lighting control, motion detection, and a presence emulator that would sense when a resident of the home was away, and then emulate someone being home. Phase two includes elements such as a feature that would turn the TV and lights on upon a resident returning to the home and advanced alarm features such as IP Camera motion tracking. Phase three will include the development of features like automatic humidity adjustment, rain detection, and flood and fire detection.
The project’s first official update post, Sergio laid out a simple project “dashboard” that is focused on allowing his readers as well as himself to easily track the progress of the various subsystems of the project. As seen above, each column represents one of five Arduino controlled nodes, with each node being based off a predefined section of the home and its grounds. Each node is broken down into various sensors / subsystems and is marked with a yellow cell when work on it has begun. The project will actually feature seven nodes total, with the final two being Raspberry Pi based, which need the extra processing power that a control hub and command center need. After getting the project’s subsystems organized, Sergio began work on the living room node, starting with the lighting control, and temperature / humidity sensors.
Sergio continued with the living room node in the project’s second update, with the lighting control being the main focus. Getting the remote lighting control up and running was fairly easy thanks to a couple of 433Mhz wireless wall plugs, and Arduino Nano, and an IR receiver. Sergio wrote some code that allowed some lights in the living room to be switched on and off with his television remote control, and wrote in a clever feature that utilizes a “ four-second double click” of the button to actuate the lights. This prevents any issues with accidental button presses or any interference that could happen when using the buttons for actual TV control task. With the lighting segment of the project tackled, Sergio moved on to utilizing a DHT11 temperature and humidity sensor in conjunction with the same Arduino Nano to begin collecting environmental data for the system.
Update number three kicked off the motion detection system and wrapped up with some work on the wireless communications system that will be used to report data from each node back to the Raspberry Pi command center. An HC-SR501 PIR sensor will be utilized in the home, garage, and garden to detect movement. When motion is detected in any of these three environments, the PIR will send a signal to the Arduino at the center of the node. The Arduino will then relay the motion trigger back to the Raspberry Pi based control center via NRF24 2.4GHz Wireless modules. “To use the NRF24L01 besides the Arduino SPI.h library, I am leveraging the library written by TMRh20,” he said. “The great thing about this library, besides the support and forums you can get, is that I can use it on the Arduino as well as on the Raspberry Pi, so... it is a great fit to the DomPi!”
Sergio finalized the code and hardware for the living room, parents bedroom, and kids bedroom in update number four. The post summarizes the process flow for both the living room and bedrooms, which is slightly different. “The living room node has a number of sensors that are polled synchronously in the loop function - it is the program which decides when to read the data. Additionally, it has the IR receiver that is read asynchronously, meaning that the IR library captures the IR data when it comes and then the loop function reads and processes it synchronously. This approach, sync/async, is the same one used for the RF 2.4Ghz Comms. The library reads the data when it comes and then the loop function process is in sync,” he said. “There are three main differences between these nodes and the living room one. The first one is that they don't require the IR receiver nor the RF433Mhz components, no need to implement reading the TV remote or sending commands to the RF plugs as this is only done by the living room node. The second difference is that they are based on Arduino Pro Mini instead of Nano, not a big difference in pings and performance, the only call out is that the Pro Mini you need to solder them. The third difference is how you power up the Arduino, while the Nano has a built-in USB adapter, the Pro Mini comes without it.”
With data being collected from the bedrooms and living room it was time to move onto configuring the Raspberry Pi 3 based control center. Update number five walked readers through the process of backing up the Raspberry Pi 3's operating system image via the terminal app on Mac OS. Sergio points out that while this is not necessary with a fresh image on the card, it is good practice to get into the habit of doing so. Once the image was backed up, the Raspberry Pi was plugged into a flat screen TV, he walked readers through the process of configuring an SSH server on the RPI to request a 4096bit shared key. This is a much more secure way of protecting remote access to the Raspberry Pi over using the much easier to crack password authentication method. The post finishes up by walking us through the steps of creating the access keys, installing TightVNC, and then tunneling into the VNC server via SSH as a sort of workaround to TightVNC not encrypting data that is being transmitted between devices.
Sergio continued configuring the command center in the project’s sixth update. This was a smaller update than the previous post but covered a very important aspect of the project. SD cards, like most flash memory, has a finite number of writes. This means that you can only write data to the card so many times before the memory begins to fail. To somewhat alleviate this issue, Sergio wants to boot the OS from a USB drive which usually have memory chips with much longer lifespans than the chips used in SD cards. If you have not yet learned how to create a bootable USB drive, and how to make it work with a Raspberry Pi, this is definitely the post for you, so click the link above and check it out.
Update number seven continued the command center build out, with the focus being on installing and configuring openHAB, MQTT, and the RF24 module communication software. openHAB is an open source home automation software suite that is compatible with Windows, Mac OS, and Linux, with UI applications for Android, iOS, and Pebble. Sergio will utilize openHAB as the core of the command center, with communications between the nodes and the command center being facilitated via the RF24 modules, all while leveraging MQTT to tie everything together. This update it yet another tutorial rich resource, and is very well written. I would highly suggest reading the whole thing before continuing on with this summary.
The project’s ninth update broke away from the command center and focused on redesigning some of the software that the project will be running, as well as building the presence emulator. The change in the way some aspects of the project are coded is due to a realization that Sergio had about openHAB, and the ability to use C code inside the automation suite itself. “These last two weeks have been quite hectic in terms of progressing with DomPi. My first intention was to develop most of the features and functionalities in C++ modules which would connect among them and with the openHAB via Mosquitto messages,” he said. “When I was half way through it, I have gladly discovered that most of the C coding could be performed directly with the openHAB via the rules and actions that this platform supports.”
With the coding redesign out of the way, Sergio moved on to building the presence emulator. “The purpose of the Presence Emulator feature is in this first development to turn on and off the rooms´lights simulating that there is someone at home while we are away on vacations or for the weekend. This is key for us as we live in the basement and want to avoid "surprises" when returning home. I have developed an openHAB set of rules that govern this emulation,” he said. Basically, some code was written to allow openHAB to control various elements inside the home when no one is home, thus simulating something that looks like people are inside and using the home when looking in from the street. This includes things like turning on and off lights in various rooms, at random, and preset intervals.
Update number ten moved on to developing the Garage Node. Utilizing another Arduino, Sergio created a node similar to the ones he is using in the bedrooms. Temperature, humidity, and motion detection are being sampled from the environment , as well as a new feature that assists in parking a vehicle in the garage. When a car is being pulled into the garage, a TFT screen on the wall will display the distance the car is from the wall thanks to an HC-SR04 “ping” sensor. To make parking even easier, the screen will display green, yellow, and red colors to indicate where the vehicle is in terms of an acceptable parking space.
Sergio continued work on the Garage Node in update number eleven and figured out a workaround with the issues he experienced in update number 10 with the TFT screen. “Due to some incompatibilities of my TFT LCD with the SPI protocol - very probably it is not releasing the bus when the device is not addressed by the chip -, the RF24 board was not working properly. Both devices, the screen, and the RF, are key components of the Garage node and hence, I could not sacrifice any,” he said. “I have not found any potential solution rather than the workaround to separate the TFT and the RF24, connecting them to two different Arduinos and interconnecting the Arduinos with I2C.”
Sergio says that while the garage node has become more complex than he had originally planned for, it is working with full functionality. “As you can see from the pictures [above] the last minute changes have transformed two arduinos and some sensors into a mess of cables prone for errors and disconnections... I promise to arrange them much better,” he said.
Updated: 12 September 2016
The project continued to move forward with Sergio focusing on the control panel and garden node in update number twelve. The control panel is based around the , and is placed at the main entrance to his apartment. The screen will display info for DomPi, the lighting controls and the presence emulator, as well as allowing users to control things such as the alarm system, turning lights on and off, and the ability to turn the presence emulator on or off. All of this functionality is made possible via the OpenHAB install Sergio covered in an earlier update. To wrap up this update, he also built out the garden node, which was a replica of the same hardware and software used in the kid’s bedroom with the only omission being the PIR sensor.
Update number thirteen was one of Sergio’s best yet, and featured a lot of finalization in the software portion of the project. “Trying to move full speed during the last two weeks of the challenge! In the last few days I have achieved a great milestone in the DomPi project: all the features from the Phase 1 are now fully operational,” he said. The first task that was tackled was the finalization the C module that acts as a gateway between the remote nodes and the Command Center. This was no small task, and for those following along at home, Sergio has included the source code in this post. Work was also completed on the weather and pollution forecast modules via OpenHAB. Finally work was completed on the basics of the alarm system. There was so much work completed in this update that I simply can not cover it all in this summary, so head to the link above to read the whole post.
Update number fourteen was not quite as long as it’s predecessor, but still contained a host up updates to the project. Sergio started off with work on the presence identification system, a feature that lets DomPi know who is at home by checking whose mobile phone is on the home network. With the presence identification system out of the way, Sergio moved on to building the Welcome Home Feature. This feature will trigger specified functions when someone enters the home and their presence is detected. In the beginning, only the lights in the living room and parents bedroom will be triggered, but future plans include turning on the television, and switching the TV to a specific channel that is dictated by who has entered the home. Finally, Sergio coded in a simple temperature alarm that would notify him via email if the home’s temperature breaks a specified threshold on either end of the warm / cold scale.
The project’s fifteenth and final update was posted on 27, August 2016, and finalized the IP Camera integration into the system. Instead of using the Raspberry Pi camera that was included in the kit, Sergio decided to use an existing Foscam IP Camera that he already had integrated into his home. His reasoning behind this was because of its preexisting integration, as well as its ability to pan and tilt remotely. This added a lot of flexibility to the system, and he could monitor more than portion of the home with a single camera. This post is full of useful information if you are trying to integrate an IP camera into your OpenHAB installation.
That is going to wrap up my project summary coverage of project DomPi. Much like project Alarm Clock, I really enjoyed watching this project progress over the last few months, and have been inspired to create my own OpenHAB-based smart home installation due to these wonderful post. If you too have been inspired to create your own Smarter Space, please read through the project by visiting its blog page. Tune in next week for another Design Challenge Project Summary here at Element14. I will be back next week with another weekly Design Challenge Project Summary. Until then, Hack The World, and Make Awesome!