Recently I purchased a set of Ring branded doorbells and chimes from my local hardware store. While I wasn't drawn in so much by the idea of a doorbell, I wanted something where I could have a chime inside and a chime in the shed so that I could hear visitors. I also wanted something that plugged in to the powerpoint so I wouldn't have to bother with batteries. I found that my local offerings consisted of basic battery operated doorbells and video doorbells, without much inbetween.
The concept seemed simple - connect these things to a wireless network and link them so that pressing the doorbell will sound the desired chimes. It is worth noting that their design would allow you to have multiple doorbells with multiple chime units that could be shared. This seemed like a good design idea for larger sites or gated communities.
Unfortunately, initial configuration of these devices was anything but simple. I first tried it on my phone. The application would ask me to connect to the wireless network presented by the device during setup. I would do this, it would connect, and then the application would go back and ask me to connect to the device's network (that I was already connected to). As a possible troubleshooting option, I tried turning off bluetooth and cellular data on my phone so that data would only go via Wi-Fi. No luck. I then checked the configuration of my wireless network as their help centre suggests setting them to channel six during setup - no luck here either. I then tried my tablet - same behaviour.
Thinking this still might be an Android version issue, things got a bit drastic. I booted up Bluestacks to emulate an Android 7 device, disconnected all my networks, and then connected to the wireless network of the Ring device only. Still the same behaviour. As a last resort, I then borrowed someone else's phone. Suddely it all worked as easily as the packaging suggested it should. The device was located, configured and working. In no time, I was flicking through trying to find chime sounds that actually sounded like a doorbell. This was proof that the devices could work, but there was something else at play.
I experimented a bit more and ended up figuring it out - the Ring application works on Android 5, but not Android 4, 7 or 8. I didn't have anything with Android 6, so that wasn't tested. Come on Ring, you think you'd test your application on more than one Android version?
Ok, this thing is 'working' - it's connected and performing its most basic task of being a doorbell. I connected the doorbell to an optional plugpack (not supplied). It puts out 15v with a 1.5A current rating - the voltage is well within their advertised spec. They don't advertise a current requirement, but 1.5A seems, uh, amp-le? The application still shows the doorbell as running on battery. Strange, the contacts on the doorbell mounting have the voltage present, why won't it use it? Oh well, lets move on. How does this thing tick?
First up, these show up with a wide range of MAC addresses, all owned by Texas Instruments - a well known semiconductor manufacturer. This tells me that Ring have decided to adapt an existing hardware/software platform - nothing wrong with that. Plenty of companies do this. Lets go deeper. How do these actually interact with the local network? Does the doorbell broadcast or multicast data to tell the chimes to Ring? That would be sensible, but it's not what happens. When you press the doorbell, the doorbell connects to the wireless network. Once connected, it then contacts an assortment of Ring's servers (running on various Amazon EC2 instances) via HTTP. It also initiates a SIP session to one of these to pass through H264 video and G711 audio. O-kay, why is this going across the world and back to get from my front door to my lounge? Beats me, but it sure as hell means it won't work if my internet is down, and probably won't work if there is a lot of traffic. Cool, so I've invited friends over to watch movies on Netflix with my limited bandwidth, and this might mean my doorbell won't work? Queue the slow clap.
Ok, enough sarcasm, lets look at the chime units. I haven't had the time yet to quite figure out how these work. They seem to poll Ring servers via HTTPS to detect doorbell presses. In the real world, this means there is up to about ten seconds between the doorbell being pressed and the chime going off - plenty of time for an apathetic courier to give up and take my package back to the distribution centre. Am I being dramatic? Yes, but I did actually time the units, and they did take that long a few times. At some point I'll have to MiTM these units and see if I can make some sense of this.
Back on the doorbell unit, specifically, the range of Ring servers. Pressing the doorbell sends (at least):
- A HTTP POST request to fw.ring.com/doorbots_api/dings?api_version=6 with an X-RingDeviceType header, no POST data and with HTTP basic authentication - we'll revisit this in a moment.
- A HTTP POST request to fw.ring.com/doorbots_api/motions?api_version=6 with similar behaviour to above
- A SIP registration to another Ring server. I think it was api.ring.com, but I can't recall 100%
When you open the Android Ring application to check who is at the door, the application first checks your account access with billing.ring.com, and then chats to alerts.ring.com to get the alert data. If you jump in to 'live video' - and I use this term loosely - the application will chat with api.ring.com via SIP.
At this stage, I am still investigating how these devices operate, with the following objectives in mind:
- Having my doorbell work without having an internet connection.
- Pulling the video feed in to MotionEye to use the doorbell for surveillance. I'm aware Ring offer devices and services for this, but I'm happy with my current offerring. For one, it doesn't rely on an internet connection.
- Capturing doorbell button presses and associated images and passing them in to a Telegram chat. I've done some work with this API before, so I'm comfortable implementing the chat side of this once I can get the data.
- Hijacking the SIP session from the doorbell to route it to my phone using the standard Android SIP functionality.
So, in summary, the concept of this device is good, but the implementation is horrific. That said, it does usually work as a doorbell (images, video and audio not so much), so I'll keep using it for the forseeable future.
I'll noticed some interesting facts along the way, listed below and updated as I go:
- In its DHCP request, the doorbell unit sends a hostname consisting of the MAC address, followed by mysimplelink. Some quick searching confirms that mysimplelink is some kind of SoC SDK for rapid wireless development from Texas Instruments. This makes sense since the MAC addresses used by these devices also indicate Texas Instruments
- The whole doorbell part looks suspiciously similar to TI's application example for a doorbell