Amcrest AD410 Doorbell

Have you updated your AD410 firmware to 20221201 ? If so, that explains why you aren’t seeing the CrossRegionDetection (Human detected) event. In fact, no events are accessible with this corrupted firmware update. Amcrest developers admitted to the exact same mistake with the AD110 firmware which took a few months to correct. No word yet on when/if this AD410 firmware will be corrected. EDIT: The latest firmware on the download page has been updated to fix this issue.

Note that within the SmartHome app it still shows xx210220 as the production version. It does not reflect or notify that there is a newer firmware available.

You were correct @GaryOkie . On the 20221201 firmware the human detection was not registering and the doorbell was disconnecting and reconnecting to wifi a few times every minute. After downgrading to the previous firmware both problems went away.

@adoucette Glad to hear you’ve resolved the event problem by reverting the firmware. Hope your WiFi connection remains stable as I had not heard of that being an issue with the new firmware.

Speaking of which, there is a newer firmware available now which the change log (Yea! finally!) states the event handling issue has been corrected. I have not installed it yet. If you do, please report back if you have any issues. You still have the old 20210220 firmware that you can go back to if needed.

Can anyone comment on how quickly the events fire using this set up? I’m currently using the Dahua integration but find doorbell press and human motion detection take up to 10 seconds to fire through to Home Assistant. I’m looking for a way to improve this and would like to hear any feedback before I try setting up using this approach.

Using the info I learned here, I am monitoring for events that are amcrest and filtering them for the doorbell button press, I get notified almost instantly using node red to process it and send the notification with a snapshot

“events that are amcrest” are from the core Amcrest integration. Derek was questioning why events from the Dahua integration are taking up to 10 seconds. They should be instantaneous as well, but I can’t confirm as I’m back to using the Amcrest core integration for a while now.

Ahh my bad, that’s what I get for not reading lol

I think you read it properly. @derekjwhitten was asking:

…which I interpret to be he is comparing his slow 10 s Dahua setup to what we are experiencing with the Amcrest integration and the events triggers to provide info as to whether he would want to try configuring this way instead.

That being said, as you said, I too get notified on my watch immediately the moment I press the button and similarly when it detects a human. For testing it configured an automation to turn on a light switch when the doorbell button is pressed and it is simply like turning on a light switch it is that quick, even a split second before I receive the push notifications. I haven’t configured mine to do the snapshot yet so I can’t speak to that portion of it. (still on test bench, not installed yet)

All around good work with this @flyinglow . I would hope we can bring this to the attention of the Amcrest integration owner so they possibly add these in as part of their documentation or better yet use this to create the actual sensors and whatnot out of the box so we don’t have to use your technique. Also the using the AlarmLocal is so much better for me with 2 doorbells, that I can identify which doorbell triggers the automation.

This is my test automation to see if I could properly determine which doorbell was pressed. My triggers add looking for the camera: <name of camera> and setting different trigger IDs to be used in the choose action down the automation. I also have an ESPHome device w/ 2-channel relay configured to be able to momentary press my mechanical doorbell chime as the chime kit is not compatible with mine:

- id: '1674677926052'
  alias: Amcrest Doorbell Pressed
  description: Trigger when Amcrest Doorbell Button Press Event Fires
  trigger:
  - platform: event
    event_type: amcrest
    event_data:
      camera: Garage Doorbell
      event: AlarmLocal
      payload:
        action: Start
    alias: Amcrest Garage Doorbell Pressed
    id: Garage Doorbell Pressed
  - platform: event
    event_type: amcrest
    event_data:
      camera: Front Doorbell
      event: AlarmLocal
      payload:
        action: Start
    alias: Amcrest Front Doorbell Pressed
    id: Front Doorbell Pressed
  action:
  - choose:
    alias: Determine which doorbell was pressed and perform actions accordingly
    - conditions:
      - condition: trigger
        id: Garage Doorbell Pressed
      sequence:
      - service: script.notify_iphone
        alias: Notify Garage Doorbell Pressed
        data:
          message: Ding Dong
          title: Garage Doorbell
      - service: switch.turn_on
        alias: Ring Garage Door mechanical chime
        data: {}
        target:
          entity_id: switch.garage_doorbell_chime
    - conditions:
      - condition: trigger
        id: Front Doorbell Pressed
      sequence:
      - service: script.notify_iphone
        alias: Notify Front Doorbell Pressed
        data:
          message: Ding Dong
          title: Front Doorbell
      - service: switch.turn_on
        alias: Ring Front Door mechanical chime
        data: {}
        target:
          entity_id: switch.front_doorbell_chime
  mode: queued
  max: 10

