[GPIO] New GPIO Binding for OH3

Rbartlett · April 30, 2021, 5:31pm

I just upgraded from 3.0.1 to 3.0.2 and had to go back in and re-install through the console again.
bundle:install
bundle:start

But it still works fine.

Midwave · May 7, 2021, 2:02pm

“glad to see this will be included in the 3.1 release!”
Does it mean the standard GPIO binding is now back available in the 3.1.0.M4 (Milestone) distribution?

I mean, i’m not targeting to use the pigpio-remote binding as I prefer the simple items file containing direct access to the pin:
Contact Knop_IN04 “Schakelaar 01 [%s]” { gpio=“pin:3 debounce:10 activelow:yes” }

ashish81sharma · May 8, 2021, 8:14pm

I tried this and it worked as a charm. However, I am not able to invert the switches. The property is not working as expected. Also, is there any way I can bind the state of the GPIO Pin to the switch. For example, if I switch on and refresh the page the Site Map shows the switch in off state. Is there any way I can bind the actual status of the GPIO Pin (Either On or Off) to a switch?

ashish81sharma · May 9, 2021, 5:56am

After restart of RPi, the invert flag started working. However, still not able to set the state of the device while opening the UI. Can someone help me in this? Is there any way we can bind two channels to the same item?

ashish81sharma · May 9, 2021, 6:05am

Seems everything is working now. I just removed autoupdate=false flag from my things file and the state is now persisting with the switch value.

Thank you for implementing this in OH 3. Loved this piece of work.

SloCompTech · May 30, 2021, 9:40pm

@sjoerdtakken I created commit from your proposal and created pull request also with few of my improvements [gpio] Added parameter for pull up/down resistor and other improvements by SloCompTech · Pull Request #10782 · openhab/openhab-addons · GitHub.

schaefc · June 5, 2021, 8:09pm

Thanks for this helpful information!

