Amcrest AD410 is supported

[andrew-d]

Version of the custom_component

0.9.2

Configuration

n/a

Describe the bug

I wanted to report that the Amcrest AD410 video doorbell appears to be supported with this integration. Some brief notes in case anyone else has this:

• Pressing the doorbell appears to fire the alarm_local binary sensor - e.g. binary_sensor.front_doorbell_alarm_local here.
• The camera shows up in Home Assistant and works fine, including both SD/HD streams and sound.
• I haven't figured out how to get the "human detection" working yet; binary_sensor.front_doorbell_smart_motion_human doesn't appear to fire, but I'll play with it a bit more.

I'm happy to do any debugging/etc. if any of the maintainers want - but I figured I'd start with the fact that it works 🎉 Thanks to everyone that's contributed!

Debug log

n/a

[rroller]

I just released 0.9.3 where I treat the AD410 as a doorbell instead of just a camera. Can you try it out to make sure things works as expected? If not I'll need to revert the change.

Also, thank you very much for reporting this info!

[andrew-d]

I updated, then removed and re-added the integration; here's what I tested:

• binary_sensor.front_doorbell_alarm_local goes unsafe/safe when I ring the doorbell
• The SD/HD video streams work, including sound
• binary_sensor.front_doorbell_call_no_answered goes from "motion detected" to "cleared" when I press the doorbell

I do see this message in the logs that I don't remember seeing before, but unfortunately I can't confirm/deny that since I don't think I have older logs:

2021-07-17 15:28:39 ERROR (Thread-4) [custom_components.dahua] Failed to handle message, error: 'NoneType' object is not iterable, Line: 100

Also, with the debug logs on, here's what I think happens when a human is detected by the doorbell (pretty-printed to be easier to read, some numbers redacted with 1 because I'm unsure if they're sensitive):

Click to expand

2021-07-17 15:37:16 DEBUG (Thread-4) [custom_components.dahua] VTO Data received: {
 'Action': 'Start',
 'Code': 'CrossRegionDetection',
 'Data': {'Action': 'Appear',
          'CfgRuleId': 1,
          'Class': 'Normal',
          'CountInGroup': 0,
          'DetectRegion': [[0, 0],
                           [0, 4000],
                           [0, 8191],
                           [8191, 8191],
                           [8191, 4000],
                           [8191, 0]],
          'EventID': 10107,
          'EventSeq': 106,
          'FrameSequence': 1111111,
          'GroupID': 106,
          'LocaleTime': '2021-07-17 15:37:16',
          'Mark': 0,
          'Name': 'IVS-1',
          'Object': {'Action': 'Appear',
                     'Age': 0,
                     'Angle': 0,
                     'Bag': 0,
                     'BagType': 0,
                     'BoundingBox': [2128, 1408, 4416, 8080],
                     'CarrierBag': 0,
                     'Center': [3272, 4744],
                     'Confidence': 0,
                     'DownClothes': 0,
                     'Express': 0,
                     'FaceFlag': 0,
                     'FaceRect': [0, 0, 0, 0],
                     'FrameSequence': 1111111,
                     'Gender': 0,
                     'Glass': 0,
                     'HairStyle': 0,
                     'HasHat': 0,
                     'Helmet': 0,
                     'HumanRect': [0, 0, 0, 0],
                     'LowerBodyColor': [0, 0, 0, 0],
                     'MainColor': [0, 0, 0, 0],
                     'MessengerBag': 0,
                     'ObjectID': 183,
                     'ObjectType': 'Human',
                     'Phone': 0,
                     'RelativeID': 0,
                     'SerialUUID': '',
                     'ShoulderBag': 0,
                     'Source': 0.0,
                     'Speed': 0,
                     'SpeedTypeInternal': 0,
                     'Umbrella': 0,
                     'UpClothes': 0,
                     'UpperBodyColor': [0, 0, 0, 0],
                     'UpperPattern': 0},
          'PTS': 11111111111.0,
          'Priority': 0,
          'RuleID': 1,
          'RuleId': 1,
          'Source': -1.0,
          'Track': [],
          'UTC': 1626536236,
          'UTCMS': 212},
 'DeviceName': 'Front Doorbell',
 'Index': 0,
}

EDIT: and this does appear to trigger binary_sensor.front_doorbell_cross_region_detection if that's configured in HASS.

