Pigpio remote binding wrongly enables all 'registered' gpio-outputs upon disable/enable action

running openhabian (3.1.0) with the pigpio remote binding on a Raspberry Pi 4 Model B Rev 1.2.
running the pigpiod (version 79) on a Raspberry Pi 2 Model B Rev 1.1 connected to a relay-board(16 relays) via the gpio pins.

The following scenario goes wrong:

  • in openhab a total of 12 gpio pins are set as output.

  • the openhab gpio binding has a connection to the pigpiod (deamon) on the pi2.

  • you can nicely switch (activate) a relay and switch it off, using the openhab gui.

  • now we set all gpio pins to ‘off’, the relays are not activated.

  • then pi2, with the relay board is rebooted

  • when pi2 is running again, the openhab gpio binding has lost the connection to the pigpiod

  • using the openhab-gui and doing the enable action on the openhab gpio binding brings back the connection to the pigpiod,

  • but also the 12 relays are also activated, that is not a desired situation.

Why does the binding activate the gpio pins upon re-enabling the connection to the pigpiod (deamon)?

Any idea?

1 Like

I have the same problem. In fact, my external blinds motor fully extended settings got messed up with a recent power outtage. When the Pi booted back up followed by a separate server running Openhab, all the GPIO pins turned on after Openhab reconnected to the pigpio server running on the Pi.

I do not have a solution for this yet. I just wanted to let you know that this problem is not isolated to you. If I come up with something, I‘ll be sure to post it here.

I am still not sure what the real culprit is, but from my experience, it happens during initial connections from Openhab after a Pi reboot (which runs pigpio–Openhab is running on a separate machine). I can now offer “a” solution, which is more of a workaround.

How it works: You enable the pigpiod.service on some port (default is 8888). Then you open another port to serve as a proxy to port 8888 to which Openhab connects to. I do this by means of socat, which does two things: Everytime a connection attempt is made, it runs a script that sets gpio pins to off. Then forwards the tcp packets to port 8888 (untouched).

cat > socat-pigpio-proxy.service <<'EOF'
Description=An abstraction layer (socat) proxy to pigpio to workaround all switches turning on upon opening first connection

ExecStart=/usr/bin/socat -v -v tcp-LISTEN:8899,fork,reuseaddr system:'/root/gpio_pins_off.sh; exec socat -v -v - TCP\:localhost\:8888'
ExecStartPre=/usr/bin/logger "socat caught inbound conection to port 8899 and will forward it to 8888"

cat > /root/gpio_pins_off.sh <<'EOF'
#/usr/bin/env bash
if [[ ! $(id -u) -eq 0 ]]; then
        echo "Must run as root"
        exit 1

5 # pin 29
6 # pin 31
13 # pin 33
16 # pin 36
19 # pin 35
20 # pin 38
21 # pin 40
26 # pin 37

function set_pin() {
        local PIN=$1
        local VALUE=$2
        echo "Exporting PIN $PIN"
        [[ -d /sys/class/gpio/gpio$PIN ]] || echo "$PIN" > /sys/class/gpio/export
        echo "Setting direction of PIN $PIN to out"
        echo "out" > /sys/class/gpio/gpio$PIN/direction
        echo "Setting active_low to 1"
        echo 1 > /sys/class/gpio/gpio$PIN/active_low
        echo "Setting value to: $VALUE"
        echo "$VALUE" > /sys/class/gpio/gpio$PIN/value
export -f set_pin

for pin in "${PINS[@]}"; do
        echo "Handling PIN $PIN"
        set_pin "$pin" 0

Initial experiments indicate that this works, despite a major weakness: I do not currently enforce order of “connection to pigpio, THEN turn off pins”. Maybe when I have some more time I’ll fix that too.