HA event entities way forward

[Koenkk]

Z2M 1.42.0 added support for the Home Assistant event entities. This was done in #24233. The current implementation has some limitations, it doesn't work for all actions atm. The current patterns are supported for now:

zigbee2mqtt/lib/extension/homeassistant.ts

Line 39 in 5b907f2

const ACTION_PATTERNS: string[] = [

My initial thought was to add a new action_data property for this (#24233 (comment)), but this will add a lot of duplication, so not a good option.

Therefore I'm now thinking to move the patterns that are now in homeassistant.ts into the e.action() exposes.

What do you think? @mundschenk-at @Nerivec @Drafteed

[Nerivec]

Whatever way is picked, I think it should follow:

• The less duplication of values/props the better, it needs to be easy to maintain...
• Avoid splitting payloads into several props if the user is going to always recombine them in automation triggers anyway (pointless)
• The "final behavior" should resemble the behavior of regular action (zigbee2mqtt-frontend) enough that it avoids too much confusion on usage (too many patterns...)
• Should have a nil-to-limited footprint when HA extension is disabled (non-HA users)

[mundschenk-at]

I can see the reasoning, but I disagree. The frontend just follows the current MQTT topic and should not be normative. The HA event API works differently and should embrace it. Having the action itself (event_type) and attributes separate also allows for proper localization in the HA frontend.

[Sineos]

Should have a nil-to-limited footprint when HA extension is disabled (non-HA users)

Without being able to contribute much to the technical side, I have a humble request:

Much of Zigbee2MQTT's beauty comes from the fact that it is agnostic to the home-automation ecosystem to which it is connected. With these ecosystems being "proprietary" to some degree, I kindly ask to not lose sight of your heritage as Zigbee2MQTT.

[mundschenk-at]

The current implementation should work on a basic level for almost all current actions, except for those like 511.344 which somehow adds endpoints to the actual payload string but not the exposes (I have to investigate this, just got notified a few hours ago), in that it passes the current action value through as the HA event_type. However, if we want to have nice even types and attributes in HA, the actions are currently parsed both on the Z2M side to define valid event_type values for the discovery topic and on the HA side to make a JSON value out of a plain string.

What exactly is your proposal? To do the parsing in e.action() and still generate a nice JSON payload (in its own topic or as part of state)? I'd be OK with that, though I think this should only be the codepath to deal with legacy converters and we should have some new API for the converters to specify the different parts without resorting to string parsing.

[Koenkk]

Or do you mean giving each action expose their own parsing regex, the default being something like ^(?:.*)$?

Yes that's what I mean, I don't think that having it hardcoded in homeassistant.ts is future proof. Also sometimes the group is part of the action, e.g. {action: "click_1"}. We could then separate this out with the regex.

I still see no way to include action_group if it has its own separate expose.

Wouldn't that be as simple as adding value_json.action_group to

zigbee2mqtt/lib/extension/homeassistant.ts

Line 2271 in 5b907f2

const value_template =

?

[mundschenk-at]

But the action expose would have to know about the action_group, not sure what we would do with a separate expose? It would only be useful if we wanted to have separate HA entity for it. Each expose results in one (or more) entities, the design does not allow for several exposes to be combined into a single discovery topic (HA entity).

[chris-1243]

@mundschenk-at Have you found out a solution on how to integrate events for devices such as 511.344 ?

[mundschenk-at]

@chris-1243 See #25061 (reply in thread). But I'm not actively working on anything until an architectural decision has been reached by @Koenkk.

[chris-1243]

@mundschenk-at I read the thread already and it completely makes sense not to spend too much effort until a final decision is taken. Thanks for the explanation👍

[Drafteed]

To be honest, I would do it like this: сompletely revert #24233 and all followups. Then add a new expose e.event() that would correspond to the new HA entity and gradually add them to existing devices/definitions. Also mark e.action() as deprecated, removing it in 3.x.x. In this case, the event entity will only be available if it is defined in the converter, otherwise users will have to use MQTT triggers until the event entity is added properly.

Regarding #24233, I think this implementation is a bit messy, IMO. All attempts to make workaround are hacky that will cause a lot of problems that will be difficult to solve later.

[Drafteed]

available by explicitly setting legacy_action_sensor

BTW, it would be nice to have a warning about the use of deprecated/experemental functions in the log and ideally in the frontend to avoid a surprised reaction from the community when these legacy functions stop working.

[antst]

I still think that we should temporarily remove events from z2m and implement them later - after carefully considering all aspects to avoid problems in the future. In the current implementation, leave only MQTT triggers and legacy action sensor, available by explicitly setting legacy_action_sensor.

I agree with that. Lets HA to sort out some issues with event entities, then Z2M can support it. To be honest, current legacy action entities is the best ATM. It is events, how they have to be.

[D3v01dZA]

I agree with that. Lets HA to sort out some issues with event entities, then Z2M can support it.

The way that event entities work in HA and your dislike of it is not a valid reason to remove support. A valid reason might be what they’re alluding to above, which is that it’s creating some extra maintenance burden.

[antst]

I agree with that. Lets HA to sort out some issues with event entities, then Z2M can support it.

The way that event entities work in HA and your dislike of it is not a valid reason to remove support. A valid reason might be what they’re alluding to above, which is that it’s creating some extra maintenance burden.

It is not what I am saying. I am saying that from look of it and limitations and discussions around it on HA forums, event entities system in HA is likely to pass through some changes. And better to spent resources on Z2M support of it, when HA will have "v2" of event entities, to avoid redoing stuff in Z2M. Which means to keep current support as experimental and as is.
Otherwise we set event entities as recommended, people start to redo their automation (half year after they redid to device triggers) and then half year later, this has to change again. And you don't want people to redo their automaton every year or half year :)

At the end of the day, it does not matter how complex particular automation looks like(even if I prefer when it looks simple and clean), you make it once and forget. People don't make new automations every day. And once in a while, when they need new automation, they can manage with anything, with help of GH and HA forums. It's only problematic when you need to rewrite dozens of automations suddenly, again and again.

Personally, I passed already through 3 transitions in how Z2M+HA automations handled. And it is waste of time every time, to rewrite it all. Especially, taking into account there is no added value in that. It is not like suddenly my home will perform space flight after that :) Automation works exactly the same as they used, which is exactly the same as I want. But I need to spend time, to get exactly the same as I had already. Because somebody somewhere decided that there is a better way, which is, often, does not have really motivated technical reasons. But Z2M and HA are production software. Not experimental toys.

And, you know, every new line of code is a potential new bug :) Avoiding writing those new lines of code without real actuality important reasons is an art of production software :)

