I’m thinking a cheap Shelly one will be able to detect this then, I’ll have a test when I get some more time 
Yeah, doesn’t have to be expensive. I’m using a cheap automotive 12V relay. The doorbell can be powered by DC12V, which is what I’m using, so this works well.
The relay trips a wireless sensor connected to OH once the button is pressed.
@matt1,@bgilmer Turns out that low probability is not zero probability. I had some time today to further test the EZVIZ Doorbell Camera and my setup that I was giving me fits. As a last resort I unlinked all Items in PaperUI then deleted the camera Thing I had created using PaperUI. I then went all text based, creating a new Doorbell Camera Thing, and linking my Items to Channels in the Items text file, not using PaperUI. In the Thing file I was able to add the sub stream(102) for FFMpeg_Motion_Input and now I can change the AudioThrehold and FFMpegMotionThrehold without freezing-up and needing to restart OH. So after a few hours of running trouble free, my preliminary conclusion is that PaperUI configuration was causing all of my problems. Hopefully this will continue to be the case, but I will report if something changes. Also, if I don’t re-encounter these problems, it likely means that something is broken in the current build of the IPCamera binding with respect to being able to use PaperUI to configure at least the EZVIZ camera.
Thanks @John_Siemon. I know Kai and others really don’t like the text-based configuration, and that there are plans to dump it in OH3, but honestly, I have had problems in the past with using PaperUI, and I really like the text based configurations where I can see things at a glance. Not to mention that that method of configuration seems to be more stable.
Glad you got things working. I am interested in poking around in the audio world as well, but just have not had time yet.
1 Like
I’m sorry but this statement to me appears to be wrong and I don’t believe I have ever seen Kai state that. There was one or perhaps more devs that wanted to and discussed the idea purely to make a single way be easier to maintain, but since Openhab’s direction is a group effort and not 1 persons it appears that Textual config is already written into Openhab 3. You can read more about it here and also about the PROS and CONS of the two methods…
In addition to supporting textual files, Openhab 3 also has a feature to IMPORT textual files to make changing from textual to UI-driven config easy.
Of course since I have not used Openhab 3 nor had any part in its development I could be wrong on this hence why I have provided the link.
I doubt that is the case, the Openhab framework takes care of things and if there was a bug in the binding it should be present in both ways… More likely to be caused by cache or the way the UI has stored information in the database for a binding that has changed a huge amount in the past 1-2 weeks. It may have been data corruption, I do not know why you had issues but the main thing is it is now fixed. It normally is not such a big issue changing versions and I tried to make as many as I could all at the same time to get it over with. Since I don’t use UI configs at all I could be wrong that only a thing file is needed to avoid issues.
If I can get my hands onto this device (without ruin my echonomic too much). I will probably have a go at the Dahua VTO2202F-P. I have had it with Ring video doorbell. Its stupid and totally useless even without openhab.
Hmm 9 volt battery is DC. I thought the doorbelll required AC? I guess it runs on both.
How long did the 9volt battery work? 
I state unequivocally that it is not the cache. As I shared in previous posts, I delete the cache and tmp file between updates. I did the same again when going with only text file config so nothing different in my approach between using PaperUI and text files. It may be the database, but if that were the case I’m not sure why it would make a difference if I used PaperUI or text files. You likely have better insight here than me.
Since I don’t use UI configs at all I could be wrong that only a thing file is needed to avoid issues.
I am planning to test this idea, however doesn’t your statement point to something broken either with the IPCamera binding or PaperUI?
I do not know why you had issues but the main thing is it is now fixed
I agree and its working just fine for 24 hrs. now with no freeze-up or dropped connections.
@matt1, Thanks for your efforts.
RulesEngine/CellMotion vs. VideoSource/MotionAlarm
@matt1, not questioning the decision, just being sure I understand where we ended up.
With the DB-1 running HikVision FW, the doorbell generates two native (non-ffmpeg-created) motion ONVIF topics using two different sensing methods.
- Onvif Event Topic:RuleEngine/CellMotionDetector/Motion (PIR Sensor)
- Onvif Event Topic:VideoSource/MotionAlarm (onboard video analysis)
The binding creates a Thing for this hardware which has two channels
- ipcamera:ONVIF:Doorbell:cellMotionAlarm
- ipcamera:ONVIF:Doorbell:motionAlarm
-
Both of these channels change state when the binding detects the
/RuleEngine/CellMotionDetectortopic changes state. -
Neither of these channels change state when the binding detects the
VideoSource/MotionAlarmONFIV channel changes state.
Please confirm that what I observe here is the expected behavior. What I understood is that my system is behaving as it should. There are complexities caused by the way ONVIF has been implemented by different vendors. You are choosing a path which we hope causes the least confusion.
Put another way, if I want to confirm PIR events before sending myself a notification in order to avoid false alarms, I can and either of the channels above with the ffmpeg-generated motion alarm. anding the two motion signals from the doorbell itself is not possible.
Thanks for all your work on this device.
Sounds like you need to clean your tmp and cache. Only one channel should move if you can trigger only one type of alarm. I have found the camera always sends both here. Also check for typos or errors in the channel linkages, easy to
Make mistakes when you cut and paste then forget to edit.
My camera always sends both and both my alarms move.
I know about cleaning the cache. How do I clean the tmp files?
So what I understand is something on my end is broken.
-
ipcamera:ONVIF:Doorbell:cellMotionAlarmshould be able to be linked to a PIR motion item -
ipcamera:ONVIF:Doorbell:motionAlarmshould be able to be linked to a video motion item
The two should function independently. This is what I understand from your reply and this is definitely not what I am seeing here.
@matt1, Just a quick followup regarding the use of PaperUI vs text files and to test your theory that only .thing file is required to avoid issues. Today I removed all links between Items and Channels that I created in the text files. I left the .Things text file intact. I stopped OH and deleted the cache and tmp directories. I restarted OH and proceeded to use PaperUI to link .Items to Channels. Its been running fine for several hours, so bottomline you appear to be correct that only the .Things file needs to created using a text file to avoid issues. PaperUI can then be used to link Items and channels for the IPCamera Thing. Assuming this is indeed true, which based on my testing it is, I suggest that while the binding remains under development using a .Things file should be an explicit REQUIREMENT not just a RECOMMENDATION. This way other, future users will avoid similar issues and free you from having to trouble such issues as mine. Again thanks for your help in solving my problem, and the effort in creating this great binding.
Type this in and do it only when you have time to deal with issues as occasionally it can cause an issue that requires multiple reboots to solve, 90% of the time cleaning things out goes smoothly.
sudo openhab-cli stop && sudo rm -rf /var/lib/openhab2/cache/* && sudo rm -rf /var/lib/openhab2/tmp/* && sudo openhab-cli clean-cache && sudo openhab-cli start
That has not been my experience. My camera always sends both events at the same time and when I cover up the cameras lens I can not get any events to occur with movement in front of the PIR. I suspect they are linked internally and the PIR uses the video picture to do the adjustments for making the PIR not see to the sides if you play with the setting in the cameras app. I have not had the time to play with seeing if it is possible to unlink them by changing settings. I assure you the binding does treat them differently.
I have it multiple times in the readme, and it can be done with the UI if you delete everything and start from scratch when you change. I have tried to warn people and this is mentioned in the Openhab documentation as well somewhere I saw it. The framework is designed to deliver bindings that are built in and not dumped into the addons folder.
I have it multiple times in the readme,…
I agree that it is in your documentation, which is extensive and well done btw, but it comes across more as a suggestion than a requirement, which I believe at this point it is. However, it’s your call as to how to handle this, but I am sure others will run into this issue as more people begin to use the binding.
My camera always sends both events at the same time and when I cover up the cameras lens I can not get any events to occur with movement in front of the PIR.
FWIW, my experience is a bit different. I agree that both channels seem to trigger, but if I cover the lense with masking tape the PIR still works without the camera, but does seem to trigger both channels ( motionAlarm and cellMotionAlarm). I am using LaView fw, but I doubt that is the reason we are seeing differences.
Lol I just checked the specs and indeed it does say AC… I can confirm though that it works flawlessly on DC, and it doesn’t get hot like people have reported on various forums. I just assumed and don’t read properly that this would be a DC device. Very strange.
So right now I’m using an old 12v external hdd transformer and haven’t had any problems.
In regards the the 9v battery, it all depends on how active the doorbell is, I’m pretty sure I had it running for a couple of weeks before I swapped it over to the transformer
seems im not the only one…
Did just notice they do the DB2 now, which can also be powered by a Li-Ion battery as well as AC, so i recon DC is ok 
And this says it comes with a Li-Ion battery:
https://www.amazon.com/EZVIZ-DB1-Doorbell-Connected-Vertical/dp/B07JNWP5M2
1 Like
Check out this video review from Intermit. Tech on youtube:
The mentioned doorbell, Dahua 2MP VTO2202F-P, appears to be awesome!
1 Like
Its a awesome system Dahua has made… I really wold like to give it a try. Unfortunatly I cant seem to fint eh VTO2202F-P unless I ruin myself 
Does indeed look like a very good system, dont think i can get away with another purchase tho 
Neither can I. But unfortunaly I bought a Ring doorbell a coupple of months ago… It simply drives me nuts. I cant really figure how any company can make such a useless video doorbell.
So I´m kinda desperate of another doorbell.
You do realise that the Dahua one does not have the ‘normal’ API implemented from what little I understand and it has the VTO API in it which is a whole different thing. You can use two scripts fed in serial to convert it to MQTT and my guess is that should only be needed for the button push, hopefully the alarms all work fine via ONVIF methods which it “should”. I am not interested in spending hours of time looking at VTO and what is involved, but if someone looks and can give a short and clear idea of what needs to be added, I am happy to do so. The binding does have the apiAccess channel and that may be possible to be used to test out sending GET requests to the camera if that is even how the VTO api works. Just be sure you understand that before you purchase it but at the end of the day, the camera this thread is about does not have button pushes sent and some of the limitations this camera has probably wont apply to the Dahua plus it has a wired interface and not wifi which is a positive thing. Price is what makes the Hikvision sure to be a winner as on sale they can be had for under USD$100.
1 Like
HOw does this Dahua doorbell compare to the Axis A8105E, in terms of integration with OH?