OpenHab 3.1 and remote GPIO on the same Raspberry Pi

Hello,

I am trying to upgrade from Openhab 2 to Openhab 3.1. It almost works but unfortunatelly, I am using many GPIO ports on my Openhab Raspberry pi 3B and, after 10 hours trying, I still cannot make them work.

I think I have installed everything that is needed: my pigpiod dameon is running, I can change my GPIO pin status by shell commands (pigs w 9 1 for instance), the GPIO binding is installed and online, I have set my items and things according to the documentation but impossible to initiate any action from OH.

I am just wondering if the configuration I am trying is feasible and if someone has managed to make GPIO work with the GPIO server being the same as the OH server.

If so, what host parameter are you using? I have tried localhost, 127.0.0.1, the actual LAN IP, ::1 that I saw on one forum but none of them worked.

Thank you for your feedback.

Kind regards

Olivier

You could try MQTTany instead. It can be used on the same Pi and/or remote ones and communicates over MQTT with OH.

Please share your Thing / Items definitions.
According to the docs " Note: If you are running Pigpio on same host as openHAB, then set host to ::1"
should be ok.
What OS do you use ? It was just an upgrade of OH from 2 to 3.1 ? Did you do a new installation of the OS ? Do you run openhabian ? Any entries in the log files that may give a hint about what is wrong ? Any entry in journal that may give a hint ?

Thank you, I will give it a try if I cannot manage to have GPIO work for setting and reading my Raspberry pins.

King regards

Olivier

Hi Wolfgang,

Thanks for your reply. I am using a fresh install of Raspbian on the RPi 3B+ with OpenHab 3.1 installed through apt-get

My thing is

Thing gpio:pigpio-remote:gpio-server "GPIO server" [host="::1", port=8888] {
    Channels:
        Type pigpio-digital-output : portail [ gpioId=9]
}

and Item file
Switch PM_GF_Garage "Portail" <sliding> (gGF) {channel="gpio:pigpio-remote:gpio-server:portail"}

Unfortunately, I have no error or warning in the log or event files. OH shows that the switch is switching from ON to OFF or vice versa but nothing happens on the pins of the GPIO. Same for reading pins: I push the buttons and close the physical switches but nothing gets triggered.

I will re-install once again with pigpiod, the binding… and tell you the result. I might have missed something during the install.

Kind regards

Olivier

I

Hi everyone,

After a full re-install of Raspbian, Openhab, pigpio… on my RPi 3B+ I have managed to have the GPIO output working. The working configuration for the host is indeed “::1”

I have tried to have make the inputs that work with OH2 work as well with OH 3.1 but once again I am stuck with possible configuration issues:

My config is the following:

Thing gpio:pigpio-remote:gpio-server "GPIO server" [host="::1", port=8888] {
    Channels:
        Type pigpio-digital-output : portail      [ gpioId=9 ]
        Type pigpio-digital-input : sonnette      [ gpioId=17, debouncingTime=1000 ]
        Type pigpio-digital-input : porte_entree  [ gpioId=4, debouncingTime=1000 ]
        Type pigpio-digital-input : porte_garage  [ gpioId=27]
        Type pigpio-digital-input : pompe_chaleur [ gpioId=5, debouncingTime=1000 ]
}
Contact         PB_GF_Garage "Porte garage" <garagedoor>     (GF_Garage) {channel="gpio:pigpio-remote:gpio-server:porte_garage" }
Contact         PB_GF_Exterieur "Sonnette" <light>     { channel="gpio:pigpio-remote:gpio-server:sonnette" }
Contact         PB_GF_Entree "Porte d'entrée" <frontdoor>     (gGF) { channel="gpio:pigpio-remote:gpio-server:porte_entree" }
Contact         CP_GF_Buanderie "Capteur Pompe à Chaleur" { channel="gpio:pigpio-remote:gpio-server:pompe_chaleur" }

Apparently the GPIO modes are correctly set after boot since I get the following upton “raspi-gpio get”:

BANK0 (GPIO 0 to 27):
GPIO 4: level=1 fsel=0 func=INPUT
GPIO 5: level=0 fsel=0 func=INPUT
GPIO 9: level=0 fsel=1 func=OUTPUT
GPIO 17: level=0 fsel=0 func=INPUT
GPIO 27: level=0 fsel=0 func=INPUT

