I would like to use a Binary Sensor to read the state of a NC push button and debouncing will be an issue. A human will push the button and release it and debouncing time has to be figured in so it can be adequately debounced but that a push and release still be detected. For instance, if I use delayed_on_off 100 ms, then that’s 1/10th of a second, which is a long enough interval to be perceived by humans. It’s also possible a person could press the button and release it in that time period. (I haven’t run tests yet.)
I’m going to use the pushbuttons, at least in this project, as latches. On boot, the circuits they activate will always be off (as opposed to an SPST switch, that could be left on). After that, pressing the button will turn the latch on. Pressing it again will turn it off. I’d rather handle the toggle/latch
I can see an issue picking a delay that’s long enough to reliably debounce a switch but it short enough that when a human presses the button, even if it’s a quick press and release, it will be detected. I also can think of several solutions, but I’d rather do it through software instead of adding more hardware components. I could add an LED that goes on when it’s been pressed long enough to be debounced and the LED stays on until the button is pressed again and debounced, so the latch can be released. That provides visual feedback to the user.
I can also, of course, debounce the switch with hardware, but that’s more involved than software, since it includes more parts and more to handle in the PCB layout.
Is there any known way to handle this so I can be sure even a quick button press is debounced but still read?
The only thing I can think of here is to measure how long a " very quick press" is. I would have thought that would be longer than bounces but am not sure. You’re suggesting it may not be though so maybe it’s not really a solution…
Might just be a matter of testing/experimenting as a next step.
LED state visual feedback makes sense. I have rttl buzzers on some buttons of mine too which serve a similar purpose (and are handy for a variety of audible feedback purposes).
I don’t know if activating internal esp pullups/downs might also help with reducing bouncing.
Another lifetime ago I did some push button tests to measure the actual debounce time required. It is highly dependant on the switch make/model but good quality ones will only require 5 to 10ms. Also check the manufacturer’s data sheets if the switch has one. They list accurate debounce times too.
Yes - settle. But it seems to me that runs into the same issue as the delayed_on and delayed_off issue - how long to wait for a debounce vs. how long a quick push on a switch is from a human finger.
I’m trying to make the software so it’s hardware independent - so if I make new versions later and can’t get the same switches or optocouplers (or anything else) and use something similar, I don’t have to redo the YAML file. If testing shows 5-10ms for most, that’s pretty fast and I can probably change it to 25ms and it’d work.
I may also do what @Mahko_Mahko suggests and measure it.
But the more I think about it, the more I think I’ll need an LED for feedback no matter what - just for safety and testing in case my switch goes on but the controlled device does not.
No, it shouldn’t, since when a press is detected it is published immediately, hence no perceptible lag, the only issue could be that two quick presses may be seen as only one, but a settle time of say 100 or 150ms should be easily long enough to debounce the noisiest switch, while still being short enough to detect the quickest of double presses.
This is reaching into the range that concerns me. 100 milliseconds is 1/10th of a second, which means the debouncing time is getting into the range of where a human can easily perceive. (Actually, I’ve read humans can perceive an image that’s flashed in front of them for as little as something like 15 ms or less.) But, more than perception, I think a person might press and release a button in 1/10th of a second or less. So if they do that, then the button goes down and is up in less than the debounce time.
BUT - if I’m misunderstanding how to use settle and that it would change on the 1st state change and stay there, please let me know. I would think, though, if it were a quick press and the button was up within that 1/10th of a second debounce time, then would it read as having been pressed at all?
I’m also thinking about what @tom_l said - that he found debouncing required a much shorter window, so maybe I can reduce the settle (or delay) time to 25ms, maybe 50, and that should be short enough to be shorter than a short press and release by a human.
(I hope this doesn’t sound like I’m trying to argue this point - I’m trying to make sure I am not not missing something.)
Yes, the press event will be published immediately. From the docs:
This filter complements the delayed_on_off filter but publishes value changes at the beginning [emphasis added] of the delay period.
Two quick presses within the delay time will be registered as only one - which is exactly what debouncing is supposed to do.
I have a garage door opener with a very crappy pushbutton and I have a 50ms debounce - it was originally a delayed off, now it’s using settle and that works much better.
That’s a very good point I didn’t even think about: If you’re turning on something like a CNC or a laser, you don’t want to do it by accident, so a quick jab would be good to reject. And for turning it off, in the case of an emergency, people will want to hold the button down until they see it stop. I guess it’s possible someone might do a quick jab in haste to turn it off then try to grab damaged materials out - but you don’t want to reach into the workspace for such a machine until you know it’s off anyway.