As soon as he mentioned buttons registering 15 times, I knew that some debouncing article of Jack Ganssle's would be shown.
Like it only occurs when somebody has hit the button no? So if somebody hits "Accept Challenge" and then because of bounce it triggers "Accept Challenge" multiple times why does it matter? Afaik, either you can (1) trivially lock them into their first choice, (2) send the extra bounce choices (which will be a noop on the server), (3) prevent changing choices in <50ms. Any of which don't require spending 12h.
I have at least 2 kitchen appliances where the delay is too high, and the user experience is that you have to press and hold the button in order to trigger it, because tapping it too fast doesn't count.
So frustrating, when the right way to do it is so easy.
Maybe I just need a microwave with Cherry MX keycaps.
Too many people find a solution that fits the bare minimum requirement and move on, leading to years of frustration from the end users. Spend a little more time using the thing like an end user would, and you can solve that issue much better, usually.
onClick event handlers in most GUI triggers on mouse button releases, for example.
Only reason to do it other way is if you have some limitations. Like timer being costly on resources (valid concern for microcontroller)
> Too many people find a solution that fits the bare minimum requirement and move on, leading to years of frustration from the end users. Spend a little more time using the thing like an end user would, and you can solve that issue much better, usually.
A little time won't give you much. Those are kind of problems where you need to be using it daily in anger to find the issues.
Like the buttons on elevator where I live. I press the button, it lights up, I do it few more times, debounce works fine!
Another day I'm in hurry, press it quickly, does not work. Turns out someone picked the worst way to debounce (wait till it is ON for that amount of ms), and on top of that tied LED to button itself so you see the light flash but button does not turn on). So you can't just tap it quickly, and you can't risk tapping it more than once because that would cancel the floor request
I had to solve the debounce more efficiently, because there were actually a few other challenge ideas which would've used the buttons and relied on more precise timing behavior.
The idea was every press would be registered correctly not matter how fast someone hit one, two, or three buttons. So simpler debounce algos were out.
In the end, I recommended against timing-based challenges because with those buttons and the Le Potatoes' strange behavior if you held down a button for more than 50-100ms, I couldn't guarantee every button down/button up would be registered, depending on the dexterity of the individual doing the pressing.
So in an odd turnaround, one of those games might artificially boost certain age groups' ability!
Also check out my blog post [1] for the exact debounce code I wound up using.
[1] https://www.jeffgeerling.com/blog/2023/100-sbcs-python-flask...
...no ? Only if you care about both on and OFF timing you'd need to get creative.
You can just
* trigger on interrupt
* ignore that input for say 50ms (or how long you want your debounce period), whether by disabling interrupt or any other way.
That way you will always catch it, on the first bounce, the fastest possible way. And as you are "NANANA NOT LISTENING" on the pin, doesn't matter whether it bounces or not.
Same with holding, as long as previous registered state was ON and you get OFF, you just send the OFF higher up the stack, start the timer, and ignore any further input for that duration.
I think that's what your code is mostly trying to do
Every time the doorbell rang I got 10-20 “sensor open/close” events, which was fun.
(Ended up using just one Node-RED trigger node with a suitable interval, since I already had that in the loop)
Hell, resistor and a capacitor on the input would probably be enough.
Or just poll every 50ms