raspberry pi door bell project: part 1

So, we recently fixed our front gate that had been getting steadily worse since we moved in. Better late than never, I always say. Installing the gate made it clear of two things: one, that the doorbell buttons in front of our door (which still don’t work) were made even more useless by a locking gate and two, that the SkyBell 2.0 doorbell I bought to replace them won’t work unless I mount it on the outside of the gate.

And that’s how the Raspberry Pi + SkyBell project was born!

Door Bell - Zoomed Out

However, being that I’m mainly a software developer nerd and not (yet, anyway) an electronics nerd, there were some problems up front. While I have had some fun piecing together sensors and LEDs on an Arduino board in the past, I never got around to building anything I’d actually plan to use on a regular basis. I mean, I built a presence detector with a co-worker at Oakley so we would both know when people entered or exited our four-man bullpen, but that was as crazy as things got.

Needless to say, I’ve had to do a bunch of research for this project. For starters, I don’t have the existing low voltage doorbell wiring typically required to install the SkyBell. Luckily, they have some instructions on using a 12-volt DC adapter in part of their instruction booklet. All it requires is a 10-ohm/10-watt resistor one one of the wires connecting up to the unit.

The only problem at that point was how to detect that the door bell button was pressed on the SkyBell! I knew logically it had to work with a traditional doorbell system, and once I learned how that worked (a simple closed circuit causing an electromagnetic piston/hammer to hit actual chimes), I figured I just had to test the unit to see if there was a voltage change. After copious amounts of reading, searching and reaching out to my high school friend, (who is an electronics whiz), it became clear I’d have to prototype it and measure with my voltage meter (I absolutely recommend one of these if you’re green when it comes to electronics).

SkyBell + Resistor Button Test

So the next step was ordering up the parts for the prototype I could measure. For that, I ordered the 12 volt DC adapter ($7.99) and 10-ohm/10-watt resistor ($5.82 for 10) (both pictured left) from Amazon. It arrived just yesterday, so I immediately cut the end off of the DC adapter, split the cable a bit, spliced one lead onto the resistor, then spliced the two leads coming out of the back of the doorbell — one onto the exposed adapter wire and the other onto the other end of the resistor. Of course, I had to expose a bit of the wire before I could measure anything, but once I’d done that, I was ready to get testing.

As you can see here, I did just that (albeit with a very clumsy approach of holding everything all at once while trying to record using my phone):

In the end, I got a clean reading. Admittedly, I don’t know if 200 is the right setting to use on the voltage meter, but it got me the results I was after. There is a dramatic decrease in voltage for roughly eight (8) seconds on push of the doorbell button.

Result for phase one of the Raspberry Pi + SkyBell (PiBell): SUCCESS!

What this means in terms of the project overall is that I should be able to detect the change in voltage once my Raspberry Pi 3 gets delivered. However, from my various learnings, it’s clear it would not be wise to hook 12 volts directly to my Pi; it would break (plus it would smell terrible).

This brings us to our next question and the next thing I’ll be testing, which is: how do you detect a change in 12 volts using the Raspberry Pi (which lacks analog-to-digital converters — ADCs — that Arduino has) without frying the thing? Well, that’s where optocouplers come in.

4N35 Optocoupler DiagramSo, as I understand it, the basic idea behind an opto coupler is this: rather than connecting things directly, you power a tiny LED inside a housing with the higher voltage line and THAT will send light over to a photocell (a resistor that changes resistance based on how much light it’s exposed to), which is actually hooked up to one of the GPIO pins on the Pi. This way, there is physical separation from higher/dangerous voltage, so any spikes will not harm the device on the side of the photocell (again, the Pi).

As you can see in the above diagram, I’ve had a confusing time learning about what each symbol means on a circuit diagram. Or what the right resistance is to use in some places. For example, after some asking around, it was made clear that a 10k resistor between the 12-volt DC power and pin 1 on the optocoupler is necessary to avoid frying the LED inside. The rest of the placements for pin connections (four actual connections in total) actually makes sense, which is what will lead me to phase two of the project: hooking up the optocoupler to the Raspberry Pi, then feeding a wire connection off of the existing doorbell wire to detect button pushes!

