Review-Dahua/EmpireTech new doorbell cam Db6l 5mp

Thanks Gary! Yeah mine is also about 7.5' high, but the room is long and I can spot it from 18' or farther. That's also good news, that there is likely more protection inside the camera itself.

Also, on another merry holiday note... HORRAY! I got 2-way talk working in blueiris without needing DMSS/internet/cloud/crud!!! The solution lied in this thread:

2 Way Talk with Blue Iris, please refresh my memory?

Hi Friends, I'm having trouble remembering whether or not I was able to successfully 2 way talk with my Lorex overviews via the Lorex app ONLY OR, that I also successfully did it via BI. Currently, I hear the audio from all cameras, but no one can hear me on the other side when I turn on the...
ipcamtalk.com ipcamtalk.com

When I setup my standard cameras, I fill out the IP and credentials, then hit "find camera" in blue iris, and BI fills out the usual generic RTSP camera type, port 80, etc. The d6bi will work the same way, but then 2-way does not function. I reconfigured using settings like shown in the that thread: Dahua camera type, rtsp main, port 8999, and add &authbasic={AUTH64} for both main and substreams. Once I did that, I went over behind my front door with the BI app opened on the db6i, hit the microphone icon, scratched my phone, and heard corresponding scratches emerging from outside...YIPEE! Now when homeassistant sends me a doorbell telegram, I can open BI and have a conversation with the person.
 
  • Like
Reactions: GaryOkie and flynreelow
Another quick update in case it helps anyone... of course BI 2-way audio is like a walkie-talkie, but also I noticed a lot of lag (like 4sec) in audio output in the BI app. This is the case with the db6i, as well as all my other cameras that have microphones in them. My guess is that has to do with the time it takes BI to process the stream. Since the walkie-talkie process turns off the db6i mic while you are speaking in BI, there is a break in the audio stream. The result is a few seconds after you turn off the green mic in BI, then you hear the db6i audio again.

Why did I think it breaks the audio stream? In BI camera settings for the db6i, I configured the audio to come from a dome camera I already had installed 4' above the doorbell. When I did this, sound returns the instant I turn off the green mic in BI. Due to the lag in the stream getting to the app, when I turn the mic off quickly in BI, I can hear the last few seconds of what I just spoke to the app.

Another observation I made, is the audio from the app to the db6i is very low latency. So low that it explains why some folks talk about loud screeching feedback sounds when they 'self test'. The feedback loop does not include any sound from the phone's speaker... it's actually from the doorbell speaker to the phone mic... the sound returns so fast you get bad constructive feedback in seconds.

A better test to determine if you reached utopia and have a real phone style 2-way is... turn on the 2-way, tap the cam and hear the click in the phone... tap the phone and hear a click at the cam. Don't tap so loud that the phone's mic can hear it directly and visa versa; that's cheating. This makes me wonder what dmss does differently to do real 2-way, without horrible echoes. I'll pay for another support year if BI figures that one out. ;)
 
truglo said:
Unfortunately the unmodified DB6i chime kit was too thick to fit under the low profile cover of my mechanical chime. So I removed the chime kit plastic enclosure with my hands and thumbnails, took a photo, and retried fitting it under the cover. I still couldn't shoehorn it in. So I took it to my soldering iron, carefully removed the large green screw terminal block, then soldered some wires in it's place. I used some VHT tape to stick it in the only place where it would fit. It was still about 1/8" too thick to slap on the front of the chime like I wanted.

View attachment 149021

Anyhow, the background story probably doesn't matter unless you have a similarly compact chime housing that makes it hard to fit a chime kit. OTOH, what may be more of interest to some is the PCB. The choice and connection of the shunts is interesting (prolly cheaper for the 50-50-10 ohm in parallel, vs having a more expensive part on the BOM). The bottom of the PCB is not interesting. It has through holes for the screw terminals (no traces to them), and a large ground plane that connects to all of the vias. You can see what appears to be a replaceable fuse near the green block marked as F1 (T1 perhaps is 1A rating). The larger 6-pin DIP (LCB710) seems to be a 1A 60V 1-pole relay (I haven't seem many silicone relays TBH). The 8-pin package is a 2-channel differential comparator. The 4-pin package in the middle looks like diodes or an opto-isolator to me. So anyways, it looks like an overall robust analog circuit, that should be easy to repair if something comes up.

