Using the new action events in Zigbee2MQTT 2.0

Configuration Zigbee
88

Just finished converting one of my automations, that controls an IKEA E1743 device, from using the now deprecated sensor entity to an event entity. Here a few of my thoughts.

It’s not a significant difference unless you employ wait_for_trigger in which case it becomes a bit more verbose.

For example, here’s a snippet of the original automation that detects single and double presses of the device’s On button. A single press sets the light’s brightness to 128 whereas a double press sets it to 255. The wait_for_trigger uses a State Trigger to detect just one desired button event (to: 'on').

  actions:
    - choose:
        - conditions: "{{ trigger.to_state.state == 'on' }}"
          sequence:
            - wait_for_trigger:
                - platform: state
                  entity_id: sensor.office_dimmer_action
                  from: ''
                  to: 'on'
              timeout: 1
            - service: light.turn_on
              target:
                entity_id: light.office
              data:
                brightness: '{{ iif(wait.completed, 255, 128) }}'

The following does the same thing but with an event entity.

  actions:
    - choose:
        - conditions: "{{ trigger.to_state.attributes.event_type == 'on' }}"
          sequence:
            - wait_for_trigger:
                - platform: state
                  entity_id: event.office_dimmer_action
                  not_from: 'unavailable'
              timeout: 1
            - action: light.turn_on
              target:
                entity_id: light.office
              data:
                brightness: "{{ 255 if wait.completed and wait.trigger.to_state.attributes.event_type == 'on' else 128 }}"

The brightness template is ever so slightly more verbose because:

  1. You can’t instruct the State Trigger to explicitly monitor the event_type attribute for a state-change to on. The reason is because it’s already on and so it cannot change to on. Therefore the State Trigger will fire for any button press, possibly not another on event as desired. So there’s a need to confirm that second button press was in fact the desired on event.

  2. If the on button is NOT pressed a second time, the wait_for_trigger times out and so wait.completed will be false and, more impactfully, wait.trigger will be none. That means wait.trigger.to_state is undefined so your template cannot refer to wait.trigger.to_state.attributes.event_type without first confirming that wait.completed is true (otherwise there will be an execution error).

Not quite as concise as using sensor.xxxx_action but I can live with it.

4 Likes