I tried the original composer file (with environment changes for username, password, etc.) to create a container on my Synology NAS, but that did not work:
ERROR: The Compose file ‘./docker-compose.yml’ is invalid because:
Unsupported config option for services.doorbell: ‘env’
So I made changes to the example by splitting out the environment variables (as in the repository itself) resulting in the following error:
With the exact image defined in the image line (in my example “3.0.0-beta.16”) it does create the container now:
Creating hikvision_doorbell_1 … done
Afterwards the container started running but unexpectedly stopped with the following error in the docker log:
socket.gaierror: [Errno -2] Name or service not known
It turned out that the host configuration should only contain the IP address (which differs for example from Zigbee2MQTT). After changing, the container runs properly and I have (after a bit of patience) multiple statuses and services to play around with within Home Assistant. For reference, find below the two files I have created:
# JSON string with the list of doorbells
DOORBELLS='[{"name": "Door Front", "ip": "192.168.x.x", "username": "admin", "password": "secret" }]'
# Connection to the MQTT broker
MQTT__HOST=192.168.x.x
#MQTT__USERNAME=<broker_username>
#MQTT__PASSWORD=<broker_password>
# To help diagnose problems
SYSTEM__LOG_LEVEL=DEBUG
SYSTEM__SDK_LOG_LEVEL=DEBUG
# Load C native libraries required by the Hikvision SDK. Use the correct folder depending on you architecture.
LD_LIBRARY_PATH=lib-amd64/
# Enable python module to get stacktraces from C native calls in the SDK
PYTHONFAULTHANDLER=true
I hope the above will help others trying to get the add-on to work in Docker. Now I just need to find some time to start playing with the add-on .
It appears that the add-on randomly puts the state on “ringing” for an extended period, hence not completely stable yet. I am now using my old “rest based”-setup to identify a press on the doorbell, while using the “answer call”-action provided by the SDK which appears to work OK. If I have more information on the “ghost ringing”-state I will update and potentially raise a ticket.
Below a bit of initial checking of the status. The top bar shows the doorbell status according to the add-on, the bottom bar using the “rest based”-setup. White periods were reboots of the containers / doorbell to try to resolve the issue. The two long purple bars are incorrect (no doorbell press, also confirmed by no camera activity).
I will track the sensors next to each other hopefully seeing that they stay aligned eventually. Up to this moment in time, I have quite some very long ring events that should not be there.
Is there any way we can track the status of the backlog download as it appears to affect the behavior of the sensor? And is this happening also on restarts of the container (which happen at night; I would not like my doorbell to start randomly ringing at that time )?
no, once the backlog is downloaded, then no false events anymore, and doesnt mather if you reboot at night… Offcourse, when you have the docker offline for a week, then next time, it will download events again offcourse…
I unfortunately just had a “false alert” after a long period that was OK (see below). If time permits, let me browse through the debug information to check whether I can find any relevant information to identify the root cause.
My HikVision has been “ringing” from yesterday evening until this morning (when a real doorbell press eventually corrected it). I noticed in the log that it is happening at the same time some motion is detected. Not sure yet whether there is a relation, but I will keep on monitoring for false ringing statuses and related log entries. In the meantime, find below the log entries (maybe someone can already make sense out of them ):
The SDK / Addon only creates events from your device thats sending it
motion is not related, its a totally different kind of event
But i have tagged beta 17, i changed something in the login, maybe an option to disable backlog
Client arming: the original arming method of access control, generally only supports 1-way arming, and supports offline event uploading; real-time arming: the newly added arming method is mainly used for arming other devices to access control devices, and supports up to 4-way real-time arming, Offline event uploads are not supported.
Hi everyone, I’m thinking about buy an internal display to my doorbell. Does doorbell continues working well with Add on and the cameras RTSP integration to HomeAssistant?
I’ve seen indoor uses an SIP connection with doorbell, so I’m fear it can break my RTSP and ISAP integrations I’m using on Scrypted currently.
Does anyone has both? Display affects the usability? Can I access RTSP and ISAP two-way audio even with indoor display?
Or the display changes some setup from doorbell and I won’t be able to use ISAPI when doorbell is connected, for example?
Yeah, exactly. I’m actually using HomeKit over Scrypted now.
Thanks, than I think the indoor won’t interfere in my doorbell over HomeKit. I need RTSP to video and ISAPi to send the two way audio.
If Scrypted developer adapt Hikvision plugin to doorbells, I think I won’t need to send a reject info anymore. Scrypted itself could send a answer message just when I open two way audio connection I guess. He promised fix it in the future, but no news since than.
Another question Fabio,: RTSP and ISAPi connection still on even when during the moment doorbell is ringing on indoor?
yes, i also have indoor, should be no issue
RTSP is directly to outdoor
callsignal (reject/answer) , maybe you need to send to indoor instead of outdoor, in my case i need to send to indoor, but you can use the SDK addon for that
У меня в паре KV6113-WTE1 и KH6230-WTE1 работают хорошо звонит показывает звонок можно еше камеры добавить. Я себе мини сигнализацию на дери сделал из тревожних входов. Связь ку них по своему протоколу на RTSP невлияет.
I have a pair of KV6113-WTE1 and KH6230-WTE1 working well, it rings, it shows a call, you can add more cameras. I made myself a mini alarm system on deri from alarm inputs. Communication with them according to their protocol does not affect RTSP.
There are 2 addons, the normal one and the beta one
The newest with most features and most events is the beta one, this will become the official one later, all will be based on MQTT now… the beta is stable, you can already try it , will be merged soon
.
)?
.