Hikvision Doorbell / Videointercom integration

Hmm ,that’s strange indeed, have you tried answer/hangup ?

2024-01-31 15:44:48.923 | INFO | sdk.utils:loadSDK:44 - Using OS: Linux with architecture: x86_64
loop[2] find 2 mac and 0 ip
2024-01-31 15:44:49.902 | INFO | doorbell:authenticate:79 - Connected to doorbell: Front Door
2024-01-31 15:44:49.928 | INFO | doorbell:authenticate:79 - Connected to doorbell: Indoor Station
2024-01-31 15:44:49.928 | INFO | event:init:87 - Setting up event handler: Console stdout
2024-01-31 15:44:49.928 | INFO | mqtt:init:117 - Setting up event handler: MQTT
2024-01-31 15:45:55.701 | INFO | mqtt:video_intercom_alarm:369 - Doorbell ringing, updating sensor
settings: mqtt=MQTT(host=‘192.168.1.120’, port=1883, username=‘user’, password=‘passwd’, client_name=None, tls_key=None, tls_certfile=None, tls_ca_cert=None, discovery_prefix=‘homeassistant’, state_prefix=‘hmd’) entity=SensorInfo(component=‘sensor’, device=DeviceInfo(name=‘Front Door’, model=‘DS-KD8003-IME1’, manufacturer=‘Hikvision’, sw_version=‘V2.2.62’, hw_version=‘0x0’, identifiers=‘6883457568564848514573776949484950485048485749488282695557565551515057’, connections=None, configuration_url=None), device_class=None, enabled_by_default=None, entity_category=None, expire_after=None, force_update=None, icon=‘mdi:bell’, name=‘Call state’, object_id=‘front_door_call_state’, qos=None, unique_id=‘6883457568564848514573776949484950485048485749488282695557565551515057-call_state’, unit_of_measurement=None, state_class=None) debug=False manual_availability=True
topic_prefix: sensor/Front-Door/Call-state
config_topic: homeassistant/sensor/Front-Door/Call-state/config
state_topic: hmd/sensor/Front-Door/Call-state/state
wrote_configuration: True

2024-01-31 15:45:55.702 | INFO | event:video_intercom_alarm:120 - Video intercom alarm from Front Door
2024-01-31 15:46:07.137 | INFO | mqtt_input:_answer_call_callback:354 - Received answer command for doorbell: Indoor Station
2024-01-31 15:46:07.177 | INFO | mqtt_input:_hangup_call_callback:331 - Received hangup command for doorbell: Indoor Station
2024-01-31 15:46:07.676 | INFO | mqtt:video_intercom_alarm:372 - Call dismissed, updating sensor
settings: mqtt=MQTT(host=‘192.168.1.120’, port=1883, username=‘user’, password=‘passwd’, client_name=None, tls_key=None, tls_certfile=None, tls_ca_cert=None, discovery_prefix=‘homeassistant’, state_prefix=‘hmd’) entity=SensorInfo(component=‘sensor’, device=DeviceInfo(name=‘Front Door’, model=‘DS-KD8003-IME1’, manufacturer=‘Hikvision’, sw_version=‘V2.2.62’, hw_version=‘0x0’, identifiers=‘6883457568564848514573776949484950485048485749488282695557565551515057’, connections=None, configuration_url=None), device_class=None, enabled_by_default=None, entity_category=None, expire_after=None, force_update=None, icon=‘mdi:bell’, name=‘Call state’, object_id=‘front_door_call_state’, qos=None, unique_id=‘6883457568564848514573776949484950485048485749488282695557565551515057-call_state’, unit_of_measurement=None, state_class=None) debug=False manual_availability=True
topic_prefix: sensor/Front-Door/Call-state
config_topic: homeassistant/sensor/Front-Door/Call-state/config
state_topic: hmd/sensor/Front-Door/Call-state/state
wrote_configuration: True

2024-01-31 15:46:07.677 | INFO | event:video_intercom_alarm:120 - Video intercom alarm from Front Door

I have no idea, it should work…

You say that’s the speaker is not idle… What if you press the doorbell button again 1 time, does it make the call? Or do you need to press it 2 times?

The doorbell rings as normal if I press the doorbell button again. The only way it seems to resolve the issue is to restart the Hikvision doorbell add-on which is strange.