[mundschenk-at]

I highly doubt that HA will change their event platform in any significant way. No "Version 2" of that is coming in the foreseeable future.

Maybe they'll tweak their state engine for the event_type attribute or add a new type of automation trigger for event entities, but at this point I think it's more likely that they'll add some UI sugar instead. @Petro31's WTH has only 58 votes at the moment, so it does not look like there is a lot of momentum for any change at all on the HA side.

[antst]

Just in case, real-life example of evolution of automations in HA with current implementation of event entities. Simple case: button (in this aqara) toggles light group.

legacy actions:

triggers:
  - trigger: state
    entity_id: sensor.study_button_action
    enabled: true
    to: single
actions:
  - action: light.toggle
    target:
      entity_id: light.study_lights

currently recommended device triggers:

triggers:
  - domain: mqtt
    device_id: a6e65827e8df0b0725d86b1384138489
    type: action
    subtype: single
    trigger: device
    enabled: true
actions:
  - action: light.toggle
    target:
      entity_id: light.study_lights

event entity:

triggers:
  - trigger: state
    entity_id:
      - event.study_button_action
    enabled: true    
conditions:
  - condition: state
    entity_id: event.study_button_action
    attribute: event_type
    state: single
actions:
  - action: light.toggle
    target:
      entity_id: light.study_lights

If I add second button to this scenario, this story will look even more scary....

[D3v01dZA]

Either HA should change events implementation, when it is allows to react to from X to X, even if X is unchanged.

Events already allow this, they are triggered by the state which I implemented as a time much like a button and have the event as an attribute.

Or Z2M should send "cancellation" message.

Not necessary because of what above.

[Koenkk]

@jbouwh just confirmed that event entities should trigger even when receiving the same event twice. @mundschenk-at could we be doing something wrong from the z2m side?

[mundschenk-at]

I think this might be a misunderstanding of the issue: The event entities trigger fine with the same event twice in a row, however that just means the state (in HA parlance, not Z2M's) of that entity gets updated to the current timestamp. The attribute event_type of that entity stays unchanged (because it's the same event and HA silently drops unchanged attribute values), and anything listening to an attribute change will not get triggered.

Technically, that is all consistent, but somewhat unexpected behavior for at least for non-technical users. It also means to get all events from the entity, you have base your automation trigger on the event entity state (i.e. all events) and need a condition afterwards to narrow things to a specific event_type. This is not very elegant or concise, especially considering that it needs templating to do it properly without race conditions (i.e. you cannot do it all in the UI).

@Koenkk @jbouwh

[DubhAd]

There is discussion about this "feature" - https://community.home-assistant.io/t/wth-are-event-entities-not-triggered-a-second-time-when-using-the-attribute-event-type-in-a-state-trigger/804428/. The OP there has started trying to get the behaviour made sane, at least as an option people can enable, but for now I'm afraid it's really best done with templates:

triggers:
  - platform: state
    entity_id: sensor.office_dial_moes_action
    to: 'toggle'

becomes

triggers:
  - trigger: state
    entity_id: event.office_dial_moes_action
    to: ~
        # null and ~ (and NULL) are functionally identical - I just happen to prefer ~
conditions:
  - condition: template
    value_template: >-
      {{ trigger.to_state.attributes.event_type == 'toggle' }}

The reason for using templates is so that you're looking at the state that caused the trigger to fire, otherwise if multiple things happen you could be looking at the wrong state.

That can at least all be done in the UI (I wrote it up here).

[mundschenk-at]

Only if you consider templating to be "in the UI" 🤷