[BUG] GPIO pins are reverted to default pullup/pulldown state by plugin. Breaks button inputs

[numericOverflow]

Plugin Version PhysicalButton: Version 0.6.2 Octoprint: Version 1.10.3 OctoPi: Version 1.1.0, running on Raspberry Pi 4 Model B Rev 1.2

Sorry for the long post, but I wanted to be detailed in my diagnosis

Describe the bug

PhysicalButton is overriding the pullup state of configured inputs to the factory-default pullup/pulldown/no-pullup state. It's even overriding the overrides in configure.txt firmware which can set state very early in boot process. Doing this renders buttons inoperable because they are floating with no internal pullup/pulldown. My buttons stop working.

Example

I have a button on GPIO17 to control my relay on GPIO26. GPIO17 input state defaults to no-pullup but I want to use the built-in pullup so I can just ground the pin with my button to activate.

I have an override in my pi's config.txt to force the GPIOs I need for buttons to enable the internal pull-up.

/boot/firmware/config.txt

gpio=17=ip,pu

See the Raspi docs on pinctrl output to decode, but briefly: ip=input and op=output pu=pullup pd=pulldown and pn=pullup_none

If I completely disable octoprint daemon, and reboot the pi, my GPIO17 pin is in the desired state overridden by my config.txt values, as expected. GPIO26 will get converted to output by PhysicalButton when it executes later, so it's fine as-is for now..

root@octopi:/home/pi# pinctrl get 17,25
17: ip    pu | hi // GPIO17 = input
26: ip    pd | lo // GPIO26 = input

However, when PhysicalButton plugin starts or saves the state, it is reverting the GPIO17 pin back to no-pullup state. I've confirmed this by writing a watcher shell script that checks the states every 1 second and can see it happen after direct interaction with PhysicalButton (startup/saves/edits/etc).

I've also confirmed this is linked to PhysicalButton plugin, because pin states are not altered when the plugin is disabled in Octoprint plugin manager.

To Reproduce

Reboot the Pi with octoprint disabled

root@octopi:/home/pi# systemctl disable octoprint
Removed "/etc/systemd/system/multi-user.target.wants/octoprint.service".
root@octopi:/home/pi# reboot
The system will reboot now!
root@octopi:/home/pi#

After reboot:

root@octopi:/home/pi# pinctrl get 17,25
17: ip    pu | hi // GPIO17 = input
26: ip    pd | lo // GPIO26 = input

#start Octoprint:
root@octopi:/home/pi# systemctl enable octoprint
Created symlink /etc/systemd/system/multi-user.target.wants/octoprint.service → /etc/systemd/system/octoprint.service.
root@octopi:/home/pi# systemctl start octoprint

#
#wait a little bit for octopriint to start
#

root@octopi:/home/pi# pinctrl get 17,26
17: ip    pn | lo // GPIO17 = input
26: op -- pn | lo // GPIO26 = output

GPIO17 (my button) has reverted to no-pullup (FAIL) GPIO26 (my relau) has gone to output mode (PASS)

The same thing happens if you

1. Set the GPIO17 states to use pullup in SSH session
2. pinctrl set 17 ip pu
3. Go into Octoprint > Plugin PhysicalButton > edit button
4. save settings in browser
5. re-check pin configs via SSH
6. pinctrl get 17,26 and see GPIO17 pullup is none again.

Expected behavior

PhysicalButton should not be reverting input GPIO pins to no-pullup.

It looks like there's code to default to pullup-true on button setup, but I can't figure out why it's choosing no-pullup (other than that's the pin default on GPIO17 from what I can tell.

Additional context

FYI - I had this GPIO setup (button & relay on pins 17 & 26) working OK in my previous setup. Same exact PI board, with same pins but older version of octoprint (using python 2.x), So I don't think it's a hardware issue since that suff is same, and I've checked with multi meter that electronics seem to be OK. I'd have to dig through that SD card image to figure out exactly what versions I had that worked.

[numericOverflow]

OK, I went down a massive rabbit hole on GPIO and Raspi only to learn that newer kernel builds have changed the GPIO handling mechanisms, so the old ones don't seem to work.

In my case, the default method (rpigpio package, I THINK??) wasn't working. I was able to force octoprint to use the lgpio package instead.

To do this, I edited the octoprint service file:

• ssh into your raspi

EDIT 2025-07-14: update per @Ohmarinus in comments below Make sure you have both the lgpio & RPi-GPIO python modules installed in octoprint's python venv**

#MAKE SURE YOU ARE NOT ROOT, only run as 'pi' or you can mess up permissions and wreck your octoprint python environment!

cd /home/pi/oprint
source bin/activate
pip install lgpio RPi-GPIO

Note: (default user is 'pi' but update the username accordingly if you changed it from stock setup assumed above) - adjust cd /home/[username]/oprint above as needed if user is not pi

Now edit your octoprint service configuration: sudo systemctl edit octoprint

• then modify the service so that you add this at the top:

