alexei.dolgolyov
3e98e14882
- Add `debug_enabled` input that surfaces per-stage persistent notifications ([1/4] trigger, [1.5/4] conditions, [2/4] message, [2.25/4]/[2.75/4] around the service call, [3/4] result, [3.5/4] post-branch checkpoint, [4/4] alarm control). - Include a `blueprint_version` stamp in [1/4] so it's obvious when a stale cached copy is still running. - Gate the notify branch on `trigger.id == 'sensor_on'` so clearing a sensor no longer fires a stray notification when another sensor is still active. - Replace `binary_sensors.index()` (sandbox-restricted) with a namespace loop and drop the `sensor_index.__class__` reference that broke the [2/4] render. - Drop `response_variable` from the notify call — it could abort the script past `continue_on_error` when the service didn't declare response support. - Add `continue_on_error` on notify and alarm service calls so one misconfigured step doesn't cancel the whole automation. - Tighten `has_notify_target`/`has_alarm_switch` to also reject whitespace, '[]', and 'None' string forms. Version bumped 2.5.2 → 2.6.4.
58 lines
2.5 KiB
Markdown
58 lines
2.5 KiB
Markdown
# Multi-Sensor Alarm & Notification Blueprint
|
|
|
|
This blueprint monitors multiple binary sensors and triggers push notifications and alarm device control when sensors activate.
|
|
|
|
## Features
|
|
|
|
- Per-sensor custom notification messages
|
|
- Debounce timer to prevent false alarms from brief sensor triggers
|
|
- Optional melody and volume selection for alarm devices
|
|
- Automatic alarm turn-off when all sensors clear
|
|
- Notifications are only sent on sensor ON (not on clear)
|
|
- Built-in debug mode that creates persistent notifications at each stage
|
|
|
|
## Debug Mode
|
|
|
|
Enable the **Debug** → **Enable Debug Logging** toggle to create persistent
|
|
notifications at each execution stage. Use this when notifications are not
|
|
reaching the target device:
|
|
|
|
1. **[1/4] Trigger Received** — shows trigger ID, entity, state transition,
|
|
which sensors are currently on, the resolved notify target, and whether
|
|
it is considered "usable" by the condition check.
|
|
2. **[2/4] Sending Notification** — shows the target entity, sensor index,
|
|
and the exact message that will be sent.
|
|
3. **[3/4] Notification Sent** — shown after the `notify.send_message` call.
|
|
Contains a troubleshooting checklist if the notification never arrives.
|
|
4. **[4/4] Alarm Control Done** — shows which alarm switch action was taken.
|
|
|
|
Additionally, stage info is written to the HA system log under the
|
|
`blueprint.alarm_notification` logger.
|
|
|
|
### Common causes of "no notification delivered"
|
|
|
|
- The notify integration is offline or the target device has notifications
|
|
disabled.
|
|
- `notify_target` is not actually a notify **entity**. Test from Developer
|
|
Tools → Actions → `notify.send_message` with the same target and
|
|
message; if that fails there, it will fail in the blueprint too.
|
|
- The sensor state change was shorter than the debounce duration and the
|
|
`sensor_on` trigger never fired. Temporarily set debounce to `0` to rule
|
|
this out.
|
|
- The notify integration rejects the message (e.g., Telegram bot with an
|
|
invalid `chat_id` in its configuration). Check the HA log for the
|
|
failing service call.
|
|
|
|
### Implementation note: notify via `notify.send_message`
|
|
|
|
The blueprint uses `action: notify.send_message` with
|
|
`target.entity_id: "{{ notify_target }}"`. This is the canonical modern HA
|
|
pattern and requires `notify_target` to be a notify **entity** (visible in
|
|
Developer Tools → States). Integrations that only register a `notify.<name>`
|
|
service but no entity are not supported by this blueprint directly — create
|
|
a notify entity for them or adapt the blueprint.
|
|
|
|
## Author
|
|
|
|
Alexei Dolgolyov (<dolgolyov.alexei@gmail.com>)
|