[rroller]

So things are good for you now?

I'm a little concerned about this log line...

2021-07-17 15:28:39 ERROR (Thread-4) [custom_components.dahua] Failed to handle message, error: 'NoneType' object is not iterable, Line: 100

Do you have any more details about that line?

[andrew-d]

I did a bit of debugging today, and it occurs here:
https://github.com/rroller/dahua/blob/9910d0d/custom_components/dahua/vto.py#L100

I added a bit of extra logging right before the call to handler, and here's what I see:

2021-07-25 12:19:12 DEBUG (Thread-4) [custom_components.dahua] About to handle message 4: <function DahuaVTOClient.load_access_control.<locals>.handle_access_control at 0x7f1ac99af1f0>

And then if I add a log line right before this line:
https://github.com/rroller/dahua/blob/9910d0d/custom_components/dahua/vto.py#L256

I see:

2021-07-25 12:23:39 INFO (Thread-4) [custom_components.dahua] handle_access_control: params={'table': None} table=None

I don't know what causes this, but it doesn't seem to be causing any problems. This is all on the latest release (0.9.10).

[rroller]

Thank you for the bug fix! Released in https://github.com/rroller/dahua/releases/tag/0.9.13

[tlykken]

Hey guys - thanks for the work so far.

I just loaded this up running the latest release, 0.9.13, and I too am not seeing any firing on the binary_sensor.front_doorbell_smart_motion_human sensor. The rest of the sensors @andrew-d mentioned are working as working are for me as well.

The human binary sensor is going to be big for me as I get too many false alarms with just the motion sensor (bugs, car lights, etc).

Anything I can send through to help troubleshoot, just let me know.

[tlykken]

Or should I open up another ticket for an enhancement request?

[andrew-d]

@tlykken - confusingly, the doorbell doesn’t use the “smart human detection” for human detection; it triggers binary_sensor.front_doorbell_cross_region_detection

[andrew-d]

Here’s my Home Assistant automation:

alias: Doorbell Alert Human Detected
description: ''
trigger:
  - type: motion
    platform: device
    device_id: b6b0a20fcc5f9d36d4deb45bb3c6d60e
    entity_id: binary_sensor.front_doorbell_cross_region_detection
    domain: binary_sensor
condition: []
action:
  - service: camera.snapshot
    target:
      entity_id: camera.front_doorbell_main
    data:
      filename: >-
        /media/front_doorbell/human_snapshot_{{as_timestamp(states.automation.doorbell_alert_human_detected.attributes.last_triggered)
        | int }}.jpg
  - service: notify.mobile_app_phone
    data:
      title: Human at Door
      message: |
        Someone is at the front door
      data:
        attachment:
          content-type: jpeg
          url: >-
            /media/local/front_doorbell/human_snapshot_{{as_timestamp(states.automation.doorbell_alert_human_detected.attributes.last_triggered)
            | int }}.jpg
mode: single

[tlykken]

@andrew-d Interesting! Thanks for the info. I might just link the two in HA so that I can keep using the human field for now. Edit: Hmm - maybe I can't do that. No worries, I will use cross-region for now.

Do you think this should be changed so it fires the human sensor long-term or is there a reason to keep it as the cross region sensor?

Thanks so much for the great description and code example.

[rroller]

Do these doorbells even have human detection? I'm just blindly adding the sensors because I can't detect if the doorbell supports it or not.

[tlykken]

@rroller Yup, they do. As @andrew-d mentioned, when human detection fires on the doorbell, HA/this code triggers the sensor called binary_sensor.front_doorbell_cross_region_detection. It seems like it's miss-mapped on this side.

When "non-smart"/any motion detection fires on the doorbell, binary_sensor.rfront_doorbell_motion_alarm is triggered which makes sense.

Should I open a ticket to re-map binary_sensor.front_doorbell_cross_region_detection to binary_sensor.front_doorbell_smart_motion_human?

Thanks! (BTW - awesome HAC, love it)

[GaryOkie]

just chiming in - I also have the new AD410 and concur with @tlykken .

While it's not a problem to continue to use cross_region detection for human detection, it would be more sensible to be mapped consistently. Ditto for button press. I find I need to use "CallNoAnswered" for button press on AD410.

