I recently finished my project to replace our doorbell with a Raspberry Pi. Currently it supports two switches, one at the front door, and another at the back door. The latter isn’t quite working yet because I lost the screws for the switch. I’m pretty sure that they’re on my desk somewhere among the detritus of a half dozen unfinished projects, and piles of assorted junk…
- Supports illuminated LED switches
- Each switch can play a different sound
- Integrates into OpenHAB (home automation)
- REST service control to play alerts, and speak via espeak/TTS
Below is the final circuit on a 3d printed base that is approximately the same size as the original doorbell. The lower-left side of the board is a LM386 audio amp that I was going to use with a small speaker that I had. It sounded good at my desk, but not so much in the living room. It just wasn’t loud enough, so I opted to go with a small, cheap pair of amplified computer speakers, leaving the amplifier on the board unused.
This schematic is roughly equivalent to what I built. I’m a noob with gschem, so I apologize for the quality. In order to allow the switches to be illuminated using the existing wiring, I’m using a comparator to detect the voltage drop across the LED’s in the switches. The pot controls the trigger voltage. The output LED’s were in my prototype, but not in the final build. The circuit runs at 5v so, both outputs have voltage dividers to limit the output to 3.3v for the Pi’s GPIO. Only one is shown in the schematic.
Below is one of the switches that I modified to replace the incandescent lamp with LED’s.
The original doorbell was a traditional solenoid that would strike metal chimes. It ran on low voltage AC. I replaced the power supply with 5vdc.
Once the doorbell was up and running, we noticed a problem. The back door would ring every so often. The switch wasn’t connected yet, so it wasn’t real. It seemed to happen often when the AC would kick on, likely caused by noise being induced into the wiring. During the initial design, I considered the possibility of this, and similarly, dealing with the switch de-bouncing, and thought about implementing hysteresis in the comparator, but I figured I could just deal with it in software… (LOL!) which leads to the second problem. I coded up what I thought would handle the de-bouncing and noise rejection. It didn’t work! After some hours of debugging the code (I couldn’t reproduce the problem, so I had to insert debugging code and wait for the ghost switch presses to occur), I learned something interesting. The code is written in Python, using interrupts on the GPIO. My code would interrupt on the rising and falling edges of the signal and compute the time that the switch was pressed. Unfortunately, you can’t tell which edge triggered the interrupt. I read a post where someone suggested that you could read the state of the pin at the beginning of the interrupt handler. My problem was that, from the time the interrupt was raised, to the time that I read the pin, the state had changed! This caused all kinds of chaos. Once I knew what the problem was, the fix was pretty easy.
The next thing was to hook it into the home automation system. This was pretty easy to do with OpenHAB’s REST API. I just created Contacts for the switches and and made the doorbell send state changes via REST. For now, I just have it sending alerts to our phones when someone presses the doorbell. It’s kind of handy when I’m downstairs and can’t hear the bell. Eventually, I might make it turn the porch light on if someone rings the bell at night.