[GPIO] New GPIO Binding for OH3

[scoobydrvr (Keith Wheaton)]

I’m attempting to use this binding to piggy back off of my home security panel. I followed the instructions provided in the documentation and, when I add or edit a channel, the following message appears in the log

2021-07-20 09:44:23.321 [WARN ] [internal.handler.PigpioRemoteHandler] - Failed to initialize gpio:pigpio-remote:a50fc9ae60:BackDoor: (-41) no permission to update GPIO

Any ideas what is going on here?

EDIT:
I’m not sure if this is the right thing to have done or not but I gave the file

/etc/systemd/system/pigpiod.service.d/public.conf

755 permissions and restarted Openhabian and all the odd behavior went away, save for one. I’m still getting the above warning for one item on GPIO Pin 1. It looks like that pin has an alternate function for EEPROM clock so I moved that input to GPIO Pin 24 and all is working now.

[Constantinos_Contis]

hi guys,i finally switched to openhab3 on my rpi openhabian and i have a problem with gpio binding.I use 2 output channels pin 18 and pin 23 to drive 2 relays.Upon restarting the output pins are going at the ON state so my relays close and stay closed until i use them again…Any ideas?
edit : i think i have the same problem as Wadu

@Wadu

Then I create the thing configuration and save it, now the gpio’s switched on and hold the on state. The relais switched on.
This is an new situation. The milstone builds only activate the gpio’s with the thing configuration but doesnt switch them.

when

Thing 'gpio:pigpio-remote:212d9a9a3c' changed from INITIALIZING to ONLINE

all my output channels goes ON and stay ON…until i toggle them once.Then they work nice.My input channel is not affected by this.I use 2 relays to control access control units for my home.If my system restarts pigpio sent ON continuously and i cant control my doors until i toggle gpio items once…

initial state: OFF

at channel’s configuration has no effect…

[ilo (Lehocky)]

Hi
The problem with “When the Raspberry starts, now the GIO’s starts with ON state” is only after restarting OpenHAB, not when restarting the GPIO add-on or updating OpenHAB.

Setting all GPIO Outputs to ON after restarting OpenHAB happens when the GPIO add-on is initialized (see log during restart).The GPIO add-on switches GPIO to the ON state when going to the “changed from INITIALIZING to ONLINE” state (sends a command to switch all Output for the PIGPIO daemon). The PIGPIO daemon takes care of switching to the ON / OFF state of GPIO (HW RPI).
The Main UI (Openhab) does not know that Item.state has been changed and therefore you can see that Item.state is OFF.

There are more repair options, for me the fastest GPIO switch
(relay to OFF) when starting OpenHAB in about 3 seconds from the ON state, it can be done similarly to what I described earlier in the problem with Input, but the commands are different.

Command (for PIGPIO daemon) to switch GPIO 4:

• pigs w 4 1
  (set GPIO 4 high)

• pigs w 4 0 (set GPIO 4 low)

• pigs mils 5000
  (the next command delays by 5 seconds in case a process has already started and its duration is a few seconds, typically valve ON / OFF).

Note: High / Low selection is related to Inverted Output function and relay type …

Try the following:

• ssh to OpenHAB
• sudo nano /home/openhabian/set_Output.sh
• Type for example:
  pigs w 4 1
  pigs w 6 0
  pigs mils 5000
  pigs w 12 0

(or the commands you need to run at system startup)

• Ctrl x
  Y (Save file)
• sudo chmod 755 /home/openhabian/set_Output.sh
• exit

Main UI:
settings
Bindings
Add
Exec Binding
Install

Main UI
Rules
Add
Type name “XXX”
Add Trigger
System Event
choose 80 - Things initialized
done
Add Action
Run Script
DSL rule

copy text:

executeCommandLine (“home / openhabian / set_Output.sh”)
logInfo (“XXX.rules”, “Ouput set”)

Save
Back

Run a script in the Main UI:

• Settings
• Rules
• select “XXX” (or your name)
• Run Now (Ctrl-R)

