Notification Automation trace indicates all conditions not met when all actually are & action is executed

I am currently running Home Assistant 2024.6.2 using the HassOS image running on a stand-alone x86-64 based machine. I am very new to Home Assistant and this is actually my first post on this forum.

The goal of this automation is to fire off a notification if any of my alarm monitored sensors change state.

The automation trigger is ‘state_changed’ and rather than setup a group I’ve opted to use a template to filter for only those sensors I want to monitor. As long as I maintain my naming convention I can add additional sensors without making any changes to the automation or to a group.

I currently have 4 conditions defined:

  1. The triggering entity_id startswith ‘binary_sensor.qolsys_panel_’ (to ensue only desired sensors get beyond this point)
  2. AND Home Assistant has not been restarted for at least 1 minute (handles unwanted restart notifications as sensors come back online)
  3. AND input_boolean helper is ‘on’ (temp helper allowing me to test without physically arming panel, to be removed after testing)
  4. OR the Alarm Panel state is not ‘disarmed’ (allowing notifications only when armed_home, armed_away, armed_vacation)
- id: '1716743778180'
  alias: Alarm Panel Notification
  description: QolSys Alarm Panel Sensor Alarm
  trigger:
  - platform: event
    event_type: state_changed
  condition:
    condition: and
    conditions:
    - condition: numeric_state
      entity_id: sensor.uptime_minutes
      above: 1
    - condition: template
      value_template: >
        {{ (trigger.event.data.entity_id.startswith('binary_sensor.qolsys_panel_') and trigger.event.data.old_state is not none) }}
    - condition: or
      conditions:
        - condition: state
          entity_id: "input_boolean.alarm_notify_enable"
          state: 'on'
        - condition: template
          value_template: "{{ not is_state('alarm_control_panel.qolsys_panel_partition1','disarmed') }}"
  action:
  - service: notify.mobile_app_sm_s901u1
    data:
      title: QolSys Alarm
      message: "\"\U0001F514 Alarm {{ trigger.event.data.old_state.attributes.friendly_name
        }} has changed from {{ trigger.event.data.old_state.state }} to {{ trigger.event.data.new_state.state
        }}\""
      data:
        ttl: 0
        priority: high
        actions:
          - action: "URI"
            title: "Notification History"
            uri: "settings://notification_history"
  mode: single

Here’s a typical Trace after one of the monitored sensors changes state:

