I was one of the lucky few to be selected for this awesome road test, and as I wait for the hardware to hack, here's a brief introduction to my project.
A small introduction
I've been studying electrical engineering in Lappeenranta University of Technology since 2007. For the last couple of years I’ve been also working there part time, participating in energy measurement development for solar and wind energy, utilizing both National Instruments LabView and related hardware, as well as Beaglebone Black and Raspberry Pi as low cost solutions.
My passion towards home automation has grown ever since my dad started building a house "in the middle of nowhere" back in 2006. As the house isn't occupied during weekdays, some sort of remote controllable automation was required. At the time automation systems for remote control were expensive, very basic and terrible to use. This lead to the idea, that we could develop our own system. The first version was ready for winter 2007, just monitoring few temperature sensors. Ever since the system has grown and currently it's used both for my flat and my fathers house, together spanning 15 temperature sensors, 10 wired relays, 5 wireless switches/dimmers, couple of magnetic switches and three webcams with motion detection.
I've been experimenting with different solutions for home automation for ages and I've always come to the conclusion, that "I can do it better." This is not to mean that other solutions are done worse or nothing like that, it's just easier for me to keep things under control and just the way I want by doing them myself. I know, that developing a own version of stuff that's already been done is basically idiotic and wastes a lot of time, but I like to tinker with things
Based on other blog posts so far, I'm doing something very wrong. I'm not planning on using OpenHAB or solving a specific problem(s). Instead, I'm trying to achieve something that would benefit the community as whole, instead of just showcasing the hardware. This will be quite boring to most of you, as it'll be quite some time, till (and if) I get anything visible done, but I'll try my best.
I'm planning on implementing the EnOcean protocols etc with Python, as it's the language of choice for most of Raspberry enthusiasts out there (and me). I'm aware, that there is some stuff done already, but they only implement parts of the protocol (at least the ones I've found), without a proper API and support for multiple device types. Of course I'm going to use on protocol implementations written before on other languages for inspiration and ideas.
The main goal is to get a framework for enthusiasts to build their own projects, with the package being ready to go with a simple "pip install enocean". After this I'd like people to be able to receive messages by a simple "from enocean import Listener; Listener().start()".
If I get to that stage, of course I'm going to provide a "reference design" to extending the functionality, with a web UI.
If I have time, I'd also like to develop some specific hardware solutions which I have the need for, but those aren't a priority at the moment. I’ll introduce them, if I ever get to that point. Also I'm planning on implementing this as part of my existing system.
So far I've been nose deep in documentation! Things have progressed quite nicely though, I should have basic message ("packet") parsing done now (just started working on the project today, maybe 8 hours of coding or so). Of course, the code is quite rough and without comments or exception handling so far, but I'll sort them out some time later.
I'll be trying to learn something new in this project also, properly managing unit tests! I've done some basic ones before in couple of projects, but properly testing a project is something new to me.
So the next big challenge will be creating proper tests for the modules done so far, this should be quite simple though, as there's quite a lot of message examples in the documentation. After tests for the message handling is done, I’ll move on to designing the serial part of the library, so I can actually receive messages.
This will probably be after I get the hardware and do some functionality tests to see, that the design of the library is OK. I don’t want to release a library before I’m comfortable with the basic API, as it shouldn’t change once it’s designed.