A garage door opener is a pretty classic hack around these parts. IR, Bluetooth, WiFi, smartphone controlled, web interfaces — we’ve seen it all. But if you want to keep track of people going in and out, you need some way of logging what’s happening. You could go ahead and roll up your own SQL based solution, tied into a custom web page. But there’s an easier way; you can build a garage door opener that logs events to Google Drive.
[WhiskeyTangoHotel] was looking for an ESP8266 project, and a garage door opener seemed just the ticket. It’s simple enough to code up, and control over WiFi comes in handy. Interfacing with the garage door was simple enough — the existing opener uses a simple push button, which is easily controlled by wiring up a relay to do the job. Logging is as simple as having the ESP8266 send requests to IFTTT which is set up to make posts to a Google Sheet with status updates.
The project is fairly basic, but there’s room for expansion. By using separate Maker Channel triggers on IFTTT, different users of the garage door could be tracked. It would also be easy to add some limit switches or other sensors to detect the door’s position, so it can be determined whether the door was opened or closed.
There’s always another take on the garage door opener — check out this hack that opens the garage door in response to flashing headlights.
That is a handy method, that is more widely applicable. Nice find! Google sheets are very powerful and Google drive is a pretty secure way to save copies of things off-site, but how safe are your credentials if they are in that device? Would a safer “one-way data valve” require pushing the data to a buffering area, then pulling it off there with code running in the cloud? The idea being that at worse a person who accesses the logging device only gets the credentials for the buffer. Does anyone have a better, more secure, way of doing this?
Google’s APIs are set up to handle this for you using access tokens limited to very specific tasks on specific resources. If these tokens are compromised the attacker would only be able to use that specific service (e.g. view all of the info on that sheet) for a brief amount of time. It can be tricky, but if you think it through, you can build a very secure interaction using OAuth. But if you really wanted to implement a buffer, you could set up an AWS Lambda (free tier) to run some Python. This would actually be riskier as you are increasing the attack surface (not only can the device be hacked, but your web-app could be compromised as well). My idea would be a credential saved on the garage opener (or whatever device) that authenticates a post made to the Lambda function. Lock down the Lambda function to only accept requests from a specific IP (provided you can guarantee an IP). This would help to prevent unauthorized users from posting data through your buffer, further I’d add a throttle of some kind that would mitigate the damage (like 1 post every 15secs). If the device became compromised the attacker would only get the credential to authenticate posts to your buffer. Your client secret for posting to your google sheets would live on AWS and would follow all of the above rules.
There’s a way to use Google services with custom apps; I’ve done it to allow my RPi to email me things. It allows you to generate a key for your custom app to use so you don’t have to give it your full credentials, and it can be removed at a later date if it becomes compromised. Quite useful!
The device is connected via his LAN so you have to connect to the house WiFi first. So it’s as safe as the WiFi. If he has all the authorized devices register their MAC addresses then it should be pretty secure. I’ve done that because my WiFi is in the ADSL router so outside my LAN which is firewalled.
Wish there was an Edit button! That last sentence needs punctuation! I have a firewall between my ADSL router and the LAN. The WiFi has the MAC addresses of the authorized devices, and the DHCP is set to serve the same IP to a device each time it connects. The firewall has these IP in the Allow table. This arrangement seems to work. I set it up 10 years ago when I found the students in the flat 2 floors above me had managed to break my password and connect 2 iPhones and an IPad to my Wifi!
Noob here. Why is the BS170 N-Channel MOSFET apart of the circuit? Can you not wire directly from the ESP8266 to the relay? I looked at the Wiki for the relay and its ‘logic’ seems to operate at 5V. Is that what the MOSFET does?…Increase the signal voltage to the relay?
The FET in this case is being used as an inverter. A high signal from the ESP turns on the FET and this pulls the “IN1” connection on the opto-isolated relay board to GND, turning on the relay.
If you invert the signal in code, you should be able to do away with the FET, if the ESP can sink enough current to turn on the LED in the opto-isolator.
It can support it. I have a garage door opener with the exact same components minus the FET. The ESP sinks the current just fine.
Great Project. I have no WiFi coverage in my garage so decided to use gsm network you can read about my GSM Gate Opener here:http://blog.makerstorage.com/gsm-gate-opener/
My ESP and relay combo would not work without the use of a FET.
I guess all low cost relays modules are not created equal.
I use Loggly for this part of my Garage Door system. It’s a little more straightforward than the Google Drive method, and it has more Splunk-like searching/filtering features you would want in a log system. I use Google Drive to store the pictures the motion sensor triggers when someone is in my garage, so I know how much less straightforward using Google Drive OAuth is.
Excellent gooods from you, man. I have undestand yiur stuff previous
tto and you are just exremely magnificent. I reall like wyat you’ve acquired here,
certainly like what you’re stating annd thee way inn which youu say it.
You make it enjoyqble and you still take care oof to keep it sensible.
I can nnot wait to read far more froom you. This is actually a great site.