Below this line:

### Editing /etc/systemd/system/octoprint.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

Add this:

[Service]
Environment="GPIOZERO_PIN_FACTORY=lgpio"
Environment="LG_WD=/tmp"

Above this line

### Lines below this comment will be discarded

• Save your modifications and exit the editor.

That will set the default pin factory that gpiozero uses, which in turn made PhysicalButton start working.

Then restart octoprint, either in the web GUI, or using this command via ssh: sudo systemctl restart octoprint

[Ohmarinus]

OK, I went down a massive rabbit hole on GPIO and Raspi only to learn that newer kernel builds have changed the GPIO handling mechanisms, so the old ones don't seem to work. ...... Then restart octoprint, either in the web GUI, or using this command via ssh: sudo systemctl restart octoprint

Hi, thanks for your explanation. I have tried out this fix, but sadly it still doesn't work. Does it still work for you or is a new fix needed?

[numericOverflow]

@Ohmarinus - Mine's been running since I got it working initially.

Can't guarantee I can help, but what pi are you running (raspi 3/4/5?) also what version of octoprint & octopi are you running?

can be found at:

Settings (wrench Icon) > System Info button at bottom:

Mine:

OctoPrint - Version 1.10.3 OctoPi - Version 1.1.0, running on Raspberry Pi 4 Model B Rev 1.2

[Ohmarinus]

@Ohmarinus - Mine's been running since I got it working initially.

Can't guarantee I can help, but what pi are you running (raspi 3/4/5?) also what version of octoprint & octopi are you running?

can be found at:

Settings (wrench Icon) > System Info button at bottom:

Mine:

OctoPrint - Version 1.10.3 OctoPi - Version 1.1.0, running on Raspberry Pi 4 Model B Rev 1.2

Hi, thanks for your reply.

I decided to downgrade and install a fresh older version of OctoPi, version 1.0.0. This runs on a Pi Zero 2 W

Info:

octoprint.version: 1.8.6 env.plugins.pi_support.octopi_version: 1.0.0

Before this I had the same version you were running on the Pi Zero 2 W.

On the current downgraded version, Physicalbutton still doesn't run (I mean, it runs, but the button presses aren't registered), but I did discover that the 'enclosure plugin' does run for me, still allowing me to add some kind of physical button GPIO functionality. It's a bummer that I can't use PhysicalButton because it's a lot easier to work with.

[Ohmarinus]

Just to add, I made a 2nd SD card with the newest version of everything:

octoprint.version: 1.11.2 env.plugins.pi_support.octopi_version: 1.1.0 env.plugins.pi_support.model: Raspberry Pi Zero 2 W Rev 1.0

Also did this: https://github.com/LuxuSam/PhysicalButton/issues/95

The GPIO input is still not working sadly.

[Ohmarinus]

Good news;

I fixed it. I'm a bit of a noob and didn't know I had to manually install lgpio as well :)

Going into the env and sending this: pip install lgpio

Fixed it for me!

Thanks for your patience :)

[LuxuSam]

Hi there! I apologise for the radio silence lately. I’m currently overwhelmed with work and haven’t had time to give the plugin the attention it deserves. However, I’ll try to take a look at what you provided over the weekend. Thanks a lot for your help!

[Ohmarinus]

Hi there! I apologise for the radio silence lately. I’m currently overwhelmed with work and haven’t had time to give the plugin the attention it deserves. However, I’ll try to take a look at what you provided over the weekend. Thanks a lot for your help!

Hi Sam, for reference, I did a fresh install today of the latest OctoPi and this sums up how I fixed it: https://github.com/LuxuSam/PhysicalButton/issues/100#issuecomment-3070332716

It was a combination of fixes :) Thanks for keeping it alive!

[numericOverflow]

@Ohmarinus - Nice find! FYI - just to make things more concise, I updated my fix-instructions listed above to include a new step to also install lgpio module into the octoprint python venv. LMK if you did something different or have any suggestions

[Ohmarinus]

@Ohmarinus - Nice find! FYI - just to make things more concise, I updated my fix-instructions listed above to include a new step to also install lgpio module into the octoprint python venv. LMK if you did something different or have any suggestions

The only difference is that I'm not using the 'pi' username, so for me the filepath was slightly different. Maybe for newer users this could be easier to understand? cd /home/[username]/oprint

I don't know either, I'm not the most user-friendly-aware person I know :D

I also needed to do the fix I mentioned in the above reply to LuxuSam to make it all work. And I haven't tested if the debounce works, so I'll still have to check that out once I have my control panel made. I'm still in the process of redesigning, soldering and 3D printing the button panel. I guess I can test if the debounce works once I'm done with soldering, but I read in the issues that the debounce didn't work for someone else.

[numericOverflow]

@Ohmarinus - got it, Added the need to install both lgpio and RPi-GPIO

[LuxuSam]

Sorry, I'm really busy at the moment, I'll try to find time to work on the plugin as soon as I can