Hi there,
As I’m planning to update rpi 4 to RPi 5, but I come across the issue that GPIO binding is not compatible with RPi 5, is any update about this, that GPIO binding will supported by rpi5,
I asked the last person who reported this to open an issue on openhab-addons but I don’t think they did so. Someone needs to finddd and integrate a different GPIO library in the add-on. I don’t have an RPi 5 so I’m not a good person to open the issue.
In the meantime, there are tons of external third party script which basically provide “GPIO to X” type features. My own sensorReporter is one which should work on an RPi 5. It uses a different library and others have tested it. It can use MQTT or the openHAB API directly to send updates and receive commands from Items direcrtly.
1 Like
Actually, I did open an issue regarding this on the openhab-addons repo back on October 29, 2025 [https://github.com/openhab/openhab-addons/issues/19585\]. Unfortunately, there hasn’t been any activity, replies, or triage on it since then, which is why I’m bringing it up again.
In the meantime, I will look into sensorReporter as a workaround for the RPi 5, but I do hope we can find a maintainer to integrate libgpiod (or a similar library) into the native binding eventually.
1 Like
Unfortunately, this is not only a problem with the Raspberry Pi 5; it no longer works with Trixie on the Raspberry Pi 4 either. 
1 Like
If you want to keep the functionality mainly inside OH, could you do something with the python binding and a virtual environment? Then install gpiod with pip?
Personally I find the Debian or RPi repos to be quite out of date with GPIO libraries, so have a manager like pip pull a recent version is beneficial.
Namely the libgpiod library, which is called gpiod as a python wrapper version. There was quite a few changes over the last few years going between version 1.x to 2.x
Also I remember some issues when upgrading to Trixie. The character device changed it’s name from gpiochip4 to gpiochip0.
1 Like
OpenHABian now uses rgpiod instead of pigpio.
Unfortunately, this does not solve the issue, because the openHAB GPIO binding does not work with rgpiod.
Since I only need outputs, I implemented a simple workaround using the EXEC binding.
For inputs, slow polling would still be possible, but without edge detection. Therefore, an interrupt-based solution is not feasible with this approach.
EXEC binding configuration
command="/usr/bin/pinctrl set %2$s", interval=0, timeout=5, autorun=true
I use only a String item as the input parameter and set it, for example, to:
10 dh
or
10 dl
This switches GPIO 10 accordingly.
For pure output use cases, this is currently the simplest solution in my opinion.
1 Like
While the EXEC binding provides a functional workaround for GPIO control, it often proves difficult to configure and lacks the long-term reliability required for stable home automation. To ensure fluent and native support for newer hardware and software architectures, there is a growing need for a dedicated update to the GPIO binding.
The pinctrl command seems to bypass the kernel management of the GPIO interface, which isn’t a good idea for general unsupervised operation. When using something like libgpiod / gpiod will request lines (GPIO pins ) from the kernel so they are reserved for a consumer, and are also cleaned up automatically by the kernel when a process ends.