[GPIO] New GPIO Binding for OH3

Hi,
I think that is also possible :slight_smile:

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.
:sunglasses:

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

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.

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.

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.

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

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 :slight_smile:
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 :slight_smile:

Chris,

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

Regards,
Jeremy

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

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.

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

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
}
  1. 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.

‘expire’ is a standard openHAB feature. It should work with the binding as it did in OH2 - if properly configured on the Item - all it does is generate a command that gets passed to the binding and should be indistinguishable from a UI or rules issued command.

The binding option would be duplicate effort - except that standard expire does not deal in milliseconds, and I can see there might be uses for that on a GPIO.

I wonder though if it is worth renaming it to ‘pulse’ or something, to avoid confusion with the standard feature, and better name its purpose.

Indeed, especially when automating button presses that distinguish between short and long presses.

I’m also catering to one of my use cases with the blink functionality (that name might also be dubious). I have custom GPIO interface boards where BCM18 is wired to a LED. By flashing the led I can tell that the link is up and OH is running on the far end. These are deployed on remote rPies.

I do fully agree that the changing the name to avoid confusion is best. That is easily done. I have updated the build to reflect this. Chris’ example file config would now look like:

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,pulse=2000,pulseCommand="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
}

Or optionally use the expire functionality directly on the Items.

1 Like

Thanks a lot - it is working now :slight_smile:
And rossko made me searching on GUI interface - I didn’t see “Expiration Timer” earlier.
It is working as well :slight_smile: :upside_down_face:
U’ve made my day -OH forum is amazing - i’d like to buy U a beer!
Let me know how can I do it…
Now i’m going to connect some 1wire and i2c sensors…

Hi rossko57 - indeed there is an option - I didn’t see “Expiration Timer” earlier…
I Was configuring items using files - GUI I used only to switch ON/OFF :rofl:

Excellent, Glad you got things sorted out. If you have any more GPIO issues, I am watching this thread.

Hello @jeremyrumpf,

I just installed openHAB 3.3. I used your binding snapshot before; however I cannot find the additional settings now in openHAB 3.3. Did your snapshot not find its way in the official release?

Thanks again for your support!

Florian,

You are correct, i have not submitted a pull request for it. I was hoping for some more feedback on features and stability before submission. But myself, and a few others on the forum have been using it successfully for a few months now. The consensus is that it is much more stable and useful than it’s original 3.X implementation.

I will rebase it against 3.4-SNAPSHOT and submit.

Regards,
Jeremy

2 Likes

Hi, I am running Openhab 3.4.0 on a Raspberry Pi4. I have configured a separate Raspberry pi3 and put pigpio on it so I can control the gpio pins from Openhab. On the remote Raspberry I have attached a 4 port relay module.

I originally used the standard GPIO binding. I created my thing, an output channel and a switch to control it. Great, it switched the relay on/off. Then when powering down the remote Raspberry and then powering up the connection did not re-establish. I disabled & re-enabled the thing and the remote relay then goes nuts and turns on/off continuously.

I saw this post with your GPIO binding which gives options for reconnection. I uninstalled the old binding & installed this one. This now automatically reconnects if the remote Raspberry is disconnected and reconnected but I still have the same issue with the relay turning on/off continuously.

If I start the remote Raspberry with the thing on Openhab disabled, the relays are fine. It seems to be as soon as the thing connects/comes online and changes the GPIO pins to OUTPUT that the relay then has issues. Has anyone else experienced this or knows how to overcome this. Any help would be appreciated.