Developers new to the OpenZWave project are often confused by system behavior immediately after the application is started. I thought I’d quickly write up a blog entry detailing some of what I’ve learned about the system, hopefully this will be of value to OpenZWave developers and/or users.
One common point of confusion among new users is that the system takes some time to initialize. At startup, the application queries the controller and all registered devices for their state and configuration information. Attempting to perform operations on the network during this initialization phase can result in errors or inconsistent/confusing responses. It often comes as a surprise to new users that this phase can take quite some time to complete. Network size, the state of devices on the network, congestion or weak signals, and a plethora of other factors can contribute to long startup times; an average network of Z-Wave devices can take several minutes to initialize. Continue reading OpenZWave: Startup Sequencing, Values, Etc.→
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
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!
Random Ramblings on Software Development, Electronics, and the Maker Movement