Add debug mode and harden notify flow in Alarm Notification

- 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.

Common/Alarm Notification/README.md

@@ -8,7 +8,50 @@ This blueprint monitors multiple binary sensors and triggers push notifications
 - 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)
+Alexei Dolgolyov (<dolgolyov.alexei@gmail.com>)