a few great shows

Note: the following post discusses Hannibal, Rick & Morty and The Path. I don’t believe there are any real spoilers in here, but just a fair warning.

So I just finished breezing through three really decent (in my opinion) shows I can’t believe I didn’t see previously: Hannibal, Rick & Morty, and The Path. Mainly, I was blown away that no one had really made a big stink over me seeing either Hannibal or Rick & Morty. The Path, I tried on my own but I haven’t heard anyone really talking about it. I find that pretty strange. Of course, these shows aren’t exactly “Lost” in both their build-up, intensity and mystery, but they do each possess a very engaging characteristic.

Take Hannibal, for example. It’s easy to think of a murderous sociopath as sort of one dimensional — in The Silence of the Lambs, Lecter seems almost like a cat who has found a new plaything in Clarice Starling. It seems like he’s just toying with her for the sake of the game itself, only trading little bits of what she’s after in exchange for personal details. Sure, that’s interesting and Lecter is terrifying as a character because he seems to be able to smell where someone has been before his lizard brain even detects whether they’re lying about a particular question. That’s already an interesting character. A cat-like creature wearing human skin that will bare his fangs the moment someone he has distaste for drops their guard.

The Hannibal Lecter of the Hannibal TV series, on the other hand, seems purely lizard like. The things hinted at in other movies on the character are shown in more vivid detail in the series. We get to see what Hannibal’s love interests are like. Yes, he’s a cannibal — unacceptable — but putting that aside for the sake of good television, just watching the way the character goes through his “process” in everything from his therapy sessions, to the meticulous way he prepares all his food, down to the ease with which he plays people. Again, to Hannibal, everything is still a game but there is such a style to him that it almost makes you question who the real hero is at times. You can almost begin to see the world through his eyes and he really, really hates rude people and is endlessly fascinated by human monsters. In a sense, he is their savior. And again, putting aside the eating of folks, it’s hard not to want to emulate the way Hannibal lives his home life. I don’t know who they’re consulting to dress these sets, but they’re doing a fine job.

Anyway, I’m late to the Hannibal train but I really do hope they carry on with another season. I’ve read rumors saying it’s possible, but there’s nothing set in stone yet. If you catch wind, please let me know.

Moving on to Rick and Morty, a friend of mine mentioned it in passing a while back and I kind of put it in the back of my mind but then decided to dive in after reading a Reddit post on the subject. Actually giving it a chance was a great decision, mainly because — despite the show being crude and aiming for funny most of the time — a lot of the plots are just very interesting and I find myself having a lot of, “Why didn’t I think of that?” moments, which is great. I can’t wait to see what else these guys come up with.

Next is The Path. Sure, it’s a drama. And yes, I may have used the gateway of Hugh Dancy from Hannibal as a sort of divining rod for what to watch next, but I actually got really interested in where this show would go. Cynically, I know the show isn’t going to really shock me with anything I haven’t seen before, but who cares? To me, the really interesting part is that it seems to be show that’s not taking a side on cults (movements?); it doesn’t seem to be a tongue-in-cheek message about people in Scientology or whatever. For me, it seems to be showing the ugly and the beautiful along with it. That being said, am I thinking of ever joining something similar? Nope. Not even close. But that doesn’t mean I don’t find it interesting.

It’s so easy to sort of blanket everyone in a “movement” as sheep who refuse to accept reality as it is and choose a better version to believe in just because life is easier when all the answers are provided, but obviously there’s more to it than that. Within the movement, everyone remains human and they don’t want to kill everyone else, but they definitely consider themselves otherly or separate. In fact, people in the movement want to help the people in society that no one else wants to look out for and that society just sort of sweeps under the rug. I think that’s the really interesting part. In helping the weak, they become strong. That echoes some truth about other religions/movements in reality as well: people operate within the framework of the movement, but can’t run from all it means to be human. Particularly when they’re living right alongside their trangressing counterparts.