BTW - I also have the older AD110 doorbell which does not have human detection. It uses the same callnoanswered for doorbell presses and VideoMotion for general pixel motion. But this doorbell also has a PIR sensor for motion that does NOT trigger VideoMotion events, but instead triggers AlarmLocal events.

EDIT: correction - VideoMotion events MAY be triggered concurrent with PIR/AlamLocal events, depending on how the motion block grids are configured. The PIR itself does not trigger VideoMotion.

[rroller]

On the device info screen, can you tell me what shows up in the model number?

As an example, here's one of my cams...

I'll look at trying to fix this.

[andrew-d]

Here's mine:

[rroller]

Thanks! So for my VTO2202F doorbell/door station the Motion Alarm fires as expected, so not really sure why the AD410 doesn't.

Not having an AD410 makes this a little hard to debug.

Can you enable debug logging for this integration (and restart)...

logger:
  default: info
  logs:
    custom_components.dahua: debug

Then you should see the raw events from the doorbell in the logs. Can you post the event logs and from there I'll understand more.

[rroller]

I actually see the event log posted above. That's exactly what I needed. I can see that 'Code': 'CrossRegionDetection' was what was fired, but it has an Object Human in the data. Let me see what I can do with that.

[rroller]

For the SmartMotionHuman event, I've released 0.9.20

Can you please try it out and let me know if the human sensor fires? Thanks!

[GaryOkie]

Nope. Same as before.

Here are the sensors that were fired when walking in front of doorbell and then pushing the button...

Front Door Cross Region Detection detected motion
Front Door Alarm Local was unsafe
Front Door Call No Answered detected motion
Front Door Alarm Local was safe
Front Door Call No Answered cleared (no motion detected)
Front Door Cross Region Detection cleared (no motion detected)

Here's the corresponding event log trace... (Only Human detection enabled and not General Motion detection enabled in the SH app, so no VideoMotion events).

Amcrest/Dahua Event Code Captures 
 type=AD410
 class=DB
 HTTP API version=2.85 
 Firmware ('version=1.000.0000000.7.R', 'build:2021-02-20\r\n') 
 --------------------------------------------------------------