When Run the script manualy
in openHAB Log Viewier (http: //192.168.XX.XX: 9001 /) You can see:

Output set

The same after restart OpenHAB in openHAB Log Viewier.

Hope this helps.

[Danny_Cohn]

I’m having the same problem with the relays activating at boot. Setting a rule to toggle them off isn’t an option for me, I can’t have them on for even a few seconds until the rule fires.

Has anyone found a proper fix for this? Can I switch which pins I’m using to help resolve this?

[ilo (Lehocky)]

If you can’t have them on for a few seconds, try removing the Output SW with the Things configuration, creating a (virtual) SW with the same name and Rules that will run the script on the ON or OFF Relay (GPIO hi / lo).

Or try another way to control GPIO

Controlling GPIO with OpenHAB (RaspberryPi)

This will probably give you a better result. Allen recommended NodeRed as an alternative. If you code something in Python you can publish/subscribe for events using OH’s REST API or using MQTT. For an example see https://github.com/rkoshak/sensorReporter. I have this running in various RPis to interact with sensors and actuators around the house and use MQTT to publish the sensor readings and subscribe to MQTT messages to cause things to occur.

[CrazyIvan359 (Michael Murton)]

I’ve also written a piece of software to control GPIO and more on single board computers. It was designed with responsiveness in mind and can set pin states at startup based on the config file.

MQTTany - GPIO and more over MQTT

MQTTany v0.14.1 >>> Raspberry Pi 4 support is here in v0.14.1! <<< MQTTany is the evolution of a simple Python program I wrote to allow me to control the GPIO pins on a Raspberry Pi 3 from my openHAB server. MQTTany is designed to make it easy to connect hardware on single board computers to your home automation solution. It is built around the concept of modules, each with a specific purpose, so that only the components that are needed for your use case are loaded. Communication Modules are r…

[ilo (Lehocky)]

Hi
I will try to describe it better in this example:

@Wadu

I have configured this things:

removing the Output SW with the Things configuration:

before things file:
Channels:

// Heizung

Type pigpio-digital-output : GPIO-output-27 [ gpioId=27, invert=true] 

after things file:
Channels:

// Heizung

//    Type pigpio-digital-output : GPIO-output-27 [ gpioId=27, invert=true] 

Items config - SW with the same name:
before Items file:

Switch GpioOutput02 {channel=“gpio:pigpio-remote:GPIO-pi-1:GPIO-output-02”}

after things file:

Switch GpioOutput02
// {channel=“gpio:pigpio-remote:GPIO-pi-1:GPIO-output-02”}

new Rules
(control GPIO 27 switching On/Off):

rule "GpioOutput02"

// GPIO 27 On-OFF
when
	Item GpioOutput02 changed
then
	if(GpioOutput02.state == ON ){
		executeCommandLine("/home/openhabian/GpioOut02On.sh")
        logInfo("set.rules", "GpioOutput02 is On")
	}
    else {
		executeCommandLine("/home/openhabian/GpioOut02Off.sh")
        logInfo("set.rules", "GpioOutput02 is Off")
	}
end

ssh to OpenHAB

sudo nano /home/openhabian/GpioOut02On.sh

Type:

pigs w 27 1

Ctrl x

Y (Save file)

Type:

sudo chmod 755 /home/openhabian/GpioOut02On.sh

Similar for Off:

sudo nano /home/openhabian/GpioOut02Off.sh

Type:

pigs w 27 0

Ctrl x

Y (Save file)

Type:

sudo chmod 755 /home/openhabian/GpioOut02Off.sh

sudo reboot

After restart, GPIO 27 (Item GpioOutput02) does not switch to ON.

At the first request to change the state of GpioOut02, the GpioOut02-Relay is switched via the GpioOut02On.sh or GpioOut02Off.sh script.

Note:
For non-inverted relays it is necessary to change the command in GpioOut02Off.sh and GpioOut02On.sh file.

Maybe I explained it in more detail and
I hope it helped …

[Wadu (Walter)]

@ilo

Maybe I explained it in more detail and
I hope it helped …

hi,

thank you for your lines.
In tha past I used wiringpi to switch the gpio’s. With the same functionality as you explain.
My target was to use openhab 3.0 without bash scripts. It runns well from 3.0 M2 to M4.
But with the 3.1 Release it doesn’t run.
Now I reuse my old scripts and install wiringpi to switch my HeatingSystem.
Thank you

[ilo (Lehocky)]

Hi,
I think that is also possible

try to:

sudo nano /etc/rc.local

write before EXIT default setting for GPIO …

pigs w 23 1
or
pigs w 23 0

You can also run simple scripts here if you already have GPIO settings for example:

/home/openhabian/output.sh

I tried it a while ago and it works.

So you don’t need any extra Rules or bash scripts and there is no switching during OpenHab startup.
The file “/etc/rc.local” is automatically loaded at system startup, before gpio:pigpio-remote
so once gpio: pigpio-remote is running it already has some input parameters and does not switch Relay to ON (GPIOs of logic 0).

I think the problem is that the pigpio daemon needs to have some default values ​​defined, otherwise it will set to GPIO logic 0 and that means ON for the inverted relay.

It would be best if GPIO Binding had a default value for Output Channel somewhere in the settings.

[marcelser (Elser Marc)]

Do we still have no default value for the GPIO output pins in the add-on? There have been long discussion in this thread and lots of workarounds hacks. But it seems still no support for dault values was added which would make all those startup hacks obsolete

[Anarchor (Steve Mills)]

Firstly, I’m new to Openhab. I’ve successfully installed Openhab 3.2 on a Raspberry Pi 3 and have
managed to configure Hue devices, X10 devices via an Insteon PLM and Zwave devices via an Aeon Labs Zenstick. Now I’m attempting to use the GPIO pins on the Pi to control some relays.

I have pigpiod installed on the pi and the GPIO binding installed in openhab. I managed to configure a channel for each relay, and as I configured each channel the corresponding relay was set to ON (the red LED beside the relay on the relay board came on and the relay clicked appropriately). Now that the channels are all defined, all of the relays are set to ON and I cannot control them. When I attempt to toggle them ON or OFF via the Things interface, no luck. I’ve even tried adding a channel to my Model and triggering the channel toggle switch from the model and still no joy. I’ve watched the log file in console using log:tail and when I toggle the channel switch the log tells me that the Channel has changed to the OFF state, but it physically hasn’t on the board (red LED is still on and the relay didn’t click off). Not sure what to try next.

[Anarchor (Steve Mills)]

Upon further testing, I don’t believe my problem is with Openhab or the binding. When I use the “pigs” commands from the openhabian pi I cannot change the status of the relays even though the status of the pins changes. Example: if I type “pigs w 4 0” the status of the pin changes (as indicated by “pigs r 4”), but the relay is not triggered to the corresponding status. To carry that further if I change the status of a pin using openhab (the switch toggle in the UI), again the relay does not trigger, but the pin (as indicated by pigs r) does. So I believe the binding is doing what it should. Question now is why is pigpiod not controlling the relays? I should probably find a more appropriate discussion for this question.

[ilo (Lehocky)]

Depending on what you say, you may have a damaged GPIO pin 4.
Try another GPIO pin and test whether the relay responds or not.
The GPIO pin must not be connected to 5V only 3.3V,
otherwise the output transistor on the GPIO (4) will be damaged.
Other GPIOs are likely to be fine. GPIO pin 4 is used on Onewire.
See Raspberry Pi GPIO Pinout
and try another GPIO pin (17,27,22 …).
If that doesn’t help, try replacing the relay board or test if it works.

[jeremyrumpf]

All,

I am working on a project where I wish to include some contact sensors in a building into openhap using a remote RPi and the GPIO binding. After prototyping things, I found a few issues with the binding. One issue is the lack of reconnect to pigpiod. The other is any form of gpio pin state sync.

With that said, I started digging into the binding code to see what was up. So far I’ve managed to correct the pigpiod reconnect. The binding now supports a heartbeat to detect connection failures.

I’ve also added some configurable actions for when the binding connects or reconnects.

An example Thing config:

Thing gpio:pigpio-remote:shoppi "ShopPi GPIO" [ host="192.168.164.5", port=8888, 
                                                heartBeatInterval=10000,
                                                inputConnectAction="REFRESH",
                                                inputDisconnectAction="NOTHING",
                                                inputReconnectAction="REFRESH",
                                                outputConnectAction="REFRESH",
                                                outputDisconnectAction="NOTHING",
                                                outputReconnectAction="REFRESH" ] {
    Channels:
            Type pigpio-digital-output : BCM18 [ gpioId=18 ]
            Type pigpio-digital-input  : GPI23 [ gpioId=23,debouncingTime=30,pullupdown="UP",invert=true ]
}

heartBeatInterval:

• Time in ms to check the state of the pigpiod process. This is done by issuing a CMD_TICK on the command socket.

inputConnectAction inputReconnectAction:

• REFRESH - Issues a refresh on the input channels at INITIALIZING connect. This reflects the gpio pin value back on the channel.
• NOTHING - Do nothing (existing binding behavior).

inputDisconnectAction:

• SETUNDEF - Set’s the input channesl to UNDEF
• NOTHING - Do nothing

outputConnectAction:

• ALLON - Set’s the output channels to ON at INITIALIZING connect, commanding the gpio pin.
• ALLOFF - Set’s the output channels to OFF at INITIALIZING connect, commanding the gpio pin.
• REFRESH - This reflects the gpio pin value back on the channel.
• NOTHING - Do nothing.

outputDisconnectAction:

• SETUNDEF - Set’s the output channels to UNDEF
• NOTHING - Do nothing

outputReconnectAction

• REFRESH - Issues a refresh on the output channels at reconnect. On reconnect, the gpio pin value may reflect on the channel state UNLESS a channel item has been commanded to change. This one was confusing to me. It appears that OpenHAB queues channel commands until the Thing goes back online. This negates the REFRESH.
• NOTHING - Do nothing (existing binding behavior).

Few questions:

1. While this code is fresh in my mind. I would like to submit for feedback on the functionality.
2. Request any other functionality (as long as it is reasonably doable).
3. Find some folks other than me that may be willing to test.

I have made a build available: here
Code is: here

Build was made with:

openjdk 11.0.14 2022-01-18 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.14+9-LTS)

