Garage Security

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'm in the middle of refactoring the entire software base... er... just because. The Python code was becoming a bit of a tangle, and I needed to sharpen my Reactive/Scala/Play skills. There is now a "PlayRefactor" branch in the GitHub repo that is a re-write of the web application that hosts the JavaScript webcam, Google Hangouts notifications and GPIO button presses.

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.

I'm using the Garage Security codebase to do a home security camera as well... maybe with automation? Now beginning to modularize things so I can use the same codebase for both projects.

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.