the command “pigs r 27” works (return 0 or 1 depending on the sensor of my garage_door but “pigs r 4” returns always 1 whatever the status of the physical sensor status so, at least for GPIO 27, the problem seems to be between pigpio and OH not exchanging the status.

I have tried many changes on the Pi like for instance adding “gpio=4,5,17,27=ip” in my /boot/config.txt [All] section but it did not change anything. Still nothing happening in OH when the sensors change status. No error or warning messages either.

If you have any idea to fix my problem, I will try them either today or next WE.

Kind regards

Olivier

If this can help, here is my debug log when OH3.1 starts:

2021-10-03 14:22:43.962 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory] : BundleComponentActivator : ComponentHolder created.
2021-10-03 14:22:44.015 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory] : Component created: DS=DS13, implementation=org.openhab.binding.gpio.internal.GPIOHandlerFactory, immediate=false, default-enabled=true, factory=null, configuration-policy=optional, activate=activate, deactivate=deactivate, modified=null configuration-pid=[binding.gpio]
2021-10-03 14:22:44.090 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory] : Component Services: scope=singleton, services=[org.openhab.core.thing.binding.ThingHandlerFactory]
2021-10-03 14:22:44.130 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory] : Component Properties: {}
2021-10-03 14:22:44.150 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory] : Querying state disabled
2021-10-03 14:22:44.170 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory] : Querying state disabled
2021-10-03 14:22:44.181 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory] : Component can not be activated since it is in state disabled
2021-10-03 14:22:44.258 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory] : Querying state disabled
2021-10-03 14:22:44.316 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Updating target filters
2021-10-03 14:22:44.340 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Changed state from disabled to unsatisfiedReference
2021-10-03 14:22:44.360 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Component enabled
2021-10-03 14:22:44.380 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : ActivateInternal
2021-10-03 14:22:44.411 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Querying state unsatisfiedReference
2021-10-03 14:22:44.440 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Querying state unsatisfiedReference
2021-10-03 14:22:44.467 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Activating component from state unsatisfiedReference
2021-10-03 14:22:44.500 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Querying state unsatisfiedReference
2021-10-03 14:22:44.520 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Querying state unsatisfiedReference
2021-10-03 14:22:44.586 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Changed state from unsatisfiedReference to satisfied
2021-10-03 14:22:44.593 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : registration change queue [registered]
2021-10-03 14:22:44.668 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Checking constructor public org.openhab.binding.gpio.internal.GPIOHandlerFactory()
2021-10-03 14:22:44.720 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Found constructor with 0 arguments : public org.openhab.binding.gpio.internal.GPIOHandlerFactory()
2021-10-03 14:22:44.733 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : This thread collected dependencies
2021-10-03 14:22:44.787 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : getService (single component manager) dependencies collected.
2021-10-03 14:22:44.820 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Querying state satisfied
2021-10-03 14:22:44.860 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Querying state satisfied
2021-10-03 14:22:44.929 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : getting activate: activate
2021-10-03 14:22:45.017 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Locating method activate in class org.openhab.binding.gpio.internal.GPIOHandlerFactory
2021-10-03 14:22:45.041 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Declared Method org.openhab.binding.gpio.internal.GPIOHandlerFactory.activate([interface org.osgi.service.component.ComponentContext]) not found
2021-10-03 14:22:45.081 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Locating method activate in class org.openhab.core.thing.binding.BaseThingHandlerFactory
2021-10-03 14:22:45.093 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Found activate method: protected void org.openhab.core.thing.binding.BaseThingHandlerFactory.activate(org.osgi.service.component.ComponentContext)
2021-10-03 14:22:45.138 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : invoking activate: activate: parameters [org.apache.felix.scr.impl.manager.ComponentContextImpl]
2021-10-03 14:22:45.178 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : invoked activate: activate
2021-10-03 14:22:45.200 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Set implementation object for component
2021-10-03 14:22:45.248 [DEBUG] [ing.gpio.internal.GPIOHandlerFactory] - bundle org.openhab.binding.gpio:3.1.0 (267)[org.openhab.binding.gpio.internal.GPIOHandlerFactory(305)] : Changed state from satisfied to active

Reading this

I am a bit confused.
Does it mean that no input status is updated in OH neither for GPIO 27 nor for GPIO 4 ?

Hi @Wolfgang_S,

Sorry if my explanations were not clear:
Indeed I do not have any status change in OH neither for GPIO27 nor for GPIO4.
At least for GPIO27, pigs command picks the status change but it does not reach OH.

