Just disovered this approach Getting too late for me to spam the doorbell but some quick tests weirdly didn’t trigger the template sensor at all. My config is currently
binary_sensor:
- name: "Sound Raw"
id: sound_raw
platform: gpio
pin:
number: GPIO4
mode: INPUT_PULLUP
internal: true
on_multi_click:
- timing:
- ON for 2ms to 100ms
- OFF for 2ms to 500ms
- ON for 2ms to 100ms
- OFF for 2ms to 500ms
- ON for 2ms to 100ms
- OFF for 2ms to 500ms
- ON for 2ms to 100ms
- OFF for 2ms to 500ms
- ON for 2ms to 100ms
- OFF for 2ms to 500ms
then:
- binary_sensor.template.publish:
id: sound
state: ON
- delay: 5s
- binary_sensor.template.publish:
id: sound
state: OFF
invalid_cooldown: 25ms
- name: "Sound"
id: sound
platform: template
device_class: sound
The log says the timings don’t match but looking at the timestamps they do? Maybe the timings are too small
2025-03-13 19:38:54.617 ... [D][binary_sensor:036]: 'Sound Raw': Sending state ON
2025-03-13 19:38:54.622 ... [V][binary_sensor.automation:025]: START min=2 max=100
2025-03-13 19:38:54.622 ... [V][binary_sensor.automation:026]: Multi Click: Starting multi click action!
2025-03-13 19:38:54.641 ... [V][binary_sensor.automation:090]: Multi Click: You can now RELEASE the button.
2025-03-13 19:38:54.641 ... [D][binary_sensor:036]: 'Sound Raw': Sending state OFF
2025-03-13 19:38:54.649 ... [V][binary_sensor.automation:054]: A i=1 min=2 max=500
2025-03-13 19:38:54.649 ... [D][binary_sensor:036]: 'Sound Raw': Sending state ON
2025-03-13 19:38:54.666 ... [V][binary_sensor.automation:071]: Multi Click: Invalid length of press, starting cooldown of 25 ms...
2025-03-13 19:38:54.668 ... [D][binary_sensor:036]: 'Sound Raw': Sending state OFF
2025-03-13 19:38:54.690 ... [V][binary_sensor.automation:075]: Multi Click: Cooldown ended, matching is now enabled again.
2025-03-13 19:38:54.926 ... [D][binary_sensor:036]: 'Sound Raw': Sending state ON
2025-03-13 19:38:54.933 ... [V][binary_sensor.automation:025]: START min=2 max=100
2025-03-13 19:38:54.933 ... [V][binary_sensor.automation:026]: Multi Click: Starting multi click action!
2025-03-13 19:38:54.946 ... [V][binary_sensor.automation:090]: Multi Click: You can now RELEASE the button.
2025-03-13 19:38:54.946 ... [D][binary_sensor:036]: 'Sound Raw': Sending state OFF
2025-03-13 19:38:54.956 ... [V][binary_sensor.automation:054]: A i=1 min=2 max=500
2025-03-13 19:38:54.956 ... [V][binary_sensor.automation:090]: Multi Click: You can now PRESS the button.
2025-03-13 19:38:55.456 ... [V][binary_sensor.automation:096]: Multi Click: You waited too long to PRESS.
2025-03-13 19:38:55.464 ... [V][binary_sensor.automation:071]: Multi Click: Invalid length of press, starting cooldown of 25 ms...
2025-03-13 19:38:55.492 ... [V][binary_sensor.automation:075]: Multi Click: Cooldown ended, matching is now enabled again.
Like I wrote before, those really short <10ms periods might be difficult for the component. Looks like it starts counting several ms after the trigger.
You need to just read through the documentation, thata by far the best way to help yourself.
If you read the documentation and learn what debounce means/does and then get familiar with the other sensor filters, you will quickly find out that many filters are very similar to others and in many cases you could swap different filters in/out and still get the same results.
If you’d have just done a quick read through the configuration options, they specifically tell you which filter to use for debouncing binary sensors.
Just read the documentation, i cant any more strongly recommend that to everyone or else you’ll struggle for the duration you use Esphome, Homeassistant, and anything else.
I wonder if your sensor works like it should. The ON time proportionally is so low that it feels like the threshold adjustment is not working…
Anyway, If multiclick is not able to detect the shortest signals you need to find another approach.
You could try something like this:
-Remove all multiclick automations and put only delayed_off 500ms filter. That should set your binary sensor ON for the whole time bell is ringing.
-Pass the state to template binary sensor and there set delayed_on filter 1s. That should filter out the door slam or any noise that is shorter than 1s.
Another approach could be experimenting with the analog output of your sensor with
Analog Threshold Binary Sensor
I did skim through the options. The settle option didn’t seem to be what I wanted for this case but maybe some experimenting would make this one work too.
I know I’ve asked quite a lot for input but beside the knowledge gap with ESPHome, I also want(ed) to avoid having to experiment (and thus constantly ringing the doorbell) too much as I’m just renting.
I wonder if your sensor works like it should. The ON time proportionally is so low that it feels like the threshold adjustment is not working…
I mentioned my doorbell sound not being consistent. Might be that tbh
You could try something like this:
-Remove all multiclick automations and put only delayed_off 500ms filter. That should set your binary sensor ON for the whole time bell is ringing.
-Pass the state to template binary sensor and there set delayed_on filter 1s. That should filter out the door slam or any noise that is shorter than 1s.
That seemingly did the trick. I’ve kept the values you suggested and a few tests with ringing and slamming the door correctly detected the doorbell yay. I’ll keep observing it with those settings and might slap a delayed_off to the template binary sensor if it works out so I don’t get spammed as I just need one trigger in my automations.
For reference and in case anyone needs it, this is my sensor config:
Getting too late for me to spam the doorbell but some quick tests weirdly didn’t trigger the template sensor at all. My config is currently