hmm, thats indeed really strange
What happens if you wait long enough
press the doorbell button send the reject or answer+hangup command, then wait more then 120 sec … that makes the 8003 drop the call anyway (defined in ivms) , can you start the two way audio ? without restarting addon?

i also see this one in your log, after the call is dismissed, i wonder what that means, i dont have any alarm when i dismiss a call, i dont see such event…

2024-01-31 15:46:07.677 | INFO | event:video_intercom_alarm:120 - Video intercom alarm from Front Door

Can you enable debug on the addon , and then post that specific event again?

log_level: DEBUG
sdk_log_level: DEBUG

OK, Will do that now. In the meantime, I tried another test.

  1. 2 way audio working
  2. Press doorbell button
  3. Pressed the HA entity indoor button for answer call
  4. Pressed the HA entity indoor button for hangup call
  5. 2 way audio not working
  6. Waited 5 mins - still no 2 way audio
  7. Rebooted indoor station - still no 2 way audio
  8. Rebooted outdoor station - 2 way audio back

build 230204
33685566
1507844
0x0
V4.0
build 181206
Vis
88
true
true
2
4
1

[2024-01-31 16:54:57.611][DBG] SimpleSTDCommandToDvr with out cmd[GET /ISAPI/System/deviceInfo], input size[0], max segment length[262144]
2024-01-31 16:54:57.664 | DEBUG | sdk.utils:call_ISAPI:125 - Call ISAPI request method url body: GET /ISAPI/System/deviceInfo
[2024-01-31 16:54:57.668][INF] Private connect 192.168.1.103:8000 sock=175 this=0x6d081574 cmd=0x117000 port=45394
2024-01-31 16:54:57.672 | DEBUG | sdk.utils:call_ISAPI:165 - Response output:
Embedded Net VIS
48513033-3236-3137-3739-c0517e02cdc4
DS-KH6320-WTE1
DS-KH6320-WTE10120200916WRQ03261779CLU
c0:51:7e:02:cd:c4
V2.2.20
build 230601
V1.0
build 000000
DVR
1
255
2
8

1

[2024-01-31 16:54:57.672][DBG] SimpleSTDCommandToDvr with out cmd[GET /ISAPI/System/deviceInfo], input size[0], max segment length[262144]
2024-01-31 16:54:57.737 | DEBUG | event:start:255 - Registering callback function using SDK
2024-01-31 16:54:57.741 | DEBUG | doorbell:setup_alarm:90 - Arming the device via SDK
[2024-01-31 16:54:57.743][INF] Private connect 192.168.1.102:8000 sock=202 this=0x6d081574 cmd=0x111020 port=53128
2024-01-31 16:54:57.752 | DEBUG | doorbell:setup_alarm:90 - Arming the device via SDK
2024-01-31 16:54:57.761 | DEBUG | input:loop_forever:29 - Waiting for input command
[2024-01-31 16:54:57.757][INF] Private connect 192.168.1.103:8000 sock=205 this=0x6d081b58 cmd=0x111020 port=45404
[2024-01-31 16:55:27.828][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 16:55:57.852][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 16:56:27.878][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 16:56:57.918][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 16:57:27.945][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 16:57:57.970][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 16:58:33.025][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 16:58:58.067][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 16:59:28.121][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 16:59:58.142][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 17:00:01.271][INF] Alarm[0] IP[192.168.1.102] data_len[568] alarm_len[568] status[430]
2024-01-31 17:00:01.284 | DEBUG | event:_handle_callback:220 - Callback invoked from SDK
2024-01-31 17:00:01.307 | DEBUG | event:_invoke_handlers:192 - Invoking 2 handlers
2024-01-31 17:00:01.308 | INFO | mqtt:video_intercom_alarm:369 - Doorbell ringing, updating sensor
settings: mqtt=MQTT(host=‘192.168.1.120’, port=1883, username=‘user’, password=‘passwd’, client_name=None, tls_key=None, tls_certfile=None, tls_ca_cert=None, discovery_prefix=‘homeassistant’, state_prefix=‘hmd’) entity=SensorInfo(component=‘sensor’, device=DeviceInfo(name=‘Front Door’, model=‘DS-KD8003-IME1’, manufacturer=‘Hikvision’, sw_version=‘V2.2.62’, hw_version=‘0x0’, identifiers=‘6883457568564848514573776949484950485048485749488282695557565551515057’, connections=None, configuration_url=None), device_class=None, enabled_by_default=None, entity_category=None, expire_after=None, force_update=None, icon=‘mdi:bell’, name=‘Call state’, object_id=‘front_door_call_state’, qos=None, unique_id=‘6883457568564848514573776949484950485048485749488282695557565551515057-call_state’, unit_of_measurement=None, state_class=None) debug=False manual_availability=True
topic_prefix: sensor/Front-Door/Call-state
config_topic: homeassistant/sensor/Front-Door/Call-state/config
state_topic: hmd/sensor/Front-Door/Call-state/state
wrote_configuration: True

