EZVIZ DB1/HikVision HD1 Doorbell with Shelly Uni + general deepdive

I switched from Ring and Nest to the EZVIZ DB1 smart doorbell, because I wanted to eliminate a cloud dependency from the basic camera/doorbell functionality in my house. This doorbell has come up in these forums several times. I solved the button press issue by creating a smart doorbell push sensor using a Shelly Uni. I also did a fairly comprehensive review of the available compatible apps, plus a pretty thorough traffic audit, and I dissected the firmware a bit.

I finally have a smart doorbell that works both as an IP camera and a doorbell, with local HA integration, and reliable low-latency two-way phone comms. It’s not a perfect product, but when fully configured and combined with HA and Frigate, I think it is the best solution available right now.

I took detailed notes while I got everything working, and have written it all up in a detailed report. It’s a little long, but you can skip to the bit that interests you. Hopefully this guide will contain something useful for anyone currently using the doorbell, and anyone considering buying one.


Wow, thanks for this detailed report. Just a week ago I pulled this camera out of my drawer again. Where I put it after finding out catching the button press reliably was a pain. With the help of your guide I may finally find enough willpower to actually put it to use! :wink:

Thank you very much!

1 Like

Great read @seanblanchfield,

Thank you for taking the time for a very concise deepdive.

Here not using the built in PIR or mobile apps anymore and went to an external facing the door 433Mhz PIR connected to a Sonoff to Tasmota 433Mhz hub which works better for me these days.

Amazing write-up, thanks @seanblanchfield!

I’ve had the DB1 for several years now and have always completely firewalled it from any outside internet access. Since setting it up in Frigate and HA, I haven’t missed any of the features it would provide, apart from one.

I’ve poked around at various times over the last couple years to try to find a way to toggle the blue LEDs around the button (so I could automate it through HA of course!). The control is available in most of the apps, but I wanted local control. I found the pyEzviz package last year but unfortunately it just talks to the cloud.

From what I can tell, it’s likely some MQTT message that the doorbell receives to enable/disable the LEDs. Did you dig any deeper than I did?


Thank you for posting such a comprehensive Blog regarding the EZVIZ DB1.

I have a Hik-Vision CCTV system which uses many of the same technologies. I have an Enterprise class firewall solution at home. I split my home network into three separate subnets, with full Firewall segregation between: Computer_LAN, IoT_LAN and CCTV_LAN.

The Hik-Vision documentation regarding required Service Ports is absolutely terrible! I’ve spent countless hours reviewing Firewall logs to discover what’s actually necessary to make it all work properly.

Hik-Vision have an App for iOS and Android called Hik-Vision connect. No port forwarding is necessary.

I hope others find the information below useful.

Defined Protocols:

Defined Rulebase:

(wouldn’t let me post two images in the same response).

Wow great info. Thanks for sharing. I think it mostly supports my conclusions about what the different traffic is. It doesn’t cover all of the traffic I observed the doorbell generating (e.g. the voice traffic and mqtt traffic), but there certainly seems to be a lot of overlap.

I second your approach of isolating the doorbell from other devices in your house, just to be on the safe side. I’m using Fresh tomato firmware on my router, and have put the doorbell on a virtual wifi for IoT devices. This IoT virtual wifi has “AP isolation” turned on so clients connected to it can’t see each other, and it is mapped to a vlan that prevents communication out to other vlans in the network. All it can do is talk to the internet. I haven’t bothered to restrict its internet access.

This write up and others have saved me so I’ll share a few notes. Thanks to all who contrubute so much, I’m trying to add some insight and admit I lack etiquette and form. I mostly learned from Sean’s contributions and those he credits. I chose to lean on the DNS trigger as it has been flawless unless I fiddle, but that’s not tested long term. I would next build a current (Shelly/GPIO) box for than and include my back door, different cameras, and another “input” if I went that way.

  1. I ran a pihole to scrape DNS logs becasue I didn’t want to depend on my main firewall (pfsense) and it’s so easy to spin a container for pihole and tell pfsense to send DNS for whatever clients to whatever pihole(s) …plenty of good reasons to have those to play with

  2. it works to flawlessly notify HA of dorrbell pushes for me so far. At first without being selective on syntax I’d get 4 triggers because the logs are showing responses and cached responses… so first hit is 3, then w/ cache subsequent were 4. you need to add the while read;do echo “$REPLY”|grep -q -F “query[A] alarm.use.s3.amazonaws.com” syntax to avoid this, looking only for the initial log mention of that url.

