Option to trace scripts/automations where action is triggered only

Feature Requests
1

I have a few automations where they have triggers like a movement sensor that are not run because they don’t meet the conditions, is there a way we can have an additional option we can increase the chance of having the trace for those that get past these conditions (i.e. to run the actions/the Then do section)

If you don’t there is a risk it would be triggered so many times without the action being called that it would go over the amount of traces you have configured or the default of 5 traces. Making it harder when you troubleshoot later and the required trace you want has been dropped.

Proposed option:
e.g.

trace:
  stored_traces: 5
  action_triggered_only_traces: true

The trace view could indicate that action triggered only traces are enabled for this automation/script so the viewer knows that back and forward buttons only includes those where the action has been triggered.

2

Triggered automations that stop at a condition do record a trace.

Yes. Write your conditions to allow this.

Moving this post to the configuration category as this is not a feature request. You just need help constructing your automation to do what you want.

Please share your automation yaml correctly formatted for the forum and describe what you want it to do, and what it is not doing now.

3

Hello,

A basic example (without the extra actions/conditions that happen when they are triggered and pass the conditions on what I would like to see the trace on)

alias: test - motion basic
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.hallway_sensor_motion
    to: "on"
    enabled: true
condition:
  - condition: state
    entity_id: input_boolean.run_before
    state: "off"
    enabled: true
  - condition: sun
    after: sunrise
action:
  - action: input_boolean.turn_on
    target:
      entity_id:
        - input_boolean.run_before
    data: {}
mode: single

I’d want this to trigger the actions if there is motion detected at some point after sunrise and it hasn’t been triggered before

So being a motion sensor trigger it can be triggered many times before and even after the one time it runs the actions (until the input_boolean.run_before is turned off)

So it can generate a lot of traces which can potentially overwrite the trace I want to look at

The other way I can get around this I’m aware of is;

  • Increasing the amount of traces - but it still has the potential of overwriting the trace I’m interested in especially if I want to troubleshoot later or there is a lot of motion triggered trace - this could be lots so may not be easy to find or select the trace I’m interested in
  • Switch the conditions to a template trigger - but that means I have to rejig all the conditions into a template making it harder to view in the GUI and move conditions around or disabling individual conditions quickly and possibly understand the trace if it just returns a true/false value for the one condition where before they would be individually listed in the trace.

I thought it would be good to have a way to specify on an automation level that for for something that causes a lot of triggers with conditions that are normal for it to not to run the automation to find the trace your after. This proposed flag would still store the trigger and condition part of the trace, but it wouldn’t show traces for when the automation wasn’t run. Not the default as I would want to choose what I would need to troubleshoot at that level.

Either that or a way to have it store tons of traces and a way to filter out all the times that the automation is triggered but not run. :slight_smile:

4

Ok, I misunderstood your request. I’ll move it back to the FR category.

5

yeah, this would be super cool!

I am also having the same kind of issue with a lot of my automations.
Some are time based, checking for some condition, so unless I debug it immediately, I usually loose the interesting trace even though I have increased the number of kept traces to pretty high values.

6

I would also consider options for how to handle duplicates

trace:
  stored_traces: 5
  on_duplicate: replace

where on_duplicate values could be: replace, discard, keep (the default)