Happily, the new unit does seem to stay better connected to our WLAN. In the past I was not comfortable evaluating the behavior of the Doorbot+client application given the questionable connectivity. At present the network connection seems sufficient to examine the behavior of the system as a whole.
I have the DoorBot client application installed on a variety of devices:
- Nexus 4 Android mobile phone (Me)
- Nexus 5 Android mobile phone (Mrs)
- Nexus 7 Tablet (2013)
- 4th generation iPod Touch
- iPad with Retina display
The fact that I’m using so many devices may be a little unusual, but I would expect that many families will use 2-3 devices, most likely a couple of cell phones (his & hers) and a tablet. Although a family with kids may well have more than this.
Setting up the DoorBot involves creating an account with the companies monitoring service, then getting the device connected to your local wireless network.
First, you give the Doorbot a name and select the correct time zone for your location.
Next, you have the handheld device connect to the DoorBot when it’s in set up mode. In this mode the DoorBot broadcasts an SSID that includes “DoorBot_” and the last several digits of its MAC address, making it easy to pick from the list of Wifi signals in the area.
Once connected the app prompts you to select your Wifi SSID. When a signal is selected it prompts for the encryption key, then programs the DoorBot to connect to that network. Once the process is complete the DoorBot is connected to your WLAN.
Given our initial troubles, I went through the Wifi setup process a number of times, on various devices. The user experience with the client varies between the iOS and Android versions. I found that the iOS experience was a little more refined overall.
If you make a significant change to your wireless network, for example a change in SSID, RF channel or encryption key, it will be necessary to reset the DoorBot and go through the Wifi setup anew. The reset process is very simple. It requires that a small recessed switch on the back of the unit be pressed with a pointy object. To access the reset button you must remove DoorBot from its mount.
DoorBot includes a plastic mount and a variety of hardware that’s intended to accommodate mounting to different surfaces. As our DoorBot is mounted to a square steel fence post ours not a typical installation. Nonetheless, I was able to drill some holes and get the mounting plate firmly attached to the post. Most installations should be easier than what we experienced.
The DoorBot itself is secured to the plastic mounting plate with a single Torx type screw at the bottom of the device. The kit includes an appropriate Torx screwdriver. The company refers to the bottom screw as a “proprietary security screw” but I expect that a suitably silly thief could easily make off with a DoorBot. The company has stated their confidence in the mounting scheme, offering to replace any DoorBot that is stolen.
The DoorBot client apps supports subscribing to the updates from multiple DoorBots. Additional mobile devices can connect to the company’s service using only the email address and password for the account. Once logged in they see all of the DoorBots registered to the account.
You can select which DoorBot will “ring” each client. For each DoorBot you can access a call history and rename the device if desired. In the iOS version of the app you can also see battery status for each DoorBot.
Your DoorBot account can be accessed via the web, in which case you can also see that battery status of the associated devices.
You can also invite others, giving them access to your DoorBot. The company calls this “sharing” access to the DoorBot. It’s how I gave Stella access from her Nexus 5 using her email address as a login. It’s easy to see how you can give access to family or guests on an as-needed basis. of course, they must install the DoorBot app to their handheld device to take advantage of the invitation.
The client apps are all independent, each one unaware of the status of the others. They all ring in parallel when the button is pressed. I wish that the client app would inform the user how many client apps are actively subscribed to each DoorBot. There may be times when others in the family are off-net or otherwise unsubscribed. There’s considerable value in knowing that yours is the only handset still receiving DoorBot status updates. After all, since it’s not a phone, there is no voice mail to fallback on.
One of the first odd behaviors I discovered with the service & the client app is that it will “ring” multiple clients, but when one client answers the remaining clients continue to ring. If you have a number of clients in you immediate vicinity this can be annoying.
The DoorBot client had another unfortunate behavior with respect to Android devices. Once it has been running it defeats the devices ability to automatically turn off the display. Thus once you answered the door your device would stay lit indefinitely, running down its battery in record time. This was the very first thing that I reported to the company, who were just in the process of putting up a ZenDesk site to track their issues.
One evening I was away from the house taking a class. As it my habit I put my cell phone on vibrate so as not to disrupt the class. Unfortunately, the DoorBot client app does not take notice of this, so when a late delivery came to the house my cell phone “rang” even though I was not at home and my phone was set to vibrate. Had I known that the DoorBot app didn’t adhere to system wide notification setting I could have disabled the subscription to the DoorBot or even stopped the app, but that should be unnecessary.
On the iPad I find it awkward answering the DoorBot . There is a visual notification of the DoorBot activity, but then I have to enter the passphrase to unlock the iPad, go into the DoorBot app and accept the incoming call. It’s a process the has more steps than my wife will tolerate.
For example, as of today the iOS version shows me a battery status where the Android version does not. This is significant since a dead DoorBot is of no use at all.
For each device there are few settings and status indications, including name, time zone and call history.
While the device was actually sending a video stream I noted that my router indicated around 500 kbps in outbound traffic. That seems about right given that the DoorBot camera is said to be sending a 640×480 pixel stream.
Rather than comment directly on the quality of audio and video experienced when using the DoorBot I’ve decided to show an example and let you come to your own conclusions. This sample recording starts with a walk through the client app before proceeding on to an example call from the Doorbot.
It was actually quite difficult to capture this example video. This is the best quality result of a number of attempts to capture the output of the DoorBot client app using various devices. This particular recording was made using my Nexus 4 Android phone. It’s display was capture into Wirecast in a fashion described previously.
It happens that there is no audio with this recording. That’s the result of something about my recording setup. I was going to try to record another example, but then it occurred to me that I’ve never heard legible audio from the DoorBot, so it wasn’t worth the effort.
The only edit in the video clip was to eliminate a long delay between the overview of the client app and the incoming call from the DoorBot.
A decade or more of dealing with SIP and H.323 devices both personally and professionally has given rise to expectations of device performance. With IP phones call setup and tear-down can be frighteningly fast. Further, the media quality of calls passed over a well-managed, pure-IP pathway can be outstanding. With respect to signaling and media handling DoorBot completely fails to keep pace with my desk phone, even my oldest, cheapest desk phone.
There’s considerable latency in response to a button push at the DoorBot. There can also be many seconds of latency in the passing of the call media, which I can only presume always goes via their media proxy. If Stella or I are racing to reach our phones, or fumbling with unlocking the iPad or what-not, that can add more time before the person at the gate has any indication that someone is responding to the button press.
The push-to-talk functionality that’s supposed to allow us to address the person at the gate also suffers substantial latency. When the button is pressed it can be 15-20 seconds before the person at the gate gets any form of a response from us.
I accept that my expectations, arising from experience in telephony and video conferencing, may not be valid in this context. So I polled our regular Fedex and UPS drivers about their experience of the DoorBot at our house. I was careful not to taint their opinion with my own. I expressed my enthusiasm for this fancy new doorbell and asked what they thought.
Each of them felt that a much more immediate response to the button press was required in order to convince them to wait at the gate. Given a delay of more that 5-6 seconds they would assume no-one was home and depart. In some cases that would be fine, since they would toss the packages over the fence. In other cases, most especially when a signature is required, their departure would be a considerable inconvenience.
The feedback from the delivery drivers helped me to solidify in my mind the difference between DoorBot as a tool or toy. It brought into focus the question of novelty or necessity. If you work from a home office and routinely deal with couriers then you need a reliable tool that provide them quick feedback that you’re there. If the traffic to your door is if better described as “friends and family” then DoorBot and it’s ilk are cool and kind of fun.
The experience of using DoorBot has also highlighted the value of voice over video. Seeing who is at the gate is not nearly as important as being able to quickly confirm that we’re home. Immediacy of contact is critical. Voice alone is adequate. In fact, interaction with the person at the gate is likely more effectively accomplished in a pure voice mode of operation.The fact that the device only interacts with a smart phone app is as much a limitation as a feature.
We certainly gave DoorBot a solid try. We made a real effort. We had it installed for over 90 days and tried two different hardware devices. We took sensible steps to extend our Wifi in support of its use. We engaged the manufacturer to deliver feedback even when they were not prepared to be so engaged.
We suffered through a number of software quirks and shortcomings. Too many to describe here in fact. It’s possible that the company will eventually resolve all of the issues users bring forward, but they don’t seem to be moving very quickly or communicating well with customers. They have not, to my knowledge, laid out any kind of road map describing how or when they are to address the issues that have arisen. In fact, in private correspondence the company has stated that their development plans are “private and confidential” which is a stance that I find most unfortunate, even unwise.
In the end, DoorBot simply does not meet our needs. We hope that by sharing our experience we can help others to decide if it might meet their needs, without going to the effort of evaluating it themselves.