Help with event entity triggers

[busman]

Sorry, a bit late coming back here. (See referenced post)

I’m using this solution widely where I trigger on an event (or in my case often many) and then in a choose look at the event_type.

On a restart (or, for example, restarting the zwave integration), I get events fired. I assume that is so that listeners could update the state at startup. The result is things get turned on that should not have been – the scene controller button wasn’t pushed.

The trigger data has this from_state that includes restored: true. I couldn’t find docs on that, but I assume that I can check that in a condition to test if the event is from a restart and not an actual button pushed on a scene controller.

trigger:
  id: '0'
  idx: '0'
  alias: null
  platform: state
  entity_id: event.bar_ceiling_light_scene_001
  from_state:
    entity_id: event.bar_ceiling_light_scene_001
    state: unavailable
    attributes:
      restored: true
      event_types:
        - KeyHeldDown
        - KeyPressed
        - KeyPressed2x
        - KeyPressed3x
        - KeyPressed4x
        - KeyPressed5x
        - KeyReleased
       ...

So, specifically something like this:

conditions:
  - condition: template
    value_template: "{{ not trigger.from_state.attributes.restored }}"

[Mayhem_SWE (Magnus)]

Is there a question here? Why did you post this as a separate thread rather than a reply in whatever thread you’re referring to?

@koying

Not sure where you got that trigger yaml from (AI?) but it’s completely bogus.

It is not a trigger, it is a trigger variable which he has copied from traces. Or at least that is what I would expect, considering what it looks like…

[tom_l]

@Mayhem_SWE

Why did you post this as a separate thread rather than a reply in whatever thread you’re referring to?

I moved it from the community guide as that is not a support topic.

[123 (Taras)]

@busman

On a restart (or, for example, restarting the zwave integration), I get events fired.

Post the trigger you’re using, exactly the way it appears in your automation. Also, what is producing event.bar_ceiling_light_scene_001? I assume it is z-wave?

[busman]

I posted it there because it was a follow up to a response to how to avoid device ids where an entity doesn’t have a state change to use - like a scene controller.

At that time I received a response showing how to use event ids. But that response didn’t handle the situation of restarts generated events, which is important (preventing unexpected running of devices, for example).

[123 (Taras)]

@busman

situation of restarts generated events

That’s seems abnormal to me.

I have automations employing State Triggers monitoring event entities. They don’t fire when Home Assistant is restarted.

That’s why I asked to see how you configured your State Trigger.

[busman]

I was surprised too. Seems odd an event would fire on restart as (in this usage) could run automations when a button wasn’t actually pushed. Could it be related to the z-wave integration?

(I also looked at the zwave-js logs and didn’t see the event starting there. I’ll poke at it more today.)

It’s just triggering on the event entity ids (like in the post @TheFes I linked to). The trigger output I posted was for entity_id: event.bar_ceiling_light_scene_001, and in that specific automation the trigger is this:

triggers:
  - trigger: state
    entity_id:
      - event.living_room_cans_scene_001
      - event.living_room_cans_scene_002
      - event.wall_splash_scene_001
      - event.cabinet_lights_scene_001
      - event.family_room_cans_scene_001
      - event.family_room_cans_scene_002
      - event.bar_ceiling_light_scene_001
      - event.recirc_pump_remote_switch_scene_001
      - event.recirc_pump_remote_switch_scene_002
      - event.primary_bath_fan_zen71_scene_001
      - event.2nd_bath_fan_scene_001
conditions:
  - condition: template
    value_template: "{{ not trigger.from_state.attributes.restored }}"
actions:

And from that trigger data you can see that there’s that restored: true attribute. I wasn’t able to find documentation on that, so just assumed it’s there for cases like this.

Here’s a similar example, but of a less involved automation.

Automation example

alias: Bill's Scene Controller
description: Handle buttons on the small scene controller.
  - trigger: state
    entity_id:
      - event.bill_s_scene_controller_scene_001
      - event.bill_s_scene_controller_scene_002
      - event.bill_s_scene_controller_scene_003
      - event.bill_s_scene_controller_scene_004
conditions:
  - condition: template
    value_template: "{{ not trigger.from_state.attributes.restored }}"