View attachment 149020

It works perfect with my chime, even without an internet connection. I did have to use DMSS to configure the chime link, but it's isolated now.
Click to expand...

I located my chime adapter near transformer.

Review-Dahua/EmpireTech new doorbell cam Db6l 5mp

wasnt sure since its a doorbell cam and not a regular cam.... True and that may very well be the case. I don't have one to try and I do not recall anyone trying it. I am optimistic though that if it can be brought into BI and it is kinda ONVIF, that we could stumble on the right setting to...
ipcamtalk.com ipcamtalk.com
 
  • Like
Reactions: truglo
Merry Christmas to all!

Tinman said:
I located my chime adapter near transformer.
Click to expand...
That's interesting... do you have an electric chime? My mechanical chime emits a scary buzzing noise, indicating enough current to create problems before long... when I briefly had the chime kit disconnected. It was a bit tricky getting 2 wires under one screw without this happening, and anytime the chime kit came off you could feel/hear the buzz. I posted this recently... shows it's supposed to go parallel to the chime itself:

DahuaWiki

dahuawiki.com dahuawiki.com
 
Yes, mine is electronic. My point was that the chime kit has to be wired into the circuit, but it doesn't care where in the circuit as long as it is installed.
 
I discovered something that may be of interest to those having frequent disconnects; the db6i appears to disconnect often when using 24VAC/40VA transformers.

My existing doorbell transformer was a more common 16VAC/15VA unit. It had just 2 dropouts over a week of frequent use. Those 2 dropouts occurred when I was testing 2-way talk at night time... while the IR illuminator was on, the white LED warning light was on, I was talking continuously to the unit via 2-way, and repeatedly pushing the button to ring my mechanical chime. In other words, I was trying to get it to dropout. I thought I could fix this edge case by upgrading my transformer to one of those 24VAC/40VA units that online reviewers say fixed problems with their ring brand units.

So I ordered one from Amazon, wired it to mains, checked it put out the expected 28VAC no load, and hooked up the bell wires. My first round of testing showed major problems. The doorbell rebooted consistently every time I just as much as triggered the motion (so recording to SD card and LED warning light on, but 2-way turned off). Pushing the button immediately resulted in a reboot every time. The mechanical chime would not move/ding at all. 2-way was very intermittent and frequently resulted in dropouts or a corrupted video stream (seen as large areas of the frame severely pixelated in BI).

None of these problems existed when I was running the small "normal" transformer. So I put the old one back in, gave it my best shot at getting it to drop out; daytime so no IR, but the LED was on, I was talking loud on 2-way, and repeatedly ringing the bell (of course motion is triggered the whole time). No dropouts at all (though I expect rare dropouts if I do stupid things at night time). I think this is very much conclusive evidence.

So I suggest to folks who have dropout problems and are using a 24VAC/40VA transformer, downgrade to a smaller 16VAC transformer. Likewise, if your db6i is having dropouts with 16VAC/15VA, be aware that "upgrading" the transformer to 24VAC could actually make the problem worse.

That said, I plan to return the 24VAC unit and buy a 16VAC/30VA unit to test. I have a feeling that might be a solution to my rare dropouts.
 
Are you able to move the date/time to a different location on the screen on the Dahua? I'd like to to this on the Lorex but no way to do it...
 
teredactle said:
Are you able to move the date/time to a different location on the screen on the Dahua? I'd like to to this on the Lorex but no way to do it...
Click to expand...
Yes, the db6i allows moving overlays around...
Untitled.jpg

sergedest said:
Would you recommend integrating one of these in their current development state, or stick with a wide view turret/fisheye until this they get better?
Click to expand...
It depends... the db6i is wifi, and does not have the same level of control over exposure settings, 3dnr, etc that dome/turrets have. So all else equal, the db6i is overall not as good a camera, period. By all else equal, I mean assuming doorbell functionality, 2way audio, and warning LED are not relevant for your application. IMHO, the doorbell and 2-way functionality shouldn't be considered, since it requires DMSS and allowing the db6i to phone home. That said, there may be other reasons that make the db6i a better choice.

