GPIO input not working

Tags: #<Tag:0x00007f7450d254f8>
  • Platform information:
    • Hardware: RPi Model3
    • Java Runtime Environment: which java platform is used and what version
    • openHAB version: 2.4
  • Issue of the topic:
    Using the gpio1 binding, running OH 2.4 on my RPi, I cannot get the status of the input to be read correctly.
    I have installed binding, updated items and sitemap files, connected a normally-ope push button across a 3.3v pin and a GND pin, but I cannot get a consistent read of the input.

What i mean by consitent read, is that it has worked on a very few occasions, i.e. OPEN/CLOSED is shown when button is NOT PRESSED/PRESSED. but the majority of the time it does not respond to button presses.

I have even added "openhab’ to the GPIO group, but still does not work.
Am I missing something?

Items file:
Contact Button “Button [%s]” (GF_Lounge) [“Lighting”, “Switchable”] {gpio=“pin:12 activelow:yes debounce:10”}

Sitemap file:
Text label=“Button” icon=“light” {
Default item=Button label=“Button”
}

Please help.

Sounds like there may be an issue with how its wired. Are you using a pull up/down resistor or just straight wire to button?

Sounds like you need a pull up resistor and 10k ohm is a good starting point. Might want to see here for more info on how to use and wire up resistors.

1 Like

No I’m not using a pull up resistor. Just a straight wire to button.
The reason for this is I used the approach taken by MKSmartHome on his blog, with the most basic update of item and sitemap files. This worked perfectly for me.
I then used the same Hardware setup but ported the code to the sitemaps and items files I’m developing for my home (extracts shown in my original post).
I just don’t see why the behaviour would change with effectively the same code (in different files) and the same hardware layout.

Any help would be greatly received.

Trust me, floating wires (i.e. no pullup or pulldown) WILL cause weirdness, and being weird you will not discern the pattern to it.
It costs one cent to eliminate the issue forever.

1 Like

It will cost me one penny where I come from!!! (UK-based) :grinning:
Actually, with the comment from H102 there I updated my circuit and incorporated a 10k pull-up resistor into the input pin, as suggested and shown in the link provided by H102. though there was overall improvement, I still had some issues.
These issues being that the state is not correctly reported after an action predominately on the momentary normally-open push button, the reported state remain closed after release of button. It does not change state until another push of the button is exectuted.
Any ideas of what the issue may be?

You need to show us what you mean by “state reporting” - event logs, tules ?

The state reporting is what shown on the Basic UI.
i.e. OPEN or CLOSED or in other words the position of the button
42

May we see your events.log with some comment about what you expect to happen instead.

The status changes in the events are not always in sync with the status show on the UI.
See attached picture for example

.

Also though (and more importantly) the status of the switch is not in sync with the status of the event & UI. i.e. switch OPEN; status showing CLOSED.
Quite worrying.
See attached picture showing status CLOSED, but button is released, i.e. OPEN.


(nothing wrong with the button contacts. Checked them with a meter.!

Okay, that’s clearer. Two different complaints.

The UI’s are always a bit strained to keep up with refreshing data. There’s a bunch of ways to mess it up as well, make sure for example that your sitemap is error free e.g. look in openhab.log for “sitemap loaded” and check for any following warnings.

In the case you illustrate though, the most significant thing I think is that your Item changed state twice in less than 10mS. I’m not at all surprised the UI missed that.
openHAB would have sent two event notifications to the UI but when that close together there is absolutely never any guarantee they would arrive at the UI in the original order, let alone get processed in the same order.

openHAB isn’t a realtime system, we are never going to get sub-10mS displays.


The timestamps are cropped out of your second picture, but I wouldn’t mind betting the same kind of thing is going on. Rapid changes have fired multiple events in openHAB and which one got acted on last is pot luck.

I reckon you have an electrical noisy switch, it happens. I’m a hardware guy so I would put a 0.1uF capacitor across the contacts.

However I also would expect that simply changing to debounce=100 will sort this out.

1 Like