actions:
  - variables:
      buttons:
        001_KeyPressed:
          - light.turn_on
          - light.bills_smart_dimmer
          - brightness_pct: 20
        001_KeyPressed2x:
          - light.turn_on
          - light.bills_smart_dimmer
          - brightness_pct: 100
        001_KeyPressed3x:
          - light.turn_on
          - light.bed_lamps
          - brightness_pct: 20
        002_KeyPressed:
          - light.turn_off
          - light.bills_smart_dimmer
          - {}
        002_KeyPressed2x:
          - light.turn_off
          - light.bed_lamps
          - {}
        003_KeyPressed:
          - light.turn_on
          - light.bills_smart_dimmer
          - brightness_step_pct: -15
        004_KeyPressed:
          - light.turn_on
          - light.bills_smart_dimmer
          - brightness_step_pct: 15
      key: >-
        {{ trigger.entity_id[-3:] + '_' +
        state_attr(trigger.entity_id,"event_type") }}
      the_action: "{{ buttons[key] }}"
  - if:
      - condition: template
        value_template: "{{ 'True' if the_action }}"
    then:
      - action: "{{ the_action[0] }}"
        metadata: {}
        target:
          entity_id: "{{ the_action[1] }}"
        data: "{{ the_action[2] }}"
    else:
      - action: persistent_notification.create
        data:
          title: "{{ state_attr(this.entity_id, 'friendly_name') }}"
          message: |-
            {{ 'Triggered with: ' + trigger.entity_id + "

             Do not know how to handle: " + key }}
mode: single

[123 (Taras)]

1. Add this line to your State Trigger.

    not_from: unavailable

2. Remove the Template Condition
3. Save the automation then restart Home Assistant.

Let me know if the automation is still triggered on startup.

[busman]

Thanks. I’ll have time to test in a few hours. Looks like it would work from the trigger data I posted above.

I was hesitant to use the state since the events can fire without any state change. I need to learn more about initial states at startup, or when restarting an integration.

Do you, by chance, happen to know any details on the restored attribute and/or why these events apparently fire at startup?

[TheFes]

My initial post (the one linked to) was based on my experience with ESPHome events, where events entities are not restored after a restart.
I know that for Zigbee2MQTT events, the events do restore, and thus will cause a trigger if you use something like the linked post. This is because the state will change from unavailable to the valid previous state.

I don’t have any Zwave devices, so I can’t tell anything about that.

Adding a not_from: unavailable will prevent that. The part from the trace you shared clearly shows the from state was unavailable.

[123 (Taras)]

What I suggested comes from this helpful guide.

Using the new action events in Zigbee2MQTT 2.0

The new Zigbee2MQTT 2.0 introduces the new event based actions for things with buttons. And at the same time deprecates the old way of using action sensors. Note that you enable these new actions by setting the Zigbee2MQTT configuration “Home Assistant experimental event entities” to enabled (true) However, it seems the Zigbee2MQTT devs have pulled back on the plan to remove the legacy sensor based method, so for now users can start to play with the events but it may be best to keep things as …

My automation’s State Trigger employs not_from: unavailable and prevents it from firing on startup because, on startup, the event entity’s state value undergoes a state-change from unavailable to whatever value it had prior to the restart.

[busman]

Thanks. Yes, it works for the Z-Wave integration. Is it the integration generating the event, or just due to the state change from “unavailable”?

I’ll poke around and see if I can find the purpose of that restored attribute. Curious about it.

[busman]

Minor addition in case someone finds this. I ended up also adding not_to to catch shutting down.

triggers:
  - trigger: state
    not_from: unavailable
    not_to: unavailable
    entity_id:

I also had an edge case where had to re-include a device and the from_state was null, so the not_from: unavailable didn’t catch that.

trigger:
  id: '0'
  idx: '0'
  alias: null
  platform: state
  entity_id: event.recirc_pump_remote_switch_scene_001
  from_state: null
  to_state:
    entity_id: event.recirc_pump_remote_switch_scene_001
    state: '2025-02-13T20:15:16.256+00:00'
    attributes:
      event_types:
        - KeyHeldDown
        - KeyPressed
        - KeyPressed2x
        - KeyPressed3x
        - KeyPressed4x
        - KeyPressed5x
        - KeyReleased
      event_type: KeyPressed

[KennethLavrsen]

Note to anyone reading this with zigbee2mqtt in mind.

The event triggers often do not create events unless the event value changes. In many cases this prevents detecting the same button pressed twice or more. So in my guide on Using the new action events in Zigbee2MQTT 2.0 I advice people to not use the event values in the trigger. Just trigger on anything related to the event entity and use conditions in the actions to decide which event value it was and what to do.