One of the driving factors behind my plunge into Home Automation is energy conservation. I believe that usage monitoring is a critical part of conservation; to that end I purchased the excellent ECM-1240 home energy monitor from Brultech. It’s a nicely integrated serial device with support for monitoring seven independent channels, including pulse devices such as water/gas meters. While the ECM-1240 is excellent, I was unable to get usage data at a finer level of granularity than the circuit. I picked up a couple of devices to see which was the best fit for my needs:
- [amazon_link id=”B000CSWW92″ target=”_blank” container=”” container_class=”” ]Watts Up Pro[/amazon_link] monitor
- [amazon_link id=”B0032JRGZ8″ target=”_blank” container=”” container_class=”” ]Kill-a-Watt[/amazon_link]
- [amazon_link id=”B0049VHKIQ” target=”_blank” container=”” container_class=”” ]Aeon Labs Smart Switch[/amazon_link]
The Watts Up Pro device is essentially a more advanced version of the Kill-a-Watt with the addition of a USB port and extensive data logging capabilities. The Kill-a-Watt was interesting because I wanted to build a Tweet-a-Watt which would wirelessly send usage information via an embedded XBee. Finally, the Aeon Labs Smart Switch caught my eye as it provides energy usage information as well as the ability to remotely control the connected load.
I did some googling to find as much information as I could about Z-Wave device control. There are lots of code fragments floating about, but very few turn-key projects that would get me up and running quickly. Several open-source home automation projects offer Z-Wave support, but I found most of the code to be poorly written, tightly coupled to specific HA projects, or too fragmentary to be of much use. Finally I stumbled upon the open-zwave project.
The open-zwave project is a GPL-licensed, reverse engineered implementation for the control and management of Z-Wave devices which is unencumbered by Zensys’ licensing. As I’ve noted before, the “official” Zensys developer kit costs a staggering $1,500 USD, placing it firmly out of reach of the hobbyist. The open-zwave project is actively developed and maintained and has a very helpful developer community.
One of my goals in developing my own home automation solution is to become proficient in Python. In the past I have found converting an existing implementation to a new language to be a very effective learning tool, so I rolled up my sleeves and began to port open-zwave to Python. When I had ported about 50% of the functionality I stumbled across Maarten Damen’s py-openzwave project. Maarten had taken a different approach; rather than porting the entire library to Python, he used Cython to wrap the existing open-zwave implementation.
Because the open-zwave project is being actively developed, the ugly reality of keeping my Python implementation in sync with the baseline code became more apparent. I decided to shift gears and run with Maarten’s approach instead. I forked Maarten’s project on github and got busy coding. Maarten had ported a couple of methods, but I wanted more extensive support; I spent a couple of days building out the ZWave Manager implementation, adding PyDoc documentation strings, and generally learning how the open-zwave project (and Z-Wave in particular) worked.
I also wrote a Python wrapper class to simplify interaction with the open-zwave implementation, providing a simpler interface which takes care of the low-level details of working with the underlying library. Some of the interactions with open-zwave are extremely fine-grained.
Open-zwave library initialization can be an extremely time consuming process, especially in large installations or where there are sleeping devices; Startup takes over a minute on my network of 20 or so Z-Wave devices. Because of this fact, a simple standalone command line application for device control is impractical. I am currently developing a set of tools for Z-Wave device management. The first is a web application which will stay resident and will provide a browser-based GUI as well as a full REST implementation; the second is a curses (text-based) GUI which can either work standalone or use the REST interface back-end. You can see what the curses interface looks like on this post on Maarten Damen’s blog.
If anyone is interested in contributing to this effort, please feel free to fork my project on GitHub. My hope is that this project will eventually be incorporated into the open-zwave project itself.
I will be posting more about py-openzwave, ZWave, and my home automation project as I have time to do so. Please feel free to check out the code, and comments and feedback are extremely welcome!