Raspian Jessie / GPIO input

The alejandroguirao binding does work about 90% of the time for incoming contact items and all the time for outgoing switch items, The problem is occasionally it misses contact items changing, my system’s problem is very noticable on 2 of my contacts

I guess I spoke too soon. Contrary to your findings I don’t seem to be able to turn on an LED via an output GPIO. The missed contact items is not really much of an issue to me since I use if for a PIR motion detector. If it misses one it’ll usually get another shortly afterwards and I only care about motion not the lack thereof.

I’d try using another pin in case it’s being held up by something else running on the Pi outside of OH

Well now I’ve had time to research the LED issue a little more thoroughly it turns out it was a bug in my code. It works fine now.

1 Like

@kevin, do you know if an issue / bug was reported for the GPIO incoming contacts? If so could you pass the link / number (I could not find it in this thread)

@Jeroen I don’t think it has a bug report, although there might have been one for the GPIO pins not working at all when Jessie came out. The inputs problem is a recent discovery

I would just like to add that I’m experiencing the same problem as reported by @kevin. Status of items in openhab doesn’t always correctly reflect the actual status of the pins as seen by the OS. I’ve experimented extensively with the wait and debounce options to no avail.

@maintainers can you advise how this intermittent GPIO binding contact problem can be reported as a bug and hopefully fixed please.
Several people in this thread seem to have the same problem

OH 1 issues can be reported here.

OH2 issues can be reported here.

Thanks Chris, will carry out further tests in the next few days and report it with as much details as possible.
@Steamrunner @Jeroen and anyone else watching this thread please tell me what the exact physical switch you are having the problems with.
In my case some of mine seem worse than others so I’d like to tie it down a bit more if possible so the maintainers can reproduce it easier

I’m seeing this on all inputs regardless of the type of switch I’m using. I currently using a big red industrial push button, my shut down everything button, two regular light switches the type usually used to switch 220V lights directly, and a up/down select switch to control a motor that opens and closes a roof.

I’m currently using openhab 1.8.3 form the apt repositories and the gpio binding made by Alejandro. (As discussed earlier in this thread)

One thing I wonder is whether the contact state isn’t reported after a reboot until its been cycled through
CLOSED > OPEN > CLOSED. I’ve just added logging to see if some of my dodgy contacts are sitting uninitialised after a reboot. I have 2 that seem to work OK and 2 that seem intermittent.

The contact states are being read correctly on boot up. I’ve just removed the global debounce variable from openhab.cfg and added it back to my more reliable items. I have left no debounce setting on my 2 troublesome contacts which seem slightly better but it hasn’t totally fixed it. I’ve also turned on logging on the binding so I can see if its missing any commands. My aim is to provide as much information as possible when I do the bug report as intermittent faults are difficult to find.
@Steamrunner can you add this to your logback.xml and see whether the GPIO activity is there when Openhab isn’t updated.

<appender name="GPIOFILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>/tmp/gpio.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
  	<!-- weekly rollover and archiving -->
  	<fileNamePattern>logs/wemo-%d{yyyy-ww}.log.zip</fileNamePattern>
  	<!-- keep 30 days' worth of history -->
  	<maxHistory>2</maxHistory>
</rollingPolicy>
<encoder>
 	<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger{30}[:%line]- %msg%n%ex{5}</pattern>
</encoder>
</appender>

<!-- Change DEBUG->TRACE for even more detailed logging -->
	<logger name="org.openhab.binding.gpio" level="TRACE" additivity="false">
	<appender-ref ref="GPIOFILE" />
</logger>

My dodgy contacts are configured as

Contact DodgyDoor1 "Dodgy Door 1"{ gpio="pin:25 activelow:no" }
Contact DodgyDoor2 "Dodgy Door 2"{ gpio="pin:23 activelow:no" }

