WTH are event entities not triggered a second time when using the attribute `event_type` in a state trigger?

Month of "What the heck?!"
1

The new event entities are meant to replace old school event triggers (and Z2M sensor’s). The problem is, the features are not 1 to 1.

Old school events will always trigger when an event occurs, same with the legacy event sensors in z2m.

The new event entities do not support this functionality though. If the same event comes through a second time, the event is essentially ignored because the event_type attribute does not change.

It’s also not clear to users how to get around this issue. You need to know enough about event entities and state triggers to overcome this issue. You’d need to know to remove attribute and to in your state trigger, while also adding a condition that checks the attribute of the triggering entity. It drastically over complicates events in a different way.

WTH isn’t there a special case built into state triggers to account for an event entities event_type attribute to account for this? Or why don’t we have a trigger that supports event entities like this?

2

Actually ran into this same ‘problem’ yesterday myself. I solved it by moving the logic from the trigger (using different trigger_id's) to the action, like so:

triggers:
  - trigger: state
    entity_id:
      - event.ikea_tradfri_remote_badkamer_action
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: event.ikea_tradfri_remote_badkamer_action
            attribute: event_type
            state: "on"
        sequence:
          - action: <some action>
      - conditions:
          - condition: state
            entity_id: event.ikea_tradfri_remote_badkamer_action
            attribute: event_type
            state: "off"
        sequence:
          - action: <some action>

Question remain whether this ‘feels’ intended, or that the trigger should just trigger on the same event … I’m not sure to be honest :slight_smile: …

3

It’s an unintended consequence of making events into entities.

1 Like
4

I’m pretty sure the documentation for the new event entities just introduced in Zigbee2MQTT has got this wrong because they haven’t followed the process you describe here.

5

Good spot - I’ve submitted a PR to the Z2M docs to change that.

3 Likes
6

This is my WTH as well but I didn’t find this topic (stupid search…). So my arguent for it:

I do like the switch to events for a lot of things. The event-entity is a nice addition for that. The only thing I find a big WTH is the fact that you still have to use a state-trigger to use it while it is a “stateless” entity.

Now I get it that an event-entity does have a state, the datetime it fired. But it doesn’t feel correct.

This WTH get’s bigger because of the use of event_type as attribute which has nothing to do with the event_type of real events. Because a HA event of an event-entity is still just state_changed.

So in order to do a trigger on an event-entity with a specific event_type you have to make a state-trigger without a to/from-state. And add a condition to check the state of the attribute of the event-entity. This is even what the documentation suggests. To me, three things are wrong with this:

  • You have to make a trigger and a condition to make it work. Double work.
  • You do both a state-trigger and a state-condition on an item that’s introduced as state-less.
  • You have to hope the event-entity does not get events too fast because the trigger and the check of the attribute are two separate steps. Especially if you do other actions before checking the attribute, it might already have changed.

So I think an event-entity-trigger is the missing piece here. Or, what I would suggest to get it more in line with real events, extend the event-trigger to accept the entity id of event-entities. Although yes, there is still a huge difference between a HA event and an event-entity, I think it would be much cleaner if it is possible to just do:

trigger:
  - platform: event
    entity_id: event.hue_remote_control
    event_type: short_release

Especially if this would be something you could setup in the UI. And this would be way less confusing than a state-trigger and the confusion on how to check the event_type (which in reality is just an attribute…). Which also makes sure the attribute is checked when the event fired.

3 Likes
7

The only downside to your suggestion is there’s already an event trigger, so we’d need to come up with another name or alter the existing state trigger. I’m not sure what route is better. Either way, it’s definitely needed.

1 Like
8

You are right it exists but this is not the only time a block can do entirely different tings depending on the keys used in it. In this case, once you supply an entity id of an event-entity it should not look for a real HA event but for a state change (+ optional the event_type as attribute). Without entity id, it should check for a real event aka stay the same as it is now. This way it would be fully backwards compatible.

Yes, this is a bit of a stretch for the event-trigger. But I think the whole root cause is the choice to basically name an entity to something that already exists in HA. Even though the term event is logical, because it already existed it is confusing as hell now…

The other option would be to pick a different name for the trigger. But than I would also clearly label the event-entity as such. But even then I think it would cause quite the confusion between real events and event-entities with their different event_modes. So that’s why I would propose to stretch the event trigger to bring event-entities closer to the feeling of a real event.

Third option would be to let event-entities trigger a complete new type of event (event-event?) and make a GUI element for that. But still will be confusing and will probably need quite some changes under the hood.

9

I was quite enthusiast with that implementation on the Z2M side and I was eager to make the switch from “state / _action” to events with version 2.0. However, it’s way too convoluted to implement it in HA.

This kind of automation where I can intuitively map different button presses, as different triggers, to one or more actions with choice become overly complicated with templates with this system.

triggers:
  - entity_id:
      - sensor.entree_bouton_aqara_gache_portillon_et_garage_action
    to: single
    id: portillon
    trigger: state
  - entity_id:
      - sensor.entree_bouton_aqara_gache_portillon_et_garage_action
    to: double
    id: portillon
    trigger: state
  - entity_id:
      - sensor.entree_bouton_aqara_gache_portillon_et_garage_action
    to: hold
    id: garage
    trigger: state

With to: ~ / null, you also have the issue of having your automation seen as triggered even when it will not match anything in the end (and it could happen when coming back from unavailable also).

The implementation of Deconz with events sent on the bus was more intuitive than that.

  trigger:
  - platform: event
    event_type: deconz_event
    event_data:
      unique_id: 00:17:88:01:06:06:81:5c # Stable ID that does not change like the HA device ID
      event: 1002 # Click (xxx2) on left button (1xxx)

Why not sending the “button events” (“button” for disambiguation) on the event bus with a event event_type that would contain the “button event” in the event_data ?

  trigger:
  - platform: event
    event_type: event
    event_data:
      entity_id: event.entree_bouton_aqara_gache_portillon_et_garage_action
      event_type: "click"

I don’t think that would be worse than the official solution which has “state” for a stateless thing 3 times:

triggers:
  - trigger: state
    entity_id: event.hue_remote_control
actions:
  - alias: "Choose an action based on the type of event"
    choose:
      - conditions:
        - alias: "Normal evening scene if the button was pressed"
          condition: state
          entity_id: event.hue_remote_control_on_button
          attribute: "event_type"
          state: "short_release"
        sequence:
          - scene: scene.living_room_evening

And worse, this does not handle the race condition issue that requires an ugly template (again) to capture the attribute in the context of this specific trigger run.

There is also the lacking implementation of the event details in the logbook discussed here.

Edit:
Actually, maybe it could be already possible to do that with the event bus with something like that (I need to test).

  trigger:
  - platform: event
    event_type: state_changed
    event_data:
      new_state:
        entity_id: event.bureau_julien_bouton_hue_tap_dial_volet_et_lumieres_action
        attributes:
          event_type: press_release
          button: button_1

Edit 2: Not possible because of this (8 years ago).

10

Yes, logbook spamming may not be the major issue with how the event entity works, but it’s definitely one of them.

11

An alternative good name was brought up in this post:

state_reported

I think this can also be done in a non-breaking manner.

12

state_reported is the name of the event that exists in HA today that is fired in large volumes. There was a PR specifically created to disallow triggering on it. The path the devs seem to want to take instead is to expand the state trigger to allow triggering on a report. Something like adding a configuration like fire_on_state_reported: true. The name of that setting I came up with myself and maybe isn’t great, but if I read between the lines that behavior is what the devs would agree to for a PR.

Edit: here is the PR I mentioned, for reference.

1 Like
13

I didn’t know that. For this to work for the use case discussed here, I guess it should only be for state that is reported as a side-effect of an action. Otherwise, state that is reported not in response to an action may lead to unnecessary invocations.