[SOLVED] GPIO-Binding seems to stop working after certain time


I use a reed-connector (ELV Energy-Sensor Gas 2 für Wärmezähler, ES-GAS-2 | Haustechnik | ELV Elektronik) to count my gas usage. It is connected to my Raspbery Pi 4B via a GPIO pin. I installed pigpiod and the GPIO-binding; via a rule I can count the gas usage. Everything works fine.

However, after a day or two the GPIO-binding stops counting. I can easily check this, when I manually hold a magnet to the reed contact. Nothing happens. However, if I check it directly on the console via pigs (pigs r 22) it works. After a reboot, the binding starts working again.
Any idea what I could do? Is the binding reliable for counters?

I use openHAB 3.2 with openHABian.

Thanks for your help!

The binding itself does not count, does it ?

Is there any error in the openhab.log file.
Do the events appear resp. stop to appear in the events.log file ?
Did you try to increase the logging level of the GPIO binding ?

No. I did not put that correctly. I have a rule which executes the following code, when the GPIO pin switches from OFF to ON:

Gas = itemRegistry.getItem('Gasverbrauch').getState();
events.postUpdate('Gasverbrauch', (Gas + 0.01));
logger.info('Gaszähler: Neue Umdrehung');

So far, I did not see an error. I switched the log level now to TRACE. Is there a possibility to get a separate logfile just for the binding?

Thanks for your help!

When it seems there are no updates anymore. I general it means a thread pool is blocked. Since this seems to be related to rules here, it can be the rule thread pool that is blocked for some reason. It can be some rules are blocking, and this will cause all other rules to also block. To get the thread info you can issue the following command on the Console :

threads --monitors --locks

This will give you a list of threads and hopefully gives you an insight in what threads are blocked and can get an idea of where too look.

Yes, that is possible. See Logging | openHAB . It refers to further documentation.

An example can be found in this thread: Redirect binding logs to file

Thanks for the hint (however, I am bit overstrained by the result). But can the rule really be the problem? The GPIO-PIN-channel does not receive ON signals any more whereas I can verify that the raspi receives the signals. Could there be a problem in the connection between the binding and the pigpio-service?

Your command gave me the following result for my rule. Maybe I check it again when it stopped working:

"OH-rule-Gaszaehlung-1" Id=29468 in WAITING on lock=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@281b10
    at java.base@11.0.14/jdk.internal.misc.Unsafe.park(Native Method)
    at java.base@11.0.14/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
    at java.base@11.0.14/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
    at java.base@11.0.14/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1170)
    at java.base@11.0.14/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)
    at java.base@11.0.14/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
    at java.base@11.0.14/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
    at java.base@11.0.14/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base@11.0.14/java.lang.Thread.run(Thread.java:829)

Yes run this command when it stops working. If there are blocking threads it will show threads as blocking.
It can be the binding. I expect if it’s the binding we’ll see the stack trace pointing to the binding and this should give an indication on what it blocks on and where to start looking.

A few things that this could be:

  1. The current gpio binding in the OpenHab distribution does not handle disconnects to the raspi pigpiod service. If a disconnect occurs it basically stops working cold. This has probably been the largest frustration with the current version of the binding. You may see a single log message that says:
logger.warn("Unknown pigpio exception", e);
  1. If you suspect a thread is hanging, or if you can get a stack trace that points to such. A culprit may be that the gpio binding schedules a future to handle input debounce. I’m not sure how fast the pulses come in for your application, but it is possible that this could be conflicting with something if the frequency is fast enough:
jPigpio.gpioSetAlertFunc(gpio.getPin(), (gpio, level, tick) -> {
        lastChanged = new Date();
        Date thisChange = new Date();
        scheduler.schedule(() -> afterDebounce(thisChange), configuration.debouncingTime, TimeUnit.MILLISECONDS);

Is your OpenHab instance also running on the raspi alongside the pigpiod service?

1 Like

Thank you all for your help and ideas!

On a quick look I did not find a similar log entry. Maybe I have to wait, until the binding “hangs” again.
Pigpiod and openHAB are running on the same machine.
Between pulses there are at least 10 sec, so that should not be a problem.

I have seen (via some googling) that you have published a new version of the binding ([GPIO] New GPIO Binding for OH3 - #81 by jeremyrumpf). Shall I try this version?

I would suggest trying that new version. It should be more stable in the long run. You have to uninstall the existing binding, delete the Thing, then drop the org.openhab.binding.gpio-3.3.0-SNAPSHOT.jar into /usr/share/openhab/addons. Restart OpenHab. Then recreate the binding instance, Thing, and re-link the Thing channel to your Item. You will probably want to set the heartbeat interval to around 5000ms (1/2 of your minimum pulse frequency).

Another recommendation. Lower the sample interval for pigpiod to reduce CPU usage on the raspi. Since your pulse frequency is so low, pigpiod may be burning excess CPU. To reduce this:

# Edit the pigpiod startup unit file
vi /etc/systemd/system/pigpiod.service.d/public.conf

# Add the -s 10 argument to ExecStart
ExecStart=/usr/bin/pigpiod -s 10

# Reload the systemd unit files
systemctl daemon-reload 

# Restart pigpiod

Let me know if you have success!

1 Like

@jeremyrumpf Thank you for your help!

I installed the binding and configured everything according to your recommendations. I will check it during the next days.

There was, however, an error message when I changed the heartbeat interval and the binding stopped:

2022-04-09 10:03:45.220 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio : ctor
2022-04-09 10:03:45.242 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio channels initialized
2022-04-09 10:03:45.243 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio binding initialized
2022-04-09 10:03:45.245 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio connection poll : connecting
2022-04-09 10:03:45.306 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio jPigpio initialized
2022-04-09 10:04:15.309 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio connection poll : CMD_TICK
2022-04-09 10:04:45.310 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio connection poll : CMD_TICK
2022-04-09 10:05:10.762 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio dispose
2022-04-09 10:05:10.763 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio connection poll : killing
2022-04-09 10:05:10.775 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio disposed
2022-04-09 10:05:10.777 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio channels initialized
2022-04-09 10:05:10.778 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio binding initialized
2022-04-09 10:05:10.779 [DEBUG] [internal.handler.PigpioRemoteHandler] - gpio connection poll : CMD_TICK
2022-04-09 10:05:10.782 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at org.openhab.binding.gpio.internal.handler.PigpioRemoteHandler.connectionPollWorker(PigpioRemoteHandler.java:213) ~[?:?]
	at org.openhab.binding.gpio.internal.handler.PigpioRemoteHandler.lambda$0(PigpioRemoteHandler.java:137) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]

It seems to work after reboot.

I found the source of that exception. I didn’t realize the OH framework would call initialize() without a ctor() on the binding. I have fixed it and have updated the build jar file if you care to deploy the fix. Thanks for noticing this.

Glad you got it up and running. Please keep me posted if it’s stable and handles any disconnects.

Hello @jeremyrumpf
I tested the binding for a week now and it works perfectly. Thank you very much for your help!
I will test your new version as well.