One thing I’ve found so far from the logs is several of my contact items are being triggered at once when I operate the troublesome door, suggesting that something is triggering a reread of many of the items together. I’ve also observed the same item being triggered multiple times.
The easiest way I’ve found to troubleshoot this is to import the log into excel and use VLOOKUP to assign the items in the sheet to the individual contact items

@Kevin - I agree with steamrunner - issue is independent from the actual switch being used.

Is there any chance you can do the additional logging above? After watching this for a day I suspect my dodgy one may be caused by the signal picking up noise in the cable and this causing multiple inputs sometimes to fire at once

UPDATE 2:
Since adding the debug settings I’ve noticed my input pins seem to be receiving spurious operations, for example whenever one of my relays is operated by the Pi, I receive “0” from 2 of my contact items that are already at logic “0” at the same time. I’ve also seen several groups receiving logic “0” together even though nothing has operated them. This suggests that there is something electrical that may be causing an issue.
To try and troubleshoot this I’ve added reed relay’s as input buffers on all the input items on my Pi3. This should ensure that the Pi receives a very clean 0V or 3.3V signal on its input pins with negligible noise.
I’ve also changed the debounce period to debounce:25 which is probably still a little long for reed inputs.
I’m not saying there isn’t a bug in the binding, but I’d like to make sure that my system is electrically perfect before I report it. Curiously enough my other Pi2 that services in another part of the building seems to work without missing inputs from contact items.

Final update:
It seems the GPIO Binding and the Pi itself is triggered on rising and falling edges rather than logic levels. In my case due to the way I’ve powered the relays by splitting the power cable, there is a small voltage between 0V on the Pi and 0V being fed to the contact. I think this is causing false triggers due to the 0V rail spiking slightly high when the relays come in. If a genuine state change happens at the same time as the binding is processing a false trigger spike it seems to ignore the state change and report it as logic 0 rather than logic 1.

As this problem doesn’t seem to happen on my other Pi which gets its contact 0V from the Pi’s GPIO pins I think this may be what is wrong.

To cure this I could change the wiring to use 0V from the GPIO connector on the Pi, and test again. However as my main Pi is running out of GPIO Pins I’ve decided to move my input items onto an Adafruit Huzzah ESP8266 Module running ESPEasy, communicating with the Pi over MQTT. I use this elsewhere and it works well.

If anyone wants to report the GPIO problem as a bug I’m happy to help but as I’m not going to be using it for inputs anymore I can’t test anything.

I’ve been looking into the behaviour of my switches again using the extra logging you suggested. I can clearly see that often there is a discrepancy between what openhab logs and the output of /sys/class/gpio/gpioX/value. Clearly a bug in my opinion.

Can you report the bug? Link is a few posts back. As a workaround I wonder if something outside openHAB could be used to check contact items only and update openHAB
I’ve installed my ESP8266 solution which seems to work well so far. In my case it was easy geographically to group 7 contact items and one switch item.

Just want to say… I have been tearing my hair (little of it I have) out for the past 3 days trying to work out why my 1.8.3-runtime on jasper would not find any of my PIR/Switch GPIO ports (I am changing from a custom-arduino home automation to OpenHAB… adding some MQTT in the future too).

none the less… It was driving me bananas!

then I found this link - and I assumed… its old… it wont work…
welll I was wrong!

You guys are awesome… for those who are not sure and having the same problems…
go into your /usr/share/openhab/addon folder…

sudo mkdir backup
mv *gpio-1.8.3.jar backup
sudo wget https://www.dropbox.com/s/9iv1pq7da48zmwq/org.openhab.io.gpio-1.9.0-SNAPSHOT.jar
sudo wget https://www.dropbox.com/s/r5uutaz2gbq8leo/org.openhab.binding.gpio-1.9.0-SNAPSHOT.jar
sudo service openhab restart

you are now working!

Phew…
thanks to everyone for the old thread… it still works…

(id installed the 1.8.3 runtime from default jessie installation and I have also
sudo adduser openhab gpio too
(just in case anyone else is also trying to work this out)

Good luck - and thanks again!
Mike

1 Like