{
  "trace": {
    "last_step": "condition/0/conditions/1",
    "run_id": "8ba7e3a136e8f577be59870c17735d52",
    "state": "stopped",
    "script_execution": "failed_conditions",
    "timestamp": {
      "start": "2024-06-17T13:01:00.410480+00:00",
      "finish": "2024-06-17T13:01:00.410668+00:00"
    },
    "domain": "automation",
    "item_id": "1716743778180",
    "trigger": "event 'state_changed'",
    "trace": {
      "trigger/0": [
        {
          "path": "trigger/0",
          "timestamp": "2024-06-17T13:01:00.410513+00:00",
          "changed_variables": {
            "this": {
              "entity_id": "automation.alarm_panel_notification",
              "state": "on",
              "attributes": {
                "id": "1716743778180",
                "last_triggered": "2024-06-17T12:54:20.133168+00:00",
                "mode": "single",
                "current": 0,
                "friendly_name": "Alarm Panel Notification"
              },
              "last_changed": "2024-06-15T14:02:02.137376+00:00",
              "last_reported": "2024-06-17T12:54:20.327598+00:00",
              "last_updated": "2024-06-17T12:54:20.327598+00:00",
              "context": {
                "id": "01J0K46G74R3P6MS0WAS04S2AN",
                "parent_id": "01J0K46G7400G87PWH27TA7QHZ",
                "user_id": null
              }
            },
            "trigger": {
              "id": "0",
              "idx": "0",
              "alias": null,
              "platform": "event",
              "event": {
                "event_type": "state_changed",
                "data": {
                  "entity_id": "sensor.uptime_minutes",
                  "old_state": {
                    "entity_id": "sensor.uptime_minutes",
                    "state": "2817.0",
                    "attributes": {
                      "friendly_name": "uptime_minutes"
                    },
                    "last_changed": "2024-06-17T13:00:00.410646+00:00",
                    "last_reported": "2024-06-17T13:00:00.410646+00:00",
                    "last_updated": "2024-06-17T13:00:00.410646+00:00",
                    "context": {
                      "id": "01J0K4GWGTXA41GZ6SGQ41Z06P",
                      "parent_id": null,
                      "user_id": null
                    }
                  },
                  "new_state": {
                    "entity_id": "sensor.uptime_minutes",
                    "state": "2818.0",
                    "attributes": {
                      "friendly_name": "uptime_minutes"
                    },
                    "last_changed": "2024-06-17T13:01:00.410391+00:00",
                    "last_reported": "2024-06-17T13:01:00.410391+00:00",
                    "last_updated": "2024-06-17T13:01:00.410391+00:00",
                    "context": {
                      "id": "01J0K4JQ3T3MTHRXBDHEYT083F",
                      "parent_id": null,
                      "user_id": null
                    }
                  }
                },
                "origin": "LOCAL",
                "time_fired": "2024-06-17T13:01:00.410391+00:00",
                "context": {
                  "id": "01J0K4JQ3T3MTHRXBDHEYT083F",
                  "parent_id": null,
                  "user_id": null
                }
              },
              "description": "event 'state_changed'"
            }
          }
        }
      ],
      "condition/0": [
        {
          "path": "condition/0",
          "timestamp": "2024-06-17T13:01:00.410533+00:00",
          "result": {
            "result": false
          }
        }
      ],
      "condition/0/conditions/0": [
        {
          "path": "condition/0/conditions/0",
          "timestamp": "2024-06-17T13:01:00.410547+00:00",
          "result": {
            "result": true
          }
        }
      ],
      "condition/0/conditions/0/entity_id/0": [
        {
          "path": "condition/0/conditions/0/entity_id/0",
          "timestamp": "2024-06-17T13:01:00.410559+00:00",
          "result": {
            "result": true,
            "state": 2818
          }
        }
      ],
      "condition/0/conditions/1": [
        {
          "path": "condition/0/conditions/1",
          "timestamp": "2024-06-17T13:01:00.410587+00:00",
          "result": {
            "result": false,
            "entities": []
          }
        }
      ]
    },
    "config": {
      "id": "1716743778180",
      "alias": "Alarm Panel Notification",
      "description": "QolSys Alarm Panel Sensor Alarm",
      "trigger": [
        {
          "platform": "event",
          "event_type": "state_changed"
        }
      ],
      "condition": {
        "condition": "and",
        "conditions": [
          {
            "condition": "numeric_state",
            "entity_id": "sensor.uptime_minutes",
            "above": 1
          },
          {
            "condition": "template",
            "value_template": "{{ (trigger.event.data.entity_id.startswith('binary_sensor.qolsys_panel_') and trigger.event.data.old_state is not none) }}\n"
          },
          {
            "condition": "or",
            "conditions": [
              {
                "condition": "state",
                "entity_id": "input_boolean.alarm_notify_enable",
                "state": "on"
              },
              {
                "condition": "template",
                "value_template": "{{ not is_state('alarm_control_panel.qolsys_panel_partition1','disarmed') }}"
              }
            ]
          }
        ]
      },
      "action": [
        {
          "service": "notify.mobile_app_sm_s901u1",
          "data": {
            "title": "QolSys Alarm",
            "message": "\"🔔 Alarm {{ trigger.event.data.old_state.attributes.friendly_name }} has changed from {{ trigger.event.data.old_state.state }} to {{ trigger.event.data.new_state.state }}\"",
            "data": {
              "ttl": 0,
              "priority": "high",
              "actions": [
                {
                  "action": "URI",
                  "title": "Notification History",
                  "uri": "settings://notification_history"
                }
              ]
            }
          }
        }
      ],
      "mode": "single"
    },
    "blueprint_inputs": null,
    "context": {
      "id": "01J0K4JQ3T1HPPAR82GDBQEFMV",
      "parent_id": "01J0K4JQ3T3MTHRXBDHEYT083F",
      "user_id": null
    }
  },
  "logbookEntries": []
}

