[GPIO] New GPIO Binding for OH3

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.

Hello, I am pretty new with openHAB, but I imediately have a little issue and while google with anything I search relating with this issue sends me here and i don’t find it here, i just have to ask.

The issue is as follows. I have a fresh installation of openHABian on a RasPi 3B.
On Top a 4Ch relay output card. Pigpio is configured and running on it. Remote GPIO also works. The four pins (gpio 4,6,22 and 26 are set to output and get initialized and set to output during boot to prevent flicker… Works also fine.
I instalked the binding and configured it to ::1 and 127.0.0.1 (both seems to work fine to connect localhost instead of a remote device).
I could create the thing, and the four channels, could add them to the model and the overwiew and i can switch them on and off with the togglesci added to the Overview page.
And yes they turn on and off, but if those outputs on the pi turn on for other reasons, like they get switched by a pigs command, or by the gpio fan feature or whatever, they don’t change their state and get inconsistent to the real state of the output.

How to fix that… (am using UI and not scripts for configuring)

Hi,
I am moving from OH 2 to version 4. It shocked me when I first read about depreciation of previous binding. First of all, I would like to express my appreciation to the author for this binding.

I am using rpi GPIOs to control some cheap relays. It works without any issue, but I would like to understand purpose of PULL UP and PULL DOWN resistors. I read about them, but since I am not familiar with electronics it is not totally clear what is the purpose of those.
My relays are normally OFF, but their status led light lit dimly even if the status of the relay is switched OFF. I guess because there is some current on the GPIO pin. Can this issue be solved by using PULL UP/DOWN resistor? Is this a valid usage of these options?
Thank you,

Sorry, I saw that right now only… I try to explain it, if you have further questions on it write me a PM…

I try to do it general for all kind of electronics with GPIO Style input pins, (which means not only ras pi’s, but also adruionos (AT Megas), STMs , nearly all kinds of ARM Cortex CPUs and even Intel x86 have those pins, but regularly the operationg system does not show them to the userspace, it’s also in principle same for all kind TTl logic chips).

First of all ICs may have integrated pullup / pulldown resistors or not. Some may have configurable integrated, some may have not configurable ones. On some ICs pullup or pulldown has to be attached externally, on some chips u can use internal or external pullup or pulldown resistors. For RaspberryPi it has configurable internal pullup and pulldown, and you can also attach external ones… It gives u all potential options… Generally electronics designers tend to use external pullup or pulldown resistors for two reasons… First of all u can see which type of pull is done on that pin, Second of all there is a small amount of power that is converted to heat inside the pull resistor during operation. With a external one, you can fit the consumption to the application and can get rid of the heat easily. With the internal resistors u have what u have and the heat of it gets added to the heatload of the chip… But on Raspi I normally use the internal ones for ease of use and cause the PI documentation is a bit “short” on the exact electric characteristics of the input pin, so u have to relay on that the chip designers did do their work properly and u can make advantage of that u just can configure which kind u want…

The general idea of a pullup or pulldown is, to make sure, that if the inputcricuit the pin is connected to is “open” or not connected to at all the pin has a defined electric state of “high” or “low”.

The internal resistors of the Pi have a value of about 60 to 70 kOhms (it’s not documented that well), Typical cricuits with external pulls use 10 kOhms for the external pull resistors, but any value between 100 Ohms and 500kOhms can be found depending on the application.

The idea of Pullup / pulldown is to make sure that if the application cricuit is “open” or not connected at all, the input pin gets a defined voltage. In case of PULLUP it’s +VCC (+3.3V on a Raspi) or GND (0V on Raspi) in case of PULLDOWN.

The PULL Resistor is connected betwenn +VCC and Pin for PULLUP or Pin and GND for PULLDOWN.

PULLUP: (VCC)—[60kOhm]-----(GPIOX)-------[/](appl switch)—(GND)
PULLDOWN: (VCC)—[/](appl switch)—(GPIOX)----[60kOhm]—(GND)

So on PULLUP, if switch is in open state, GPIO will see 3.3V / high / 1 when switch is open, and will see GND / low / 0 when switch is closed.

On PULLDOWN its vice versa. Open Switch = GND / low / 0, closed switch = VCC /high / 1.

For this to work, the resistance of the application has to be much lower than the PULL resistor. Otherwise you may get “undefined level” on the closed switch.

[WARNING, ONLY PLAY WITH IT ONCE YOU UNDERSTOOD IT]
with external pull resistors you also could adjust the voltage of your application, like reducing the signal of a 5V application to the needs of 3.3V logic of the Pi. If u e.g. do internal pulldown and add a resistor with half the value of the internal pulldown between the application and the Pin u can reduce 5V to 3.3V for the high signal of the input pin. (1/3 of the voltage will be lost in the resistor of the application and 2/3 will be lost in the internal resistor, making the GPIO see allowed 3,3V for high). But u really need to understand this, as it is not the full truth, because the GPIO itself also is a resistance and reduces the total resistance “seen” by the application. The resistance of the input also may not be stable, if several GPIOs are set or at high value. So really be sure what u do, start with a too big resistor and meassure the resulting voltage. Otherwise the GPIO or the processor as a whole may be destroyed. This way e.g. thermistors on analog input pins are evaluated.
[END OF WARNING]

To get consistency for your programming many libraries and also the GPIO Binding of openhab allows to invert the logic of a pin… Means that a pin that sees high reports 0, as in pullup mode the open or not connected application will report high / 1 naturally.

You should definitely do PULLUP or PULLDOWN on a digital input pin for stable operation. Which one depends on your exact application… if the application is just a simple switch, that closes the cricuit when pressed, it doesn’t matter that much, which one you do…
For the logic it’s more logical to do PULLDOWN for that, as the PIN will see 0 / GND if the switch is not pressed (or not present at all) and will see 1 if the switch is pressed.The disadvantage of Pulldown is, that it will drain a little current from the GPIO as long as the switch is not pressed. So if it is a switch, that mainly is not pressed and only get’s pressed for a short time, one can consider to use it with PULLUP and invert the logic…

And NO also if some claim this or that, there is no better way between PULLUP and PULLDOWN, it just depends on the application which one is better!!

And YES there is an big advantage of external PULLUP and PULLDOWN, as soon as you have a proper documentation of the characteristics of the IC. But with the raspberry Pi there is a lack of that information in the official documentation, so I suggest to use the internal ones, unless you have better information by meassuring yourself or reading the documentation of the processor chip used…

I hope u got the idea…

And now about the more practical part of your question…
I asume u are using relays on the outputs… With outputs in general there is no (at least internal) pullup or pulldown. And yes, as read above, as those are GPIOs, (configurable as input or output), in output mode, they drain a little voltage even if their state is off, this may already make your indicator led on the “cheap” relay light up a bit, even when off. this can be solved by adding a small resistor in line with the input of the relay, to limit the power drain current to below the trigger point of the indicator light… Normally your relays should have a proper resistor build in.
Then there are two ways to get it done. Limit the output cureent of the GPIO by adding a Resistor in line with the relay input… (this is not a PULLUP or PULLDOWN resistor, this would be considered a current limiter). You cannot destroy anything by that, but your relay may not switch on if resistor is too big, or light still doesn’t turn of, if your resistor is too small.
[WARNING AGAIN]
U could pulldown the relay + input by a parallel pulldown resistor of the right size. A too low resistor will may end up in GPIO destroyed when swithed on, cause it is more or less a short cricuit then. A too big parallel pulldown-resistor would work well, but may not supress the light…
Pullup of high side also is possible, as well as doing pullup or pulldown on the - side of the relay… I will not explain that options, even one of them may even be better in your case, but it depends on exact specifications of your relay, the gpio’s of your PI and the aplication in general, what is best. Risk of GPIO destruction is given with any of the options. The limit the power option is safe, it just can make the relay not trigger at all.
[WARNING OFF]