There are some emotional moments along the way with this show, too. People dealing with losing their faith, or in outsiders being introduced to the weirdness of anything vaguely resembling a cult. It doesn’t hurt that it has Aaron Paul (Jesse Pinkman from Breaking Bad!) and Hugh Dancy in it either.

I’ll be looking forward to the next seasons of each of these shows, particularly Hannibal and Rick & Morty.

raspberry pi door bell project: part 3

The good news: I have everything wired up outside and it works (mostly) well, even in rain!

The bad news: Pi stopped detecting the doorbell button press, it’s been raining and I haven’t cleaned up the wiring yet.

Luckily, today looks pretty clear so I feel pretty good about going outside to do some re-wiring on the door bell part of the project. In effect, this means I’m going to have to remove electrical tape and then re-apply it (ugh, so time consuming). But at least I didn’t solder it (yet!).

As for what does work:

  • Open/close sensor
    • Open events:
      • Sonos speaker says, “The gate is now open”
      • Push event via Prowl to our phones: “The gate is now open”
      • Gate plays random sound through 3.5mm audio jack (not yet hooked up but confirmed through headphones!)
    • Close events
      • Sonos speaker says, “The gate is now closed”
      • Push event via Prowl to our phones: “The gate is now closed”

So all of this is off to a great start and will be in an even better place once I get the SkyBell working fully. To do that, I not only have to fix the wiring that detects the doorbell button press again but I also have to improve the WiFi signal that reaches it because it’s slightly spotty out there to the point where it just refuses to connect. That’s okay though, because I’ve been planning on adjusting the wireless signal I get around the house anyway.

This weekend, I attempted it with the Linksys RE1000 repeater, but with little success. For some reason, the devices that connect to it only have local network access and can not see the Internet despite all my efforts. I’m not shocked though; I’ve had problems with the N-network portion of my Linksys E3200 router for a long time, so I’m guessing there’s something amiss with the hardware of the actual router.

I’m thinking I might replace the whole setup with the ASUS RT-AC68U. I found it a while back and recommended it to a friend. He recently purchased it and has nothing but positive things to say about it, so I’m heavily considering it. I figure I don’t need much of an excuse as my work fully depends on a healthy Internet ecosystem in the house. Plus, we have more and more devices that are talking to each other now.

— Update 4/26/2016 —

So I left off on this post on the 11th and unfortunately, I still haven’t made actual progress on this project. The problem turned out to be with the Pi not detecting the right voltage from the SkyBell; since I am using a simple photocoupler, this meant I wasn’t able to read the door bell button push. After spending an afternoon diagnosing the problem outside, it turned out that instead of dropping the voltage to 12V like it had been doing inside the house, outside it was dropping it to only 4V! In other words, the photocoupler LED would never turn off, even with added resistors.

Figuring I had just wired everything wrong, I decided to bring the unit back inside to test and finally get right. I was able to get it working again but then as soon as I introduced a length of CAT5 cable in between the SkyBell and the Pi, the problem resurfaced. Apparently it wasn’t bad wiring but the cable itself was acting like a big resistor (most likely because the individual wires are so thin).

So now the plan is to somehow detect voltage on button press. I can do this either by soldering said wires directly to the corresponding places directly on the PCB of the SkyBell or by adding an analog to digital converter (ADC) onto the Pi so I can literally read the drop from 10v to 4V. That has its own problems that I am currently investigating, but of course I’ll update once I figure it out.

Concurrently, I have been researching other Wi-Fi Door Bells and have found that the SkyBell HD supports IFTTT (which would allow me to get around this whole mess), but that would mean selling off the 2.0 version or keeping it and just eating the $150. Either way, I can’t believe the company would shaft everyone who bought the 2.0 version, but whatever. I’m now investigating SkyBell alternatives for my smart setup. I mean, I want to eventually build my Home API which would mean interfacing the door bell with smart locks and the way things are going with this particular unit, I am not too hopeful about the future.

I’ll update once I figure out my next step.

raspberry pi door bell project: part 2