However I get this error in the log: [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID ‘a78e6b9d6f’ failed: executeCommandLine("/etc/openhab/scripts/set_Input.sh")

The script file exists. Can anyone please help me figuring out why this happens? I use OH 3.1.0.M4.

Thanks in advance!

ilo · June 6, 2021, 9:21am

Hi
With your description not everything is clear, the text behind the error message is important, for insufficient permissions to run the script by the system:
… Cannot run program “/etc/openhab/scripts/set_Input.sh”: error = 2, No such file or directory …

Reasons why the script is not run automatically by the system during startup may be more, version of Openhab you are using (3.0.x or 3.1.x?) or version of Java or HW / OS on which Openhab is running or other …

Try the following:

update Openhab, then run the script manually (via the Main UI), then check the log file to see if the error still occurs
check (via the Main UI) the path specified in the autorun script (there should be no space in the path)
executeCommandLine (“/etc /openhab/scripts /set_Input.sh”)
then run the script manually, then check the log file to see if the error still occurs

If nothing helps, try placing the script file in another directory:

ssh to OpenHAB
sudo nano /home/openhabian/set_Input.sh
Type:
pigs m 6 r
(or the commands you need to run at system startup)
Ctrl x
Y (Save file)
sudo chmod 755 /home/openhabian/set_Input.sh
exit

Main UI change path:

Settings
Rules
select “XXX” (or your name)
Code
find the line with the text:
executeCommandLine ("/ etc / openhab / scripts / set_Input.sh")
and replace the text (path) /etc/openhab/scripts/set_Input.sh
text (path)
/etc/openhab/scripts/set_Input.sh
Save (Ctrl-S)

Here’s how to run a script in the Main UI:

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

If nothing helps with this, copy and send more information from your log file, or more information about your system …

I believe you can do it …

schaefc · June 6, 2021, 5:18pm

Hi ilo,

Thanks for the time you took to help me out. Admittedly, I am very new to the OH world, and I had misinterpreted the logging error message.

Actually it was not the execution of the script itself which has thrown the error (but it was that line which appeared in red in the log viewer), but the subsequent line, the logging line. And here I used the wrong quotation marks as I copied them from the forum. The quotation marks must be straight, but the ones on the forum are curved.

So it should be: logInfo("XXX.rules", "Input set") and not logInfo(“XXX.rules”, “Input set”)

Regards!

Wadu · July 4, 2021, 7:15am

Hi there,

thanks for your work!
I use your Binding for many month.
Now I have a Problem after updatig to the OH 3.1 release.

When the Rapberry starts, now the GIO’s starts with ON state.
I have defined a startup rule to set the right state, but for 5-10 secounds the gpio ist on.
This is a great problem for me.

Best regards
Walter

Wolfgang_S · July 4, 2021, 4:34pm

As far as understand the Raspi’s GPIO configuration during boot / startup all are set to input. This is to not force them to a high at the output in case a low level line is connected as it was expected to have an input or not force them to low at the output in case a high level line is connetected as it was expected to have an iput as this could destroy the output driver.
There are different types of inputs some have a pull up other a pull down resistor.
Those with the pull down resistor should be seen as a low for your connected hardware.

Which GPIOs do you have the problem with ?

Wadu · July 4, 2021, 6:12pm

I have configured this things:
Thing gpio:pigpio-remote:GPIO-pi-1 “GPIO-Pi 1” [host=“172.31.85.15”, port=8888] {

Channels:

// Heizung   

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

// Pool Pumpe

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

// Jalousieen

    Type pigpio-digital-output : GPIO-output-23 [ gpioId=23]

    Type pigpio-digital-output : GPIO-output-24 [ gpioId=24]

    Type pigpio-digital-output : GPIO-output-15 [ gpioId=15]

    Type pigpio-digital-output : GPIO-output-14 [ gpioId=14]

    Type pigpio-digital-output : GPIO-output-08 [ gpioId=08]

    Type pigpio-digital-output : GPIO-output-07 [ gpioId=07]

    Type pigpio-digital-output : GPIO-output-09 [ gpioId=09]

    Type pigpio-digital-output : GPIO-output-13 [ gpioId=13]

    Type pigpio-digital-output : GPIO-output-10 [ gpioId=10]

    Type pigpio-digital-output : GPIO-output-22 [ gpioId=22]

    Type pigpio-digital-output : GPIO-output-02 [ gpioId=02]

    Type pigpio-digital-output : GPIO-output-03 [ gpioId=03]

}
I use this item config:
//Kellerfenster

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

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

//Küche

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

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

//Alex Fenster

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

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

//Alex Tür

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

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

//WZ West

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

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

//Pool Pumpe

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

//Heizung

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

// WZ Süd

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

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

and this startup rule:
rule “System startup initialization”

when System started

then

        sendCommand(GpioOutput17, OFF)

        sendCommand(GpioOutput27, OFF)

        sendCommand(GpioOutput23, ON)

        sendCommand(GpioOutput02, ON)

        sendCommand(GpioOutput03, ON)

        sendCommand(GpioOutput07, ON)

        sendCommand(GpioOutput08, ON)

        sendCommand(GpioOutput09, ON)

        sendCommand(GpioOutput10, ON)

        sendCommand(GpioOutput13, ON)

        sendCommand(GpioOutput14, ON)

        sendCommand(GpioOutput15, ON)

        sendCommand(GpioOutput22, ON)

        sendCommand(GpioOutput23, ON)

        sendCommand(GpioOutput24, ON)

end

This configuration worked fine before I go to release 3.1
I used 3.1.0.M4 - Milestone Build.

Now I make this test:
I start openhab without this gpio thing configuration, now the gpio’s not in use.
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.

I hope you can understand my problem.
Thanks

Best regards
Walter

Junaid_Sterris · July 12, 2021, 6:09pm

HI Guys,

I recently upgrade from 2.5 to OH3 and my Gpios are fairly important to me.
I manage to get everything working after lots of rebooting the daemon and pigpio and linking and unlinking the Item but when i restart the raspberry pi the pigpio is offline and the state of the item is of course NULL. my public.conf file is saved as described above. Has anyone had the same issue or is there something else that i need to update first?

scoobydrvr · July 20, 2021, 2:47pm

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 · July 23, 2021, 9:02am

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

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 · August 5, 2021, 12:35pm

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 · August 5, 2021, 8:46pm

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 · August 6, 2021, 5:52am

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

CrazyIvan359 · August 9, 2021, 2:13pm

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.

ilo · August 13, 2021, 8:06am

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

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 …