Amcrest Doorbell AD110 API/Local Only

So I want to start out with underlining how important the next sentence is when it comes to this product.

Should always exercise caution when messing with anything when it comes to this doorbell and changing things via the API is no exception.

There is already at least one other topic on this on this forum here.

I bought this doorbell back in January 2020 in hopes of having a local only HA integrated video doorbell. I bricked one but the second one has held up so far and been quite nice. I only had 3 goals for this device… Local only, Feed video stream to something like Motioneye and pull doorbell presses into Home Assistant. So far I managed to achieve just that. I am sharing what I have done and my setup incase it happens to help anyone else in any way.

My doorbell is running off the initial firmware that was on it when I bought it (Sorry don’t remember what it is currently) and I know there has been at least 3-4 firmware upgrades since so I don’t know if the api is the same or even still accessible with the newer firmware. I did run across a post by an Amcrest employee stating that Amcrest was moving towards a no end user access to the api so If any of what I post works for you, upgrading at some point could end up causing it to stop.

I do use the Amcrest platform with this doorbell which does give me online status as well as pir and access to the stream which I don’t utilize the stream but utilize the other two.

I looked through the official Amcrest/Dahua API (which does not include the doorbell) to steer me in the right direction. Much of it does work with this doorbell. The important part was finding out how to list the config options that way you can get an accurate list of all the things you want to change through the API.

 http://<AD110-IP>/cgi-bin/Config.backup?action=All

This opened up everything I needed to achieve my goals such as changing the NTP for local polling of time.

http://<AD110-IP>/cgi-bin/configManager.cgi?action=setConfig&NTP.Address=<ip or url to time server>

I use Chrony to serve up time to my local network devices.
I went ahead and disabled a few other settings that indicated to attempting to reach outside my network.

http://<AD110-IP>/cgi-bin/configManager.cgi?action=setConfig&T2UServer.Enable=false

http://<AD110-IP>/cgi-bin/configManager.cgi?action=setConfig&VSP_PaaS.Enable=false

http://<AD110-IP>/cgi-bin/configManager.cgi?action=setConfig&VSP_PaaS.CustomEnable=false

Now to be clear, I cut off access to the internet to this device through my router so some of this is redundant but I went ahead and did it anyway. This will also cause the blue ring light around the button of the doorbell to flash 4 times, pause then start over. But I have a fix for that! (This is different than the Online status you get through the Amcrest platform)

http://<AD110-IP>/cgi-bin/configManager.cgi?action=setConfig&VSP_PaaS.Online=true

Unfortunately I had discovered after a day or two that the ring would start blinking again. I suspect it has something to do with some internal script I can’t access randomly checking if there is an update available for the doorbell and thus triggering the Online status back to false when it fails. In the config you can find the url for the update server but I did not see any way to disable it. So to combat this I simply made a binary rest sensor, a shell command and automation in HA to check the Online status and reset it if need be.

Binary Sensor:

- platform: rest
  scan_interval: 14400
  resource: http://<AD110-IP>/cgi-bin/configManager.cgi?action=getConfig&name=VSP_PaaS.Online
  username: !secret amcrest-username
  password: !secret amcrest-password
  authentication: digest
  name: Amcrest Doorbell Online Light
  device_class: light
  value_template: >
    {{value.split('=')[-1]}}

The scan_interval is completely optional, I have mine to only check once every 4 hours, if the doorbell was to reset the online status at the wrong time my light would blink for 4 hours and I can live with that.

Shell Command:

doorbell_online_light: "curl -u username:password -X GET --digest 'http://<AD110-IP>/cgi-bin/configManager.cgi?action=setConfig&VSP_PaaS.Online=true'"

Then I use an automation that checks the status of the Binary Sensor and uses the Shell Command to reset the Online status back to true.

The next hurdle was pulling doorbell presses into HA. Some use a device attached to the chime to detect if the doorbell was pressed and others may use something else but I really wanted to just make the API work and oh boy did Dahua(cause lets face it this is a Dahua doorbell) did this wonky. The only thing I could find in the API that changes when the doorbell is pressed is

http://<AD110-IP>/cgi-bin/configManager.cgi?action=getConfig&name=CallInfo

It appears to cycle through the numbers 0-9, in fact it can even change to the same number if the doorbell is pressed again in a short duration of time. I tackled this using a rest sensor, automation and an input bool which is completely optional.

Rest Sensor:

- platform: rest
  resource: http://<AD110-IP>/cgi-bin/configManager.cgi?action=getConfig&name=CallInfo
  username: !secret amcrest-username
  password: !secret amcrest-password
  authentication: digest
  name: Amcrest Doorbell Count Sensor
  value_template: >
    {{value.split('=')[-1]}}

In the automation set the trigger to the rest sensor state and leave the fields blank so any change would make it trigger, I added two conditions to prevent false triggers incase connection dropped and the sensor went to unavailable.

not trigger.to_state.state == 'unavailable'
not trigger.from_state.state == 'unavailable'

In my automation I have it trigger an input bool then turn it back off just so I can tally the amount of times the doorbell has been pressed.

Because I do not use the Amcrest app at all with this doorbell I did add me another shell command to reboot the doorbell should I ever need to.

Shell Command

doorbell_reboot: "curl -u username:password -X GET --digest 'http://<AD110-IP>/cgi-bin/magicBox.cgi?action=reboot'"

You can also adjust the PIR as well as change how the IR lights act through the api, those are listed in the Amcrest/Dahua documentation listed above. I had ultimately unplugged the IR lights on my device as I didn’t need them but you can adjust them through the api.