Like why did I get a db6i, when I already have a dome at my entry?

It is a doorbell powered from doorbell wiring, which allowed me to place the cam in a place where ID is much better. You can see the dome in that image, at the top left corner. That is a 2mp dahua with 2.8mm lens. The concrete walkway is ~9' below, making the angle and distance not so good for ID. By the time someone is close enough to ID at night time, I only see the top of their head (most folks look downward as they approach a set of stairs, which adds to the problem of snagging an ID). Moving the dome anywhere lower would be a huge problem aesthetically (WAF matters). So I added the doorbell cam to ID ppl walking on that brown deck (this area is perhaps the second highest security priority around my home, my driveway/cars being the first). Now I just use the dome for observation... but it can still ID farther away during daytime if needed.

DMSS was also not relevant for me... my bell wiring already has a hall sensor that triggers homeassistant whenever the bell rings. So I was already getting instant notifications before I got the db6i. I did have to increase the current threshold so the camera current spikes didn't trigger HA, but it works 100% reliably. This may be, or could be the case for you as well.

WRT 2-way... that's a problem with no great workarounds. You either need DMSS for proper 2way, or you are stuck with walkie talkie style 2-way using BI or similar. The latter works good enough for my purposes, but I wish I could have proper 2way without letting dahua have access to my network. I've heard of some network guru types hacking it so DMSS works without phoning home... but that's way beyond my pay grade.
 
Last edited:
Speaking of phoning home... I took part in a discussion about this in another thread, but I think this should go here as well.

This db6i will constantly phone home even if you don't use dmss and have p2p turned off in the camera settings. So if you have this doorbell or plan to get one, you may want to ensure your firewall is setup to block outbound connections from it. I heard other cams mentioned in that thread doing the same thing... so may as well block them all while you are at it. This is considered best practice and should be done regardless if a cam is actually known to phone home.
 
Can someone who has this DB6I doorbell please confirm its default NTP configuration, via:

<ip_address>/cgi-bin/configManager.cgi?action=getConfig&name=NTP

The reason for asking is the Amcrest AD110 and AD410 has misconfigured the NTP server and I'm wondering if this was "inherited" from Dahua developers. The config specifies an IP pointing to a single server hosted in Brazil, not a dynamic NTP pool address. Furthermore, the NTP update period is absurdly excessive - checking every 5 minutes. This is an abusive configuration not to mention the added latency.

Here is the AD110/AD410 default config (except for the TimeZone, which is the only time setting that can be changed via the SmartHome app):

table.All.NTP.Address=200.160.0.8 table.All.NTP.Enable=true table.All.NTP.Port=123 table.All.NTP.TimeZone=26 table.All.NTP.TimeZoneDesc=Middletime table.All.NTP.UpdatePeriod=5

Note that these settings can and should be changed via the API, DMSS, configtool, or NVR UI.
 
Sorry, but getting the defaults from my db6i would mean a lot more work on my end, including the stupid DMSS install/config/uninstall dance that I swore I'd only do once to get this doorbell configured for my system. I'll take your word for it that the defaults are garbage... my experience was the same. I recall similarly 'abusive' default ntp settings on my db6i, but my fully setup db6i returns more sane settings now:

Code: 
table.NTP.Address=192.168.XXX.XXX
table.NTP.Enable=true
table.NTP.Port=123
table.NTP.TimeZone=28
table.NTP.TimeZoneDesc=LowerCalifornia
table.NTP.UpdatePeriod=10

10min is OK since it's only bugging my router. As this is the case, I feel OK having my router get time online every 10min... since the numerous devices on my LAN would probably get time way more often if left on their own to do so.
 
Thanks truglo. There's a whole lot of settings in the Amcrest firmware with Dahua original references. I really wanted to know if Dahua had the same default and Amcrest just left it as-is or came up with it on their own.

I agree that if you've set up a local NTP server, the update period is inconsequential. But if you consider several thousand devices all referencing a single NTP erver in a remote country every 5 minutes - well, that's just absurd for a default config.
 
You must log in or register to reply here.
Top Bottom