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?
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 ?
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.
@hilbrand
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.
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);
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?
@jeremyrumpf
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 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
[Service]
ExecStart=
ExecStart=/usr/bin/pigpiod -s 10
# Reload the systemd unit files
systemctl daemon-reload
# Restart pigpiod
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.
Hello BillGOH. I want to realize the same function with the ES-GAS-2 sensor. Can you post a schema how you connected the sensor to the GPIO pins of the RPI.
Hi,
my electrician did all the work. He made me a connection between the ES-GAS-2 sensor and the GPIO pins. As an example we used this:
Unfortunately the binding or pigpio is still missing some turns of the sensor. Today I tried to reduce the heartbeat intervall to 3000 ms, but got the error again:
2022-11-27 12:55:01.899 [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) [?:?]
Maybe there will be a fix of the binding in openhab 3.5?
