I've long planned to start a Home Automation series in an attempt to document the deployment, configuration and monitoring of various home automation components. This journey really started over a year ago when my wife and I built our house. With network drops run to anywhere that I thought we might ever want to put anything, I saw home automation as a valid excuse to apply my passion for technology outside of work and get back to some of my more "maker" roots.
I really had a few goals that I was trying to accomplish. Energy conservation and trending were at the top of that list. I've always assumed that solar panels were in our future at some point, but without knowing what our true energy usage was, or where we were wasting energy were the first two problems to solve before considering solar in order to ensure we could right-size a solar deployment and cover a large percentage of our average energy use.
Secondary to the energy monitoring was the security and comfort side of home automation. Lighting presets, more granular control over HVAC, sunrise/sunset rules, presence driven rules, etc. were all things I was excited to learn more about and develop over time.
Home Automation is a pretty exciting field. The development of new technology and protocols, and the consumerization of those capabilities has been happening at a pretty quick pace. In the section below, you'll see that I was maybe a year early of the market in terms of what I really wanted. This series will share the successes (and failures) I've had, and hopefully prevent you from making some of the same mistakes that I made early on.
In the beginning...
Things started off pretty smooth. I bought a bunch of Ubiquiti mFi equipment (switches, dimmers, sensor controllers, power strips, etc.) and setup about a third of the house, starting with my home office. mFi provided a fantastic web-based controller that allowed you to trend energy consumption. Furthermore, it allowed you to define your cost per kW from your energy company, and it would help you to understand how much of monthly energy bill should be contributed to individual devices.
Furthermore, the mFi controller provided the tools necessary to create advanced rules and define pretty complex sensor logic. I say all of this in past tense, because just a few months after getting everything up and running, Ubiquiti announced they were ending support for mFi. While they still sell the hardware for folks that want to manage it themselves, the controller itself no longer being developed or supported. I still hold the opinion that the Ubiquifi mFi mPower Mini is the best wifi controlled switch you can buy. I'm still deploying those switches (even without an mFi controller), most recently to control my 3D printer.
Where to go next...
Facing the dilemma to either continue buying mFi hardware and deal with an end-of-life controller, or to completely start over was a daunting prospect. mFi was all wifi based, which had it's own advantages, but no more updates for the controller also meant that the mFi platform itself was never going to support non-mFi devices. This sort of killed my dream of one unified platform to control the entire house. The wishlist of feature requests from customers was never going to be handled by Ubiquiti, and the prospect that they may randomly decide to also stop selling the hardware at any time was equally as worrying. I decided it was best to try a few alternatives out before making a final decision. It's important to note that the comparison of OpenHAB, Wink and SmartThings was all done 6-9 months ago, so my views of these products depicted below may not accurately represent advancements made in those platforms between then and now. I share these experiences merely for context and to tell the story of what led me to where I am today.
The first alternative I tried was OpenHAB, running on a Raspberry Pi 2 with an Aeotec Z-Stick for Z-Wave control. I desperately wanted to love OpenHAB. It was open source, extendable, and could conceivably do whatever I wanted (if I was willing to put the time into getting it to all work).
I'll preface this with the statement that this was the late OpenHAB 1 days, before the release of OpenHAB 2. This was an awkward time because the focus of the developers was understandably OpenHAB 2, but OpenHAB 2 was not really ready to be deployed. I'm pretty technical, but as much as I tried to get OpenHAB up and running in a stable and reliable way, it just wasn't happening. I also quickly learned that the home grown nature of OpenHAB also meant that it was pretty lacking in consumer support. This meant there was no great iOS app and no great user interface, resulting in something that you really couldn't expect the other members of your household to happily use. Pairing new devices was a chore, and things frequently just didn't work. The big draw to OpenHAB was that it was open source, meaning that when it didn't work you could crack it open and debug Java on your own, but even I didn't want to do that just to turn my kitchen pendant lights on.
Looking for a more commercially viable option, I picked up a Wink Hub. As with OpenHAB this was an equally awkward time for Wink. The Wink Hub 2 was known to be in development, but the company itself wasn't tight lipped on what it would support, or if it could close any of the gaps in the original Wink Hub. I'm not positive if it's still the case, but at that time, Wink only supported devices that were formally marked as "Compatible with Wink Hub". This meant that finding switches, outlets, sensors, etc. was incredibly difficult. You couldn't just grab any Z-Wave switch and pair it.
One of my big draws to Wink was the very prominent promotion of the fact that there was an API. I took this to mean I could close any gaps in the product on my own, by coding against the API. At the end of the day, that API was pretty weak. I found myself struggling to even turn on an outside light at sunset. I returned the Wink and moved on.
Still on the hunt for a commercial product that could handle advanced rules and a wide array of devices, I next picked up a SmartThings Smart Home Hub. The SmartThings hub supports a variety of protocols, and [probably] thanks to the Samsung ownership has pretty widely adopted device support. It seems like almost any mainstream Z-Wave or Zigbee device you pick up has a "SmartThings" logo on the packaging. So far, so good.
The next big surprise for me was when I discovered SmartThings Graph. Not only does SmartThings offer a feature-rich API, they've built an entire UI around API management. Using SmartThings Graph you can create your own device profiles to add support for custom sensors or devices that don't have a formal SmartThings device profile. You can also create your own smart apps to control devices or handle more advanced sensor logic. And probably the best capability, is that those custom apps and devices you create are all surfaced in the incredibly user-friendly SmartThings iOS and Android apps.
I suddenly found myself with a platform that was a consumer product, supported by the manufacturer and a huge user community, that still provided the control and extensibility that a power user like myself wanted. SmartThings seem to have hit that balance between an open source project, consumer product, and hardware ecosystem that I didn't really think was going to exist. On top of that, they seem to develop at a pretty good rate with frequent firmware updates for hardware and app updates for iOS and Android.
All of these points led me to select SmartThings as my home automation platform going forward. Stay tuned to the Home Automation category. In future blog posts I'll share the setup, configuration, monitoring, and challenges as I continue on this mission to fully automate our home.