Close

Refining Requirements...

A project log for Home Automation - Garage Door Opener

Extract best practices from existing garage door projects. Build version that suites my needs; eventually integrate into other HA efforts.

luffmanbluffmanb 04/09/2016 at 22:340 Comments

Where I am...

So the short of it is that I have the concept of software interfacing w/ GPIO through relay to trigger the garage door open/close figured out, prototyped, and demoed. I even have a garage door magnetic reed switch on order from Amazon to be delivered sometime next week (I hope) and am fairly confident that will be a no-brainer to integrate for the status detection requirement. My next immediate task is to provide the remote front-end via webapp to interface w/ this system, or perhaps, ditch the webapp entirely and go "all in" w/ OpenHAB.

Initial attempt...

I originally had grand schemes of a live RPi Cam video feed w/ button and status overlays such as suggested by this project: http://hackaday.com/2015/02/23/another-garage-door-opener-this-time-with-security/

However, upon further digging into this project's Hackaday post, Hackaday.IO logs, DeckerEgo blog, and GitHub repository, I'm beginning to think this project doesn't actually live stream video but rather takes a still shot before and after. Regardless, my real hangup is that I spent some considerable time trying to implement it Thursday and got 90% or so the way there, but just couldn't get it to work in the end w/o doing some considerable digging through multiple layers code and httpd configurations.

Nothing against the author of that project. It does look rather slick!

Requirement Refinement...Simplicity.

However, in my project's description/details sections, I left some requirements a bit vague. For instance when I said, "Extract (and enhance) best practices from existing garage door hobbyist projects seen on web and build a version that suites my needs," one major aspect I always intended to incorporate is simplicity. The fewer the complexities, the easier to implement, troubleshoot, share, and upgrade. In my opinion, I view that as a "best practice" as well as "suites my needs." Unfortunately, after working through the example project Thursday, I determined it was just too complex for my tastes.

So, I'm backing up a bit, going more low-level to meet the minimum requirements w/o the fancy overlaying stuff--at least until I can build up to that point. I want as few software dependencies as possible. My goal is to be able to install the latest version of Raspbian "minimum" and provide a list of bare minimum software add-ons needed to complete the effort--no having to install npm/bower/pip to grab stuff outside the debian distros, no additional complex software such as motion/openCV for computer vision--which is a project unto its own right, etc. Again, I seriously do not intend to harsh on anyone else's hard work and awesome project results; it's just not the direction I'm aiming to travel.

Not only that, but I suspect my test w/ hard power off--which resulted in corrupted uSD card--to simulate power failure was extra problematic due to me running an infinite-looped Python script looking for interrupts. So again, I'm looking to simplify and trigger w/ one-shot bash scripts. While this won't help prevent uSD corruption due to the OS/services writing to the card during power drop, at least I'm removing an unnecessary variable.

Discussions