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.

[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]

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.

Their bad! :)

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

[mundschenk-at]

Hi @jbouwh! What do you mean to propose? I'm not sure what you are referring to with that link to HA events (note for others in this thread: not event entities).

[Petro31]

Hi @jbouwh! What do you mean to propose? I'm not sure what you are referring to with that link to HA events (note for others in this thread: not event entities).

He's talking about making a proposal to the core HA team about event entities.

[mundschenk-at]

I mean something like: https://www.home-assistant.io/docs/configuration/events/
For the HA IMAP integration I use the same technique.

Yes, of course, but what?

[Petro31]

I mean something like: https://www.home-assistant.io/docs/configuration/events/
For the HA IMAP integration I use the same technique.

Yes, of course, but what?

Based on what he linked, he may be referring to "old school events".

To be quite honest, I prefer them. However they are hard for beginners to understand, which is why event entities were created in the first place.

[jbouwh]

Right, but some how event entities need an easier way to configure a trigger with them. The old events have some advantages that they can propagate data attributes from the event, that can be used to filter on.

[thk-socal]

Started playing with the event entities. While I see both sides, one thing that was amazing for me was the ability to teach my wife how to make her own automations in the HA GUI tied to events of my Zigbee switches. I showed her how to press the button to force HA to see the event as an option, then go to the Automation GUI and choose that switch by name and pick the event to then drive any automation. I realize the YAML way is harder, but the GUI option was amazing for her and made it easy for her to make her own things.

So, that helps drive even more acceptance of the automations to my home. More people can more easily do it, which I think is a good thing. Currently have 2 Zigbee networks, each exceeding 180 devices and Z2M is the best for me, and I love the direction with events.