Kind regards

Hi, i have the same problema, do you have find solution?

Hi @ferraramax,

Unfortunately not. I am still stuck with Openhab2 because GPIO plays an important role in my home automation setup.

Hopefully, someone will find out why it is not working on certain configurations.

Kind regards

Olivier

I had the exact same problem since I updated to OH 3.1 and the old GPIO binding did not work anymore.

Did you define the linked Item for your input as “Switch” and not as “Contact” as stated in the documentation? This was one of the changes I had to make.

Did you also check that reading the state on the command line with
gpio -g read <GPIO#>
correctly reflects the state when the input changes?

In my case, the gpio command works food, and it update when status of gpio change, but binding not work

Thank you very much @Pete2,

Since I upgraded my OH2, I kept the same item definition for my contact since I did not noticed they were no longer expected and OH3 did not complain about it.

I will perform additionnal testing but it did fix my problem on a unit test.

Thank you again because I was stuck with this problem for more than 3 months now.

Kind regards

Olivier

1 Like

Hi olivier,
I found same troubles after upgradind OH2>OH3 as you did. It is unbelievable how and why binding was changed so much that needs extra actions(why installation of binding through UI is not enough?!) and it still doesnt work (no refresh). It was much easier with gpio1 binding …

looking forward to read your progress, personally after 5hours of trying to fix have to give up - gpio control is to important for my home.

Hi Kristoph,

the OH2 GPIO binding stopped working in OH3. I’m sure this was a pretty important design decision. As I started to get the binding working with OH2, I made the fatal mistake of migrating to OH3.

So we now have a completely new GPIO binding that has its own new problems. But if you read in this forum, GPIOs seem not to be something that should be used with OH or the maintainers are even interested in. Which of course is totally fair. OH already supports a large bunch of stuff.

OH3 made it even worse as the new binding now needs an additional service (pigpio library) to be running that samples the pins 100,000 times each second by default. I reduced it to 20,000 times but it still is a massive waste of CPU cycles:

The OH Java runtime doesn’t even come close. Having a worse CPU usage than Java is quite an achievement! :laughing:
The author of pigpiod statet that if you do not need such a high sample rate, then pigpiod is not the right choice. I agree.

Hi Pete,
I understand the authors of the binding, they do not want to change and develop it because the interest among people is low and, as you have noticed, a lot of supported devices.

However, I do not see the point in 10 sensors(states) collected in one place next to the raspberry, instead of connecting them directly to Pi GPIO, install a middleman in the form of D1mini+expander and send these states by MQTT to the raspberry which is 10cm away.

Do I only consider this insane?

2 Likes

Hi Kristoph,

no that is not insane. I also think that when you can connect sensors directly to the hardware where OH is hosted, this should be the preferred way. It is just a question of the software implementation. Using a ‘low level’ GPIO approach does not seem to be the ‘OH way’ to do it.

But since OH has a very powerful scripting engine, almost anything can be solved in software. What would be the ideal way to interface GPIOs in OH?

I was thinking about writing my own GPIO binding that has a sample rate of maybe 10 times per second and no dependency to an external service, but mantaining OH turned out to be so extremely time consuming that I don’t want to get into creating my own binding right now.

And of course I think that Nils did an excellent job of creating a great GPIO binding for OH3, but with these kind of things it might be impossible to satisfy the needs of all OH users.

Hi @stonke

After having spent hours on testing many configurations, I thought it worked (and it did for a couple of days) but now for some sensors, OH items do no longer get updated (whereas the pigs command return the correct value of the pins). So even if you manage to have it working it is not stable in time.

After having read the comment from @Pete2 , I changed the sample rate to 10microseconds to lower the CPU consumption from 8 to 5% but I do not need such sampling rate so I will search for a way to configure pigpiod differently is there is a way.

I wish there was a similar gpio binding as it did exist with OH1 and 2 because with OH3, picking the events of my home automation has become like lottery.

Kind regards

OIivier

1 Like

Hi everyone,

If this may help, I have found a way to make GPIO work again after it start to no longer detect pin status change:
restart the service by typing
ssh openhab@localhost -p8101 ‘bundle:restart org.openhab.binding.gpio’
default password is habopen

I hope this helps.

Have anyone found a solution to reduce pigpiod to a lower than 10microseconds sampling rate to lower CPU consumption?

Thank you