2024-01-31 17:00:01.321 | INFO | event:video_intercom_alarm:120 - Video intercom alarm from Front Door
2024-01-31 17:00:09.513 | INFO | mqtt_input:_answer_call_callback:354 - Received answer command for doorbell: Indoor Station
2024-01-31 17:00:09.515 | DEBUG | sdk.utils:call_ISAPI:125 - Call ISAPI request method url body: PUT /ISAPI/VideoIntercom/callSignal?format=json {“CallSignal”: {“cmdType”: “answer”}}
[2024-01-31 17:00:09.519][INF] Private connect 192.168.1.103:8000 sock=206 this=0x6d08213c cmd=0x117001 port=33962
2024-01-31 17:00:09.552 | INFO | mqtt_input:_hangup_call_callback:331 - Received hangup command for doorbell: Indoor Station
2024-01-31 17:00:09.553 | DEBUG | sdk.utils:call_ISAPI:125 - Call ISAPI request method url body: PUT /ISAPI/VideoIntercom/callSignal?format=json {“CallSignal”: {“cmdType”: “hangUp”}}
[2024-01-31 17:00:09.557][INF] Private connect 192.168.1.103:8000 sock=207 this=0x6d082720 cmd=0x117001 port=33964
2024-01-31 17:00:09.638 | DEBUG | sdk.utils:call_ISAPI:165 - Response output: {
“statusCode”: “1”,
“statusString”: “OK”,
“errorMsg”: “ok”,
“errorCode”: 1
}
[2024-01-31 17:00:09.638][DBG] SimpleSTDCommandToDvr with out cmd[PUT /ISAPI/VideoIntercom/callSignal?format=json], input size[37], max segment length[262144]
2024-01-31 17:00:10.354 | DEBUG | event:_handle_callback:220 - Callback invoked from SDK
2024-01-31 17:00:10.355 | DEBUG | event:_invoke_handlers:192 - Invoking 2 handlers
2024-01-31 17:00:10.355 | INFO | mqtt:video_intercom_alarm:372 - Call dismissed, updating sensor
settings: mqtt=MQTT(host=‘192.168.1.120’, port=1883, username=‘user’, password=‘passwd’, client_name=None, tls_key=None, tls_certfile=None, tls_ca_cert=None, discovery_prefix=‘homeassistant’, state_prefix=‘hmd’) entity=SensorInfo(component=‘sensor’, device=DeviceInfo(name=‘Front Door’, model=‘DS-KD8003-IME1’, manufacturer=‘Hikvision’, sw_version=‘V2.2.62’, hw_version=‘0x0’, identifiers=‘6883457568564848514573776949484950485048485749488282695557565551515057’, connections=None, configuration_url=None), device_class=None, enabled_by_default=None, entity_category=None, expire_after=None, force_update=None, icon=‘mdi:bell’, name=‘Call state’, object_id=‘front_door_call_state’, qos=None, unique_id=‘6883457568564848514573776949484950485048485749488282695557565551515057-call_state’, unit_of_measurement=None, state_class=None) debug=False manual_availability=True
topic_prefix: sensor/Front-Door/Call-state
config_topic: homeassistant/sensor/Front-Door/Call-state/config
state_topic: hmd/sensor/Front-Door/Call-state/state
wrote_configuration: True

2024-01-31 17:00:10.356 | INFO | event:video_intercom_alarm:120 - Video intercom alarm from Front Door
[2024-01-31 17:00:10.354][INF] Alarm[0] IP[192.168.1.102] data_len[568] alarm_len[568] status[430]
2024-01-31 17:00:12.678 | DEBUG | sdk.utils:call_ISAPI:165 - Response output: {
“statusCode”: “1”,
“statusString”: “OK”,
“errorMsg”: “ok”,
“errorCode”: 1
}
[2024-01-31 17:00:12.678][DBG] SimpleSTDCommandToDvr with out cmd[PUT /ISAPI/VideoIntercom/callSignal?format=json], input size[37], max segment length[262144]
[2024-01-31 17:00:28.181][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 17:00:58.227][DBG] Alarm chan [0] recv timeout[2]!
[2024-01-31 17:01:28.266][DBG] Alarm chan [0] recv timeout[2]!

