Home automation as a theme is rapidly gaining popularity in the consumer market. Manufacturers like Nest and SmartThings are being purchased by tech giants like Google and Samsung to compete in the race for the “smart home”. Personally, I’ve been very interested in home automation for a few years now and after a lot of hours researching the various options and having owned a few solutions, I found myself not really content with the options out there.
When considering my requirements for such a system (outlined below), I’ve come to the conclusion I’d like to start building my own DIY home automation system until a solution is released that covers my needs. I’d like to share my endeavors across a series of blog posts, starting off with the basics of hardware, software and connectivity, extending into data collection, control through apps and gaining insights through analytics.
Aside from the basic requirements of quality and price, I’ve defined a few personal requirements that weighed in on what type of solution I would want in my DIY home automation setup. These may vary for you, but hopefully my experience will provide some insight into why this matters to me.
If you know me or have read my blog, you probably know I’m a bit of a tinkerer. One of the things I love about having programming skills is that customization is literally at my fingertips, so I definitely like being able to tweak or create solutions that are completely tailored to how I want it. This is definitely also a requirement for me in home automation, so the system I would choose or build would ideally expose REST services to use in my own Windows and Windows Phone apps.
Another big thing, after having owned the Dutch made HomeWizard system, which definitely fulfilled the first requirement of exposing easy to consume REST services, I realized I have another other big requirement: stability. One of the things HomeWizard does really well is connecting different types of devices to a single home automation system: they support widely available 433 MHz radio frequency devices, which are cheap and produced by a lot of manufacturers, but also include support for Foscam Wireless IP Cameras and through software have added support for Philips Hue lighting solutions.
While being very broad in terms of supported devices, it lacked in stability in two ways: the gateway device itself relied solely on WiFi communication and living in a neighborhood with over 10 WiFi networks at any given time, connectivity to the device was unstable at times, which resulted in not being able to control the devices in my home. The second point here is the negative of relying mostly on RF devices: reaching the devices becomes increasingly unstable over larger distances or with more objects in between and these devices generally don’t communicate in two ways, so turning on the light and not reaching the actual switch would result in the gateway thinking the light was on, when it in fact was not.
Control over data
A lesson learned having owned a product that went belly-up: having total control of the data that comes out of a solution or even the communication chain to your devices is crucial for data continuity and analytics. We owned a digital scale (Youw8) hat was connected to a service to provide insights into your body weight over time and allowed you to set certain weight-loss goals and track against these goals. Very motivational if you want to lose or stay a certain weight and the service worked pretty well (despite not meeting my customization requirement). That is, until an e-mail arrived one day, stating Inotive Solutions B.V. (the company behind the product) filed for bankruptcy on December 23, 2013 and thus all services would be discontinued. There would be no way of retrieving my personal data already collected or redirecting the device to another service to continue data collection.
Another point I mentioned is control over the communication chain to your devices: although luckily not having experienced this myself, I’ve seen reports of a smart thermostat by Nefit and Bosch, called Nefit Easy. In its early days, the back-end services were sometimes unstable and due to the client apps not talking directly to the device, but actually communicating with the Nefit Easy back-end services, which in turn communicated with the actual thermostat, a few users have complained about not being able to control the heat in their own home due to service disruptions. Since then, Nefit has added a “local mode” fall back, where the device returns to manual control in such an event, but nevertheless it illustrates my point of control over the communication chain.
Having reviewed the various popular protocols in home automation, I’ve decided on using the Z-Wave protocol, due to wide adoption in the market, availability of devices and specific orientation around residential control and automation. Having reviewed the popular available gateway devices (the center of the system, communicating with all devices and providing the interface to those devices), the choice came down to the Mi Casa Verde VeraEdge and the Fibaro Home Center Lite. Note that both these devices have “bigger brothers” that allow for more customization, devices that can be connected and are generally more powerful devices, but for my home automation needs and the price I was willing to dish out for a gateway (the VeraEdge costing about 160 euros and the Home Center Lite about 280), these devices sufficed.
After a few more hours of browsing and pondering, I came across the RaZberry Project: a Raspberry Pi daughter card, allowing for communication with Z-Wave devices from a Raspberry Pi. Looking at the solution overview, I quickly decided this would be the ideal solution for me: it relies on an open platform (Raspberry Pi and the Raspbian OS), it offers a certified Z-Wave communication stack called Z-Way, which exposes all of its functionality through JSON REST APIs and it was built with custom applications in mind (the first-party software is very lightweight, allowing for a lot of customization). Not offering a first-party Windows or Windows Phone experience wasn’t a big hurdle for me here, as the first-party apps on other platforms were demo implementations of the Z-Way JSON APIs. Some time later reading the documentation and browsing through the forums, I purchased a Raspberry Pi Model B+ and the European RaZberry daughter card. (Note that Z-Wave operates at different frequencies between continents, so make sure you get the right model for your region).
In the next post of the series I’ll go into the setup of the Raspberry Pi, RaZberry and making it available over the internet. As usual, let me know in the comments below or on Twitter if you have any comments, suggestions or feedback!