Hi Olivier, is that modification very complicated to apply?
Hi Kristoph,
I downloaded the code, made some modifications in 2 c files (pigpio.c and pigpiod.c - see below, I had to rename them into .txt to upload them), recompiled and reinstalled the pigpiod executable. The command to recompile/reinstall is: sudo make install in the main directory.
pigpio.c.txt (334.4 KB)
pigpiod.c.txt (10.6 KB)
Hi, Oliver I`ve tried by creating folder named “pigpio” into etc/openhab/ but after command sudo make install received:
openhabian@openhabian:/etc/openhab/pigpio $ sudo make install
[sudo] password for openhabian:
make: *** No rule to make target ‘install’. Stop.
What went wrong? Not a linux person at all 
Hi Kristoph,
In addition to creating the pigpio directory, you need to download the pigpio project (https://github.com/joan2937/pigpio), replace the 2 files and then only run the build command : sudo make install.
This modification only reduce a bit the CPU consumption but does not solve the stability/reliability of pigpiod that is definitely not fit for this purpose.
It’s too bad that openhab 3 is no longer able to handle GPIO natively because I am sure it would remove the burden of many user.
As a workaround, I installed MQTTany (MQTTany — MQTTany v0.14.0 documentation) which I have working quite stable for a couple of weeks. I managed to have my 5 inputs configured and still have some trouble for one output.
You need to have a MQTT broker installed as well (either mosquitto or the OH integrated one).
This is probably a better way to go, especially if you are not familiar with linux
Kind regards
Olivier
Hi Olivier,
That MQTTany solution sounds interesting, would love to test it as you say that’s stable. Did you managed output issue mentioned above?
If you are using GPIO, either local or remote, you are better off trying the updated version of the GPIO binding here. It fixes most of the troubles that everyone is having.
If you need help installing or configuring it, let me know.
Sounds great Jeremy. Should I start and follow instructions from
?
Yes. If you have already added the binding by using the web interface, you will have to uninstall it from there first. Then download the file org.openhab.binding.gpio-3.3.0-SNAPSHOT.jar and place it in the /usr/share/openhab/addons directory on the host running OH (I’m not sure what the windows path is). Be sure to restart OH. You should now be able to add a Thing and see the GPIO Binding listed. Once the Thing has been configured and is ONLINE, go into the Thing and configure a Channel for each GPIO pin on the raspi that you wish to use.
Let me know if you have success.
Jeremy please review:
I have uninstalled binding by webUI,
Then downloaded and moved .jar file to location you mentioned,
Restarted OH service and indeed could see Pigpio Remote Thing possible to add manually,
So should I install, enable and start through SSH “pigpiod” now or before copying .jar file?
Hi Kristoph,
It now works also for the output. It is not as stable as the input but this might be linked to the rest of my system.
I was not aware of this new GPIO binding so I might give it a try.
Kind regards
Olivier
You are on the right path, enable and start pigpiod on the raspi. Make sure to configure the IP address of the raspi to the Pigpio Remote Thing or leave it as 127.0.0.1 if they are both on running on the same raspi. From here, you can create input or output channels on the Thing that correspond to the GPIO pins on the raspi. Link those channels to an OH switch item, you should be able to control/monitor your GPIO pins now and trigger script events on them.
You can enable the pigpiod at anytime as long as the Thing is configured and enabled in OH. The Thing status should change to ONLINE once it connects with pigpiod.
Oliver,
I have done some work on the existing GPIO binding in OH3 to make it more usable and stable. I have not submitted it to be official yet as I am hoping to gather more feedback on it. If you try it out, feel free to ask any questions. If you think of a feature that needs added (and can help test), please let me know.
Regards,
Jeremy
hi Jeremy,
It looks like the program is working. By connecting the pins on the raspberry, I was able to see what their condition in OH3 looks like. But possibly something changed or I do not understand yet how to configure the operation exactly because .things
Type pigpio-digital-input : i-22-door [ gpioId=22,debouncingTime=250,pullupdown="DOWN" ]
and .items
Switch SampleInput22 {channel="gpio:pigpio-remote:raspio:i-22-door"}
regardless of whether I choose pullupdown = UP / DOWN / OFF with or without invert = true, I have it shown as switch ON in OH3. Should I restart your program after changes to .things? The only change to see now is from ON to OPEN when changed Switch to Contact type of item.
In OH2 I was set up
Contact DoorSensor "Door [% s]" <door> (LockG, WinLockG) {gpio = "pin: 22 debounce: 250 activelow: yes"}
What with the reed switch connected between 3.3V and pin 22, in the absence of voltage (when the door is open) on pin 22, I had the OPEN status, while at 3.3V given on pin 22, the CLOSED status. How do I get a similar (can be ON for CLOSED, OFF for OPEN) behavior now?
By the way, the question is how do you implement a short switching on of the relay in order to send an impulse? In OH2, it was enough to enter:
Switch channel4 "Gate" {gpio = "pin: 21 activelow: yes initialValue: high", expire = "1s, command = OFF"}
However, the binding EXPIRE does not work in OH3 and I do not know how to approach it?
Kristoph,
Your Thing configuration looks correct. I would certainly restart OH after editing the Thing configuration files(s). For me, OH does work to reload small changes to Things or Items, but for large changes I always do a restart.
One thing to do, if you haven’t already. Enable debug output on the binding.
# ssh to the Karaf console
ssh -p 8101 openhab@localhost
Password authentication
Password: habopen
_ _ _ ____
___ ___ ___ ___ | | | | / \ | __ )
/ _ \ / _ \ / _ \ / _ \ | |_| | / _ \ | _ \
| (_) | (_) | __/| | | || _ | / ___ \ | |_) )
\___/| __/ \___/|_| |_||_| |_|/_/ \_\|____/
|_| 3.2.0 - Release Build
Use '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
To exit, use '<ctrl-d>' or 'logout'.
# Set the binding output to DEBUG
openhab> log:set DEBUG org.openhab.binding.gpio
openhab> logout
You can then follow the log output with something like:
tail -f /var/log/openhab/openhab.log | grep -i gpio
You should also see event entries in /var/log/openhab/events.log. Something like:
2022-04-26 13:42:30.264 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RaspPi_GPI6' changed from NULL to OFF
2022-04-26 13:42:30.264 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RaspPi_GPI5' changed from NULL to OFF
2022-04-26 13:42:44.423 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'gpio:pigpio-remote:shoppi' changed from UNINITIALIZED to INITIALIZING
2022-04-26 13:42:45.546 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'gpio:pigpio-remote:shoppi' changed from INITIALIZING to ONLINE
For reference, here is my test Thing configuration. The expire functionality on the output would be the GPOs with the pulse and pulseCommand attributes.
Thing gpio:pigpio-remote:shoppi "RaspPi GPIO" [ host="192.168.164.5", port=8888,
heartBeatInterval=10000,
inputConnectAction="REFRESH",
inputDisconnectAction="NOTHING",
inputReconnectAction="REFRESH",
outputConnectAction="REFRESH",
outputDisconnectAction="SETUNDEF",
outputReconnectAction="REFRESH" ] {
Channels:
Type pigpio-digital-output : BCM18 [ gpioId=18,invert=false,pulse=3000,pulseCommand="BLINK" ]
Type pigpio-digital-output : GPO4 [ gpioId=4, invert=true,pulse=5000,pulseCommand="OFF" ]
Type pigpio-digital-output : GPO17 [ gpioId=17,invert=true,pulse=500,pulseCommand="OFF" ]
Type pigpio-digital-output : GPO27 [ gpioId=27,invert=false ]
Type pigpio-digital-output : GPO22 [ gpioId=22,invert=false ]
Type pigpio-digital-input : GPI23 [ gpioId=23,debouncingTime=50,pullupdown="UP",invert=true ]
Type pigpio-digital-input : GPI24 [ gpioId=24,debouncingTime=50,pullupdown="UP",invert=true ]
Type pigpio-digital-input : GPI25 [ gpioId=25,debouncingTime=50,pullupdown="UP",invert=true ]
Type pigpio-digital-input : GPI12 [ gpioId=12,debouncingTime=50,pullupdown="UP",invert=true ]
Type pigpio-digital-input : GPI16 [ gpioId=16,debouncingTime=50,pullupdown="UP",invert=true ]
Type pigpio-digital-input : GPI20 [ gpioId=20,debouncingTime=50,pullupdown="UP",invert=true ]
Type pigpio-digital-input : GPI21 [ gpioId=21,debouncingTime=50,pullupdown="UP",invert=true ]
Type pigpio-digital-input : GPI5 [ gpioId=5, debouncingTime=50,pullupdown="UP",invert=true ]
Type pigpio-digital-input : GPI6 [ gpioId=6, debouncingTime=50,pullupdown="UP",invert=true ]
Type pigpio-digital-input : GPI13 [ gpioId=13,debouncingTime=50,pullupdown="UP",invert=true ]
Type pigpio-digital-input : GPI26 [ gpioId=26,debouncingTime=50,pullupdown="UP",invert=true ]
}
Jeremy, after 3months of use I can confirm your binding to be stable and reliable as it should be - great job!
During this time I changed the cables and positions for the raspberry three times, which involved the use of the “systemctl poweroff” command. After re-energizing, the turned to a position where they are not very welcome if not asked to. The relay board is controlled in such a way that it raises the relay when the low state appears on the given input. Is it possible within binding to configure the output that after startup raspberry output will immediately appears high state?
There are a few things in play that control the GPIO pins on startup. One is the rasperry pi itself, pigpiod, and finally OpenHab.
Right now, your GPIO pins are probably being configured by the OpenHab binding (thru pigpiod). This would result in a significant delay, as it takes OpenHab a lot of time to start after power on. You can configure the default state of the pins at power on in the config.txt file. This would change the state of the pins much faster than the binding in OpenHab could.
Second, I would still configure the binding to drive the pins high as a secondary fall back. This is easily done if you are using configuration files. The option to change is the “outputConnectAction” to ALLON. See the example below.
Thing gpio:pigpio-remote:shoppi "RaspPi GPIO" [ host="192.168.164.5", port=8888,
heartBeatInterval=10000,
inputConnectAction="REFRESH",
inputDisconnectAction="NOTHING",
inputReconnectAction="REFRESH",
outputConnectAction="ALLON",
outputDisconnectAction="SETUNDEF",
outputReconnectAction="REFRESH" ] {
Channels:
The above assumes you are not using inverted outputs in the configuration (ACTIVE LOW). The ALLON will take that into account and drive your outputs low. If you are using
invert=true, then simply replace ALLON with ALLOFF.
Regards,
Jeremy
1 Like
After reading the raspberry pi docs for config.txt. This statement:
Note also that there is a delay of a few seconds between power being applied and the changes taking effect — longer if booting over the network or from a USB mass storage device.
So there may have to be a hardware interlock created to keep your relays from raising until the raspberry boot is complete and OpenHab is fully running. One way to do this would be to take all of the grounds from the inputs on your relay board and attach them though a separate active high relay (all the grounds on a raspi are internally connected together). This way your control relays would never raise until the separate “master arm” relay is raised. You would then have a post startup trigger in OpenHab raise the master arm relay enabling the control board. By this time, all of the gpio outputs should be configured and stable.
But this solution would depend on having a free relay, and that relay would have to be an active high relay. From your previous comment, it appears your relay board has active low inputs. I’m not sure if that is configurable on your board.
Regards,
Jeremy
1 Like
Hi jeremyrumpf,
It has been new OH4 released last week. Do you think your customized addon would work on OH4.0.1 same like OH3?
Would you upgrade your OH soon ? I am willing to test that again 
I tried to build against 4.0.2-SNAPSHOT, but it looks like the dependencies are failing at the moment. Standby.