As can be seen, it indicates it did not run to completion. Clicking on the completion icon results in: This step was not executed and so no further trace information is available.

What’s surprising, however, is that I actually do get the notification, with valid expeted details, on my Android phone.

I used the Developer Tools > Events to listen for ‘state_changed’ and captured the following when I manipulated one of the monitored sensors:
event_type: state_changed
data:
entity_id: binary_sensor.qolsys_panel_front_door
old_state:
entity_id: binary_sensor.qolsys_panel_front_door
state: “off”
attributes:
group: entryexitdelay
zone_type: 1
zone_physical_type: 1
zone_alarm_type: 3
tampered: false
device_class: door
friendly_name: Qolsys Panel Front Door
last_changed: “2024-05-26T17:46:43.713568+00:00”
last_reported: “2024-05-26T17:46:43.713568+00:00”
last_updated: “2024-05-26T17:46:43.713568+00:00”
context:
id: 01HYV062M1AEE8CC50DH7EPAR9
parent_id: null
user_id: null
new_state:
entity_id: binary_sensor.qolsys_panel_front_door
state: “on”
attributes:
group: entryexitdelay
zone_type: 1
zone_physical_type: 1
zone_alarm_type: 3
tampered: false
device_class: door
friendly_name: Qolsys Panel Front Door
last_changed: “2024-05-26T17:50:33.547027+00:00”
last_reported: “2024-05-26T17:50:33.547027+00:00”
last_updated: “2024-05-26T17:50:33.547027+00:00”
context:
id: 01HYV0D32B1F3RZ96JPA796SFQ
parent_id: null
user_id: null
origin: LOCAL
time_fired: “2024-05-26T17:50:33.547027+00:00”
context:
id: 01HYV0D32B1F3RZ96JPA796SFQ
parent_id: null
user_id: null

I’d really like to understand why the trace is indicating failure, but the action is still executed. I’ve gone into the Automation UI editor and tested the conditions individually and with the exception of the template referencing the trigger.event.data, they indicated passed.

I’m assuming that there isn’t anyway to actually test the trigger referenced template since there isn’t an actual trigger when testing within the Automation UI. I did test the startswith method, via the Developer Tools > Templates using the following:
{% set qp = ‘binary_sensor.qolsys_panel_front_door’ %}
{{ qp.startswith(‘binary_sensor.qolsys_panel_’) }}
Result: True

For completeness this script has two known issues:

  1. When I tap on the notification, on my cell, it brings up Home Assistant to the default dashboard and not the expected notification history, as specified in the script. I’ll need to revisit this to see if I can resolve it.

  2. There is also another additional feature that is needed, to throttle the number of notifications, on a per sensor bases, as I had a window sensor that was vibrating as a result of very high winds here which caused me to exceed the 500 daily notification limit, causing no further notifications until the auto daily reset occurred. I’ve resolved the sensor issue, but it highlighted an issue I hadn’t initially considered.

Triggering off the state changed event means that every time any state in the server changes, your automation fires. You will get 5000 triggers to hit your logic, probably more, before one will actually run an action. You need to trigger more narrowly for this to be successful.
Maybe look for something to trigger off of like binary_sensor.qolsys_panel_ or group like entities and look for when one of them change state.

Otherwise when a temp sensor reports in or a bulb reports it’s power or the clock ticks, those are all state changes that will trigger this thing.

  1. Agreed that triggering an automation on every single state change is an anti-pattern that should be avoided
  2. You don’t need to use an and condition at the top level because conditions all must be true for the automation to run (i.e. there is an implied and)
  3. As shown in the trace, the second condition fails because the triggering entity “sensor.uptime_minutes” does not start with “binary_sensor.qolsys_panel_”
  4. This automation execution stops at the conditions and does not execute the notify service. The notification you are getting is coming from some other execution of this automation or some other automation. It would be easy to miss the trace that is passing all conditions and sending the notification because you’ll have so many of them to look through (see point #1)
Thank you for your response. It appears I really need to go back and rethink this entire automation from the beginning, after first gathering more information on automation and groups. I also need to think about how to "trigger more narrowly" as Sir_Goodenough noted. Perhaps I should start with a simpler automation :>)

