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.
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/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/4] Sending Notification — shows the target entity, sensor index, and the exact message that will be sent.
- [3/4] Notification Sent — shown after the
notify.send_messagecall. Contains a troubleshooting checklist if the notification never arrives. - [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_targetis not actually a notify entity. Test from Developer Tools → Actions →notify.send_messagewith 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_ontrigger never fired. Temporarily set debounce to0to rule this out. - The notify integration rejects the message (e.g., Telegram bot with an
invalid
chat_idin 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)