Success! As of last night, I officially got the doorbell detector working. I can’t tell you what a great feeling that is. Ah, to see your weird ideas come to life.

If you haven’t read part 1 of the series on this project, I suggest you do that just to see where I’m coming from here. Just to recap, the idea is this:

I want to install the SkyBell on the front gate (which we lock sometimes) so we get all the features of the SkyBell, but also tap into the signal from the doorbell so that I can fire events when it happens. Like playing a sound/song/voice inside the house on the SONOS, for example.

To do that, I did a ton of reading and what ended up being the most simple solution was using a little device called an optocoupler. Oh the things I’ve learned on my first Pi project.

What an optocoupler is, put simply, is a way to keep electrical signals separate while still allowing them to communicate. Sort of like that plexiglass barrier they use in prisons to separate the probably dangerous people from the presumably less dangerous people. Inside the optocoupler is a simple setup. On one side — the “dangerous” side you’re signaling from — you’ve got your LED. On the other side, you’ve got your photoresistor (a device that increases resistance with brighter light). All of this is sort of glued together with an epoxy and put inside of an opaque casing with some leads sticking out on either side to provide power and ground.

Credit: WikipediaThis diagram (left) shows all of this happening. On the left side is the LED sending light when there is signal over to the reader/collector on the right side. In my use case, I was able to wire the 12-volt “hot” (non-dashed) input to the LED side (12 volts resisted down to 1.2 volts via three 220-ohm resistors), then attach “ground” (dashed).

On the other side, I wired pin 3 to 3.3 volts from the Pi with another 220-ohm resistor in-between. Then wired pin 4 for GPIO 17 on the Pi. Now one thing you might notice here is that I didn’t wire anything to ground on the Pi, and that’s because I learned about a magical thing called a pull-down/pull-up resistor. Effectively, there are built-in resistors on GPIO ports that you can activate through code.

The reason for the existence of these things is, apparently, because physical connections aren’t either “off” (0) or at varying degrees of “on”; they float! So it’s hard to get a solid reading without assuming an on-state (pull-down resistor) or assuming an off-state (pull-up resistor). Any way you want to think of it, these built-in resistors are a huge space saver and allow for much simpler set-ups.

Oh, and I ended up going with the Sharp PC817 optocoupler/opto-isolator:

Sharp PC817 Optocoupler/Opto-isolator

Optocoupler Diagram, Credit: Wikipedia

To make a long (and very boring) story short, it means I can “read” a 12 volt signal safely into a 3.3 volt input. And that’s exactly what I did:

ASCII Raspberry Pi Doorbell Design

This is a crappy diagram and actually does not match the final “masterpiece,” but it certainly conveys the general idea. I’ve got a 12 volt DC power supply that provides current at 1 amp. Originally, it had a barrel connector (the round kind you stick into all kinds of devices), but I cut that bit off and was left with two wires — one hot and one neutral. As the people at SkyBell recommended, I spliced a 10-ohm/10-watt resistor onto the end of the non-dashed adapter wire and, as you saw in the previous post, hooked that up to the SkyBell (the left portion of the above diagram). I tested this setup with my multimeter and it worked fine, even though I had the positive/negative leads switched. Ultimately, I knew I was seeing the remaining 11-volt output drop to around 0 volts for about 8 seconds when the doorbell was pushed1.

Once I got my Raspberry Pi delivered, I had it set up and hooked up to a break-out board within an hour. I didn’t have a ton of time to play with it, but I was able to set up a simple push-button setup to light up a single LED (just to test it).

The next step was to hook the doorbell up using the photocoupler to actually read the voltage as I’d seen in bits and pieces around the web, but the trouble is that I was freaking out internally. I really did not want to break the SkyBell after forking over $100 for it, and I knew just enough about circuits to be dangerous but not effective. So I bothered my buddy Justin a lot, then to mix things up, I started bothering the people of #raspberrypi on FreeNode (great bunch of people, by the way). After running through the same scenario a number of times, it started to dawn on me that I didn’t need the SkyBell in the mix at all to test whether the drop from 11 volts to 0 volts was readable on GPIO.