If you play with your doorbell (using ivms or batch)… it needs to get rebooted to send the request reliably once again. I suspect that it wouldn’t call home to the app either if it didn’t hit the pihole/DNS but haven’t proved that yet. Anyway, it works, but if you fiddle to test, give it a reboot.

I never saw a difference in detection, no matter what zones I drew, between the ONVIF detections thatw ere published. I would invite anyone to paste a

. I would love insight on that. According to Sean

A few different entities will be available over ONVIF:

  • Cell Motion Detection. I believe this is video motion detected by the doorbell in the motion detection zone that you may have set up from the desktop configuration tool (screenshots in the Desktop Configuration Tool section above)
  • Motion Alarm. I believe this is the PIR sensor.
  • Field Detection. I don’t know what this is. It has never detected anything for me.
  • MainStream and SubStream. Camera entities for the low/high resolution stream. I recommend disabling these entities to help you avoid accidentally using them somewhere and consuming precious streaming connections.
  • Reboot. A button that reboots the doorbell.

But I see not difference in my logs in HASS betwen the detections of cell and motion. I agree the others do nothing. I’m using the 200321 firmware too because I want the sanpshot url, but admit I didn’t see if the detection ONVIF signals were different on other firmwares.

so other hints/notes:
-I run my container for pihole in LXD on QNAP, super slick, zero-time reboot, SSH, webmin, CRON
-you can send all kinds of notifications using TTS alarm notification, actionable notifications with links to the camera app or the feeds for HASS or your other cameras. Without cloud (outgoing only) you can push notifications to the public internet and then from your phone with VPN or whatever (no cloud) do everything but speak back through the MIC. I would LOVE to intercept that call and route by Voip/webrtc to the phone as the apps (terribly) try to.

here’s my bash on the pihole to catch the doorbell presses and fire the automation

#! /bin/bash
tail -fn0 /var/log/pihole/pihole.log | while read;do echo "$REPLY"|grep -q -F "query[A] alarm.use.s3.amazonaws.com" && curl -X POST -H "Authorization: Bearer 0011XXsuperinsanepassword0011" -H "Content-Type: application/json" -d "{\"entity_id\": \"automation.00_doorbell_push\"}" http://192.168.517.615:8123/api/services/automation/trigger;done```
1 Like

Thanks for the great info Matthew. Here is what my “cell motion” sensor vs “motion alarm” looks like. They are nearly identical, but there are some minor differences. I agree that drawing zones in Batch Config Tool etc doesn’t seem to make a difference.

I’m afraid I haven’t looked at this in great detail since my initial installation, because my doorbell faces a public footpath and this makes the motion sensors too noisy to be useful to me.

Yeah, same here. I use another camera for that “space” and plan to test other firmwares but need to get their support to flush/clean my accounts, separate issue. Have to work as a guest…one (small) reason (of many) I wanted to get it un-clowded.

Have you heard/found any discussion on intercepting the call? Since, using the app, you can call into the doorbell it seems certain that you could achieve a 2-way call in response to the electrical or DNS signal, or anything esle…somehow…

I haven’t seen anything about intercepting the call. The closest post is user RapidGorilla on IPCamTalk saying that he intends to replace the firmware on the device. If that turns into a project with a few people working on it, then it would be one to watch.

Here’s what I can offer regarding the “intercom” functionality (largely covered in the “security” section at the end of my post). I believe the video and audio displayed in the app is the regular RTSP feed, but that the two-way intercom is an entirely different protocol (which means there is some redundant data - the caller voice is being transmitted both in the video stream and in the intercom stream). The RCA Security app makes this pretty apparent, as you can start voice even when the video feed is turned off. From my traffic analysis, voice traffic is running over various TCP on ports like 12XXX, 7300 and 7900 to different servers than are used for the other doorbell functionality. The intercom implementation seems to be disjointed from the rest of the device’s functionality, but a lot of things about this device seem disjointed. There is however a possibility that it is a 3rd-party solution used by HikVision.

I just took a look at my original wireshark traffic captures. It looks like the TCP intercom connection is initiated on-demand by the doorbell. Perhaps a MQTT message from the control server to the doorbell, which immediately precedes this connection, contains an instruction to start the intercom. Overall, I think intercepting the intercom would require fairly significant back engineering of the app, so that a new client could be written that could authenticate with both the control server and the intercom server, signal the control server to start the intercom, and then know how to encode and decode the intercom stream.