Your third comment surprised me as I never intended for the "sensor.uptime_minutes" to be a trigger for this automation, merely a conditional check after a qolsys sensor state change triggered the automation.

As I originally stated, I was leaning away from using a group sensor for a trigger to simplify maintenance when adding/removing sensors. I also wasn't sure how to distinguish which sensor, actually changed states within the group, as I've read the group acts as a single sensor, that is when one sensor changes state the group changes state.

With regards to your 4th comment, I certainly can't rule out that some other execution is causing the automation to fire off a notification. It can't, however, be another automation as this is currently my only automation. It is interesting to me that what ever is causing the notification it contains the expected "trigger.event.data.old_state.attributes.friendly_name" of the sensor triggered during testing, albeit a door, window or motion sensor.

Again thanks for the quick responses. I'll add to this post once I've come up with a working automation.

From reading the above response I don’t think you have a good grasp on what the actual issues are with the automation traces…

We understand that’s not what you intended. But that’s the result of using the trigger that you did.

in your automation you are triggering ON EVERY CHANGE OF EVERY STATE OF EVERY ENTITY IN YOUR ENTIRE SYSTEM (not yelling just emphasizing). So the “sensor.uptime_minutes” entity changes state every minute so it will trigger the automation every minute. And in that minute there could have also been 500 (or 5000 or…) other state changes of numerous other entities in your system that then also triggered the automation to run.

I don’t think others are saying that some other automation is causing the notification. They are saying that the notification is being sent correctly in only one of potentially thousands of times the automation trigger fires because it has met the conditions you set forth in that one time out of thousands of triggers.

I would guess (not really…I’m positive) that the automation trace shows that the conditions weren’t met because the automation trace that you’re looking at isn’t the trace that actually sent the notification. Even if you looked at the trace immediately after the notification was sent (and all the others in the trace list as well) I would likely expect that the trace that sent the notification has been flushed from the trace queue many times over in just a few milliseconds. So that trace is long gone by the time you look for it giving the impression that the automation ran incorrectly.

That is what is meant by “trigger more narrowly”. You need to trigger on only the changes you are interested in instead of literally everything.

My apologies for the delay in responding, I’ve been out of the country for the past couple of weeks.

Thank you for elaborating and clarifying. I can be a bit dense at times, but I now understand.

I’ve reworked the automation to trigger only on the specific sensors, by specifying each of them.

- id: '1716743778180'
  alias: Alarm Panel Notification
  description: QolSys Alarm Panel Sensor Alarm
  trigger:
  - platform: state
    entity_id:
    - binary_sensor.qolsys_panel_front_door
    - binary_sensor.qolsys_panel_garage_door
    - binary_sensor.qolsys_panel_garage_back_door
    - binary_sensor.qolsys_panel_back_door
    - binary_sensor.qolsys_panel_overhead_garage_door
    - binary_sensor.qolsys_panel_master_bedroom_window
    - binary_sensor.qolsys_panel_living_room_window
    - binary_sensor.qolsys_panel_dining_room_window
    - binary_sensor.qolsys_panel_bedroom_1_and_2_window
    - binary_sensor.qolsys_panel_studio_window
    - binary_sensor.qolsys_panel_garage_window
    - binary_sensor.qolsys_panel_bedroom_3_window
    - binary_sensor.qolsys_panel_motion_detector
    - binary_sensor.qolsys_panel_panel_glass_break
    to: 'on'
  condition:
  - condition: numeric_state
    entity_id: sensor.uptime_minutes
    above: 1
  - condition: or
    conditions:
    - condition: template
      value_template: '{{ not is_state(''alarm_control_panel.qolsys_panel_partition1'',''disarmed'')
        }}'
  action:
  - service: notify.mobile_app_sm_s901u1
    data:
      title: QolSys Alarm
      message: "\"\U0001F514 Alarm {{ trigger.to_state.name }} has changed from {{
        trigger.from_state.state }} to {{ trigger.to_state.state }}\""
      data:
        ttl: 0
        priority: high
        actions:
        - action: URI
          title: Alarm Panel Dashboard
          uri: /alarm-panel/0
          clickAction: /alarm-panel/0
  mode: single
1 Like