I received a box chock full o’ Eaton Home Heartbeat devices today. They are nice little devices, fairly well designed (if a bit boxy). I was up and running with a basic installation in a matter of minutes – very nice. Each sensor has a little slot on top where the hardware key fits; to add a sensor to the network you need only place the key in the slot and select ‘add device’ on the key. The key itself is a little Zigbee device with a backlit LCD and a scroll/click wheel (think mouse click wheel). Devices can be edited using this litle device, can be renamed and even removed from the network. Device naming seems fairly limited, one can select from a pre-defined list of names to use for a given sensor. Docking the key with the base station both recharges the key and (I assume) backs up its configuration to the base station. You can also set alarm types for different events – either a local alarm (which beeps the key and makes the display backlight colors change to red) or a phone-based alarm. which I’ll get to later. Continue reading
I have purchased several devices from Embedded Data Systems (EDS) over the last few years. Their HA7Net Ethernet 1-Wire Host Adapter makes integrating 1-Wire devices utterly painless; it is a solidly constructed, well-engineered piece of hardware. It is also very well supported by the OWFS project. EDS is a pleasure to work with, their staff is knowledgeable, pleasant, and responsive.
I’ve got several remote areas that I would like to monitor using 1-Wire devices, and I’d like to use some of the more obscure 1-Wire devices which I’ve purchased over the years as well. This seemed like an excellent use case for the [amazon_link id=”B004G4XVKC” target=”_blank” container=”” container_class=”” ]Arduino Fio[/amazon_link]: low power consumption, built in LIPO support, and [amazon_link id=”B004G4ZHK4″ target=”_blank” container=”” container_class=”” ]XBee[/amazon_link] support to boot.
A bit of googling turned up several examples for simple 1-Wire interfacing using the DS18B20, but very little in the way of other devices. I would like to use some of the 1-Wire hardware that I have accumulated in this project – a dual channel counter, LCD board, and 8-channel relay board from HobbyBoards as well as various temperature and humidity sensors from iButtonLink. Several of the pages I found referenced Peter Anderson’s 1-Wire interface adapter, which is a nice little design but does not support chaining devices and is limited to only seven 1-Wire devices. There are a couple of other nice libraries available with more extensive device support as well, but I haven’t yet had time to dig into them.
Because I would like to support a larger number of devices on my 1-Wire bus, I don’t think direct control via Arduino is the correct approach; 1-Wire can be notoriously finicky when it comes to timing, and I just don’t want to invest that kind of time into testing and debugging. Dallas Semi has created some very nice driver chips which would fit the bill nicely. The DS2482S
i2C to 1-Wire bridge and the DS2480B
serial to 1-Wire bridge are both quite inexpensive and would be fairly straightforward to integrate with the Arduino
; The only real drawback to these is the tiny SOIC-8 package and subsequent soldering difficulties.
[edit: SOIC soldering really isn’t that difficult, as I recently discovered. Read more Generic celebrex.]
While downloading a new firmware release for my EDS HA7Net I stumbled across the HA7S TTL 1-Wire Host Adapter SIP; it occurred to me that this is an absolutely perfect fit for my needs. TTL level serial I/O, simple ASCII interface, extremely low power requirements, and very reasonably priced ($17 USD). I’ve got two on order now, will blog more once I’ve received the devices and have had a chance to play with them.
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
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!