2021-08-29 14:50:25 | Code:  CrossRegionDetection    Payload: {'Code': 'CrossRegionDetection', 'action': 'Start', 'index': '0', 'data': {'Action': 'Appear', 'CfgRuleId': '1,', 'Class': 'Normal', 'CountInGroup': '0,', 'DetectRegion': '[', 'Direction': 'Enter', 'EventID': '10839,', 'EventSeq': '8,', 'FrameSequence': '23472680,', 'GroupID': '8,', 'Mark': '0,', 'Name': 'IVS-1', 'Object': '{', 'Age': '0,', 'Angle': '0,', 'Bag': '0,', 'BagType': '0,', 'BoundingBox': '[', 'CarrierBag': '0,', 'Center': '[', 'Confidence': '0,', 'DownClothes': '0,', 'Express': '0,', 'FaceFlag': '0,', 'FaceRect': '[', 'Gender': '0,', 'Glass': '0,', 'HairStyle': '0,', 'HasHat': '0,', 'Helmet': '0,', 'HumanRect': '[', 'LowerBodyColor': '[', 'MainColor': '[', 'MessengerBag': '0,', 'ObjectID': '4278,', 'ObjectType': 'Human', 'Phone': '0,', 'RelativeID': '0,', 'SerialUUID': '', 'ShoulderBag': '0,', 'Source': '-1.0,', 'Speed': '0,', 'SpeedTypeInternal': '0,', 'Umbrella': '0,', 'UpClothes': '0,', 'UpperBodyColor': '[', 'UpperPattern': '0', 'PTS': '46128302210.0,', 'Priority': '0,', 'RuleID': '1,', 'RuleId': '1,', 'Track': '[],', 'UTC': '1630248627,', 'UTCMS': '181'}}
2021-08-29 14:50:25 | Code:  IntelliFrame    Payload: {'Code': 'IntelliFrame', 'action': 'Pulse', 'index': '0', 'data': {'Action': 'Start'}}
2021-08-29 14:50:25 | Code:  NewFile    Payload: {'Code': 'NewFile', 'action': 'Pulse', 'index': '0', 'data': {'File': '\\/mnt\\/sd\\/2021-08-29\\/001\\/jpg\\/14\\/50\\/26[M][0@0][0].jpg', 'Size': '62129,', 'StoragePoint': 'NULL'}}
2021-08-29 14:50:25 | Code:  NewFile    Payload: {'Code': 'NewFile', 'action': 'Pulse', 'index': '0', 'data': {'File': '\\/mnt\\/sd\\/2021-08-29\\/001\\/jpg\\/14\\/50\\/26[M][0@0][1].jpg', 'Size': '19419,', 'StoragePoint': 'NULL'}}
2021-08-29 14:50:27 | Code:  IntelliFrame    Payload: {'Code': 'IntelliFrame', 'action': 'Pulse', 'index': '0', 'data': {'Action': 'Stop'}}
2021-08-29 14:50:38 | Code:  LeFunctionStatusSync    Payload: {'Code': 'LeFunctionStatusSync', 'action': 'Pulse', 'index': '0', 'data': {'Function': 'Siren', 'Status': 'false'}}
2021-08-29 14:50:38 | Code:  _CallRemoveMask    Payload: {'Code': '_CallRemoveMask', 'action': 'Start'}
2021-08-29 14:50:38 | Code:  AlarmLocal    Payload: {'Code': 'AlarmLocal', 'action': 'Start'}
2021-08-29 14:50:38 | Code:  _DoTalkAction_    Payload: {'Code': '_DoTalkAction_', 'action': 'Pulse', 'index': '0', 'data': {'Action': 'Invite', 'CallID': '20210829145040@494163@192.168.2.25', 'CallSrcMask': '4'}}
2021-08-29 14:50:38 | Code:  CallNoAnswered    Payload: {'Code': 'CallNoAnswered', 'action': 'Start', 'index': '0', 'data': {'CallID': '8'}}
2021-08-29 14:50:38 | Code:  PhoneCallDetect    Payload: {'Code': 'PhoneCallDetect', 'action': 'Start'}
2021-08-29 14:50:39 | Code:  NewFile    Payload: {'Code': 'NewFile', 'action': 'Pulse', 'index': '0', 'data': {'File': '\\/mnt\\/sd\\/2021-08-29\\/001\\/jpg\\/14\\/50\\/41[M][0@0][0].jpg', 'Size': '65760,', 'StoragePoint': 'NULL'}}
2021-08-29 14:50:40 | Code:  NewFile    Payload: {'Code': 'NewFile', 'action': 'Pulse', 'index': '0', 'data': {'File': '\\/mnt\\/sd\\/2021-08-29\\/001\\/jpg\\/14\\/50\\/42[M][0@0][0].jpg', 'Size': '63646,', 'StoragePoint': 'NULL'}}
2021-08-29 14:50:41 | Code:  NewFile    Payload: {'Code': 'NewFile', 'action': 'Pulse', 'index': '0', 'data': {'File': '\\/mnt\\/sd\\/2021-08-29\\/001\\/jpg\\/14\\/50\\/43[M][0@0][0].jpg', 'Size': '61092,', 'StoragePoint': 'NULL'}}
2021-08-29 14:50:42 | Code:  NewFile    Payload: {'Code': 'NewFile', 'action': 'Pulse', 'index': '0', 'data': {'File': '\\/mnt\\/sd\\/2021-08-29\\/001\\/jpg\\/14\\/50\\/44[M][0@0][0].jpg', 'Size': '60063,', 'StoragePoint': 'NULL'}}
2021-08-29 14:50:43 | Code:  NewFile    Payload: {'Code': 'NewFile', 'action': 'Pulse', 'index': '0', 'data': {'File': '\\/mnt\\/sd\\/2021-08-29\\/001\\/jpg\\/14\\/50\\/45[M][0@0][0].jpg', 'Size': '54553,', 'StoragePoint': 'NULL'}}
2021-08-29 14:50:48 | Code:  _DoTalkAction_    Payload: {'Code': '_DoTalkAction_', 'action': 'Pulse', 'index': '0', 'data': {'Action': 'Hangup', 'CallID': '20210829145040@494163@192.168.2.25', 'CallSrcMask': '4,', 'HangupReason': 'HangupByPhone'}}
2021-08-29 14:50:48 | Code:  AlarmLocal    Payload: {'Code': 'AlarmLocal', 'action': 'Stop'}
2021-08-29 14:50:48 | Code:  CallNoAnswered    Payload: {'Code': 'CallNoAnswered', 'action': 'Stop'}
2021-08-29 14:50:57 | Code:  CrossRegionDetection    Payload: {'Code': 'CrossRegionDetection', 'action': 'Stop', 'index': '0', 'data': {'Action': 'Appear', 'CfgRuleId': '1,', 'Class': 'Normal', 'CountInGroup': '0,', 'DetectRegion': '[', 'Direction': 'Enter', 'EventID': '10839,', 'EventSeq': '8,', 'FrameSequence': '23472680,', 'GroupID': '8,', 'Mark': '0,', 'Name': 'IVS-1', 'Object': '{', 'Age': '0,', 'Angle': '0,', 'Bag': '0,', 'BagType': '0,', 'BoundingBox': '[', 'CarrierBag': '0,', 'Center': '[', 'Confidence': '0,', 'DownClothes': '0,', 'Express': '0,', 'FaceFlag': '0,', 'FaceRect': '[', 'Gender': '0,', 'Glass': '0,', 'HairStyle': '0,', 'HasHat': '0,', 'Helmet': '0,', 'HumanRect': '[', 'LowerBodyColor': '[', 'MainColor': '[', 'MessengerBag': '0,', 'ObjectID': '4278,', 'ObjectType': 'Human', 'Phone': '0,', 'RelativeID': '0,', 'SerialUUID': '', 'ShoulderBag': '0,', 'Source': '-1.0,', 'Speed': '0,', 'SpeedTypeInternal': '0,', 'Umbrella': '0,', 'UpClothes': '0,', 'UpperBodyColor': '[', 'UpperPattern': '0', 'PTS': '46128302210.0,', 'Priority': '0,', 'RuleID': '1,', 'RuleId': '1,', 'Track': '[],', 'UTC': '1630248627,', 'UTCMS': '181'}}
2021-08-29 14:51:38 | Code:  PhoneCallDetect    Payload: {'Code': 'PhoneCallDetect', 'action': 'Stop'}
2021-08-29 14:51:38 | Code:  _CallRemoveMask    Payload: {'Code': '_CallRemoveMask', 'action': 'Stop'}
2021-08-29 14:51:48 | Code:  NewFile    Payload: {'Code': 'NewFile', 'action': 'Pulse', 'index': '0', 'data': {'File': '\\/mnt\\/sd\\/2021-08-29\\/001\\/dav\\/14\\/14.50.21-14.51.50[M][0@0][0].mp4', 'Size': '23630998,', 'StoragePoint': 'NULL'}}

