Can you pls share the link?
I’m not supporting any HACS integration nor addon,
Just plain docker image that you can run on non raspberry pi devices
Thanks for you help bar, I’m not very good with coding etc. so I’m actually following these videos in an attempt to get my VTO to talk with HA to use it as a doorbell as opposed to a camera which is how I have it at the moment so please bear with me as most of the questions you ask me I have to Googgle - these are the videos I’m following & of course I’m up to the 3rd video ( The video doorbell that does Home Assistant + NVR - Intermittent Technology)
Inside HA I click on Settings - Addons - Addon Store - Search for Dahua which brings me the DahuaVTO2MQTT Addon - I click on install
I hope this answers your question 
This video is about the project when it was in github, since then stopped supporting HA addon mostly because i’m using HA core and deploy DahuaVTO2mqtt as docker to my cluster, if you would like to use it, pls follow the link in the OP
Thanks
Shall take a read, thanks for taking the time to reply bar, appreciate it 
estoy intentando instalar el complemento en mi HA y recibo el error:
The command ‘/bin/ash -o pipefail -c apk update && apk upgrade && apk add --no-cache python3 py3-pip py3-setuptools git && pip3 install --upgrade pip --no-cache-dir paho-mqtt requests’ returned a non-zero code: 3
Mi HA esta en una raspberry pi 4.
Thank you very much for sharing!
Thanks to this Docker I can integrate my Dahua Villa VTO in HA via MQTT, but it wakes me up at night around 2 am! I’ll tell you the details:
Dahua’s indoor unit, which looks a lot like an Android tablet, always works realistically. That is, whenever someone rings the doorbell, the display will be activated, and it rings.
The DMSS App installed on my phone does not always notify me when someone is ringing the doorbell. But thanks to the MQTT integration, I do get a notification whenever someone is ringing the doorbell (DahuaVTO/CallNoAnswered/Event).
The problem is that the integration with MQTT also generates messages as if someone were ringing the doorbell when nobody is ringing. For example, almost every day, around 2 am, it generates a fake ring message.
What can this be due to?
It is a bit annoying, because sometimes it does it also at 5 am and if I have the phone on I wake up.
Has this happened to anyone else?
Thanks
Happy that it works for you, now let’s try to make it even better,
Do you debug level logs you can share?
Thanks
1 Like
Yes please! Thank you very much for your help!
I’m looking forward to know how to debug level logs, so I can share them with you. Thanks in advance!
Regards
In OP there is list of environment variables, last one is DEBUG, set it to True after it happened pls post the log and additionally logs from HA ot at least when it happen while you didn’t expect it
Thanks
I just activated the debug as you indicated. To do this I had to do a new docker compose up -d and thanks to this it has generated the alert message, as if someone were ringing, which has allowed me to realize that this happens every time the Docker container “Dahua-MQTT” restarts (the time stamp match the shutdown of the Docker container in Proxmox to make a backup (about 2 AM).
But a restart of the docker container shouldn’t generate a message as if someone rings the bell? Am I right?
By the way, time zone is not properly right, it shows one or two hours less than the right one. 16:25 instead of 18:25 (but I’m not worried about that)
Hereby the debug log while restarting the container:
2023-08-31 16:25:39,740 DEBUG clients.**BaseClient MQTTClient Event received, Data: {'event': 'CallNoAnswered/Event', 'payload': {'Action': 'Start', 'Code': 'CallNoAnswered', 'Data': {'CallID': '5', 'IsEncryptedStream': False, 'LocaleTime': '2023-08-31 17:25:39', 'LockNum': 2, 'SupportPaas': False, 'TCPPort': 37777, 'UTC': 1693499139.0, 'UserID': '9901'}, 'Index': 0, 'Param': {}, 'serialNumber': '9C072E4PAJDCDBA'}}**
2023-08-31 16:25:39,740 DEBUG clients.MQTTClient Publishing MQTT message DahuaVTO/CallNoAnswered/Event: {'Action': 'Start', 'Code': 'CallNoAnswered', 'Data': {'CallID': '5', 'IsEncryptedStream': False, 'LocaleTime': '2023-08-31 17:25:39', 'LockNum': 2, 'SupportPaas': False, 'TCPPort': 37777, 'UTC': 1693499139.0, 'UserID': '9901'}, 'Index': 0, 'Param': {}, 'serialNumber': '9C072E4PAJDCDBA'}
2023-08-31 16:25:39,740 DEBUG clients.BaseClient MQTTClient Event received, Data: {'event': 'DoorNotClosed/Event', 'payload': {'Action': 'Start', 'Code': 'DoorNotClosed', 'Data': {'LocaleTime': '2023-08-31 17:25:39', 'Name': 'Door', 'UTC': 1693499139.0}, 'Index': 0, 'Param': None, 'serialNumber': '9C072E4PAJDCDBA'}}
2023-08-31 16:25:39,740 DEBUG clients.MQTTClient Publishing MQTT message DahuaVTO/DoorNotClosed/Event: {'Action': 'Start', 'Code': 'DoorNotClosed', 'Data': {'LocaleTime': '2023-08-31 17:25:39', 'Name': 'Door', 'UTC': 1693499139.0}, 'Index': 0, 'Param': None, 'serialNumber': '9C072E4PAJDCDBA'}
2023-08-31 16:25:39,740 DEBUG clients.BaseClient MQTTClient Event received, Data: {'event': 'HangupPhone/Event', 'payload': {'Action': 'Start', 'Code': 'HangupPhone', 'Data': {'LocaleTime': '2023-08-31 17:25:39', 'UTC': 1693499139.0}, 'Index': 0, 'Param': None, 'serialNumber': '9C072E4PAJDCDBA'}}
2023-08-31 16:25:39,740 DEBUG clients.MQTTClient Publishing MQTT message DahuaVTO/HangupPhone/Event: {'Action': 'Start', 'Code': 'HangupPhone', 'Data': {'LocaleTime': '2023-08-31 17:25:39', 'UTC': 1693499139.0}, 'Index': 0, 'Param': None, 'serialNumber': '9C072E4PAJDCDBA'}
2023-08-31 16:25:39,741 DEBUG clients.BaseClient MQTTClient Event received, Data: {'event': 'IgnoreInvite/Event', 'payload': {'Action': 'Start', 'Code': 'IgnoreInvite', 'Data': {'CallID': '5', 'LocaleTime': '2023-08-31 17:25:39', 'UTC': 1693499139.0}, 'Index': 0, 'Param': None, 'serialNumber': '9C072E4PAJDCDBA'}}
2023-08-31 16:25:39,741 DEBUG clients.MQTTClient Publishing MQTT message DahuaVTO/IgnoreInvite/Event: {'Action': 'Start', 'Code': 'IgnoreInvite', 'Data': {'CallID': '5', 'LocaleTime': '2023-08-31 17:25:39', 'UTC': 1693499139.0}, 'Index': 0, 'Param': None, 'serialNumber': '9C072E4PAJDCDBA'}
2023-08-31 16:25:39,741 DEBUG clients.BaseClient MQTTClient Event received, Data: {'event': 'ProfileAlarmTransmit/Event', 'payload': {'Action': 'Start', 'Code': 'ProfileAlarmTransmit', 'Data': {'AlarmType': 'DoorMagnetism', 'DevSrcType': 'Digit', 'LocaleTime': '2023-08-31 17:25:39', 'SenseMethod': 'DoorMagnetism', 'UTC': 1693419865, 'UserID': '8001'}, 'Index': 8001, 'Param': None, 'serialNumber': '9C072E4PAJDCDBA'}}
2023-08-31 16:25:39,741 DEBUG clients.MQTTClient Publishing MQTT message DahuaVTO/ProfileAlarmTransmit/Event: {'Action': 'Start', 'Code': 'ProfileAlarmTransmit', 'Data': {'AlarmType': 'DoorMagnetism', 'DevSrcType': 'Digit', 'LocaleTime': '2023-08-31 17:25:39', 'SenseMethod': 'DoorMagnetism', 'UTC': 1693419865, 'UserID': '8001'}, 'Index': 8001, 'Param': None, 'serialNumber': '9C072E4PAJDCDBA'}
2023-08-31 16:25:39,741 DEBUG clients.BaseClient MQTTClient Event received, Data: {'event': 'RtspSessionDisconnect/Event', 'payload': {'Action': 'Start', 'Code': 'RtspSessionDisconnect', 'Data': {'Device': '192.168.26.130', 'LocaleTime': '2023-08-31 17:25:39', 'StreamType': 'Extra1', 'UTC': 1693499139.0, 'UserAgent': ' go2rtc\\/1.6.2'}, 'Index': 0, 'Param': None, 'serialNumber': '9C072E4PAJDCDBA'}}
2023-08-31 16:25:39,741 DEBUG clients.MQTTClient Publishing MQTT message DahuaVTO/RtspSessionDisconnect/Event: {'Action': 'Start', 'Code': 'RtspSessionDisconnect', 'Data': {'Device': '192.168.26.130', 'LocaleTime': '2023-08-31 17:25:39', 'StreamType': 'Extra1', 'UTC': 1693499139.0, 'UserAgent': ' go2rtc\\/1.6.2'}, 'Index': 0, 'Param': None, 'serialNumber': '9C072E4PAJDCDBA'}
2023-08-31 16:26:15,658 DEBUG clients.DahuaAPI Data received: {'id': 8, 'method': 'client.notifyEventStream', 'params': {'SID': 513, 'eventList': [{'Action': 'Pulse', 'Code': 'SIPRegisterResult', 'Data': {'LocaleTime': '2023-08-31 17:26:15', 'Success': True, 'UTC': 1693499175.0}, 'Index': 0}]}, 'session': 974827207}
2023-08-31 16:26:15,658 DEBUG clients.BaseClient MQTTClient Event received, Data: {'event': 'SIPRegisterResult/Event', 'payload': {'Action': 'Pulse', 'Code': 'SIPRegisterResult', 'Data': {'LocaleTime': '2023-08-31 17:26:15', 'Success': True, 'UTC': 1693499175.0}, 'Index': 0, 'serialNumber': '9C072E4PAJDCDBA'}}
2023-08-31 16:26:15,658 DEBUG clients.MQTTClient Publishing MQTT message DahuaVTO/SIPRegisterResult/Event: {'Action': 'Pulse', 'Code': 'SIPRegisterResult', 'Data': {'LocaleTime': '2023-08-31 17:26:15', 'Success': True, 'UTC': 1693499175.0}, 'Index': 0, 'serialNumber': '9C072E4PAJDCDBA'}
2023-08-31 16:26:16,697 DEBUG clients.DahuaAPI Data received: {'id': 8, 'method': 'client.notifyEventStream', 'params': {'SID': 513, 'eventList': [{'Action': 'Pulse', 'Code': 'SIPRegisterResult', 'Data': {'Date': '31-08-2023 17:26:16', 'LocaleTime': '2023-08-31 17:26:16', 'Success': True, 'UTC': 1693499176.0}, 'Index': 0}]}, 'session': 974827207}
2023-08-31 16:26:16,697 DEBUG clients.BaseClient MQTTClient Event received, Data: {'event': 'SIPRegisterResult/Event', 'payload': {'Action': 'Pulse', 'Code': 'SIPRegisterResult', 'Data': {'Date': '31-08-2023 17:26:16', 'LocaleTime': '2023-08-31 17:26:16', 'Success': True, 'UTC': 1693499176.0}, 'Index': 0, 'serialNumber': '9C072E4PAJDCDBA'}}
2023-08-31 16:26:16,697 DEBUG clients.MQTTClient Publishing MQTT message DahuaVTO/SIPRegisterResult/Event: {'Action': 'Pulse', 'Code': 'SIPRegisterResult', 'Data': {'Date': '31-08-2023 17:26:16', 'LocaleTime': '2023-08-31 17:26:16', 'Success': True, 'UTC': 1693499176.0}, 'Index': 0, 'serialNumber': '9C072E4PAJDCDBA'}
2023-08-31 16:26:34,197 DEBUG clients.DahuaAPI Keep alive
2023-08-31 16:26:34,215 DEBUG clients.DahuaAPI Data received: {'id': 9, 'params': {'timeout': 55}, 'result': True, 'session': 974827207}
Thanks again!
Cheers
I will need the entire log, with the unexpected event,
Docker itself is just listen to events from the device and converts them into MQTT messages, so if some event was triggered, most likely it was triggered by the device itself.
What I would like to check, that there is no error, if there is one, what happened around that time
Thanks again.
Here is the complete log during a restart process of the docker container. Which produces alert as if someone was ringing the doorbell. I hope it will be useful to detect why it generates that kind of alert, since the Dahua indoor unit does not sound when I restart the docker, only the alert that I have generated via MQTT with NodeRed.
Thanks
Just trying to set this up.
On start up of docker image/container, i’m getting
2023-09-16 05:46:37,826 ERROR clients.DahuaAPI Failed to handle message, error: ‘NoneType’ object has no attribute ‘get’, Line: 87
Looks very similar to what is being called out here - Failed to read data (AccessControl Event) (#57) · Issues · Elad Bar / DahuaVTO2MQTT · GitLab
Here are more details from the log -
{“Method”:42,“TimeSection”:“00:00:00-00:00:00”}],[{“Method”:42,“TimeSection”:"00:00:00-23:59’, error: Expecting ‘,’ delimiter: line 1 column 3657 (char 3656), Line: 406
Thanks
Nothing is needed but, there is a ghost issue because the lorex doorbell doesn’t follow vto exactly.
Bars image does a prelogin which leads to a challenge which then leads to actual login.
In the login function, there is a sequence where serial number, device type, version and access control configuration are requested.
The lorex doorbell either ignored or throws an internal error when it is queried for Access control from.tje Config manager. If it 8gnores the request, the container works as expected. If it throws an error it stops the container from initilizing and it doesn’t work.
So basically you just need to enable debug logging and restart it a bunch of times until it works as expected.
I am working on a fix that will allow the container to init and boot regardless.
I am working on a fix. I added a comment to that gitlab issue just now. Should have a fix ready today.
In the meantime, if you just keep restarting the image it will eventually start. Might take a few tries though.
You can try my image at baudneo/dahuavto2mqtt:test
Right now it doesn’t solve the issue, it just has a retry loop and better logging to debug the issue. Set API_DEBUG=True in env to get dahua vto API debug msgs. MQTT_DEBUG is for Matt debug msgs. The original DEBUG env var is unused now.
My fork is on GitHub baudneo/dahuavto2mqtt. I haven’t pushed my local changes yet so the code isn’t updated. I will put a PR in on gitlab after I have it sorted.
This is the error msg sent back from lorex 2k doorbell that causes the freeze and callback handler to throw an exception:
Data received: {'error': {'code': 268959743, 'message': 'Unknown error! error code was not set in service!'}, 'id': 4, 'params': {'table': None}, 'result': False, 'session': 1149542436}
If a different port , other than 80 is used on the VTO for the GUI, would it matter?
My docker image fixes the issue and has logic to support access control if it’s supported.
Anyone using lorex or amcrest will have a better time:
baudneo/dahuavto2mqtt
Following issue closing in GitLab, issue is related to unsupported product of unsupported brand,
Since the change and the solution you are working is not related to the thread, I suggest you will open a dedicated thread relevant for your audience
Thanks
It uses port 5000, not http connection
Unsupported brand? Amcrest and lorex are both dahua with custom firmware, meaning they both implement VTO API.
So far, since lorex and amcrest don’t have gpio outputs for access control, they don’t support the access control request. 1 of 2 things happens when these devices parse the access control request, it either throws an unknown internal error and crashes or it completely ignores the access control requst and finishes the init.
I don’t understand your stance on these products not being vto when they clearly are. I also don’t understand why you would not want to fix such a simple error. It was trivial to ascertain and fix the error so dahua vto devices with access control and dahua vto devices that don’t support access control can both work using the same image. To each their own.
I’ve noticed several users complain of the same error using your image. It only makes sense to fix such low lying fruit. But again, to each their own. I’ve already fixed the issue and am happily upgrading the rest of the bugs.