And with that I managed to tackle all I wanted from this product. Some hoops for sure but given the price and security of it being 100% local it was well worth it for me. I have been running this setup for a few months now without issue.I hope this helps someone and if anyone has any improvement ideas I am certainly all ears.

3 Likes

I don’t have the option of setting a NOT condition to trigger to or from. How’s that done?

You would use a Template condition with a value like this

{{ not trigger.to_state.state == 'unavailable' }}

Doorbell button press integration here is awesome. Thanks!

Doorbell got knocked offline (assuming a firmware update), I can connect to the wifi hotspot, but the app will not proceed with pairing claiming the doorbell to be out of pairing mode, despite the LED indicating otherwise. No response from support. Browsing the web, it appears this isn’t the first time they’ve bricked a bunch of doorbells with a sh!t upgrade.

Contact Ecobee support, mine was doing this and they are sending a replacement. Don’t call they won’t answer, use the support chat

Ecobee?

I contacted Amcrest support. They finally responded, with questions that were answered in my first contact already. And though I responded with the answers anyway, crickets so far.

Crap sorry I meant Amcrest lol. Had same problem with my Ecobee but I got it sorted

Can someone post an automation of this, my brain isn’t working today, thanks
Need LESS eggnog

Edit:
Duh, very simple lol. Works perfectly

doesnt the rest senor only poll every 30 seconds or so and because of that wouldn’t there be a delay between when the door bell is pressed and when the sensor is updated?

in my other amcrest IP cams i was using SNMP events to send motion notifications to node-red from the camera as they occured, i wonder if there is a specific SNMP event for the door bell press so you can just have the event be pushed

Yes. The delay can be anywhere between 1-30 seconds before the binary toggles. In my original post there is a link to another forum post where someone has been working on adding event subscription support to the core amcrest integration for the doorbell. as of this moment it almost seems to be at a stall.

In case anyone is looking for a sample:

alias: Doorbell Notification
description: ''
trigger:
  - platform: state
    entity_id: sensor.amcrest_doorbell_count_sensor
condition:
  - condition: template
    value_template: '{{ not trigger.to_state.state == ''unavailable'' }}'
  - condition: template
    value_template: '{{ not trigger.from_state.state == ''unavailable ''}}'
action:
  - data_template:
      data:
        push:
          sound:
            critical: 1
            name: US-EN-Morgan-Freeman-Someone-Is-Arriving.wav
            volume: 1
      message: Someone is at the door!
    service: notify.notify
  - service: media_player.volume_set
    data:
      volume_level: 0.4
    entity_id: media_player.kitchen_south
  - delay: '00:00:01'
  - service: notify.alexa_media_kitchen_south
    data:
      data:
        method: all
        type: announce
      message: The doorbell is ringing
mode: single

Polling that doorbell button through REST is way too unpredictable. Sometimes its a few seconds. Sometimes its 20 seconds. I resorted to using a spare android phone and having tasker intercept the push notifications until someone comes out with a better way. Using tasker is instant and works reliably for the time being.

1 Like

I have not had that issue in the year I been using it but if precise timing on doorbell button push is mission critical you could always monitor the doorbell through other means rather than relying on the AD110 itself or the amcrest app notification.

So when someone presses the doorbell for you, what kind of delay are you typically experiencing? The default polling on REST is all over the place from my experience. Best case, you may get around 5 seconds. In my use case, that’s a bit too long.

I average around 2 doorbell presses a day and if you are getting way more than that then any delay is going to be more obvious for you. For me the majority of the time the notification I have sent to my phone via HA is near instant and never any longer than a couple a seconds for those times it isn’t. It’s lucky timing I suppose but again the amount of presses you get a day will make any random delay more apparent.

In my original post there is a link where they talk about adding the ability to subscribe to the doorbell’s door presses alert subscription so instead of polling for a change the Amcrest integration would just listen for the alert. It’s been a bit since I checked on the progress for that so you may wanna have a look. other than that as I stated above you will have to go with an additional means of detecting the doorbell press outside of amcrest and the doorbell all together which many do do since that is a universal method.

Polling is intermittently slow for me too. Then again, I can’t keep the damn thing online when temps drop below freezing. Amcrest’s support has been completely erratic. Although eventually arriving at my RMA for my first bricked device, they have a problem with various departments not being in sync. RMA not knowing what support is saying and vice versa. They ran me around in circles for nearly a month, asking for the same data over and over and over.

I chose this doorbell partly because it’s an American company, despite the Chinese guts. I’m beginning to consider other options, as this one has been an unreliable hassle. Unfortunately there’s not a lot of doorbells with RTSP available to chose from. Maybe an opportunity for crafting my own?

Sounds like you have a defective unit. I am on my second which is still running the original firmware. They had a real issue where x amount of these units would ship broken out of the box or quit working within days or weeks after installation and these were units people didn’t mess with trying to change settings and then on top of that you had the super buggy firmware where if you had used anything other than the mobile app to change a setting on it would brick the unit near instantly. It was a real mess.

It’s my second one via RMA. I’d say they have a quality problem.

I got tired of waiting for native Home Assistant support so I’ve created a project to expose the Amcrest events (including AD110 doorbell pushes) via MQTT: https://github.com/dchesterton/amcrest2mqtt. It subscribes to the events, doesn’t use polling and works instantly.

If anyone uses it, please let me know how you get on as I’ve only tested it on my AD110 so far.

6 Likes