The Cal lNo Answered binary_sensor class is oddly listed as "Motion". Since there is no button class, maybe just the default on/off would be better? Also what is the difference between the button pressed binary sensor and the "Invite" binary_sensor?

For completeness - this image confirms all the sensors that I have defined...

[rroller]

Thanks for all the logs. I’ll dive into this asap

[rroller]

@GaryOkie FYI I removed your comment because it contained your serial number. Probably better to not expose that. I copied it locally though so I can still use it to debug, thanks again.

[rroller]

OK, I figured out the issue. 0.9.21 should work for both Doorbells/VTO's/Cameras.

Please give it a try. Thanks!

[rroller]

@GaryOkie FYI ^

[GaryOkie]

Hey Ronnie - We got SmartHumans at our door now with 0.9.21 :)

Nice one.

Plan on mapping callnoanswered event to doorbell button press?

btw - had a bunch of dahua python errors last night. will see if they repeat after a restart and share logs.

[rroller]

Nice! Yeah I’ll continue to dig into the rest.

[tlykken]

@rroller Thanks Ronnie! Works great on 0.9.21, you are the man!

[ajstew444]

@rroller Ronnie you're a legend! I'm getting the same as others, a "call no answered" event when the doorbell button is pressed.

[ideal2545]

Hey guys, I was wondering if its possible to somehow control the light the AD410 has, it has a cool light you can illuminate downard or even strobe downward.

[GaryOkie]

I see these events when the light is turned on/off...

{'Code': 'LeFunctionStatusSync', 'action': 'Pulse', 'index': '0', 'data': {'Flicker': 'false,', 'Function': 'WightLight', 'Status': 'true'}}
{'Code': 'LeFunctionStatusSync', 'action': 'Pulse', 'index': '0', 'data': {'Flicker': 'false,', 'Function': 'WightLight', 'Status': 'false'}}

