The new event entities are only created for what you would consider stateless information. Pressing a button on a switch that bounces back is the classic example. Pressing a button that have “on” printed on it it does not leave the remote control in an on state. It just send a momentary message that is called “on”. You can press it multiple times and use it to toggle something on and off or you can increase the sound. Anything. These are events of transmitting the press, or the release, or the long hold etc of a button. This is what events are for.
Illumination is a sensor and it has a state which is a value with a unit lux. They are still good old sensors in Zigbee2MQTT. However 2.0 has a breaking change where the illuminance sensors were renamed so all your old sensors are gone and replaced by new. And to make matters worse they are by default disabled. You have to enable them first in Home Assistance. This takes 30 seconds from you enable them till they show up and another minute or two before the sensor sends a new value so be patient.
I’v converted a automation for my ikea E1743 and E1744 from legacy to event based triggers. All works except the toggle trigger in the E1744. You can switch it off but can not switch it on, because then the event-state does not change (toggle → toggle). You can get it working bij dimming down and then press toggle. So i’m looking for a way to change or clear the state after a toggle. Does anybody has a sollution?
p.s. Problem Solved
The problem was solved by @mekaneck on discord. I had to remove
I am the same. So pleased I only have 2 buttons to sort out, but still… I get that things have to be updated from time to time, but I think the HASS and Z2M teams need to come up with a much better way of creating an update route which is not just “it’s in the change notes” and you only find it after things stop working.
I have re-read all the 2.0 breaking changes notes and the only mention is in a section marked " Only breaking when legacy is enabled :" which is not true. I did not have any legacy settings enabled, but all my action based buttons.
The most frustrating part is I thought I had done everything “right”. I am not using NodeRed, my automation is using a blueprint, I had not customised any part, yet still an update requires me to enable a “legacy” setting to keep things working.
If I don’t enable the legacy option I cannot see any way of keeping the buttons functional. Have I missed something?
Each entity will probably have a couple of hidden entities. One, or both, will be sensor.xxx_illuminance. If you enable that entity your sensor.xxx_illuminance will return.
OK so im seeing a big problem here. The event_type attribute only changes once and does not revert back to unknown when the button is depressed. So using triggers to detect events only works if different buttons are being pressed each time, but doesnt trigger if the pressed button is same as the one pressed previously.
Im not sure how can i fix my existing automations which look like (already added attribute to event_type and sensor. to event. domain):
alias: Baby buddy buttons
description: ""
triggers:
- entity_id:
- event.baby_nappy_changing_button_action
attribute: event_type
id: wee
to: single
trigger: state
- entity_id:
- event.baby_nappy_changing_button_action
attribute: event_type
id: poo
to: hold
trigger: state
- entity_id:
- event.baby_nappy_changing_button_action
attribute: event_type
id: both
to: double
trigger: state
- entity_id:
- event.baby_bedroom_remote_action
attribute: event_type
id: bedroom_timer_start
to: toggle
trigger: state
- entity_id:
- event.baby_bedroom_remote_action
attribute: event_type
to: arrow_left_click
id: bedroom_formula_feeding
trigger: state
- entity_id:
- event.baby_bedroom_remote_action
attribute: event_type
to: brightness_up_click
id: bedroom_nap
trigger: state
- entity_id:
- event.baby_bedroom_remote_action
attribute: event_type
to: brightness_down_click
id: bedroom_sleep
trigger: state
- entity_id:
- event.baby_feeding_remote_action
attribute: event_type
to: toggle
id: feeding_timer_start
trigger: state
- entity_id:
- event.baby_feeding_remote_action
attribute: event_type
to: brightness_up_click
id: feeding_solids
trigger: state
- entity_id:
- event.baby_feeding_remote_action
attribute: event_type
to: brightness_down_click
id: feeding_formula
trigger: state
- entity_id:
- event.master_bedroom_baby_remote_action
attribute: event_type
to: toggle
id: master_bedroom_timer_start
trigger: state
- entity_id:
- event.master_bedroom_baby_remote_action
attribute: event_type
to: brightness_up_click
id: master_bedroom_nap
trigger: state
- entity_id:
- event.master_bedroom_baby_remote_action
attribute: event_type
to: brightness_down_click
id: master_bedroom_sleep
trigger: state
- entity_id:
- event.master_bedroom_baby_remote_action
attribute: event_type
to: arrow_left_click
id: master_bedroom_formula
trigger: state
- entity_id:
- event.master_bedroom_baby_remote_action
attribute: event_type
to: arrow_right_click
id: master_bedroom_nappy
trigger: state
conditions: []
This is exactly why I warned earlier and why I edited my original post
Do NOT put any “To” or “Attribute” in the trigger section of the automation.
If you do you cannot press the same button multiple times because the trigger then only fires when the event changes. You need it to trigger even when same value is sent
Repeated to answer same problem again. This is exactly why I warned earlier and why I edited my original post
Do NOT put any “To” or “Attribute” in the trigger section of the automation.
If you do you cannot press the same button multiple times because the trigger then only fires when the event changes. You need it to trigger even when same value is sent.
I appreciate this workaround, but it feels like a serious usability/feature regression, as i cannot use trigger ids anymore with the new event system? <
That’s not only going to force me to rewrite my automations, but also make the new ones much less clear and easy to read.
I tried it just to test it out (for the future if the legacy option gets deprecated) and it works. I have too many automations in node red to change at the moment!
If i cannot specify (in practice) event_type in the trigger, then i cannot really use trigger_id… theoretically i could but its pointless as it now longer identifies what exactly triggered the automation
Well, my problem is that i need to rewrite a few huge automations almost from scratch to avoid using a feature - trigger id, which not only has not been deprecated from HA, but has been introduced quite recently. Just a few months after i rewritten these automatons from using conditions to use trigger IDs - because:
a) it was a new way of doing things so i would assume its gonna be supported better
b) because the code looks nicer.
This is - by definition - a feature regression - a new feature is being introduced to HA, and then soon after another feature is being introduced which breaks the first one.
Now i have an idea how can i fix my automations thanks to your posts above, but that doesnt change the fact this is a regression. One developer probably spent time making one feature and another dev spends time making another feature, which makes the first one redundant.
Its not an automation which i written 6 years ago which needs fixing - those work all right, its the automation i wrote a few months ago to keep up with latest features, which needs fixing.
[edit] OK i see that trigger IDs were introduced over 3 years ago - times flies past, but it still feels like a new feature for someone who was with HA almost from the beginning