So I removed the SkyBell and started hooking the DC wires (with 10-ohm/10-watt resistor) straight onto my breadboard, through the optocoupler, and on the other side, I hooked up 3.3 volts of power to the third pin of the optocoupler, and GPIO pin 17 to the fourth pin.

After some careful adjustments and clamping connections together using paperclips and tiny binder clips, then plugging some code into the Pi to test for high/low signal on the port, I actually saw some success! At that point, I plugged my SkyBell back in and gave it another test. After some more futzing with bad connections (these are all temporary), I had it ready and you can see for yourself what happens:

I actually let this program run overnight and left everything connected as sort of a burn-in test. When I woke up, everything still worked perfectly. Oh, and I will post the current code for coupler.py but first, let me show you an overview of the (really crappy/ramshackle) setup:

As promised, here is the code in all its glory. Please note two things. One, the pull_up_down bit; this is something I may switch back over to use gpiozero since it looks so much cleaner. Two, the gist (which will be versioned as I make updates) is available here.


import urllib2
import time
import RPi.GPIO as GPIO
from time import sleep

PIN = 17
GPIO.setup(PIN, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
coupler = True
couplerLast = True
startTime = time.time()
elapsedTime = 0

sonosPath = urllib2.quote('/sayall/there is someone at the door')
sonosUrl = '' % sonosPath

print sonosUrl

        while True:
                if GPIO.input(PIN):
                        coupler = True
                        coupler = False

                if coupler != couplerLast:
                        if coupler:
                                elapsedTime = time.time() - startTime
                                print "Elapsed time: %01.2f" % elapsedTime
                                startTime = time.time()
                                print "DingDong! Sending to SONOS..."
                                req = urllib2.Request(sonosUrl)
                                try: urllib2.urlopen(req)
                                except urllib2.URLError as e:
                                        print e.reason
                        couplerLast = coupler

After all this was set up, I had to move on to the next step (which, if you’ve looked over the code is already present).

To get that going, I installed an excellent library that is still in beta but worked AMAZINGLY well once I had the right configuration: node-sonos-http-api. More or less, this is all I had to do in order to get it installed:

cd ~/Desktop/
git clone https://github.com/jishi/node-sonos-http-api.git
cd node-sonos-http-api/
curl https://raw.githubusercontent.com/creationix/nvm/v0.23.2/install.sh | bash
source ~/.bashrc
nvm install 4.0.0
nvm alias default 4.0.0
npm install

Then, to configure it for text-to-voice, I had to set up an account at VoiceRSS, then create a settings.json file and put my VoiceRSS API key in like so:


Once I did that, I was able to start it up and leave it running even if I log out:

nohup npm start > node-sonos.log &

Assuming your SONOS network is discoverable on the same WiFi network your Pi is connected to, what you’ll notice (or at least, what I saw) from the output of the node-sonos-http-api server was that it immediately detected the SONOS, found my “rooms” (living room), and was ready for use right away. If you have any issues with this setup, I suggest you read over the documentation provided on the repo. In fact, since the repo is changing all the time, I suggest you keep an eye on it either way if you plan to use it!

Now that I have it set up to work off of the SkyBell button press, the script above basically tells the SONOS to say, “There is someone at the door” in a British accent and it does so while temporarily pausing the music that’s playing. How cool is that?

What I have in store next is a magnetic sensor for the gate itself. When that opens/closes, I plan to play wav/mp3 files out of the audio-out jack of the Pi. What will it play, you wonder? Halloween sounds on Halloween, Christmas sounds around Christmas, and random other stuff the rest of the year! That’s the idea anyway. I’ll keep brainstorming.


  1. The 8 seconds is intentional from SkyBell’s end when the “Digital Door Chime” setting is enabled from the SkyBell app. If that’s turned off, the “low” (0-volt) happens for a fraction of a second.

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.