But that code is not documented in the API so it's a trial and error game to figure out the CGI calls.

To get clues at to what configuration can control the down light, you can view most settings via:
http://<ip>/cgi-bin/configManager.cgi?action=getConfig&name=All

After authenticating, a very long list of settings will be displayed. Search through them for "light" or whatever looks appropriate. You can also do "before and after" diff comparisons of this information after making changes via the SH app to pinpoint what setting changes (if any).

 table.All.FlashLight.Brightness=50
 table.All.FlashLight.Enable=false

So, a command to potentially turn on this "flashlight" (if that is actually the down-light) is:
<ip>/cgi-bin/configManager.cgi?action=setConfig&FlashLight.Enable=true

I did not get an error (it responded with "OK") but I did not see the light turn on. However, I can't turn it on manually right now, so I have other problems after screwing around with a lot of other settings. Yeah, there's a bit of risk involved.

I also see settings related to turning on the light when motion is detected (There is a setting in the SH app for this)...

table.All.MotionDetect[0].EventHandler.LightEnable=false
table.All.MotionDetect[0].EventHandler.LightingLink.Enable=false
table.All.MotionDetect[0].EventHandler.LightingLink.FilckerIntevalTime=5
table.All.MotionDetect[0].EventHandler.LightingLink.FilckerLightType=WhiteLight
table.All.MotionDetect[0].EventHandler.LightingLink.FilckerTimes=5
table.All.VideoAnalyseRule[0][0].EventHandler.FlashEnable=false
table.All.VideoAnalyseRule[0][0].EventHandler.LightEnable=false
table.All.VideoAnalyseRule[0][0].EventHandler.LightingLink.Enable=true

If I turn on the Motion option under Light Settings in the app, I see these configurations updated which indicate "FlashEnable" is related to the down-light...

table.All.MotionDetect[0].EventHandler.FlashEnable=true
table.All.VideoAnalyseRule[0][0].EventHandler.FlashEnable=true

Since AD410 light control isn't documented in the API, I don't know if anyone can answer your question if it is possible but it very likely is. I suggest trying these commands out yourself and helping to come up with an answer.

[zrhutto]

After changing settings in the app and pulling the config from the HTTP API, it looks like the ‘flashlight’ is handled through Lighting_V2[0][0][1].

To turn on the flashlight as a solid light:

<ip>/cgi-bin/configManager.cgi?action=setConfig&Lighting_V2[0][0][1].Mode=ForceOn&Lighting_V2[0][0][1].State=On

To turn on the flashlight as a strobe:

<ip>/cgi-bin/configManager.cgi?action=setConfig&Lighting_V2[0][0][1].Mode=ForceOn&Lighting_V2[0][0][1].State=Flicker

To turn off the flashlight:

<ip>/cgi-bin/configManager.cgi?action=setConfig&Lighting_V2[0][0][1].Mode=Off

It looks as if the light, when triggered automatically by motion will show the following (via getConfig):

Lighting_V2[0][0][1].Mode=Auto

That said, switching Mode from ForceOn to Auto won’t actually turn off the light.

I’m less familiar with the code in this repo (although haven’t had a chance to look through it heavily) - any idea what would be needed to expose the light as a switch to HA?

[simonjbamber]

@rroller - having some issues with the human detection on my AD410. I'm seeing the expected 'CrossRegionDetected' event as per GaryOkie above (see example below), but the 'Smart Motion Human' sensor is not triggering. Any ideas what going wrong? The basic motion sensor seems to be working fine.