Regards,
Jeremy

[Rugievid (Chris)]

Hi Nils,
Thank U for your efforts and very good job.
Till now i’ve been using OH2.5 with previous GPIO Binding - sth about 16 relays + 1wire + i2c temp and humidity sensors…
Thanks to U i’ve started to migrate to OH3 on Rpi4
Today i’ve stuck… In old system few relays works for a few sec after started (rollershutter needs 2sec hold)…
On previous binding in items file - all i had to do was add: expire=“5s,command=OFF” in line with GPIO definition. i.e:

Switch channel7 “WaterPump” { gpio=“pin:22 activelow:yes initialValue:high”, expire=“30s,command=OFF” }

Is there a way to accomplish the same result in new binding? (sorry for my poor english)
Thanks in advance

[jeremyrumpf]

Chris,

Which version of the binding are you using? The official distro version or my updated version?

Regards,
Jeremy

[Rugievid (Chris)]

Jeremy,
I’m using official binding… should I uninstall it and install updated version?

[jeremyrumpf]

I would uninstall the binding via the web ui. Then download this version here. Install the updated version by copying the jar file to /usr/share/openhab/addons. The updated version handles disconnects to pigpiod and also has the features I think you need.

You will see new options under the Thing configuration. For you, I would set the heartbeat to 5000 and select all the Refresh options.

