feat: Trigger cameras on HA bus events (#2512)
This commit is contained in:
committed by
dermotduffy
parent
406176eebc
commit
0a36358394
@@ -381,14 +381,40 @@ cameras:
|
||||
# [...]
|
||||
```
|
||||
|
||||
| Option | Default | Description |
|
||||
| ----------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `doorbell` | `false` | Whether to trigger the camera by automatically detecting an [HA `event.*` entity](https://www.home-assistant.io/integrations/event/#device-class) with `device_class: doorbell` on the same HA device as the camera entity. Requires `camera_entity` to be set. |
|
||||
| `entities` | | Whether to not to trigger the camera when the state of any Home Assistant entity becomes active (i.e. state becomes `on` or `open`). |
|
||||
| `events` | `[]` | Whether to trigger the camera when `events` occur (whether or not media is available) or whenever updated `clips` or `snapshots` are detected. Detection support varies by camera [engine](engine.md). |
|
||||
| `motion` | `false` | Whether to not to trigger the camera by automatically detecting and using the motion `binary_sensor` for this camera. This autodetection only works for Frigate cameras, and only when the motion `binary_sensor` entity has been enabled in Home Assistant. |
|
||||
| `occupancy` | `false` | Whether to not to trigger the camera by automatically detecting and using the occupancy `binary_sensor` for this camera and its configured zones and labels. This autodetection only works for Frigate cameras, and only when the occupancy `binary_sensor` entity has been enabled in Home Assistant. If this camera has configured zones, only occupancy sensors for those zones are used -- if the overall _camera_ occupancy sensor is also required, it can be manually added to `entities`. If this camera has configured labels, only occupancy sensors for those labels are used. |
|
||||
| `reviews` | | Configuration for triggering on review items. Currently only supported by Frigate. See [`reviews`](#reviews). |
|
||||
| Option | Default | Description |
|
||||
| -------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `doorbell` | `false` | Whether to trigger the camera by automatically detecting an [HA `event.*` entity](https://www.home-assistant.io/integrations/event/#device-class) with `device_class: doorbell` on the same HA device as the camera entity. Requires `camera_entity` to be set. |
|
||||
| `entities` | | Whether to not to trigger the camera when the state of any Home Assistant entity becomes active (i.e. state becomes `on` or `open`). |
|
||||
| `events` | `[]` | A list of Home Assistant bus events to trigger on, with optional payload filtering. Each entry subscribes to one HA event type and fires the camera trigger every time that event is dispatched (and the optional `event_data` filter matches). See [`events`](#events). |
|
||||
| `media_events` | `[]` | Whether to trigger the camera when `events` occur (whether or not media is available) or whenever updated `clips` or `snapshots` are detected. Detection support varies by camera [engine](engine.md). |
|
||||
| `motion` | `false` | Whether to not to trigger the camera by automatically detecting and using the motion `binary_sensor` for this camera. This autodetection only works for Frigate cameras, and only when the motion `binary_sensor` entity has been enabled in Home Assistant. |
|
||||
| `occupancy` | `false` | Whether to not to trigger the camera by automatically detecting and using the occupancy `binary_sensor` for this camera and its configured zones and labels. This autodetection only works for Frigate cameras, and only when the occupancy `binary_sensor` entity has been enabled in Home Assistant. If this camera has configured zones, only occupancy sensors for those zones are used -- if the overall _camera_ occupancy sensor is also required, it can be manually added to `entities`. If this camera has configured labels, only occupancy sensors for those labels are used. |
|
||||
| `reviews` | | Configuration for triggering on review items. Currently only supported by Frigate. See [`reviews`](#reviews). |
|
||||
|
||||
### `events`
|
||||
|
||||
The `events` list subscribes the card to Home Assistant bus events. Each entry maps to a single `event_type` (e.g. `zha_event`, `deconz_event`, or any custom event your automations fire). Because events are momentary (HA fires them once, with no on/off), the card treats each fire as an instantaneous trigger; the visible "active" window is then controlled by [`view.triggers.event_hold_seconds`](../view.md?id=triggers).
|
||||
|
||||
```yaml
|
||||
cameras:
|
||||
- camera_entity: camera.front_door
|
||||
triggers:
|
||||
events:
|
||||
# Trigger only on a specific ZHA device firing its 'press' command.
|
||||
- event_type: zha_event
|
||||
event_data:
|
||||
device_ieee: '00:11:22:33:44:55:66:77'
|
||||
command: press
|
||||
# No `event_data` filter -- triggers every time this event is fired.
|
||||
- event_type: home_doorbell_pressed
|
||||
```
|
||||
|
||||
| Option | Default | Description |
|
||||
| ------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `event_type` | | The Home Assistant event type to subscribe to (e.g. `zha_event`, `deconz_event`, or a custom event name fired by one of your automations). Same field name and meaning as in HA automation YAML. |
|
||||
| `event_data` | | Optional dictionary of key/value pairs the event's payload must contain for this entry to trigger. Matching is a deep subset (every key listed must be present in the event payload and match; extra keys in the event are ignored). Same field name and semantics as in HA automation YAML. Omit entirely to trigger on every fire of this `event_type`. |
|
||||
|
||||
> [!TIP] Shared `event_type` values like `zha_event` and `deconz_event` fire for **every** device on that integration. Without an `event_data` filter the camera would trigger on any Zigbee/deCONZ device press in your home. Use `event_data` to narrow down to the specific device you care about; you can copy values straight out of **Developer tools → Events** in Home Assistant.
|
||||
|
||||
### `reviews`
|
||||
|
||||
@@ -429,6 +455,11 @@ cameras:
|
||||
entities:
|
||||
- binary_sensor.front_door_sensor
|
||||
events:
|
||||
- event_type: zha_event
|
||||
event_data:
|
||||
device_ieee: '00:11:22:33:44:55:66:77'
|
||||
command: press
|
||||
media_events:
|
||||
- events
|
||||
- clips
|
||||
- snapshots
|
||||
|
||||
@@ -153,7 +153,7 @@ human interaction with the card; this behavior can be configured via the
|
||||
| `actions` | | The actions to take when a camera is triggered. See [Trigger action configuration](#trigger-action-configuration). |
|
||||
| `filter_selected_camera` | `true` | If set to `true` will only trigger on the currently selected camera. |
|
||||
| `show_trigger_status` | `false` | Whether or not the `live` view should show a visual indication that it is triggered (a pulsing border around the camera edge). |
|
||||
| `signal_hold_seconds` | `30` | The synthesized on-period for momentary trigger sources that have no native on/off state (e.g. HA `event.*` entities or anything that fires as a single signal). For a doorbell press paired with `trigger: call`, this is effectively the ring window during which the call can be answered. Added _on top of_ `untrigger_delay_seconds`. Ignored for stateful sources (`binary_sensor`, `switch`, etc.). |
|
||||
| `event_hold_seconds` | `30` | The synthesized on-period for momentary trigger sources that have no native on/off state (e.g. HA `event.*` entities or anything that fires as a single signal). For a doorbell press paired with `trigger: call`, this is effectively the ring window during which the call can be answered. Added _on top of_ `untrigger_delay_seconds`. Ignored for stateful sources (`binary_sensor`, `switch`, etc.). |
|
||||
| `untrigger_delay_seconds` | `0` | The number of seconds to continue to consider the camera triggered after the source ends, before taking the configured `untrigger` action. |
|
||||
| `untrigger_force_seconds` | `0` | The number of seconds after a camera first triggers before force untriggering that camera. Set to `0` to disable. |
|
||||
|
||||
@@ -165,7 +165,8 @@ human interaction with the card; this behavior can be configured via the
|
||||
> "ring-then-end-if-unanswered" pattern), the ring lasts until the source ends
|
||||
> plus `untrigger_delay_seconds`. For momentary sources (HA `event.*` entities,
|
||||
> a doorbell press), the source ends instantly so the ring window is
|
||||
> `signal_hold_seconds` (default `30`s) plus `untrigger_delay_seconds`.
|
||||
> `event_hold_seconds` (default `30`s) plus `untrigger_delay_seconds` (default
|
||||
> `0`s).
|
||||
|
||||
### Trigger action configuration
|
||||
|
||||
|
||||
+31
-2
@@ -363,7 +363,9 @@ elements:
|
||||
|
||||
The [`doorbell` profile](configuration/profiles.md?id=doorbell) turns a dashboard into a phone-like ringer when somebody presses the doorbell, by setting [`view.triggers.actions.trigger: call`](configuration/view.md?id=triggers) and auto-discovering [HA `event.*` entities](https://www.home-assistant.io/integrations/event/#device-class) with `device_class: doorbell` on the camera's device (Ring, UniFi Protect, Nest, DoorBird, Reolink, etc.). The intended deployment is a wall-mounted tablet sitting on the dashboard.
|
||||
|
||||
A doorbell press is instantaneous, so the card synthesises a ring window from [`view.triggers.signal_hold_seconds`](configuration/view.md?id=triggers) (default `30`s) — long enough for a typical phone-style answer window. `untrigger_delay_seconds` then lingers past that, same as for any stateful trigger.
|
||||
A doorbell press is instantaneous, so the card synthesises a ring window from [`view.triggers.event_hold_seconds`](configuration/view.md?id=triggers) (default `30`s) — long enough for a typical phone-style answer window. `untrigger_delay_seconds` then lingers past that, same as for any stateful trigger.
|
||||
|
||||
`triggers.motion`, `triggers.occupancy`, and `triggers.media_events` are off by default — only the explicit doorbell press triggers the call, so casual motion won't make the card ring.
|
||||
|
||||
```yaml
|
||||
type: custom:advanced-camera-card
|
||||
@@ -381,6 +383,33 @@ profiles:
|
||||
> [!TIP]
|
||||
> If your doorbell exposes a `binary_sensor.*` or `switch.*` instead of an `event.*` entity, list it under [`triggers.entities`](configuration/cameras/README.md?id=triggers) on the camera manually. Auto-discovery only covers `event.*` based doorbell entities.
|
||||
|
||||
#### With a Zigbee (ZHA / deCONZ) doorbell button
|
||||
|
||||
Zigbee buttons connected via ZHA or deCONZ typically don't expose a per-device entity — they fire raw HA bus events (`zha_event`, `deconz_event`) shared across every Zigbee device on the integration. The `doorbell` profile's auto-discovery doesn't cover this case; reuse the profile (it still wires up `trigger: call` / `untrigger: call` and the ring window) but opt out of auto-discovery per camera and add [`triggers.events`](configuration/cameras/README.md?id=events) with an `event_data` filter to pick out the right device.
|
||||
|
||||
You can copy the exact `device_ieee` (ZHA) or `id` (deCONZ) and command values straight out of **Developer tools → Events** in Home Assistant — listen to the event type, press the doorbell, and use whatever appears in the `data` payload.
|
||||
|
||||
```yaml
|
||||
type: custom:advanced-camera-card
|
||||
cameras:
|
||||
- camera_entity: camera.front_door
|
||||
live_provider: go2rtc
|
||||
go2rtc:
|
||||
modes:
|
||||
- webrtc
|
||||
triggers:
|
||||
# Opt out of the profile's `event.*` auto-discovery -- this camera
|
||||
# uses an HA bus event instead.
|
||||
doorbell: false
|
||||
events:
|
||||
- event_type: zha_event
|
||||
event_data:
|
||||
device_ieee: '00:11:22:33:44:55:66:77'
|
||||
command: press
|
||||
profiles:
|
||||
- doorbell
|
||||
```
|
||||
|
||||
## Events from other cameras
|
||||
|
||||
`dependencies.cameras` allows events/recordings for other cameras to be shown
|
||||
@@ -1412,7 +1441,7 @@ cameras:
|
||||
motion: true
|
||||
entities:
|
||||
- binary_sensor.kitchen_door_opened
|
||||
events: []
|
||||
media_events: []
|
||||
view:
|
||||
triggers:
|
||||
show_trigger_status: true
|
||||
|
||||
Reference in New Issue
Block a user