Sean, if you’re able, it would be VERY helpful to post a direct link to the Hikvision batch tool version One simple way is to grab the link, search on archive.org and ensure archive has saved a copy. Then post a link to the archive :wink:

I (and many others) literally cannot use the link you gave.

Thanks for the feedback Pete. I’ve updated the post with a direct link to the exe on archive.org, and I’ve also posted the link to it on Nelly Security (which I’m 99% sure didn’t work for me originally, but works fine now).

1 Like

OK, next item not easily found: firmware 200321 for Hikvision DS-HD1… got a link?

It appears to be here: http://usdownload.ezvizlife.com/device/DS-HD1/2.0/DS-HD1.dav

I can download that file without issue now, although I recall I initially had to go through a North American IP address to get it. Anyway, DM me if you can’t download it.

1 Like

Got it, thanks! I’m at a US IP address already :wink:

I’ve successfully switched to the HIK 200321 firmware. Some key hints I’ve not seen clearly documented:

  • For me, the upgrade failed until I did a reset (push cam button 10 seconds) and connected to the cam’s built-in wifi. (Note: it’s at
  • Even with the upgrade (via Batch Configuration) saying it worked… nothing actually changed until I did a physical reboot/reset – again using the cam button. Clicking “Reboot” in the app left it still on the EZVIZ_xxxxx wifi.
  • Best bet after successful FW change (you know it happened when the EZVIZ_XXX wifi changes to the HIK wifi: again connect batch config to the hik wifi, change that wifi to EZVIZ_xxxxx and pw EZVIZ_… - and use one of the apps (i used EZviz) to do initial config the “normal” way at the cam. That enabled audio, physical chime (which I have) , and proper wifi connect.
  • (Reminder: AFAIK, do NOT upgrade to newer FW and do NOT further change the PW
  • Even though the FW changes to 200321, the version numbering remains as 5.2.4 from the EZVIZ install. No idea how or why :wink:
  • AFAIK, Motion Detect in the HIK Batch Config software doesn’t do anything

Finally I solved all the problems.
I threw the EZVIZ DB1 in the trash and replaced it with the Reolink Doorbell; Light years ahead.

1 Like

I’ve got a set of questions that (AFAIK) are not addressed in your deep dive, nor have I seen them elsewhere. I wonder if you have any thoughts:

  1. Wifi security protocol

WPA vs WPA-2 – I have Unifi AP’s and controller. Reasonably good stuff. It claims to be set as WPA2-PSK. And that’s what my phone tech-analyzer SW says.

YET: Batch Configuration claims to be set for WPA-PSK ??!!

Have you ever looked at this?

  1. Time - DST

I thought the cam was set to auto-change. At least the config says that…

…but it didn’t (last weekend). I had to go in and update.


  1. Perhaps most important (last because I was sure I’d remember this :wink: )

Nobody talks about sharing the doorbell APP with multiple in-home adults…
…nor how to cleanly reset/update if the cam reboots

Scenario: power outage.

Symptoms after power restoration:

a) My Blue Iris reconnect perfectly
b) My phone App (guarding vision) no longer connects nor receive alarms
c) And I’ve never worked out how to share the config with another person’s phone

This seems silly. Aren’t there simply some basic network/SN/whatever params that need to be entered into the app?

In the interests of “simplicity” they all seem to require resetting the camera, to enable the app.


(related thought: any chance a reflector could be used by an app using tricky proxy of some kind? :wink: )

  1. Wifi security protocol

I didn’t notice or look into this. I think WPA2 is back compatible with WPA clients, but WPA (v1) is nearly 20 years obsolete now. Perhaps Batch Configuration has mislabelled the setting (I hope so!). Can you explicitly block WPA1 clients in your Unifi AP?

Time - DST

Mine updated to DST without intervention, and is currently accurate.

  1. Sharing app between users

My wife and I both use the Guarding Vision app and we don’t have difficulty with doorbell reboots. We use Guarding Vision on Android, and I have shared the doorbell with her from the app, with mine as the master account. IIRC it just worked. We haven’t had problems with power outages breaking anything. If fact, I have a “reboot doorbell” button on our HA wall panel that cycles power to the doorbell circuit via a Shelly relay. It doesn’t cause us any issues on the rare times we want to reboot it.

In terms of how to do the sharing, there’s multiple sharing options in Guarding Vision here, which work well for me. Maybe you are seeing something different.

(related thought: any chance a reflector could be used by an app using tricky proxy of some kind? :wink: )

I’m afraid I don’t understand what you want to solve with a proxy here.