When you configure your channels. The options you are looking for are expire and expireCommand. Please note, the expireCommand is subject to the Invert flag. If the Invert flag is true, an OFF command actually turns on the GPIO pin (simulates active low). To disable expiration, leave expire set to 0.

[Rugievid (Chris)]

Thank U Jeremy - i’ll try it on weekend and let U know.
You’re the best

[jeremyrumpf]

I just realized you may be used to using config files vs the gui. Let me describe an example config via files.

1. Configure the GPIO Binding: Create /etc/openhab/things/gpio.thing

Thing gpio:pigpio-remote:rpi4 "Rpi 4 GPIO" [ host="127.0.0.8", port=8888,
                                                heartBeatInterval=5000,
                                                inputConnectAction="REFRESH",
                                                inputDisconnectAction="NOTHING",
                                                inputReconnectAction="REFRESH",
                                                outputConnectAction="REFRESH",
                                                outputDisconnectAction="NOTHING",
                                                outputReconnectAction="REFRESH" ] {
        Channels:
                # Outputs
                Type pigpio-digital-output : GPO7  [ gpioId=7, invert=true,expire=2000,expireCommand="OFF" ]
                Type pigpio-digital-output : GPO27 [ gpioId=27,invert=false ]
                Type pigpio-digital-output : GPO22 [ gpioId=22,invert=false ]     

                # Inputs
                Type pigpio-digital-input  : GPI6  [ gpioId=6, debouncingTime=50,pullupdown="UP",invert=true ]


                # Repeat for all GPIO pins in use
}

2. In your items file you can then link your Switch Item(s) to the GPIO channel(s) defined in the Thing:

Switch   Channel7   "WaterPump"   { channel="gpio:pigpio-remote:rpi4:GPO7" }

The key here is the expire behavior I think you are looking for can be directly handled by the gpio Binding in the channel configurations vs using the Expire statements on the Items. Which way is easier or better is open for debate.