I’m in the same boat as you.
Are you 100% positive that turning on legacy action sensors doesn’t work? I see your statement conflicting with other reports.
One thing does not work for me here:
I get an event from the switch.
I trigger an automation based on that event.
I get event_type and attributes.direction out of event, but to actually see data about the sensor - I cannot get that from the event, I have to query current state of sensor.
This seems wrong, as current state of sensor might change (and usually has already changed) - this is simply a race condition by design; and this is just to get information that already was in an event send by a device.
Why is the event data both transformed and lost during processing by z2m 2.x?
I don’t know, ask the z2m creators.
With E1743, when long press button, a mqtt message is published but not created as event.
The mqtt message is also different when short or long press:
Short pression has the action property, long pression has the action_brightness_delta property
Value of action_brightness_delta can be controlled by the specific parameters on zigbeetomqtt
in the above sample, brightness will be incrented/decremented by 20 all 300ms (between 0-255)
Below, an example to catch event and long press in automation to manage a light:
alias: Eclairage - Chambre Candice - Ruban LED - Commande via bouton
description: ""
triggers:
- trigger: state
entity_id:
- event.bouton_onoff_ch_candice_action
id: by_event
- trigger: mqtt
topic: zigbeetomqtt/Bouton/OnOff/Ch.Candice
value_template: "{{ value_json.action_brightness_delta }}"
id: by_mqtt
payload: "0"
conditions: []
actions:
- choose:
- conditions:
- condition: and
conditions:
- condition: trigger
id:
- by_event
- condition: state
entity_id: event.bouton_onoff_ch_candice_action
state: "on"
attribute: event_type
sequence:
- type: turn_on
device_id: bbf0517404b6311afeb180ebc91a0044
entity_id: dd112993ea1464e162a50ba01e2cd778
domain: light
- conditions:
- condition: and
conditions:
- condition: trigger
id:
- by_event
- condition: state
entity_id: event.bouton_onoff_ch_candice_action
state: "off"
attribute: event_type
sequence:
- type: turn_off
device_id: bbf0517404b6311afeb180ebc91a0044
entity_id: dd112993ea1464e162a50ba01e2cd778
domain: light
- conditions:
- condition: and
conditions:
- condition: trigger
id:
- by_mqtt
sequence:
- action: light.turn_on
metadata: {}
data:
brightness_pct: "{{ int(trigger.payload_json.brightness /255 *100) }}"
target:
device_id: bbf0517404b6311afeb180ebc91a0044
mode: single
The trigger.to_state.attributes.event_type or trigger.to_state.attributes.button (not all remote controls have this) is available and contains the values saying what what button was pressed. The trigger.to_state is a snap shot of the event entity the minute it was pressed. The reason to use this and not test for the event entity value in the actions part of the automation is exactly to avoid the race condition where the value changes again between trigger and the tests done in actions. And this is true for all types of triggers where things are very real time.
If you make a trigger on an analog sensor like temperature is has no practical importance but some rapid button presses while HA is very busy can create a race and then it is good to use the trigger.to_state.
Well, then with 2.x the trigger.to_state is missing values from the event for this knob type. Where best to post a bug for this?
Zigbee2MQTT is a 3rd party open source project which also supports Homey, Domoticz, Gladys Assistant, IoBroker and probably others.
So all bugs related to Zigbee2MQTT itself should be reported on that project
The addon is done by the HA team packaging it in a docker container so bugs related to the addon as an addon can be reported in the HA project but anything related how Zigbee2MQTT works has nothing to do with the addon.
You find the Zigbee2MQTT project github here
Thank you.
For reference, someone has opened a bug for this already: ERS-10TZBVK-AA - HA event has not action step/transition/rate · Issue #25729 · Koenkk/zigbee2mqtt · GitHub
The 1743 surely create actions for long press also
Here is my working automation for a 1743
alias: Office Blinds Switch
triggers:
- trigger: state
entity_id: event.office_blinds_switch_action
not_from: unavailable
actions:
- choose:
- conditions:
- "{{trigger.to_state.attributes.event_type == 'brightness_move_up'}}"
sequence:
- data:
topic: office-blinds/set
payload: "50"
action: mqtt.publish
- conditions:
- condition: template
value_template: >-
{{trigger.to_state.attributes.event_type ==
'brightness_move_down'}}
sequence:
- data:
topic: office-blinds/set
payload: "0"
action: mqtt.publish
- conditions:
- condition: template
value_template: "{{trigger.to_state.attributes.event_type == 'on'}}"
sequence:
- data:
topic: office-blinds/step
payload: "10"
action: mqtt.publish
- conditions:
- condition: template
value_template: "{{trigger.to_state.attributes.event_type == 'off'}}"
sequence:
- data:
topic: office-blinds/step
payload: "-10"
action: mqtt.publish
initial_state: "on"
mode: queued
max_exceeded: silent
I know about the legacy option but…
How the hell I am supposed to fix my automations now in Node RED, so these will work in the future when I won’t be able to use legacy actions.
(This is the most ridiculous update ever in HA, caught me completely by surprise).
HA is without guilt here. It is Zigbee2MQTT that released the new event entities before they were finished and disabled the working sensors too early.
Z2M devs have already a discussion about delaying the deprecation of the legacy sensors. Reenable them and follow the development.
Aha, OK, thx for clarification.
However, it looks like this change will remove something which was simple to use, and unnecessarily overcomplicates everything else, great.
1 Like
Yes, it’s true, an event is created but unfortunately only once.
So, if you continue to press the button, there is no other event. (but other mqtt message is created)
So, to increase/decrease the brigthness, you have to release and press for another step.
It’s why, I use a mqtt trigger to manage the brigthness. Also, in the mqtt message, the brigthness value is pushished by button.
But, I wonder in this case, if there is any interest in using an event trigger…
I think there were already discussions on the github page of Z2M about devices normally sending always another event before they send the same again (press → release → press).
Already at that time I thought I wouldn’t bet that’s true, and it seems your devices is an example for that.
Maybe one of the zigbee pros here have an answer how to handle that.
Otherwise I would suggest to post this to the Z2M 2.0 release discussion on Github or raise an issue there.
Unfortunately, thar really depends on the device. However, even the same event should be emitted several times (and it certainly is if the MQTT payload action is published).
The action_brightness_delta is something different. It would not have been part of the legacy _action sensor either (or rather: only if legacy entity attributes was enabled as well).
1 Like
There are two very different scenarios
There is the scenario where the human user presses the same button twice. Like a step up or down. Or a light toggle on/off. These are sent as event entity messages and HA has a problem retriggering on these IF you put any values for To or Attribute in the trigger section. This is already covered well now
Then there are some switches where Zigbee2MQTT sends repeated messages while you hold down a button. But only with some devices.
If you only control zigbee lights, then it is not the best way to control dimming up and down. Philips Hue bridge does it much more elegantly.
When you press dimming up or down, a message is sent to the light group to increase or decrease at a slow rate. When you release the button a stop message is sent to the light group. You get a much more smooth dimming up and down. And only two zigbee messages are sent so you avoid flooding the network with messages. The worst you can do is send messages every half second to a HA group of e.g 7 lights. This would make HA send 7 individial messages via Zigbee twice a second.
We can do the same as Hune with Zigbee2MQTT
Here is one of my automations where a simple 2 button IKEA can turn light on and off by short press and dimm up and down by long press.
alias: Bedroom Desk Switch
description: Bedroom desk lights with dimming
triggers:
- trigger: state
entity_id: event.bedroom_desk_switch_action
not_from: unavailable
actions:
- choose:
- conditions:
- "{{trigger.to_state.attributes.event_type == 'on'}}"
sequence:
- entity_id:
- light.bedroom_desk
action: light.turn_on
- conditions:
- "{{trigger.to_state.attributes.event_type == 'off'}}"
sequence:
- data:
entity_id:
- light.bedroom_desk
action: light.turn_off
- conditions:
- condition: template
value_template: "{{trigger.to_state.attributes.event_type == 'brightness_move_up'}}"
sequence:
- action: mqtt.publish
metadata: {}
data:
topic: zigbee2mqtt/Bedroom Desk/set
payload: "{\"brightness_move\": 50 }"
- conditions:
- condition: template
value_template: >-
{{trigger.to_state.attributes.event_type ==
'brightness_move_down'}}
sequence:
- action: mqtt.publish
metadata: {}
data:
topic: zigbee2mqtt/Bedroom Desk/set
payload: "{\"brightness_move\": -50 }"
- conditions:
- condition: template
value_template: "{{trigger.to_state.attributes.event_type == 'brightness_stop'}}"
sequence:
- action: mqtt.publish
metadata: {}
data:
topic: zigbee2mqtt/Bedroom Desk/set
payload: "{\"brightness_move\": 0 }"
initial_state: "on"
mode: queued
max_exceeded: silent
1 Like
Hi All,
I successfully updated to Z2MQTT 2 and as per this thread my Ikea & Samsung buttons stopped working. I can see the events in the integration section for the button (Just trying an Ikea button to start with) and I can also see the events in the states tab of developer tools (event.office_remote_action)
The problem I am having is that when I look for the new event entity in the automation for my Ikea button it does not show in the list. I did get all my buttons working by enabling the legacy option in the Z2MQTT settings but I am curious why I cannot use the new event entities
Any help or advice would be appreciated as always
Are you using a blueprint? The selector might be locked to the sensor domain and would then not allow event entities to be selected.
Yes it is a BluePrint for the Ikea 5 button remote.
I just tried cresting a new automation not using the BluePrint and was able to see the event entity. You might be right about the BluePrint. I will just leave the legacy option enabled for now, the buttons are all working