Looking for a dynamic trigger

[MelleD]

What is the best way to create a dynamic trigger all binary sensor states?

I would like to trigger an automation/blueprint when a state (binary_sensor) changes from off to on, if the binary sensor is a device class problem.

Currently, I trigger all sensors and check in the condition whether it is a “problem.”

Is there a better trigger point?

triggers:
  - trigger: state
    entity_id: []
    to:
      - "on"
conditions:
  - condition: template
    value_template: |-
      {{ state_attr(trigger.entity_id, 'device_class') == 'problem' }}

[123 (Taras)]

@MelleD

create a dynamic trigger all binary sensor states?

You may wish to try an experimental feature introduced in 2025.12.0.

Purpose-specific triggers and conditions

[Didgeridrew]

That won’t help yet, only occupancy device class binary sensors are available at this point.

@MelleD

Currently the best option is to create a template sensor that counts the number of “problem” binary sensors that are “on”, then use that entity’s state change as your trigger with a template condition that checks that the value increased.

[MelleD]

Could I use somehow a event with state change as trigger?

[Didgeridrew]

@MelleD

Could I use somehow a event with state change as trigger?

That would not be recommended because there is no method within the Event trigger configuration to limit it to a certain domain and/or device class. So the automation would trigger off every state-changed event of every entity in the system.

[MelleD]

@Didgeridrew

That would not be recommended because there is no method within the Event trigger to limit it to a certain domain and/or device class. So the automation would trigger off every state-changed event of every entity in the system.

Do you think it slows down the system?
But could I limit it to the state old_state ‘off’ and new_state ‘on’ and then a condition

  - condition: template
    alias: Only problem device class and entity id which contains 'wartung'
    value_template: |-
      {{ 'wartung' in trigger.entity_id and state_attr(trigger.entity_id, 'device_class') == 'problem' }}

[Didgeridrew]

@MelleD

But could I limit it to the state old_state ‘off’ and new_state ‘on’ and then a condition

No you can’t. The trigger itself would require you to be able to provide the whole object for new_state and/or old_state, which you can’t because you can’t know the time-based properties like last_changed.

@MelleD

Do you think it slows down the system?

Yes. Though the effect will depend a lot on the particulars of the system. On any system it’s likely to be an unreliable trigger because a lot of events will get thrown out when used in single mode. And using other modes just makes it use more resources.

[MelleD]

Why is it not recommended to use conditions?

Then I’ll probably go with a list as input.

[Didgeridrew]

@MelleD

Why is it not recommended to use conditions?

You can use conditions, but they don’t affect the trigger listener, they just process data after the trigger fires to check whether the actions should be executed.

[MelleD]

Sorry I meant, why is it not recommended to use state_event as a trigger?

[Didgeridrew]

Please clarify.

[MelleD]

@Didgeridrew

That would not be recommended because there is no method within the Event trigger to limit it to a certain domain and/or device class. So the automation would trigger off every state-changed event of every entity in the system.

Why is this not recommended to use it with conditions?

So the system will be slow or what is the problem to listen on every state_change?

[Didgeridrew]

@MelleD

Why is this not recommended to use it with conditions?

The recommendation is to not use an Event trigger based on state_changed events… Doing so is like making a janky version of the State Machine.

Adding conditions doesn’t address the cause, which is an overly-general trigger definition. Conditions do not affect how often the events happen or how often the trigger fires. They only affect whether or not the action are executed.

@MelleD

So the system will be slow or what is the problem to listen on every state_change?

Again… Yes it will slow the system to some degree, and it will be unreliable.

[MelleD]

@Didgeridrew

Again… Yes it will slow the system to some degree, and it will be unreliable.

Okay, that was my question. Thank you. Perhaps I have already made the mistake. I created a test automation to take a look at the event and trigger. Now I no longer have access to my UI.

EDIT: Lesson learned, System crashed with one trigger.
Connect via smb and remove the automation in the yaml directly.
Hard Restart workes again Puh

[tom_l]

Just FYI this would never trigger for binary sensors:

@MelleD

  - trigger: state
    entity_id: []
    to:
      - "On"

The state is 'on' not 'On'.

[MelleD]

Without an entity id it’s not working. I thought this could work because it’s optional

@tom_l

The state is 'on' not 'On'.

Solved this in the example

[tom_l]

@MelleD

because it’s optional

It is not.

[MelleD]

But you can create a empty list for entity id the code works without error. A empty list is for me semantic optional

[tom_l]

https://www.home-assistant.io/docs/automation/trigger/#state-trigger

If you don’t give it entities then it is not going to work. Thus - not optional.

[MelleD]

@tom_l

If you don’t give it entities then it is not going to work. Thus - not optional.

For me, an empty list means optional, and as I said, no error is thrown. So the validation must be buggy.