Have you ever glanced at your garage door opener and arrive at the painful realization that you're toting around a clunky chunk of electronics that has barely changed in 15 years, and only slightly changed in the 10 preceding that?
Does that bug you? Do you think to yourself "why the heck do I even need to carry this retarded and bulky wireless transceiver when I have like a half dozen on my smartphone?"
If any of these are familiar to you, or if none are but you are just too damn curious to stop ... then read on
Solution SummaryThe notion is using WiFi, we will issue open requests to a stationary OEM garage remote wired directly to an ESP8266. Whenever in range of the WiFi network, we need only our phone to open the door.
I couldn't leave it at that, so also included in the solution is MQTT, data logging as well as WiFi/MQTT profile management.
Note that the hardware for this is very undramatic and well understood by the community. The challenges faced were almost 100% software related, so the focus of this article is mostly on the software we run on the ESP8266.
Feature Exploration: MQTTMQTT enables a fully internet-connection scenario, if desired. For this application, connectivity is LAN-only but is fully capable of operating on the internet - with just a bit of elbow grease applied to secure it. That's a topic for a different time though.
MQTT operates in a publish/subscribe pattern - therefore it's happiest when there's at least one server and one client. To this end, I use a Raspberry-Pi derivative, the NanoPi2. Any Debian-based machine on your network will do the job.
The software itself is Mosquitto, a very lightweight open source and surprisingly mature MQTT server.
Since we are leaning on WiFi for our security (you ARE running a locked-down WiFi network, right?...) we run our MQTT server without security. This means installation of the MQTT server is extremely easy. The guide here covers the process well.
Side note: before you balk at the unsecured MQTT server, this presently is the best practice for IoT devices - mostly because many IoT devices have not-all-there SSL stack.
Feature Exploration: Data LoggingAfter encountering a couple of sporadic, accidental garage opens I decided data logging was crucial. I don't want to be holding my ... horses ... wondering why the heck it decided to randomly open. To really do this right, we've used a few technologies:
- SPIFFS: EEPROM file system for ESP8266, a perfect destination for our logfiles
- NTP: link into network time server so that we know when open requests really occurred and make our logfile easier to read in general
- Serialization: The MQTT payload shall carry a unique number from 1-100 representing which device initiated the garage open request
For the record, the sporadic opens were never traced any of the software provided here =)
Feature Exploration: Serial ConsoleBeing a software developer by trade, I am most comfortable when a full diagnostic console is available. Since the ESP8266 is loaded with available code space, there's a Console interface for doing a number of important operations at runtime vs compile time:
- Access and view/clear data log for when open requests occured
- Set WiFi profile
- Set MQTT profile
- Query system version and status
This is probably squarely in the overengineering category, but I was annoyed at recompiling every time I tried this on a different network, plus the notion of compiling in secrets at compile time I find unappealing (but not annoying).
With that said, the system still bases itself off of statically compiled secrets.h, but is immediately overridable with profiles. In the SPIFFS file system, the profile named "default" is tried first, then roll through others.
For WiFi, the profile folder is /etc/network/wifi
For MQTT, the profile folder is /etc/services/MQTT
The MQTT profile system is not fully tested yet because we're employing mDNS to discover our Mosquitto server. This takes a bit of extra configuration on the Linux machine but is worth the effort. Alternatively, statically linked MQTT address is viable.
Feature Exploration: util.embeddedThis is a support library I've open sourced and use in all my microcontroller projects which can't use mbed OS. util.embedded is a work in progress and fluctuates a lot, so be warned. Oh yeah, and it's kind of a beast of a code base :)
CodeRight now, hackster.io doesn't support gitlab, so here's a direct link to the public repo . When time permits I might just move it to github anyway. License is currently LGPLv3
Compiling and ProgrammingThis project uses Ivan Kravets' fantastic PlatformIO software to get the job done. Setting up PlatformIO and the nuance of actually programming the ESP8266 hardware I leave out of this article today (many, many good articles on that elsewhere) but will expand the topic if enough readers are interested.
Things to know about compiling this project:
- Using a fair bit of symbolic linking which could pose some Windows problems. Development on Linux/OSX recommended for now
- Using quite a few submodules, so be sure to do your git submodule init/git submodule update routine.
- I've not tested the submodules under accounts other than my own and expect some access rights issues early on. Please relay any issues you have with that my way and we'll clear them up.
The general idea is GPIO15 (defaults to pulled down) activates the OEM garage remote itself.
Hardware DetailThis was initially prototyped on an Adafruit Huzzah, and then later I soldered up my own protoboard as pictured for this article. Really any NodeMCU-ish board ought to do the job. The only extra stuff going on is a transistor & resistor soldered across the OEM garage opener remote switch itself. Your particular arrangement will probably vary from mine.
My particular arrangement I'm actually running the entire circuit at 3.0V, which allows us to safely eliminate the battery from the OEM remote (Liftmaster 830max). ESP8266 is 100% happy running at this voltage. I stuck some extra big capacitors around the regulator just to make sure it didn't sag much below that.
I plan to do a full schematic / BOM and eventual PCB of my own, but in all honesty I am a hardware newb so the design YOU have in mind right now is probably better =) If enough of you are interested I'll definitely break down every little bit of the hardware in this article.
Future FeaturesI plan to add a rangefinder to the device so that we can query it and see if the garage is actually open or not. For this feature, we'll add limited internet connectivity.
Comments