Hello, ok I just discovered something.

Tested in both Chrome and Safari on a MacBook.

  1. 2 way audio working
  2. Press doorbell button
  3. Pressed the HA entity indoor button for answer call
  4. Pressed the HA entity indoor button for hangup call
  5. 2 way audio not working
  6. Closed the browser window and opened again
  7. 2 way audio back again

I’ll try with the companion app on my iPhone.

ah ok, so its not an issue with this addon after all :slight_smile:
Maybe the audio session with go2rtc is still in use…

Maybe press that button on/off again, i think thats starts again a new two way audio session…
image

This button should mute/stop the two way audio also i believe, then you can start it again pressing the mic button or phone icon

image

Only difference between mic button is that the mic button starts the audio, just usefull when there was no real call incoming
And the phone icon, sends first the answer+hangup, and then starts the audio, usefull on a real incoming call

I think I agree with you. I put the MacBook aside and used just the companion app on my iPhone. Same thing:

  1. 2 way audio working
  2. Press doorbell button
  3. Pressed the HA entity indoor button for answer call
  4. Pressed the HA entity indoor button for hangup call
  5. 2 way audio not working
  6. Closed the companion app and opened it again
  7. However - 2 way audio not back
  8. Restarted Frigate
  9. 2 way audio back again
1 Like

do you think frigate keeps the audio session open? what happens when using the mic button? toggle off/on again? does that make a new audio session?
Or maybe its go2rtc related?

Ok, so the plot thickens:

Tested in Safari on a MacBook.

  1. 2 way audio working
  2. Press doorbell button
  3. Pressed the HA entity indoor button for answer call
  4. Pressed the HA entity indoor button for hangup call
  5. 2 way audio not working
  6. Edit the Frigate Card
  7. Change the live view provider to JSMpeg
  8. Saved and closed Frigate Card (the microphone disappears of course)
  9. Edit the Frigate Card Again
  10. Changed the live view provider to go2rtc
  11. 2 way audio back again

So there is something affecting go2rtc where a disconnection and reconnect restores the microphone again?

Toggling the microphone doesn’t resolve it unfortunately.

hmm, i tested it also, didnt use the card for a long time, and i see indeed the same behaviour! something must have changed… i dont use the frigate addon, i’m using an beta version of the frigate card , where no addon is needed… So it must be related to go2rtc OR HA Frontend …

Other users should see the same issue

So should I try the Beta Frigate card?

no, same behaviour, i see the issue here too…

First of all, i think we need to add an delay between the answer+hangup button anyway, sending hangup immediately after the answer, is way too fast for the indoor device to handle…


            - type: custom:frigate-card-menu-icon
              icon: mdi:phone
              tap_action:
                - action: call-service
                  service: button.press
                  data:
                    entity_id: button.ds_kh9510_answer_call

## add pause here..
                - action: call-service
                  service: button.press
                  data:
                    entity_id: button.ds_kh9510_hangup_call
                - action: custom:frigate-card-action
                  frigate_card_action: unmute
                - action: custom:frigate-card-action
                  frigate_card_action: microphone_unmute

The first time it seems to work, when doing answer + hangup manually, when pressing the mic/mute button, it seems its not closing the audio… not sure why
Or it doesnt start a new audio session
refreshing the page or closing companion app, and opening the view again , seems to work … for the moment, i have no idea what could be the issue

Ok, I’ll keep digging to see if I can find a resolution. The pause in between answer and hangup didn’t work for me but interestingly, then you answer the call the doorbell state still says ringing. When you press hangup it does actually go back to idle. Maybe a red herring.

yeah, the answer command indeed is a strange think, seems its different for every user

Did some more testing outside, it indeed only works the first time… Afterwards not more, seems a refresh of the page is needed…!
Not sure what a refresh does, but it must kill some audio session thats was still open before… gonna look if there is maybe somekind of refresh service on the hass card, maybe we can use that after the two way audio session is closed

1 Like