The other day an idea popped in my head for a side project that would involve the Gmail API. Whenever this happens, I normally hit up the developer site, find a simple tutorial, and immediately get my hands dirty.
This tutorial assumes I’m doing development on my local machine where it can pop open a web browser and authorize the API access. Most of the time I don’t operate that way – I use a remote Linux server of some kind.
To get this quick start guide working on a remote server:
In the Google Developers Console, generate a client ID for a native application (this may work with other types of client IDs, but I know it works with a native one)
Save the client_secret JSON to the script directory
Add the ability to read command line arguments and call the function ‘tools.run_flow()’ instead of just ‘run’
Run the script with “–noauth_local_webserver” as an argument
Now when you run the script, you’ll get a link to copy into any browser to authorize the access. Then, you’ll get an auth code to paste back into your script.
I’ve included both scripts so that you can compare easily. I hope this saves others from frustration and I also hope Google improves the tutorial.
The garage door opener remote was removed from its casing and I located the button used to open the door. My particular model had three buttons.
I soldered a jumper on the button leads to always create a circuit, removing the functionality of the button so it’s “always on” when power is applied. The button was this style – a standard electronics button.
I removed the coin battery and soldered on two leads that will be powered by the Raspberry Pi. When the Raspberry Pi sends power, this will be no different than someone normally pressing the remote button.
I wrote code to control the pin that outputs power.
Garage door openers can vary, but I’m willing to bet a lot (if not most) use a CR2032 battery. The Pi puts out 3.3 volts, (.3 V higher), but I haven’t noticed any issues.
I’ve provided the simplest example here. The next step would be to have the code driven by a web interface that could be loaded on a phone or a web browser.
There will be an exciting part 2 to this article where I take this one step further!
After upgrading to Yosemite, I noticed that graphics performance was starting to lag a bit on my 2009 Mac Pro while driving two monitors at fairly low resolutions. At one point I had two GT 120s running separate monitors, but after one replacement and two failures, I was back down to one.
I decided to look into upgrade options and was happy to see that OS X now supports non-EFI video cards. The only catch: You won’t see anything displayed until OS X loads your drivers. Who cares?
I settled on an EVGA GeForce GTX 660 2GB, which Best Buy happened to sell. I can feel the judgement from the hardcore nerds for buying something at Best Buy. Nevertheless, this was much cheaper than trying to buy another GT 120 to replace my second one and offers WAY more power. I don’t game on my Mac – I just want the OS to feel snappy and fluid.
Like many powerful cards, the GTX 660 requires the PCIe 6 pin power connector from the power supply or motherboard. I’ve ordered this, but until it gets here, I’ve rigged up an external power source.
My Dad and I built the alarm system for their house in late 2009. He handled hardware, I did software. From time to time I export the data it collects just for the heck of it, since it’s been running non-stop for years.
The back door at their house has been opened 41,267 since the end of November 2009. That’s kind of surprising to me.
It’s interesting to see some patterns in the graph – it’s how many times the door has been opened per month. You can definitely tell what year I bought my house.