For that, I’ve ordered the CanaKit Raspberry Pi 3 Ultimate Starter Kit ($89.99), which comes with a bunch of cool stuff (including the resistors I need!). Plus, I ordered 40 feet of outdoor rated cable ($13.49) to connect to the actual 120V output, and the PC817 Optocouplers ($6.99 for 10). I went with the PC817 optocoupler over the 4N35 because, as far as I can tell, it does the same thing but only has four pins to worry about (trying to keep confusion to a minimum here).

Overall, I still need to prototype the entire setup, make sure nothing sizzles, figure out how to detect the voltage change from the Pi from, say, Python, and then from there, do whatever I want. I’m thinking I’ll play a sound over SONOS for starters.

thoughts on the upcoming robot revolution

Do you hear that buzzing noise at the edge of the horizon? It’s the sound of the machines plotting to steal our jobs (and even jobs from immigrants).

They Took 'Er Jobs!

Oh, that sounds silly does it? Well, think again. And again. And AGAIN.

Joking aside, it’s really a question of when, not if. Large companies have been slowly replacing workforces with automation where possible, and who could blame them? Robots are amazing, and uh, fast. Plus, they don’t sleep, eat or even take breaks. And they don’t need vacation. Oh, and they won’t form unions.

Unless you program them to, of course.

So with robots taking on repetitive tasks here in the U.S. and those jobs not going to other humans, what happens to the people who already have a tough time finding work? Sure, some of them can join in on the fun work of maintaining the robots who replaced them (yay!), but for a significant portion of the rest, there will simply be no jobs for them to grab. By some recent estimates, over 5,000,000 jobs will be lost to automation by the year 2020. That might sound small compared to the world population, but when you consider the 15 countries polled, it starts to sound like a bit more of a problem.

To arrive at those numbers, the WEF surveyed 15 countries that make up 1.9 billion workers, including China, France, Germany, Japan, Mexico, the UK and US. In other words, about 65 percent of the total workforce worldwide.

And if you think it’s just blue-collar workers, think again.

The WEF claims white-collar workers — administrative and office jobs — are at the highest risk of being replaced.

From what I can tell, this isn’t even taking into consideration the recent leaps in technology that are being made by private companies. Boston Dynamics, for example, released a new version of Atlas — a bipedal robot that can walk on uneven terrain, track and lift objects, and even get back up to a standing position when pushed over:

This is a robot that could feasibly be programmed to do a variety of jobs thousands of people are doing right now. By 2020, it’s almost guaranteed a bot like this could take over a lot of jobs on factory floors that require walking, or jobs out in the wild — like delivering mail and packages — from an autonomous vehicle. And that’s just the beginning.

You’ve got AI being developed at such a rapid rate that it’s only a matter of time before a computer can not only do the menial tasks humans do, but do them better. You may remember IBM’s Deep Blue beating Chess grand champion Gary Kasparov back in 1997. Well, recently Google’s DeepMind beat Go grand champion Lee Se-dol about ten years before it was predicted to be possible.

DeepMind may not take your specific job over any time soon, but the point is that the time between leaps is becoming shorter and shorter; learning robots could, hypothetically, be given a task and learn the best way to do it. That includes my line of work — software development. Within ten years, it’s not outside the realm of possibility that a person like myself could be threatened with a more economical robot replacement.

So where does this leave us? Well, jobless, most likely. That isn’t necessarily a death sentence either. For a lot of people, there’s the option of starting up a home-based business and dealing with the job loss that way. Or why not cash in on the robot economy yourself? After all, with new industries come all kinds of new problems to solve.

But that still leaves a large chunk of the population outside. In the rain. Laying in the gutter.

