Getting your $%*# Ring Doorbell hard-wired

by Thomas Brady in , ,

I got a Ring Doorbell as a gift recently (thanks, Mom!), and, after about 4 weeks I’m finally satisfied with its installation!

It’s not hard to find people complaining on the internet that their Ring Doorbell installation isn’t working. The design is… not great. There are spring pins on the back of the device that are meant to make contact with copper pads built into a mounting bracket. You mount the bracket to your wall, terminate your wires into it, and the pads channel the signal/energy through the spring pins into your fancy doorbell.

That is, if it’s all working.

Based on my experience, as often as not, or perhaps more often, the spring pins won’t make contact. There are lots of reports online of similar situations, citing warped brackets. The mounting bracket itself is quite thin, and if you’ve cranked down the mounting screws, internet wisdom states, you can warp the bracket, thus deflecting the plane of the copper pads, making it difficult for the pins to connect.

I removed the bracket. I re-attached the bracket, careful not to over-tighten the screws.

I did it again.

And again.

There was a brief window in which the device decided that it was, in fact, hard-wired (you can tell a few ways, including the white ring around the button staying lit full-time, and a couple places in the app reporting that the battery is begin charged and/or explicitly reporting that the device is “hardwired”). Despite not touching the device, this window closed.

I had an idea. I would “fluff up” the pads with pillows of solder, like so:

 My solder-pillowed mounting bracket

My solder-pillowed mounting bracket

The pins would surely make contact now, right?

Right! The ring stayed lit! The app reported being hard-wired! I was a genius! 

I decided I should document my fix for fellow fancy doorbell owners online. 

I removed the Ring Doorbell from the mount, and found… broken pins. The “pillows” were too fluffy, it seems, and the action of attaching and/or detaching the unit from the mounting bracket was enough to break a couple of the pins. I was defeated. And probably for good. My modification was surely warranty-ending, and since I had not purchased the doorbell myself in the first place, even trying to get it replaced was probably not going to be fun. 

At this point I had two choices. I could continue using the doorbell “wirelessly,” (i.e. removing it from its bracket periodically to recharge it via USB cable), or I could take a chance on a more extreme fix. I think you can guess which way I went.

I broke out my volt-meter, and set about figuring out the pin assignments of those copper pads. The circuit board was fairly easy to see, and didn’t appear to have any components onboard, only traces. If you hold it up to the light just so you can make out the trace paths. Looking at those and testing things out with the volt-meter, I was fairly certain that the left three pads of the middle and lower sets were the only useful pads, and that three of them went to each screw terminal, like so: 


So, reversing that pattern, I soldered wires directly into the back of the doorbell; yanking out the spring pins and soldering wires into the pads beneath. Then I cut out enough of the mounting bracket (including the board with the traces and terminals) to make room for the wires, and twisted the 6 wires from the doorbell into the two from the wall. 

The white ring shone. I was, once again, restored my genius status. 

So, warranty be damned, I’ve got a working fancy doorbell, and a good story to tell. 



A request came in the comments for a photo of the finished wiring. I’m not sure how helpful this will be, as it’s a pretty ugly soldering job, but here you go (below). It’s difficult to see what’s going on in the photo, but I essentially have three wires soldered onto the terminals that I shaded green in the photo above, and three soldered onto the terminals shaded yellow. Each set of three is then twisted together with each other and with the lead coming out of the brick.


One thing I didn’t think through about this approach is that if I ever need to reboot my doorbell, I’ll need to figure out if Ring has a hard reset button (don’t think they do) or cut these wires.



by Thomas Brady in ,

So, uh, yeah...

I seem to have done that oh-so popular thing where you abandon your blog and only tweet from time to time instead of having fully-formed thoughts.

Well, this didn't fit into a tweet, so, I'm back! I hope.

If you ever, say, write a sketch to an Arduino Leonardo that randomly sends keyboard and mouse input to a host computer, for the purpose, let's say, of making that person think that their keyboard, mouse and/or computer are malfunctioning, you might later find out that if you didn't wrap the HID-mode stuff in your Arduino sketch in some sort of enable/disable functionality that it's now nearly impossible to write new sketches to the Leonardo.

If you do find yourself in such a pickle, and you happen to have an AVR Dragon (or similar), here's the way forward: install avrdude (brew install avrdude if you're on a real computer) if you haven't already and issue a commmand similar to this one (I leave it to your capable hands to change what needs to be changed):

avrdude -v -patmega32u4 -cdragon_isp -Pusb -Uflash:w:/Applications/ -Ulock:w:0x2F:m

The Electric Imp-spacebrew-nod-uino

by Thomas Brady in , ,

I've been dying, ever since a couple of the core contributors visited frog Austin a little over a year ago, to play with Spacebrew, and in yet another skunkworks bit of hacking at work recently, I finally got to.

We, the secret snooping society, want to fill the Austin studio with sensors of varying type and scope, and we wanted it to be very easy for people, once they've found us out, to play along. This is a perfect fit for Spacebrew, which aims to make interactive spaces, exposing data via a simple API. One rig can be set up to be a data "publisher," and, without permission or help of any kind, anybody that can reach that server via a network/Internet connection can write a "subscriber" that can do whatever it likes with that data (usually, visualizing it).

As I was building this out (our project used a simple proximity sensor to track motion near the elevator, as a proxy to counting elevator trips), I realized that we also wanted historical data. Spacebrew is a super convenient way to provide real-time data, but it doesn't have any affordances for persisting data. So, I built a Node.js server that both acted as the Spacebrew publisher, via the javascript API, and write data to a mongoDB.

I also finally got to play with the Electric Imp, a nifty little WiFi-enabler.

You can read all about it, and get all the source code, on github, but here's a short walkthrough of how it works (from the "What does it do?" section of the project's README):

  1. Use an Arduino to power a proximity sensor as a motion detector, and, when it sees motion, send a command over serial to an
  2. Electric Imp, which throws an event over the Internet to
  3. Electric Imp's cloud service, which we've configured to exposes an API that rolls up and reports these events upon HTTP GET, which
  4. Our Node.js server polls, and upon finding new events, acts by both
  5. Writing a record to a mongoDB and
  6. Forwarding the event to
  7. Spacebrew

Up to this point we have built a Spacebrew publisher, that happens to also persist data (something not typically included in Spacebrew).

We have also included an example Spacebrew subscriber, in the form of a web app that uses the Spacebrew javascript API in order to increment a count of movements observed. Our web app first polls our Node app to get a historical count for the day, and the timestamp of that last movement. The real-time Spacebrew updates then increment this historical count, and reset the last-movement-seen clock.