I understand your point, but in that way you don’t have multiclicks event.I have updated the “solution” to use binary sensors instead of template buttons, because HomeAssistant triggers the automation on reboot and there is no need to grant additional permissions. Obviously when event entities will be implemented in esphome everything will be much cleaner.
You do have mave multi-click actions. You keep referencing events and needing events… An event is just an action that can be used as a trigger or condition. An esphome button press is a HA state change event. An esphome “event” is just a state change, sensor update, switch.turn_on… theyre the same thing, they just dont call them “events” in esphome.
I think you have some confusion. Clicks, double clicks, hold of buttons are events (something happened) and there Is no way to pass this information to home assistant referenced to the device (and thus autodiscovered by the automation editor and logged into the device). It Is possibile only to write a generic event into the HA’s event bus.
You could catch the event of a state change, in your example a binary sensori state change. This way you can indirectly acknowledge that the button was pressed (because the state of the binary sensor has changed).
In your example your referring to multiclicks that executes their action directly in the node (and not in Home assistant).
1 Like
The only thing im confised about is why you are fixated on using Events? Thats not the normal or recommend way to use in automations. Esphome isnt HA and what happens in the event bus is for HA, not esphome, theyre 2 different things and esphome is meant to run 100% independently of HA.
Yes, it executes directly on the node, ya think? Its not HA and by itself isnt a HA event. Stop using Events, thats not the way to get clicks ad multi-clicks into HA automation editor. You’re doing it wrong.
1 Like
If you want esphome clicks to be HA events, which doesnt really make sense and isnt really the way to use “clicks” you have to make an esphome automations that triggers a HA event for each one, just like the documentation says… You know, the documentation you keep telling me i dont understand.
What i dont think you really understand is these 2 arent made for each other only. Esphome is completely capable of running automations on the node and “normally” how its used and when you need to work with HA, you can create services, send service calls, templates and other ways.
The reason its usually done this way is the esphome node can still work independently of HA if HA ever goes down or has issues. Youll figure it oit over time though.
This creates a generic event, and is not linked to the device and thus not autodiscovered. If had read the topic you would have known.
Its generic? You know why i dont know that? After 3 yesrs of using esphome? Because theres no reason to use events!!! Stop using events! Thats not how you do this!
1 Like
That didnt sound right that its generic so i checked… Again, your wrong. The data and Title are what identifies this nodes from any other node. It’s just like giving something a unique ID
binary_sensor:
- platform: gpio
pin:
number: D5
inverted: true
mode:
input: true
pullup: true
id: encoder_button
name: Rotary Encoder Button
on_click:
- min_length: 50ms
max_length: 500ms
then:
- homeassistant.event:
event: esphome.button_pressed
data:
title: single_click_node1
- min_length: 50ms
max_length: 500ms
then:
- homeassistant.event:
event: esphome.button_pressed
data:
title: double_click_node2
- min_length: 50ms
max_length: 500ms
then:
- homeassistant.event:
event: esphome.button_pressed
data:
title: multi_click_node3
I’m really trying to help you but, it’s frustrating that you wont provide any details. So, you have a button and you want to do multiple clicks, right? What are these clicks supposed to do? what do you want to happen for in HA?
I believe what you’re looking for is the equivalent of the MQTT “Device Trigger” (MQTT Device trigger - Home Assistant). If that’s the case, I opened a feature request on Github for this exact issue.
Hi there. This thread seems to be spot on, or at least very close to, what I’d like to acheive. Since I totally suck at (understanding) YAML, I will instead explain what I’d like to do, what constraints I know of, and some other stuff that concerns me 
First of all, I’m an EE with long experience of building microcontroller-based devices of all sorts. I usually code the firmware for them in a low-level language, which is probably why I’m having such a struggle wrapping my head around the YAML stuff. That is a “me problem”, I know, but with proper guidance I’ll might come out on the other side a bit wiser. Hopefully. Anyway, this is what I’d like to do:
In my kitchen I have a ceiling lamp, and some lamps above the counters. The latter are gouped in a light-group. All the lamps are IKEA Zigbee, and setup via ZHA. So far, so good.
Now, what I don’t like about this setup, is that it is relying on either control from the HA frontend or the bound (ZHA bindings) IKEA remote. That remote doesn’t fit in with the rest of my wall switches, as well as some other stuff that I’m not totally happy with, such as being battery powered, etc.
I have a two-gang wall switch in the kitchen, that I have added return springs to, and put a ESPHome-flashed Shelly2PM behind. This way I have two momentary buttons, and two relay outputs for the lights.
I would like to have the following situation:
When the system is in normal operation, ie. HA is running, it has control over the Zigbee network, it has an API connection with the ESPHome Shelly etc…
- A single click on either button should toggle the assigned light. For instance, button 1 is assigned to the ceiling, button two to the counters light-group. When switching on, the lights should revert to the same brightness they had before being switched off.
- A double click should turn on the light and set it to maximum brightness.
- A triple click should alternate between three colour temperature settings, cold → mixed → warm (in a round-robin fashion, like the IKEA remote does when you click the right/left buttons)
Worth noting here is that only the ceiling light supports changing color temp, but to keep the ESP side simple, I’d like it to function the same way for both buttons.
That was the “everyting works” scenario. Now for the “stand-alone”, where ESPHome for some reason can’t communicate with HA:
Each click on the button should toggle the corresponding output realy. That’s it. No fancy stuff here. Button 1 → Relay output 1, Button 2 → Relay output 2.
That being said, it sould be understood that in “normal” mode (HA connected), both output relays should always stay on, so the lights may be under full Zigbee control.
Then to some stuff I have been considering:
To me, as a hardware designer, I would prefer that detection of single, double and triple clicks, was done locally in the ESPHome module. The reason is timing. I beleive that the ESPHome is better suited to distingush between the various clicks, compared to each state change being transmitted over the congested WiFi (I live in an apartment block, and you would’t beleive the amount of active WiFi’s in the ether…)
Another thing I’d like to do (if possible) is to make the ESPHome device code generic, in that sense that it shouldn’t be hard-coded to certain lights. I would like to reuse the code for multiple (at least 5) Shellys that I have behind various light switches (converted to momentary buttons). So if possible, I’d like to “soft-assign” each button to a light entity or group, via the HA frontend in some way. It doesn’t have to be full-fledged UI; making an automation is perfectly fine.
And as a last wish, I would like the ESPHome device to expose only either the buttons or the discrete click-events, such as “single”, “double” or “triple”. The relay outputs should be hidden or internal to ESPHome. This is mostly aesthetical, and isn’t a show-stopper in any way. I just beleive that HA shouldn’t (be able to) control the lights via their power supply; that is an “emergency” situation, and should be left to the closest device to control. I beleive there is less room for mishaps that way - I may be wrong.
Thank you for reading through, and please comment any questions or if I’m unclear (have left out vital information).
Hi Eriond. Yes creating binary sensors would work, but I think that if you can wait a little bit there is a push request to implement event entities in esphome that I think will be merged soon. In this case the code will be cleaner and efficient.
Ok, that makes sense. I was already along the same path as You, by creating some sort of messaging mechanism using homeassistant.event: but then I read @Fallingaway24 stating over and over again that we don’t have to use events; and that this communication somehow magically happens in the background. So instead of questioning either point of view, I would like to see an working example of what I’m trying to acheive, and then perhaps it will make more sense to me. 
The recent released ESPHome version 2024.5.0 supports this:
substitutions:
short_min: 10ms
short_max: 500ms
long_min: 500ms
long_max: 2000ms
event:
- platform: template
id: button_1
name: Button 1
device_class: button
event_types:
- pressed_short
- pressed_long
binary_sensor:
- platform: gpio
name: "D1"
# internal: true
pin:
number: D1
inverted: true
mode:
input: true
pullup: true
on_click:
- min_length: ${short_min}
max_length: ${short_max}
then:
- event.trigger:
id: button_1
event_type: pressed_short
- min_length: ${long_min}
max_length: ${long_max}
then:
- event.trigger:
id: button_1
event_type: pressed_long
1 Like