HA MQTT Device Events do not deliver payloads

[ejpenney]

What happened?

I have an automation for an RGBGenie 3009, this device has a color wheel that allows sending arbitrary colors. With the removal of _action entities, automations like this will stop working since the payload_json attribute which is found in the _action entity will no longer be accessible:

description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.family_room_switch_action
conditions: []
actions:
  - action: light.turn_on
    data_template:
      entity_id: "light.family_room_all"
      xy_color:
        - "{{ trigger.to_state.attributes.action_color['x'] }}"
        - "{{ trigger.to_state.attributes.action_color['y'] }}"
mode: queued
max: 10

I'll note that there is a viable work around for this specific automation which looks something like this:

description: ""
triggers:
  - trigger: mqtt
    topic: zigbee2mqtt/Family Room Switch
conditions:
conditions:
  - conditions:
      - '{{ trigger.payload.action == "color_move_3" }}'
actions:
  - action: light.turn_on
    data_template:
      entity_id: "light.family_room_all"
      xy_color:
        - "{{ trigger.payload_json.action_color['x'] }}"
        - "{{ trigger.payload_json.action_color['y'] }}"
mode: queued
max: 10

That said, I can imagine more complex automations would be out of luck since Home Assistant does not allow using wildcards in event triggers. Waiting for generic MQTT events like this might cause unexpected behaviors, for example: if a device reports a change in battery level while an automation is executing. One place this would break is while waiting for an event in a loop. This is probably not a blocking issue, but it will make some automations orders of magnitude more complex and in some cases I imagine existing behaviors might be impossible.

What did you expect to happen?

The MQTT device trigger would ideally contain a variable with the payload data included for use in automations/scripts.

How to reproduce it (minimal and precise)

Try to setup an automation for any device that sends arbitrary payload data (EG: x,y color values) when an event occurs.

Zigbee2MQTT version

1.42.0

Adapter firmware version

20230507

Adapter

usb-Silicon_Labs_Sonoff_Zigbee_3.0_USB_Dongle_Plus_0001-if00

Setup

Proxmox LXC (TTeck)

Debug log

No response

[chris-1243]

Have you tried this ? You should listen to event_type. I have done some modifications in my automation and it seems to work fine like this.

description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.family_room_switch_action
conditions: []
actions:
  - action: light.turn_on
    data_template:
      entity_id: "light.family_room_all"
      xy_color:
        - "{{ trigger.to_state.attributes.event_type_color['x'] }}"
        - "{{ trigger.to_state.attributes.event_type_color['y'] }}"
mode: queued
max: 10 

[ejpenney]

trigger.to_state requires the _action entity which goes away in 2.0, only the MQTT device actions will exist, and these do not provide event data.

[chris-1243]

Did you have a look at this PR?
It remains experimental and some work is still needed.
It is possible to try by adding this in configuration.yaml:

homeassistant:
  experimental_event_entities: true

If you run Z2M 1.42.0-latest_dev, you should be able to see how Z2M 2.0.0 will look like #24989.

[ejpenney]

That's intriguing, I suspect that would work. I think event entities are the right way to do this (as opposed to device triggers) disappointed we don't get these in an release before the removal.

I'll have to update to the dev version to verify, but again, I suspect this would work.

[chris-1243]

Normally. In standard 1.42.0 if you set this in configuration.yaml:

homeassistant:
  legacy_entity_attributes: false
  legacy_triggers: false
  experimental_event_entities: true

you would have the events as well. Keep in mind, the events are still in experimental mode. Some changes might happen

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days