Hikvision Integration - delay when reporting movement

Configuration
1

Hi there,

I am using the standard Hikvision integration with an NVR and am using the motion detection to trigger certain actions (e.g. turning on lights, or sending a notification with a captured still image). The problem I have is that certain actions (specifically “field detection”) have a great deal of delay between the NVR firing the event (seen by the audible beeps coming from the NVR) and the binary sensor in HA reporting the event. As a note, the NVR is pretty good at detecting events quickly, based on some tests with my wife walking up and down the drive (!!) but the issue appears to be how the events are being processed by HA.

I’ve noticed that the documentation mentions at configurable delay, but changing this has not improved the responsiveness of the field detection sensors.

My sensor config is as follows:

binary_sensor:
  - platform: hikvision
    host: 192.168.x.x
    username: !secret hikvision_username
    password: !secret hikvision_password
    customize:
      home_cctv_recording_failure_0:
        ignored: true
      home_cctv_disk_full_0:
        ignored: true
      home_cctv_disk_error_0:
        ignored: true
      home_cctv_illegal_access_0:
        ignored: true
      network_video_recorder_field_detection_1:
        delay: 0
      network_video_recorder_field_detection_2:
        delay: 0
      network_video_recorder_field_detection_3:
        delay: 0
      network_video_recorder_field_detection_4:
        delay: 0
      network_video_recorder_field_detection_5:
        delay: 0
      network_video_recorder_field_detection_6:
        delay: 0
      network_video_recorder_line_crossing_1:
        delay: 0
      network_video_recorder_line_crossing_2:
        delay: 0
      network_video_recorder_line_crossing_3:
        delay: 0
      network_video_recorder_line_crossing_4:
        delay: 0
      network_video_recorder_line_crossing_5:
        delay: 0
      network_video_recorder_line_crossing_6:
        delay: 0

…and this has created the following binary sensors:

binary_sensor.network_video_recorder_field_detection_1
binary_sensor.network_video_recorder_field_detection_2
binary_sensor.network_video_recorder_field_detection_3
binary_sensor.network_video_recorder_field_detection_4
binary_sensor.network_video_recorder_field_detection_5
binary_sensor.network_video_recorder_field_detection_6
binary_sensor.network_video_recorder_line_crossing_1
binary_sensor.network_video_recorder_line_crossing_2
binary_sensor.network_video_recorder_line_crossing_3

Sample automation:

- id: cctv_movement_detected_drive
  alias: CCTV Movement Detected - Driveway
  trigger:
  - platform: state
    entity_id:
    - binary_sensor.network_video_recorder_line_crossing_1
    - binary_sensor.network_video_recorder_field_detection_1
    from: 'off'
    to: 'on'
  condition:
    condition: or
    conditions:
    - condition: state
      entity_id: binary_sensor.house_alarm_set
      state: 'off'
    - condition: state
      entity_id: sun.sun
      state: below_horizon
    - condition: state
      entity_id: binary_sensor.house_occupied_adult
      state: 'off'
  action:
  - service: camera.snapshot
    data_template:
      entity_id: camera.drive
      filename: /config/www/cameras/drive_snapshot.jpg
  - service: notify.pushover
    # <notification stuff goes here>

Any suggestions as to what I might try to make this work a bit better?

2

I’m also experiencing these delays with smart events on my Hik cameras. I always assumed it was a hardware thing, the time the little embedded MCU needs to do the image and AI processing for human / vehicle recognition. I never checked if the alerts where faster on the NVR.

I had a look at the sources of both the HA hikvision integration and the PyHik library it uses. The default delay in the integration is set to 0, so it should not have any effect even if you leave it at the default. There’s no specific event activation delay in PyHik either, there’s only a hardcoded (!) timeout of 5 seconds for events that send an activation but no deactivation state. This delay then sets the total length of the event, it’s not a time to trigger delay either.

So either there is some bug / delay somewhere else in the HA API (you’d need to trace into the code or riddle it with debug log statement with timestamps to find that) or the event presented in the ISAPI alertStream is delayed. The NVR doesn’t use ISAPI to communicate with the cameras, but a different proprietary protocol. So it could get the event earlier that way.

1 Like
3

Oh and one more thing I noticed. It seems that smart events on cameras with human/vehicle detection have two states internally in the camera itself. One that signals a potential event (but the camera is not entirely sure yet) and then another one that signals that the event is legitimate.

This is how I know. I have a DS-2CD2646G1 camera over my driveway. It has a line crossing event defined with both human and vehicle detection enabled. When triggered, it both enables recording on the NVR itself and it sends an event to HA (Notify Surveillance Center).

One night, a spider decided to build her web in front of it. It was swinging in the wind under IR light. This is what I got on the NVR track with the automatic recording:

image
image782×84 4.96 KB

Lots of false triggers … or not. Because while it recorded small snippets of the spider doing spidery things in front of the lens, none of those events made it through to HA. Only when an actual human or vehicle passed, then it would both trigger auto recording and send it to HA. What I think is this: the camera sends the NVR a preliminary potential trigger event. This is done over the proprietary API. The NVR beeps and starts recording (if programmed that way). But the event is not yet confirmed. It then runs through the ML model (which can take a few seconds) and only if confirmed, then the event is sent ‘to the surveillance center’, ie. to HA over the alertStream. This is done so that the NVR can start recording as early as possible if the event turns out to be legitimate, without waiting for the machine learning model to do its work.

1 Like
4

Thanks for the reply.

Interestingly, I’ve got a mix of cameras - some with vehicle/human detection supported and some without. I’ve got a few of the new “ColorVu” cameras (DS-2CD2347G2) as well as some older domes, so I might have a play to see what impact those setting have on the notification delay. Certainly iVMS-4200 reports a prompt detection at almost the same moment as I hear the “BEEP BEEP” from the NVR, but it’s quite possible that the lag is artificially induced in the ISAPI API. If I get chance, I’ll get some wireshark running on the interface to see what’s actually getting pushed and when so I can at least work out whether the delay is NVR or HA.

One thing - I’ve noticed that smart event line cross detections can be much more quickly processed than motion detection, which suggests it might be an NVR thing. Have you noticed this yourself?

5

The easiest way is to just use curl to dump the alert stream to a console and watch how long it takes for the motion event to appear in it, in relation to the NVR detection or from the iVMS app. The end point is

ISAPI/Event/notification/alertStream

That’s also the one the HA hikvision integration monitors.

About the detection speed of various events, I did notice that field detection takes quite a bit longer than line crossing. That might be down to my settings though. I haven’t tried any of the other events types they have. In general I prefer using line crossing events and do the field type detection with external PIR or microwave detectors.

2 Likes
6

Hi)
I have exactly the same problem.
Huge delays on smart notifications.

Has anyone managed to find a solution?

7

hi,
You could try my newly published integration which supports real-time notifications.
hikvision_next
When set up forwarding notifications to phone, I get them even eye blink before hik-connect app.

1 Like