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)?
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'
[Unit]
Description=An abstraction layer (socat) proxy to pigpio to workaround all switches turning on upon opening first connection
[Service]
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"
[Install]
WantedBy=multi-user.target
EOF
cat > /root/gpio_pins_off.sh <<'EOF'
#/usr/bin/env bash
if [[ ! $(id -u) -eq 0 ]]; then
echo "Must run as root"
exit 1
fi
PINS=(
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
done
EOF
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.
