One compulsive behavior I can't seem to shake is the fear that I have left the garage door open. I count the squares on the front, I measure the light and shadows, I obsess. To tell the truth, even if I had a magic device that would send me a message every time the garage door opened or shut, I wouldn't trust it. I have to see it.
To feed my neurosis, I began working on a combo surveillance camera / garage door controller with an Internet interface. The first thing I attempted to get working was the method of opening the garage door; up to this point it seems like most efforts have been using a relay to close the switch of the hard-wired "big button" for the garage door opener. I wanted to have the freedom to place the device anywhere I wish, not unlike the garage door keypad that comes with most openers now. A spare Chamberlain universal remote was just sitting in my garage, so I decided to shuck it and re-use the logic board within.
See http://blog.deckerego.net/search/label/garage%20door for detailed background on how this project was tested and initially constructed. The build instructions at Hackaday Projects should walk you through the hardware setup, and the README within the GitHub repository should walk you through the software setup.
The GarageSecurity project has FINALLY been updated to support the latest version of Raspian. The biggest hiccup was switching to the WiringPi2 library - which is now the defacto library for addressing GPIO pins. The good thing is pin addressing is now entirely in userspace (no sudo required!), however there were significant changes that required refactoring.
Things are up & tested with the latest version of Raspian however - so have at it!
Just added support for turning on and off lights via GPIO. The implementation is pretty straightforward and really just geared towards relays - such as the PowerSwitch Tail II (http://www.powerswitchtail.com/Pages/default.aspx). Now I can flip the lights on in the garage and peep around, rather than building a light ring around the camera. And it so happened my overhead LED light bar didn't have an on/off switch ANYWAYS, so two wins in one!
I totally acknowledge that installation of all the software dependencies and managing configurations is a pain in the butt. Because Pi's are often single-purpose (ish), I think I'm going to remedy this by making Garage Security a .bin file that can be flashed directly onto an SD card.
With a little tweaking, I believe I can also create a web front-end that allows you to put in your Jabber, S3 and WiFi settings before the .bin is downloaded. That would make installation TONS easier.
I'm also working on more general-purpose GPIO buttons for the web interface. Rather than just having a button to trigger the garage door opener, what if you also could have a GPIO pin fire to enable your home irrigation system? Or just blink an LED?
The GPIO abstraction will be first, followed by the customized .bin installation. Until then, I'm trying to re-install on a Pi 2 and I'm making special note of the installation steps I've missed along the way. Turns out I missed plenty.
I've made a few additional modifications to GarageSecurity. The UI is a bit updated now, with the camera feed taking up as much screen real estate as possible and buttons overlaid. This is especially helpful for mobile or tablet viewing.
I also added support for the HIH6130, a temperature/humidity I2C breakout board based on the Honeywell environmental sensor. This adds the current temperature and relative humidity to the security camera web interface. Very helpful for those who need to keep their car above freezing or below boiling.
The Scala/Play conversion for GarageSecurity didn't work - no way the JVM + Motion would fit on a RaspPi Model A. Instead I'll have GarageSecurity exist entirely in Python and will clean up the codebase. A new project, HomeDashboard, will consume the REST APIs from GarageSecurity and will display a central command console for the house.
I have re-introduced the Motion subsystem as well; in general it was more flexible and easier to deal with than streaming video to the webapp itself. HOWEVER - this means that nearly all the memory of a Model B Raspberry Pi is consumed between Apache 2, Java and Motion. In fact, you have to start the webapp before the motion subsystem otherwise motion's memory consumption crowds out the JVM bootstrap.
I don't want the JVM move to be a boat anchor however - I'm targeting support for running within 256 MB of RAM using a Model A. If that doesn't work... I may just have to move back to Python.
The README.md in GitHub still says OpenCV is required, and I also make mention of the Motion subsystem in the project. I started with Motion, tried to advance things with OpenCV, however the current state of the software project has a homebrew imaging solution.
I need to finally make a decision on what the appropriate path forward is. I'm going to do some tweaking on the homebrew solution - if it (finally) works I'll clean up the documentation and point everything to homebrew. Otherwise I'll need to decide between OpenCV and Motion... likely OpenCV.