[BUG] Debounce not working

[cesaregiannetti]

Plugin Version
0.6.2
gpiozero 2.0.1
octopi 1.1.0 (bookworm)
GPIOZERO_PIN_FACTORY=lgpio

Describe the bug
Pressing the button causes the action to be executed multiple times.
My button is a normally-open microswitch connected between BCM 5 and GND.
The only action is TOGGLE of BCM 17.

I tested different "Hold Time"s from 10ms to 500ms and "Async" true or false.
It really looks like a debouncing issue, because the number varies from 2 to 4 depending on how long I press.
It looks like the Hold Time is ignored, but I don't know if it was intended as a debouncing.

To Reproduce
click a physical button

Expected behavior
action is executed once

for some reason -- Failed to upload "octoprint.log" --
I paste here the content

2025-06-08 11:05:12,074 - octoprint.plugins.physicalbutton - DEBUG - Reacting to button Light switch
2025-06-08 11:05:12,075 - octoprint.plugins.physicalbutton - DEBUG - Sending activity with identifier 'Light' ...
2025-06-08 11:05:12,078 - octoprint.plugins.physicalbutton - DEBUG - The activity with identifier 'Light' was executed successfully!
2025-06-08 11:05:12,081 - octoprint.plugins.physicalbutton - DEBUG - Reacting to button Light switch
2025-06-08 11:05:12,084 - octoprint.plugins.physicalbutton - DEBUG - Sending activity with identifier 'Light' ...
2025-06-08 11:05:12,091 - octoprint.plugins.physicalbutton - DEBUG - The activity with identifier 'Light' was executed successfully!

2025-06-08 11:05:35,092 - octoprint.plugins.physicalbutton - DEBUG - Reacting to button Light switch
2025-06-08 11:05:35,092 - octoprint.plugins.physicalbutton - DEBUG - Sending activity with identifier 'Light' ...
2025-06-08 11:05:35,095 - octoprint.plugins.physicalbutton - DEBUG - Reacting to button Light switch
2025-06-08 11:05:35,098 - octoprint.plugins.physicalbutton - DEBUG - The activity with identifier 'Light' was executed successfully!
2025-06-08 11:05:35,102 - octoprint.plugins.physicalbutton - DEBUG - Reacting to button Light switch
2025-06-08 11:05:35,099 - octoprint.plugins.physicalbutton - DEBUG - Sending activity with identifier 'Light' ...
2025-06-08 11:05:35,105 - octoprint.plugins.physicalbutton - DEBUG - Sending activity with identifier 'Light' ...
2025-06-08 11:05:35,110 - octoprint.plugins.physicalbutton - DEBUG - Reacting to button Light switch
2025-06-08 11:05:35,113 - octoprint.plugins.physicalbutton - DEBUG - The activity with identifier 'Light' was executed successfully!
2025-06-08 11:05:35,114 - octoprint.plugins.physicalbutton - DEBUG - The activity with identifier 'Light' was executed successfully!
2025-06-08 11:05:35,116 - octoprint.plugins.physicalbutton - DEBUG - Sending activity with identifier 'Light' ...
2025-06-08 11:05:35,123 - octoprint.plugins.physicalbutton - DEBUG - The activity with identifier 'Light' was executed successfully!

[cesaregiannetti]

I think it's also worth mentioning the following:

$ ls -l /dev/gpiochip*
crw-rw---- 1 root gpio 254, 0 Jun  8 01:05 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 Jun  8 01:05 /dev/gpiochip1
lrwxrwxrwx 1 root root      9 Jun  8 01:05 /dev/gpiochip4 -> gpiochip0

I'm not sure it's relevant, though I cound't determine if it's only on my installation or if it's common to have.
For sure I didn't do that on purpose

[cesaregiannetti]

I had time to dig into the code and, though I don't know Python, I'm convinced that "Hold Time" could not work as a software debounce, because debouncing it's not about how long the button has been pressed, but rather how many times it was pressed in a short period of time. The code spawns a new thread every time the button is pressed and checks if it's still pressed after buttonTime, but it does so in parallel as many times as the number of bounces, resulting in the log I posted.
Assuming an hold time of 50ms, here's my reconstruction:
11:05:12,024 Actual button press (value 1) -> thread T1
(value 0)
11:05:12,031 First bounce (value 1) -> thread T2
11:05:12,074 Reacting to button (value 1) T1
11:05:12,081 Reacting to button (value 1) T2

I believe you should use bounce_time from gpiozero. It can be configurable by the user (which I have no knowledge to do myself) or a fix value, for which I suggest 20ms, as suggested online and confirmed by my experiments.
I think it's a reasonable value for a physical button, no one is ever gonna be able to click faster than that.
I'll send a pull request with that hardcoded value as soon as I figure out the proper way to do it.

[cesaregiannetti]

I don't have permission to push my branch, so here's my patch, in case you want to commit yourself.
Please consider using it, as it's so simple, yet so effective that in my opinion it's the only missing key to this great project, the only plugin I could find that correctly uses gpiozero and could work with the new GPIO stack.

diff --git a/octoprint_physicalbutton/lib/gpio_setup.py b/octoprint_physicalbutton/lib/gpio_setup.py
index 300b8e9..5297f57 100644
--- a/octoprint_physicalbutton/lib/gpio_setup.py
+++ b/octoprint_physicalbutton/lib/gpio_setup.py
@@ -15,7 +15,7 @@ def setup_buttons():
             continue
         button_gpio = int(button.get('gpio'))
         button_mode = button.get('buttonMode')
-        new_button = Button(button_gpio, pull_up=True, bounce_time=None)
+        new_button = Button(button_gpio, pull_up=True, bounce_time=0.02)
         if button_mode == "Normally Open (NO)":
             new_button.when_pressed = react_to_input
         if button_mode == "Normally Closed (NC)":