2021-12-01 16:02:57 DEBUG (Thread-22) [custom_components.dahua] VTO Data received: {'Action': 'Start', 'Code': 'CrossRegionDetection', 'Data': {'Action': 'Appear', 'CfgRuleId': 1, 'Class': 'Normal', 'CountInGroup': 0, 'DetectRegion': [[0, 0], [0, 4000], [0, 8191], [8191, 8191], [8191, 4000], [8191, 0]], 'EventID': 10043, 'EventSeq': 24, 'FrameSequence': 347058, 'GroupID': 24, 'LocaleTime': '2021-12-01 16:02:57', 'Mark': 0, 'Name': 'IVS-1', 'Object': {'Action': 'Appear', 'Age': 0, 'Angle': 0, 'Bag': 0, 'BagType': 0, 'BoundingBox': [4112, 3800, 4992, 6952], 'CarrierBag': 0, 'Center': [4552, 5376], 'Confidence': 0, 'DownClothes': 0, 'Express': 0, 'FaceFlag': 0, 'FaceRect': [0, 0, 0, 0], 'FrameSequence': 347058, 'Gender': 0, 'Glass': 0, 'HairStyle': 0, 'HasHat': 0, 'Helmet': 0, 'HumanRect': [0, 0, 0, 0], 'LowerBodyColor': [0, 0, 0, 0], 'MainColor': [0, 0, 0, 0], 'MessengerBag': 0, 'ObjectID': 377, 'ObjectType': 'Human', 'Phone': 0, 'RelativeID': 0, 'SerialUUID': '', 'ShoulderBag': 0, 'Source': 0.0, 'Speed': 0, 'SpeedTypeInternal': 0, 'Umbrella': 0, 'UpClothes': 0, 'UpperBodyColor': [0, 0, 0, 0], 'UpperPattern': 0}, 'PTS': 43031702400.0, 'Priority': 0, 'RuleID': 1, 'RuleId': 1, 'Source': -1.0, 'Track': [], 'UTC': 1638374577, 'UTCMS': 745}, 'Index': 0, 'serialNumber': 'Z1721F1E17CA7', 'deviceType': 'AD410', 'DeviceName': 'Front Door'}

[GaryOkie]

Amcrest adjusts the Dahua firmware to suit their SmartHome app quite a bit. Although the AD410 implements the Dahua SmartPlan AI for human detection, they did this strictly with Cross Region Detection and not the Smart Motion Human method. There really isn't any need for SMH as you can rely on the CrossRegionDetection event for very reliable human detection.

For Home Assistant, here's all you need for the event trigger:

  trigger: 
  - platform: event
    event_type:  dahua_event_received
    id: Human Motion
    event_data:
      event: CrossRegionDetection
      payload:
        action: Start
        data:
          ObjectType: Human

The other possible ObjectType for Dahua cameras is "Vehicle", but the AD410 didn't implement it. Checking for ObjectType is currently unnecessary since it will always be Human for now.

[simonjbamber]

@GaryOkie - thank you for rapid and detailed reply! I'll switch to using the CrossRegionDetection event as you describe (or may reinstall the integration and add that sensor.)

[GaryOkie]

Happy to help. Regarding binary sensors, my advice is to stick with triggers based on events. Although RRoller did nice work adding the option to create sensors for you via the config, my understanding is this is not a feature that the core HASS team approves of. There was a PR a year ago to implement new binary sensors in the core Amcrest integration for doorbell press, but Balloob nixed it saying that "events should be handled - as events". Hard to argue with that logic. :)

In any case, as long as this custom component remains custom, feel free to switch to the built-in sensors if preferred.

[simonjbamber]

Makes sense. I reinstalled component with the CrossRegionDetection sensor but it didn't activate so looks like I will be relying on the event anyway. Out of interest do you know if anybody has done anything interesting with the other data embedded in the event? Looks like there's some info on bounding box for the detected object and also the detection region the event was triggered by (appears in app you can configure more than one region) - wondering if these can be used to differentiate between people coming from different directions or entering v leaving house. I'm going to have a play - would be useful for me as I'm likely to get a lot of false positives from my neighbours, but probably too much overlapping space to just exclude via using a single small detection zone.

[GaryOkie]

Dahua firmware with SmartPlan support does allow for multiple rules for defining multiple region detection regions, each with "Enter", "Exit", and "Appears" object movement options, along with human and vehicle recognition. Amcrest has dumbed down the firmware for simplifying the SmartHome app and has apparently locked out the ability to add additional rules or even tweak the existing one via other software or the API.

My attempts to define the AD410 detection region to trigger only when people approach the door, and not anyone walking out the front door have been futile. If the AD410 would support CrossLineDetection (aka TripWire) this should be easily possible with an incoming direction arrow only.

I've made this and other enhancement requests to the Amcrest product team. There hasn't been a single firmware update released yet for the AD410, so there might be some feature enhancements forthcoming.

[GaryOkie]

Another follow-up regarding binary sensors - you can create your own from events. Of course, using the Dahua integration to create them for you is easier, but as you have found, there are considerable variations in events and the data they present across different camera/doorbell firmware. It will be difficult I think for this integration to manage all the variations in a consistent manner.