Confirming this works, I now have modified the packages\amcrest.yaml to have presses and sensors for each, but I’ll just show the different doorbell button presses here:

  - trigger:
      - platform: event
        event_type: amcrest
        id: start
        event_data:
          camera: "Front Doorbell"
          event: AlarmLocal
          payload:
            Code: AlarmLocal
            action: Start
      - platform: event
        event_type: amcrest
        id: stop
        event_data:
          camera: "Front Doorbell"
          event: AlarmLocal
          payload:
            Code: AlarmLocal
            action: Stop
    binary_sensor:
      - name: Front Doorbell Ring
        icon: mdi:doorbell-video
        state: >-
          {{ 'on' if trigger.id == 'start' else 'off' }}

  - trigger:
      - platform: event
        event_type: amcrest
        id: start
        event_data:
          camera: "Garage Doorbell"
          event: AlarmLocal
          payload:
            Code: AlarmLocal
            action: Start
      - platform: event
        event_type: amcrest
        id: stop
        event_data:
          camera: "Garage Doorbell"
          event: AlarmLocal
          payload:
            Code: AlarmLocal
            action: Stop
    binary_sensor:
      - name: Garage Doorbell Ring
        icon: mdi:doorbell-video
        state: >-
          {{ 'on' if trigger.id == 'start' else 'off' }}

So, I will swap out the original test triggers for that automation and just use the binary sensors. This should work, but haven’t tested yet.

- id: '1679240460251'
  alias: Amcrest Doorbell Pressed (New triggers)
  description: Trigger when Amcrest Button Press Event Fires
  trigger:
  - platform: state
    entity_id:
    - binary_sensor.front_doorbell_ring
    to: 'on'
    id: Front Doorbell Pressed
  - platform: state
    entity_id:
    - binary_sensor.garage_doorbell_ring
    to: 'on'
    id: Garage Doorbell Pressed
...

Sorry this got long, but hope it helps someone else that may have similar situations with having more than one doorbell.

1 Like

I thought Derek asking about “this setup” meant his setup using the Dahua Integration which is slow… not the OP setup.

I concur that the Amcrest Integration provides immediate event triggers, and would greatly benefit from adding new sensors. There have been PR’s to do just that. These PR’s have been rejected due to the NO MORE YAML CONFIG rule. So until the effort is undertaken to modernize this integration to use the config flow UI, we need to rely on parsing events. Ain’t that hard, and examples like yours are indeed helpful to new users.

Post edited.
Guys, I struggled getting template sensors to work, turns out they defaulted to unknown, and never came online until I went out and tripped them. I just was assuming they’d default to off. I’m a bone head.

Apologies everyone for the ambiguity in my post…

I was asking about any latency observed with the Amcrest integration and the tips shared by @flyinglow. I’m currently using the Dahua integration and find the Amcrest app goes off on my phone almost instantly, but the event in HomeAssistant is about 10 seconds behind. I’m running into further issues with my set-up since my early post, so I’ll have a go at flyinglow’s approach this weekend and see how it goes.

What is your setup you are using to run HA? are any other integration’s slow?

As @BigWalnutZ does, I also check events, depending on how you are filtering them this can be slow, if you pull in all events and then filter it out after looking for it this is a slow process and hammers HA, the better option if this is the case is to filter events only for what you are looking for from the off.

So my system is filtered from the off to only look at Amcrest events:
image

Where after it looks for AlarmLocal and Start
image

And then runs the rest of the automation

Any further info you can give about your setup will help, could be a network issue, HA issue, integration issue.

1 Like

I did all this and I can see the camera display, and when i press my doorbell I can play a sound on all my google minis, but then afterwards the Front Door Bell Ring is stuck on “On”. I have to manually go turn it “Off” in the developer tools each time, Any idea why this may be? The person detection also just triggers On, and then never back off as well.

Thanks.

I’m actually stuck and found this post after trying that exact thing (walk outside and push the button then show my face). I’m certain both events worked within the camera because the native Amcrest app gave me the relevant event alerts.

Firmware is 20210220 and the “doorbell Online” sensor shows connected, the streaming picture works, but the Human, Motion, and Ring sensors all show unknown. Over in the event viewer I subscribed to event type “amcrest” and I see plenty of results in therms of motion and video recording, but I haven’t see my button presses or human detection show up.

I wonder if that’s enough info to trigger any other ideas on your part?

It sounds like your integration is working fine using the event type “Amcrest” since you are seeing all the events showing up.

But… " Human, Motion, and Ring sensors all show unknown"? The core Amcrest integration doesn’t have a doorbell ring sensor! It has a motion sensor and a Crossline Detection (tripwire) sensor, but not a human motion detected sensor (aka CrossRegionDetection).

You can craft your own sensors using events or just trigger on these events directly.

Maye you have confused the custom Dahua integration configuration which provides a plethora selection of sensors that the Amcrest integration does not.

That could very well be true - I’m a bit confused by this thread and I’m pretty much copying the YAML Here’s what I’ve got right now:

# amcrest AD410 doorbell
amcrest:
  - host: 192.168.1.12
    username: admin
    password: [redacted]
    name: frntdoorbell
    resolution: high
    stream_source: rtsp
    scan_interval: 15
    binary_sensors:
      - online

template:
  - trigger:
      - platform: event
        event_type: amcrest
        id: start
        event_data:
          camera: "Front Door Bell"
          event: CrossRegionDetection
          payload:
            Code: CrossRegionDetection
            action: Start
            data:
              Action: Appear
              Object:
                ObjectType: Human
      - platform: event
        event_type: amcrest
        id: stop
        event_data:
          camera: "Front Door Bell"
          event: CrossRegionDetection
          payload:
            Code: CrossRegionDetection
            action: Stop
            data:
              Object:
                Action: Appear
                ObjectType: Human
    binary_sensor:
      - name: Front Door Bell Human
        icon: mdi:motion-sensor
        state: >-
          {{ 'on' if trigger.id == 'start' else 'off' }}

  - trigger:
      - platform: event
        event_type: amcrest
        id: start
        event_data:
          camera: "Front Door Bell"
          event: AlarmLocal
          payload:
            Code: AlarmLocal
            action: Start
      - platform: event
        event_type: amcrest
        id: stop
        event_data:
          camera: "Front Door Bell"
          event: AlarmLocal
          payload:
            Code: AlarmLocal
            action: Stop
    binary_sensor:
      - name: Front Door Bell Ring
        icon: mdi:doorbell-video
        state: >-
          {{ 'on' if trigger.id == 'start' else 'off' }}

  - trigger:
      - platform: event
        event_type: amcrest
        id: start
        event_data:
          camera: "Front Door Bell"
          event: VideoMotion
          payload:
            Code: VideoMotion
            action: Start
      - platform: event
        event_type: amcrest
        id: stop
        event_data:
          camera: "Front Door Bell"
          event: VideoMotion
          payload:
            Code: VideoMotion
            action: Stop
    binary_sensor:
      - name: Front Door Bell Motion
        icon: mdi:motion
        state: >-
          {{ 'on' if trigger.id == 'start' else 'off' }}

That’s using the amcrest integration and creating the binary sensors that should do their obvious things, no? (meaning that the “human” sensor goes ON when the AD410 notices a person, etc etc). The sensors show in my default dashboard, they’re just always in the unknown state.

I don’t use the techniques described in this thread that I see you have closely followed. There are some things that just look really weird to me unless firmware differences are behind it.

For example, the Doorbell press event isn’t “AlarmLocal”. That event is associated to the older AD110 doorbell for motion events detected via its PIR sensor. The correct doorbell press event is “CallNoAnswered”.

Both the AD110 and AD410 report “VideoMotion” events for pixel-change motion but typically you should disable Motion Detection for the AD410 in the SmartHome app as it throws too many false motion events. Just opt to use only Human Detection in the AD410 and check for the CrossRegionDetection event.

I use a much simpler method of triggering on AD410 events that doesn’t rely on creating binary sensors as the examples in this thread show.

Automation.yaml

- id: doorbell_button_pressed
  alias: Doorbell button pressed
  trigger:
  - platform: event
    event_type: amcrest
    id: DoorbellPress
    event_data:
      event: CallNoAnswered
      payload:
        action: Start

  action:
    - service: script.doorbell_press_actions
- id:    human_motion_detected
  alias: Human Motion Detected
  mode: parallel
  max: 5
  trigger: 
  - platform: event
    event_type: amcrest 
    id: Human Motion
    event_data:
      event: CrossRegionDetection
      payload:
        action: Start
        data:
          ObjectType: Human
  action:
    - service: script.human_detected_actions

awesome - this is working much better (obviously after making sure the action pointed to something real, since I didn’t have a ‘script.human_detected_actions’ setup yet… but I will soon).

Good stuff, thx!

1 Like

Well, I’m making serious progress but I’m unable to get snapshot images to come through.

- id: doorbell_button_pressed
  alias: Doorbell button pressed
  trigger:
  - platform: event
    event_type: amcrest
    id: DoorbellPress
    event_data:
      event: CallNoAnswered
      payload:
        action: Start
  action:
  - service: notify.notify
    data:
      title: xxxxx Doorbell Pressed
      message: xxxxx doorbell pressed
      data:
        image: http://192.168.1.26/cgi-bin/snapshot.cgi
        authentication: digest
        username: admin
        password: [redacted]

anything obviously wrong here?

I assume you are using the HA Companion Notifier? I’ve not used that before so can’t really say why it isn’t liking the snapshot.cgi URL. (Digest auth is correct).

What I do is call the camera.snapshot service to create a jpeg then send that image file using Telegram notifier. I believe you can do the same with Companion notifier instead of a URL.

Edit: maybe the problem is you specified image: for the url, instead of “url:”? The error message suggests that as well (failed to load attachment).