Help with event triggers

Configuration
1

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 }}"
3

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?

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…

1 Like
4

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

5

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?

6

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

7

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.

8

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
9
  1. Add this line to your State Trigger.
    not_from: unavailable
  1. Remove the Template Condition
  2. Save the automation then restart Home Assistant.

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

1 Like
10

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?

11

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.

12

What I suggested comes from this helpful guide.

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.

13

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.