When using the normal amcrest integration should there be an event listener called amcrest? Or does it just show up? I was going to watch for the event but expected to see an event topic to subscribe to (same with rrollers dahua, no binary sensor for button press and didn’t see an event topic either). Also I don’t see the 110 mentioned on rrollers docs
i am talking about two different, the official and another but I know @GaryOkie is familiar with both so I figured he’d know… with the official did you get an amcrest event on the events page of listeners?
The event_type for the core Amcrest Integration is “Amcrest” and it does show up in the developer’s event tool as an active listener. This doorbell press “CallNoAnswered” event is the same for the AD110 and AD410, and can be triggered in the exact same way as rroller’s custom dahua integration except the event_type/listener is “dahua_event_received”.
Motion event handling is different between the AD110 and AD410, since the latter has the excellent human detection which leverages IVS/intrusion detection AI.
EDIT: Since all I care about is the “start” of an event and not when/if “stop” occurs, I don’t need to create binary sensors. Triggering on events is just as easy once you understand how to include the payload. It’s true that rroller’s custom integration automatically creates binary sensors for events that are selected, but I prefer not to use them.
Yeah I’ll have to mess around with them again… I must have had something else going on because I didn’t get a listener for either integration on the events page… maybe I needed to force refresh or something.
The Amcrest integration passing events capability was added in the 2021.5 release. There is an outstanding issue that the subscription to “All” events is failing on some Amcrest cameras. See https://github.com/home-assistant/core/issues/50264 Check your logs to see if this is occurring for you, otherwise I have no idea why you aren’t seeing events if you have an updated HASS version.
A PR was submitted to include a new config to disable events, but it was rejected due to it requiring a YAML config update. Ironically, a later PR to include a new “crossline_detected” binary sensor was added which did require a YAML update and it was APPROVED! Different reviewer, different understanding of HASS dev rules. Sheesh.
EDIT: just now reviewed other Amcrest PR’s that were closed and rejected due to this YAML config show-stopper rule. Back in Feb 2021, there was a PR to add NVR support to the Amcrest integration! That would have been very useful. (BTW - RRoller’s does support Dahua NVR’s which should work for Amcrest NVR’s)
Could you please explain this beginner how exactly I can implement the call button of my AD410?
I have an integration for this doorbell using ONVIF, but it doesn’t expose the call button.
So I have manually added this to my configuration.yaml:
@nikotine - You won’t need both Amcrest and Onvif integrations for camera streaming, recording, PTZ support, etc. But you do need the Amcrest integration (or Amcrest2MQTT or Dahua Integtration) to trigger on doorbell press events or any camera event, so may as well just use it alone.
You also should specify these amcrest settings in the YAML config:
resolution: high
stream_source: rtsp
Note that the amcrest integration has not yet been updated to use the configuration UI so that is why it doesn’t show up in the integrations list.
The automation code above is all you need for triggering upon a doorbell button press. You will need to add your desired actions. There are other events possible - such as for human detection.
Thanks for your answer. I just tried that trigger above and it worked!
I’ll keep the ONVIF integration for the moment, as it seems to work well, next to the Amcrest integration.
Anyone have feedback on reliability of using events from the amcrest integration vs using Amcrest2MQTT
IE does it recover gracefully if the Doorbell loses wifi and reconnects or reboots?
I am currently using Amcrest2MQTT and would like to simplify down to a native integration if it is reliable… I have had some issues with Amcrest2MQTT that have now mostly been resolved…
I’ve used both and find the core amcrest integration event passing to be very reliable, even after reconnecting. I switched to it from amcrest2mqtt for the very reason you mentioned - to simplify things.
I’m also testing the custom dahua integration which also handles events nicely, and even provides the option to create binary sensors (which are nice to have, but not essential). It too works for the AD110/AD410.
I installed an AD410 over the weekend and I’m using the Dahua integration. The camera and motion detection works, but the doorbell button press duration is inconsistent. I left the entity names as created, and so I expected to see button presses reflected in binary_sensor.front_doorbell_call_no_answered. However… it only works sometimes. The last time I pressed the doorbell button, it remained in a detected state for over an hour, and subsequent presses don’t change the state. I can set the state in HA and it’ll remain. Maybe I’ll have to fudge it after a timeout; has anyone else encountered this?
EDIT: I should say that I have no Dahua or Amcrest event listeners listed here: https://<ha-ip>/developer-tools/event.
You should post issues with the custom Dahua integration to RRoller’s Dahua github site.
The auto-generated binary_sensor seems to be missing the “stop” event in your case. I don’t use those sensors and instead trigger only on the button press “start” event, as so:
trigger:
- platform: event
event_type: dahua_event_received # Note: for the core Amcrest integration, specify "Amcrest" here instead
id: doorbell press
event_data:
event: CallNoAnswered
payload:
action: Start