Theclosest popular alternative devices are the Nest Doorbell (Wired) and the Ring Pro 2, which in my experience were reasonably good cloud-based cameras but useless doorbells that caused me to regularly miss callers to the house, with multi-second audio lag if I tried to talk to anyone at the door using their apps. In contrast, the DB1 has the potential to be both a great camera and a great smart doorbell.
I managed to resolve this list of cons to my satisfaction, leaving me with a smart doorbell that I think beats any alternative on the market. In this comprehensive post, I provide details on how I did this.
First, I need to acknowledge that I am indebted to the IPCamTalk community and their HikVision Doorbell 101 page. I wish that every super-long evergreen forum thread has someone like David L maintaining a summary that distills out the collective wisdom of the entire thread. If you are planning to buy one of these doorbells, that 101 page will be your bible.
Use of the Shelly Uni to detect dumb doorbell presses is discussed in forums here and here. In these threads, the Shelly is powered by the same source as the doorbell chime transformer, but it is detecting a dumb doorbell (basically a momentary switch), not a smart doorbell. The suggested diagram is very close to one of the configurations documented in the Shelly Uni user manual for AC buttons and switches:
To move forward, I decided make life easier by isolating the doorbell circuit from the Shelly Uni by using a relay. This would split the circuit in two: one half would be the doorbell controlling a relay, and the other half would be a Shelly Uni detecting if the relay was on or off.
On my first attempt I left the power kit out of the circuit, and found that this caused the relay to be unstable. The relay might close spontaneously, or would not open after the doorbell button was released. There was too much current going through the relay coil from the normal operation of the doorbell. With the power kit connected in parallel across the relay, the instability disappeared.
I initially understood the power kit as a resistor that allowed some current to bypass a solenoid, but it is more complicated than that. User @fredkruger from the IPCamTalk forums opened up his power kit and posted a photo:
With the power kit installed, the DB1 could control the relay exactly as I hoped, as shown in this slow-motion video of a button press. You can see the relay closing at the same time that the multimeter measures a drop in voltage across the doorbell as the doorbell closes the circuit (note: I was powering the doorbell with 24V AC during this test).
I found this Shelly forum thread (in German, Google translate version here) in which users @thgoebel and @DIYROLLY discuss the same frustrations of detecting AC with the Shelly Uni, and conclude that it either has a design flaw or that the user manual incorrectly describes it supports detecting AC at its inputs. User @thgoebel makes the practical suggestion to just switch to DC if possible, or if not possible to add a diode to half-rectify the AC signal into the input sensor.
The battery in this circuit should last nearly forever. It is only consumed when the doorbell is pressed. In the Shelly forum thread linked previously, user @thgoebel reported that the Shelly Uni input sensor consumes about 1mA of current. Assuming 2 seconds per doorbell press and 5 visitors per day gives about 1 hour per year of battery consumption. Therefore, yearly energy consumption is about 1mAh. A cheap AAA battery has a capacity of about 850-1200mAh, and would therefore last about a thousand years! (unfortunately, its shelf-life is probably only 10 years ?)
After getting a prototype working on the dining room table with sticky tape and lever wire connectors, I started final assembly. I used a small piece of stripboard to solder the circuit together, with a terminal block to receive the external wiring to the transformer and doorbell. I packed the pieces into a small enclosure as shown, with the Shelly Uni WiFi antenna poking out the top. Finally, I mounted it on the inside of my electrical consumer unit cabinet.
Once everything was working smoothly, I experimented with voltage. I had done most of my testing on 24V AC, but found that I could switch the transformer over to 12V AC and everything continued to work fine. I have left it at 12V ever since.
Many of the download links given in the 101 for various firmware brands (including the HikVision ones) seem to be restricted to North American IP addresses. To download them from Europe or elsewhere, you might need a VPN, to download them from a VPS server, or to get a friend in North America to email them to you.
There are a number of different mobile apps that can be used with the doorbell, corresponding to the various brands that have rebadged it: Hik-Connect (for HikVision), RCA Security (for RCA), EZVIZ, LaView One (for LaView) and Guarding Vision (for Nelly). Here are my conclusions having tested them all on Android (I did not test on iOS).
Having finally found a member of this family of related apps that actually works reliably, I was quick to turn off auto-updates for it in the Play Store, in case a future update might break it. I also used the following commands to grab backups of the associated APK files off my phone, so I could reinstall them if something happens to the app and I need to install them on a new device (commands below are in a Linux Bash terminal with ADB installed and USB debugging enabled on the phone, which is connected by USB).
While testing the various apps I found that I could re-use an account I made on the Hik-Connect app in the RCA Security app, and vice versa. In addition, when I added my doorbell to the Hik-Connect app it appeared in the RCA Security app. It appears that both the Hik-Connect app and the RCA Security apps are frontends to the same backend database where account details and registered devices are stored.
Recommendation: Install both apps. Use the Guarding Vision app as your master account for managing the doorbell and reliably receiving calls from it. Share the device with the RCA Security app, and use it as your main UI for checking out the camera or initiating conversations over it as an intercom.
You can add the Shelly Uni to Home Assistant either via MQTT or via the Shelly integration. If you are using the Shelly integration, make sure to enable CoIoT on the Shelly as described in the integration documentation. This will ensure that Home Assistant is notified instantly when the doorbell is pressed. When added via the MQTT integration, an Input 0 binary sensor was created that represented the state of the IN_1 binary input contact on the Shelly board. I disabled all the other entities, which corresponded to contacts that were not physically connected to anything.
The doorbell provides a hi-def main stream and a low-res sub stream. Only three streaming clients can be active at any one time. The stream URLs are as follows (replace VERIFICATION_CODE AND DOORBELL_IP_ADDRESS with your own values):
The doorbell can be added to Home Assistant via the ONVIF integration (Settings > Devices & Services > Integrations > Add Integration > ONVIF). Home Assistant will probably auto discover the doorbell. If you need to manually configure it, ONVIF is available at port 80, with the username admin and password equal to the 6 letter Verification Code (from the back label of the doorbell).
The doorbell RTSP stream works with Frigate without any special FFMPEG magic. Frigate-Hass-Card provides an excellent UI for viewing the doorbell from within HomeAssistant, allowing you to quickly view the doorbell stream and quickly navigate between and replay recent events.
I found myself more concerned about the security of this device than I was for its predecessors - a Google Nest doorbell and an Amazon Ring Pro. On reflection, I think I was spooked by HikVision being a Chinese state-owned company, but there is really no reason I should trust Google and Amazon products any more than this one. In any case, I decided while writing this post to take a close look at who this device tries to talk to.
A related piece of research is presented in this video from Sharkfest21 (the conference for the Wireshark network protocol analyser) in which Simone Mainardi describes how he analysed traffic from IOT devices in a project that was jointly supported by the European Union NGI and Horizon 2020 research funds. His materials are online at this dropbox link. He monitored the devices using a man-in-the-middle testbed, based on a Raspberry Pi running a bridged WiFi access point (using hostapd), and he monitored passing traffic using tcpdump. He did not specifically test the EZVIZ DB1 doorbell, but found some interesting traffic patterns on related camera products from EZVIZ:
I am experienced with low level networking and peer-to-peer systems. As CTO of Demonware I was closely involved in design and implementation of the peer-to-peer code and hosted platform that connect millions of players in real-time in the Call of Duty video game franchise, and many other video games. Based on my recollection of implementing the ICE and the STUN RFCs for establishing peer-to-peer communication through NATs, I expect a product like the DB1 doorbell to generate the following types of traffic at a minimum:
This passive monitoring approach was pretty easy to set up but many packets were not captured due to the distance between my workstation and the doorbell. This made it hard to confidently analyse what the doorbell was doing.
Excluding
litedev.ezvizlife.com, none of the other IP addresses were discovered using DNS. I tried to find where these IP addresses came from by unpacking the firmware using binwalk, and searching the unpacked contents with grep and a hex editor. The only hardcoded IP address I could find was for a DNS server (which I never saw used).
3a8082e126