Here's an example of how to create your own binary sensor using the template integration. (This code goes in configuration.yaml)

template:   # Create a binary_sensor for AD410 human detection
  - trigger:
    - platform: event
      event_type: dahua_event_received
      id: start
      event_data:
        Code: CrossRegionDetection
        Action: Start
    - platform: event
      event_type: dahua_event_received
      id: stop
      event_data:
        Code: CrossRegionDetection
        Action: Stop
    binary_sensor:
    - name:  Doorbell Human Motion Detected
      state: >-
        {{ 'on' if trigger.id == 'start' else 'off' }}

You can easily adapt this for the AD410 for doorbell press if you find it useful for your automations to trigger on binary sensors instead of events.

NOTE: If you have more than one Dahua/.Amcrest camera or doorbell, you can identify which one triggered the event from the camera name - {{ trigger.event.data.camera }}

EDIT: per the following post, the code shown here has been edited to properly work for the custom Dahua integration.

[simonjbamber]

Thanks @GaryOkie. I followed your basic approach, but my binary template sensor configuration ended up being slightly different (see below). Perhaps yours is based on amcrest integration rather than dahua one?)

template:
  - trigger:
    - platform: event
      event_type: dahua_event_received
      id: start
      event_data:
        Code: CrossRegionDetection
        Action: Start
    - platform: event
      event_type: dahua_event_received
      id: stop
      event_data:
        Code: CrossRegionDetection
        Action: Stop
    binary_sensor:
    - name:  Doorbell Human Motion Detected
      state: >-
        {{ 'on' if trigger.id == 'start' else 'off' }}

[GaryOkie]

Yes, you are correct. I had this example code created for the Amcrest integration and just changed the event_type from Amcrest to dahua_event_received. I did not realize that Action vs action and event vs Code differences.

I had since deleted that code from my configuration since I no longer needed to use binary sensors. I just trigger on the events in the automation directly.

[rroller]

I've started to working on adding the security light feature. This is what it'll look like, see below. The options will be: Off, On, Strobe.

This seem OK? I should have this done tomorrow.

[ideal2545]

Looks great to me, very excited its a great option to have and to be included in automations! On Dec 24, 2021, at 11:11 PM, Ronnie ***@***.***> wrote:  I've started to working on adding the security light feature. This is what it'll look like, see below. The options will be: Off, On, Strobe. This seem OK? I should have this done tomorrow. [Screen Shot 2021-12-24 at 11 09 04 PM]<https://user-images.githubusercontent.com/445655/147379602-79775613-c24a-4ba2-ab66-c569b5b57678.png> — Reply to this email directly, view it on GitHub<#52 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADKLFEZ3PQIKDDL5ZSBKYXLUSVVB3ANCNFSM5ANYT4BA>. You are receiving this because you commented.Message ID: ***@***.***>

[rroller]

Do you know if any other amcrest doorbells have the security light other than the AD410? Trying to figure out how I should gate the feature. I guess I could try to make a call to see if it works during setup

[GaryOkie]

Amcrest sells just 2 smart doorbells - the AD110 & AD410, and only the latter has a (weak) light and siren. There are 2 other SmartHome products that have a bright light and loud siren - ASH25 & ADC2. They might share the same API calls for controlling the lights, but that's TBD.

Lorex (now directly owned by Dahua) offers essentially the same doorbells that Amcrest OEM's from Dahua. This is the older LNWDB1 and the 2K version B451AJD which has the same feature set as the AD410. I've heard that the Lorex doesn't respond to API calls over port 80, which is very odd.

[rroller]

The security light feature is released in https://github.com/rroller/dahua/releases/tag/0.9.28
Please give it a try and let me know, thanks!

[rroller]

I believe everything in this thread is now resolved :D

Please reopen or create a new issue if there's anything else. Thanks everyone!

[rgaufman]

Did you ever figure out what LeFunctionStatusSync means? - also cannot find documentation for this anywhere

[GaryOkie]

Amcrest has not publicly released any API documentation related to SmartHome devices (nor has Dahua for their equivalent devices that Amcrest adapts).

The event code "LeFunctionStatusSync" is only meaningful with the associated data payload. Examples are the status of the "Function: Siren", and the puddle light. Each of these should be able to be managed through the API, but the alarm siren hasn't responded to the API calls I've tried.