In desperation to try to get this project functional and ready for install by the end of April 2016, I have been bouncing back-n-forth a bit on trying to complete the Baseline (Phase 1) as-is vs. mushing major components from Phases 2&3 into a refined baseline. In other words, if I could get openHAB working, I wouldn't need to develop my own web interface or certain aspects of web security as it provides those for me. Not only that, but I would gain the expansion capabilities of a full-blown home automation backend to grow. I could also provide some additional sanity checks by ensuring I get text notices on my/wife's phones whenever the system is used to trigger the garage door--just in case someone did hack in, or if I had a floating pin problem, etc.

Web GUI

Why I hate the web GUI component of this project...

Over the course of this project, my biggest frustration has been trying to recreate multiple projects' web interfaces to control the RPi GPIO. I have many years of on-again-off-again experience w/ both static and responsive web design and manually coding in HTML4/5 and CSS2/3. However, I somehow never got around to truly learning the depths of Javascript or its multiple spin-offs, so unfortunately this hurts me when trying to troubleshoot some of the more complex dynamic web designs used in many of these sample projects.

On the flipside though, I know from experience that properly coding a webpage to "look right" on multiple web browsers (and especially nowadays on multiple devices w/ varying screen resolutions, input methods AND running multiple browsers) can be very time-consuming. This is why I was really hoping to find a good existing framework to remove a lot of that overhead work and yet provide a clean, responsive, secure, and robust web interface that was still flexible and simple enough to modify to interface w/ the needed RPi GPIO code layer.

When trying to recreate projects I had found similar to mine, I did my best to follow their instructions, but I found the instructions were either:

1. Lacking in enough detail to complete all the steps, or
2. So dated that the underlying software packages were outstripped by current releases, or
3. So dated that the underlying frameworks' projects had died (I'm looking at you WebIOPi!), or
4. Too complicated/complex to meet my requirements to be long-term, easily sustainable.
5. (or some combination of these)

However, there were two that I was able get to mostly interact w/ my Pi's GPIO to trigger the relay, and of those, only the following Instructable was completely repeatable. It was also simple enough for me to easily modify for the triggering behavior I desired for the relay to imitate a momentary button push. However, while it was a rather ingenious design for the purpose the author was implementing, it ultimately was not ideal for the components and look-n-feel I was after.

• See: http://www.instructables.com/id/Simple-and-intuitive-web-interface-for-your-Raspbe/?ALLSTEPS

WebIOPi, node.js, javascript, jQuery, PHP...?

So, I spent much of the weekend digging through which new framework(s) I could learn from scratch quickly enough to turn this project around. I dug through Adafruit, Instructables, Hackaday, Element14, MakeUseOf, various Google searches, etc. Again, WebIOPi came up a lot, too bad it's not supported any longer; also these projects all referenced older RPi models/Raspbian installs**. I spent some time trying out node.js and Jade; a lot of projects are moving in that direction. But it was going to take a bit more time than I had to learn and properly write a web server app w/ all the security features needed to open this up to access from across the Internet--probably something I'll want to learn eventually though.

**FOOTNOTE: Why does this matter? Granted, even if WebIOPi were still relevant, I could pretty easily tweak the code to match any changes in GPIO layout (26-pin prior to B+ models vs 40-pin on newer models). The bigger problem would likely be in major changes from Raspbian "Wheezy" to "Jessie"; this transition is a lot like moving from RHEL6 to RHEL7, the classic UNIX System V architecture has been superseded by systemd. So many of the software packages have been updated and the way the userland interoperates w/ kernel space is different. In other words, too many changes for a safe bet the instructions would still be repeatable on current hardware/software.

Pi Camera

During all this, I did expand my existing hack of "TheFreeElectron" 's webinterface to take a photo with the original (IR-filtered) RPi camera board and publish it to the webpage, but to see it, the webpage needed to be manually refreshed.

openHAB/MQTT

So, not being happy w/ my webpage hacking, I returned to openHAB exploration. I posted earlier how I got it installed on a second RPi2 and initially working w/ the Nest Thermostat bindings, but I'm still new to openHAB and having to learn its ways. I also had not yet determined how to "bind" a homemade project into the openHAB event bus.

MQTT

This is where MQTT comes in. It is a lightweight publish-subscribe messaging protocol for use on top of the TCP/IP. Multiple home automation projects are using it for IP based communications w/ homemade sensor networks. While I am familiar w/ the concept of pub/sub messaging protocols, I have never personally implemented one before. (At my previous job, I worked w/ some folks who were modernizing our system's architecture, and a key component to their new design was the utilization Data Distribution Service (DDS)--which is an open standard "machince-to-machine" middleware (m2m) for real-time systems.)

So, I started my foray into MQTT at the behest of the following MakeUseOf guide.

• http://www.makeuseof.com/tag/openhab-beginners-guide-part-2-zwave-mqtt-rules-charting/

Aside: Formerly MQTT=Message Queue Telemetry Transport--"formerly" b/c historically the MQ came from IBM's MQ messaging queuing product line, but technically queuing is not required to be supported in the ISO standard.

Mosquitto & MQTT.fx

Anyway, I installed Mosquitto (open source MQTT client/broker set readily available in Raspbian repos) on both RPi's and decided to try and figure out what I would expect to see on the messaging layer. For that, I installed MQTT.fx on my Fedora workstation; it's free and came up regularly in my Google searches on beginner learning of this protocol. This is a Java based GUI MQTT client--think of it as something similar to Wireshark, but instead of listening in on IP traffic, you can listen in on MQTT messaging traffic and sub/pub to them as well; it also gives a good overall breakdown of the traffic data such as how many clients are currently subscribed to the broker, how many bytes of data transitioned the message bus, etc.

• MQTT.fx: http://mqttfx.jfx4ee.org/

In the end, I was successful in getting MQTT.fx to publish and subscribe to the Mosquitto broker on the OpenHAB RPi, but I could never get my OpenHAB configuration to publish onto the virtual MQTT bus.

After a frustrating few hours of trying to get MQTT w/ openHAB to work tonight, I'm torn where to go next. I don't know if the problem is because I'm using Mosquitto instead of Paha MQTT, or if I just don't understand something about MQTT or openHAB in general. Are my configurations for openHAB to talk to the Mosquitto broker wrong? Are my openHAB Items/Sitemaps files referencing MQTT bindings wrong? Am I just too tire to see the mistakes?

WHERE TO NEXT?...

I need to get something working by this weekend. The way I see it, I have 4 options:

1. Continue in frustration w/ OpenHAB/MQTT
2. Try openHAB w/ a different binding
3. Revert back to web GUI frustrations and just get it working for now only internal to my LAN. Add the security for external access later.
4. Try something new, and expand the Twilio capability to receive texts that trigger the GPIO in addition to just sending notifications out.