Open Garage

Problem:

We recently got a new garage opener, and unlike the old one, this one only came with one remote. Unfortunately, we have three cars. This means that every time I came home, I have to get out and open the garage or park up front. Nope. I wanted a remote! Ofc, I don’t want to buy one like a normal person. I want to hack our opener to see how I could crack open the door.

Inspiration

I began with researching how people handled DIY remote garage openers. There were many solutions out there. Some were full fledged projects dedicated for this purpose like the GaragePi Project. I wanted to try and build everything from scratch for this weekend project.

I didn’t want to mess with the actual opener itself as well. Too much heavy lifting. So I started my research. I was inspired by this instructable.

Setting up the Hardware

The plan for the project was pretty straight-forward. I need to the push-button terminals on our garage remote to be triggered by a microcontroller such as an Arduino.

Following that, I’d have to trigger the microcontroller via the web. I’ve done both of these in the past on separate occasions, but putting the two together was not something I’ve done before.

To trigger the garage, you have to take apart your remote and flip over the circuit. Take a pin and start connecting terminals near the buttons. It probably won’t burn out because the voltage and current is really small. I found the two pins that when shorted triggered the door to open and close. I soldered extension wires to the pins of the pushbuttons.

After that, I wanted to test out triggering the pins with an Arduino. Since the circuit was already existing, I thought that a relay would be the best plan here. I drove over to Fry’s picked out a low voltage relay and hoped for the best. Side note: if you’ve never worked with a relay before, you should, because it makes this really satisfying click noise when it flips on.

The relay, however, did not work. The voltage/current in the remote’s circuit was not enough. I was only working with 3.3V!

That’s when I reached out to my friend, and he brilliantly suggested, to just use the power from the Arduino! Meaning, power the garage remote using the Arduino. Thereby making it all one big circuit. So I removed the battery from the original Garage Remote, soldered wires onto the terminals that controlled the buttons, and plugged it into the Arduino.

The code I wrote was just the sample blink LED code. Instead of an LED on the pins, I used the Garage Remote.

// the setup function runs once when you press reset or power the board
void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
}

And it worked! Hardware complete! I just had to expose this over the web to use with anything.

Using the Pi

After I got the hardware working, I knew the same thing could be done on a Raspberry Pi. The beauty of the Pi is that it operates like a normal computer. All I had to do was boot it up, throw a web-server on it and then interface with the GPIO pins to perform the same actions as Arduino.

So once again, I started off by testing the hardware. Here’s a good tutorial for blinking an LED with a Pi and Python. It’s the most basic of code.

The Pi ’s GPIO works well with Python. So this means that my web server should also be in Python. The only Python server library I knew was Flask.

I set up a route called Toggle that called the necessary GPIO code. That’s also when I learned about GPIO.Reset. It’s an important command.

When building a web-server with Raspberry Pi and interfacing with GPIOs, make sure to call GPIO.Reset. If your server crashes or shuts down, resetting allows the pins to be reused. I learned this the hard way, and the pins would be stuck in the on-state.

The next couple hours I spent debugging my program and testing. The garage door would randomly open and close during the night. I swapped out the remote for an LED so I could simulate it.

After I had the server set-up, I had to expose it so that I could access my web-server outside our wi-fi network. This is how I learned about ports.

Port Magic

I had used the “cloud” before, but I had never worked on the lower level networking aspects. This article on accessing our home computers from anywhere was a good start. The article was a nice find because it explained what all of the settings in the router configuration meant.

Networking was a blur to me before, but after working on this project, ports, port forwarding and IP Addresses all seemed to click together.

Anyways, the task here was to give the Raspberry Pi a Fixed IP Address. IP Addresses come in two types, one is public facing and the other is internal. Our router assigns all of the clients that are connected to it an IP (this is usally something like 192.168.xxx.xxx). Our router itself has another IP like (64.12.22.xx), that’s the public facing IP.

I mapped the local IP to a particular “port” on the router. This told the router that all requests to the public IP at a particular port should be forwarded to the internal IP. Wiring all of this up, it worked! I could control my garage from anywhere in the world. However, there was still one more challenge.

Our public facing IP changes every 48hrs or so, so that means the url to my garage would change then too. I would never know it changed or what it changed to. So if my IP was was 64.12.22.xx, two days later it would be 64.12.22.yy. This isnt the case with folks like AWS or Azure, becuase they pay the ISP for fixed IPs.

So to solve this problem for us amateurs, our routers have this problem called Dynamic DNS. A provider like Dyn will provide a fixed Web Address. Our router will then go to the Dyn portal, and update the new public IP information as soon as it changes. If you want this on the cheap, buy a D-Link router. They provide free Dynamic DNS domains, or else it’s like $40. With my new static url, I was able to use my garage from anywhere.

The good thing with building a web-service is that there is native IFTTT support. I wired our garage to IFTTT to get triggered on things such as location and virtual button presses. However, the latency with using IFTTT was far too much compared to a more reliable web call done by my browser. I didn’t want to wait 5 seconds for my door to get signaled and then another 10 as it slowly opens.

Building a Mobile App

My faster approach to opening my garage was to build a Mobile App. I added a simple password based auth system that was hard-coded into my server. My app took the password and allowed me to control the remote. I used my Xamarin.Forms for the App logic.

My mom also suggested a feature where the door should only unlock within a certain distance from the home. Don’t want the garage door open because of an accidental press.

So, I added a location service into the app to restrict access on when it was called. It worked! The app was lightweight and fast. I also realized that writing code for locations and handling coordinates is a pain.

Conclusion

I learned a wide array of things. From basic hardware skills with relays to port-forwarding and Dynamic DNS, I built an end-to-end solution in less than 24hrs. That’s enough for me. A perfect weekend-project. It did something useful.

For the futrue, and if I built it again, I’d really focus on the server. The server should have 0 downtime. If I ever get time, I would look more into ways to improve reliability and probably look into using an ESP8266 for this type of project. A Pi just has too much going on.