My wager is that within the next twenty years, we’re going to see millions of people supplanted by machines in the US alone. A significant portion of these people won’t be able to find work anywhere and won’t be able to start a successful home-based business. How will the welfare system possibly handle the influx? If it’s the one we’ve got now, it won’t. And we should never assume that the market will take care of jobs for all those in need; obviously that is not the case.

Look, I don’t even know that I’m suggesting basic income for all, although I don’t think it’s an option we should take off the table. Plenty of smart people are researching it or think we should research it, and some really smart people — Stephen Hawking included — think it’s the way to go, unless robots can provide everything virtually for free. In an AMA post a while back, someone asked him about this very subject and he brought up yet another excellent point:

If machines produce everything we need, the outcome will depend on how things are distributed. Everyone can enjoy a life of luxurious leisure if the machine-produced wealth is shared, or most people can end up miserably poor if the machine-owners successfully lobby against wealth redistribution. So far, the trend seems to be toward the second option, with technology driving ever-increasing inequality.

It is not in the interest of the people who makes these machines to let robots simply provide us with everything we might need, although I do foresee some of the richer humanitarian types going that direction. Whether it’s profitable is not for me to say. And I must say, it seems rather naive to let robots provide all we need (what happens when the people who control the robots decide to start controlling us? These things need consideration).

What does seem more likely though is universal basic income.

Personally, I don’t care about the socialism stigma on the idea, especially if it means millions of people not having to suffer. On the contrary, if we can’t create an automated society where humans can essentially worry about the top tiers of Maslow’s Hierarchy of Needs and the alternative is misery, then what alternative is there?

As always, I’m open to your thoughts.

maximize/minimize gets added to refined-github

If you use Github on a regular basis, you may have noticed how really large pull requests can quickly get out of hand. For this specific reason, I created a little (unpublished) Chrome plugin a while ago to add the ability to maximize/minimize diff blocks in the Github pull request file change page (see below).

Then the other day, I happened across the (published) Refined Github Chrome extension, which is a similar collection of modifications to Github in a Chrome, so I decided to ask them whether they’d like my feature added in. As it turns out, they did! So after an hour of actual coding and changing the jQuery-dependent code over to use the much lighter Sprint.js, the change finally got green-lighted. A little back and forth with some great suggestions and now the feature is officially added in.

Here is the feature in action:

Maximize/Minimize for Github Pull Requests

The only difference between when I made this gif and now is that the plugin features a zoom-in/zoom-out cursor when hovering over the block header box where you can individually min/max.

Next, I’ll make it so the same functionality works in other diff blocks.


I felt like making a domain search tool for myself, so I did. I figured someone might get some use out of it as well.

Also, I really like the domain — domango.io (pronounced doe-mango).

It might seem slow at first, but it’s looking up a lot of information on each domain.

Update: I have shut Domango down as other priorities took place and, frankly, it was fun but there are far superior services available.

os x: set file self destruct based on tag


If there’s one thing I dislike, it’s clutter.

Once in a while, I like to do a purge of my downloaded files and things on my Desktop. What I kept finding, however, is that I was unsure about whether I needed certain files after even just a few weeks. This would lead to me putting them somewhere (hopefully) temporary labeled “delete_me” or something similar. Then, when I’d happen upon the folder later on, I still wasn’t quite sure about whether it was okay to delete the folder.

So I thought about using Finder’s Tags so I could label things that were OK to delete. It wasn’t much of a leap from there to see if I could use a cron script to delete the files for me after a time of my choosing, and sure enough — it worked!

Of course, I had to be my own guinea pig, because I didn’t want to risk deleting someone’s important files but knowing I back up my most important files, I wasn’t too worried.

Months later, I’m still using this process routinely, so I decided to put it online in case anyone out there has a similar need.

You can check it out here: OS X Self Destruct

No, I don’t mean OS X will self destruct. I just like the idea of a message that will destroy itself at a time of your choosing like on Inspector Gadget.