Problems Reading GPIO Pins

[tom_l]

There’s a bit of discussion starting here about the problem. I am far from an expert and don’t really understand why the event is missed.

There was a PR to include polling of the GPIO that seems to have been merged: https://github.com/home-assistant/home-assistant/pull/27198

If it’s not working you should comment there.

[TheFax]

CaptTom, did you solve your problem?
I have an issue that seems strictly related to yours.
I’m sure that electronic part is OK.

Thank you.

[CaptTom (Tom)]

@TheFax

CaptTom, did you solve your problem?
I have an issue that seems strictly related to yours.
I’m sure that electronic part is OK.

Yes and no.

HA is still unable to reliably read when the state of GPIO pins change. However, for my particular project, I did find a workaround. This workaround doesn’t give you instant notification of the state change, as you would need for a doorbell, for example. I just monitor the state of various components in my heating system, so checking the state every 15 seconds is good enough for my purposes.

Here’s where I posted my workaround:

Pi 4 and Gpio Issues

Thanks Alex. I think if I started over, that’s the route I’d go. It turns out the problem isn’t with the pull-up resistors, anyway. Even hard-wiring an external resistor didn’t help. The problem is, simply, HA can’t read GPIO input reliably. It seems nobody with the skill set to fix it is spending any time on it. That’s just the way volunteer, open-source development works. But I do think I may have found a workaround. It turns out real-time GPIO status information is recorded in the file syst…

If you google site:home-assistant.io gpio capttom * you’ll find a bunch of discussions, and can read about all the other rabbit holes I’ve been down, along with some workarounds that others have offered.

(* For some reason the search on this site never seems as helpful to me as searching this site from Google.)

[TheFax]

CaptTom, tom_l
I worked to solve this issue.
I have reported my results here:
https://github.com/home-assistant/core/issues/10498

Edit a single line on the source code of Hassio is enough to enable the polling on input pins.

[CaptTom (Tom)]

@TheFax

I have reported my results here:
https://github.com/home-assistant/core/issues/10498

Edit a single line on the source code of Hassio is enough to enable the polling on input pins.

Thank you!!! Do you think this fix will ever get incorporated into the base Hassio?

I’m not sure I want to get into changing that sort of thing on my HA system. I just blindly update every time there’s a new version, and I assume at some point any changes I make would be overwritten. So updating the “source” (actually, Python is a script language, but I know what you mean) doesn’t seem like a long-term solution I can rely on. But where my workaround wouldn’t work, like for a doorbell, it’s good to at least have another option.

[TheFax]

@CaptTom

Do you think this fix will ever get incorporated into the base Hassio?

Yes, some people are working on this issue. A solution (probably) better than mine is already present and ready to be tested/committed on the master branch. It is waiting for real-life tests and someone that should click “accept”.
GitHub: #31788.

[dankrill]

For what it’s worth, I got mine working, thought I’d share:

I thought the issue was software too for the longest time because I have pull down resistors and a buffer chip between my “door bell” style buttons and the GPIO which act as a debounce circuit. Signal was pretty straight edge. But I was still getting about a 33% successful detection rate in HA. (Pi 4 @ v0.108.8)

Just for fun I played with more capacitors and WOHOO, I got it working!

I now have a 100% detection rate in HA no matter how fast I repeatedly press the buttons.

Here’s what fixed it: I soldered one side of 1uF (micro farad) ceramic caps to the NO pin of each switch. And the other side to a common ground wire. (I have 12v on the COM pin of the switches)

I tried putting the caps at the board, very little improvement, the caps need to be right at the switch.

So in conclusion, the issues REALLY WERE hardware. If the Pi triggers an interrupt, it looks like HA will indeed act on it.

[chrisV]

Hi Dan ( @dankril ),
can you please confirm that your solution is still working 100% reliably?
I’m seeing similar issues. I tried buffering with a 7405 (Open Collector TTL inverter) and later with an optocopler. I also used (tantalium) decoupling capacitors and verified signals with a multimeter and oscilloscope. I see clean (relatively slow) rising edges with no overshoot.
It seems to work for a few minutes, but then the RPI does not seem to detect the input signal any more (nor the rising, nor the descending edges)
I’d appreciate if you could elaborate a bit on your working solution
More info here: Raspberry PI GPIO input buffer circuit
Thanks so much,
chrisV

[Nils154]

Problem not yet fixed here. I have a Pi2 with a Pibrella. LEDs on the Pibrella report all three PIR sensors are low, yet HA reports high for one of them.

[chrisV]

Hi,
I can confirm that this https://github.com/home-assistant/core/issues/10498 fixed it for me
Steps:

1. in the directory of the configuration.yaml, create the custom_components directory
2. under that dir, create the rpi_gpio2 directory
3. extract the 2 files from the attached zip into it
4. make them rx for everyone: chmod 755 *
5. in “binary_sensors.yaml”, change the domain of the gpio binary sensors from “rpi_gpio” to “rpi_gpio2”
6. restart home-assistant.

I have setup an endless loop in NodeRed that outputs data to GPIOs to activate relays. Those relays provide tension to opto-couplers which then again trigger other GPIO inputs. When I see the input signal, I change the output and when that makes it back to the input, I change it again. I had this loop running all night and it did not miss a single beat.
rpi_gpio2.zip

[CaptTom (Tom)]

Thank you so much for running that test! This is the first true fix I’ve seen.

I notice that fix was posted over on GitHub back on on Feb 13, 2020. Do fixes usually take over a year to make it into the stable release?

[chrisV]

Hi @CaptTom Yes, this is a shame.
This issue is open for about 3 years I think.
And things got worse on the RPI4 (the implementation of a middle-ware that is used by the GPIO stack has changed)
This workaround works beautifully.
My only concern is about the potential impact on the Home Assistant environment (e.g. like on CPU load) I asked greg2001on github for some background on his workaround
chrisV

[Bergerie]

Thanks for making this available. Has taken a while to find a solution after the switch from Rpi3 to Rpi4 64. The community workaround rpi_gpio2 works flawlessly for me.

[mburget]

Hi everyone,
I had the same issue and after using the rpi_gpio2 custom component (without threads) successfully for months I finally took the time to provide a PR hoping to get it officially in.
The PR is #48170.
Nothing new inside but the proposal out of the discussion not using threads.
The backlog seems to be currently quite full, so feel free to review it if you are interested to get the issue closed

[Bergerie]

Am I correct in saying that core version core-2021.6.0 invalidated the rpi_gpio2 patch and that the original rpi_gpio is functioning?

[gbuico (Giacomo)]

Frankly, I’m a bit confused.
I did all my GPIO tests during the past month and I never had a problem.
I’m insure about the HA version I’ve been using.
A couple of days ago I decided to move it to “production” and before doing it I did a version upgrade to 2021.6.3 and everything stopped working !!
Meaning, I have 5 pull-up sensors, whenever I connect one of them to ground it changes its status in HA but will never return to the previous state when I disconnect.
Plus, from that point on, whatever other change to GPIO pin is not seen by HA.
Electrically the right tensions and polaritirs are measured.
After seeing your post, I rolled back to 2021.5.5 and evrything works fine (without gpio2 !!)
Anybody else??

[WillyVanilly (Filipvdb 01)]

Is this already been confirmed?

[Bergerie]

I’m running the following code for the past two years now without any problem. i.e. the patch is no longer needed in my case.

- platform: rpi_gpio
  invert_logic: true
  ports:
    12: Security System

[CaptTom (Tom)]

I finally got around to switching one of my GPIO entities over to the GPIO platform (instead of the command line platform, reading the GPIO value files.)

So far, after just two on/off cycles, it seems to be working. I’ll continue to monitor, but it will be nice to put this chapter behind me after all this time!

[CaptTom (Tom)]

Well, all my GPIO sensors have been working fine since my last post. Looks like after all those years they finally fixed the GPIO input problem in HA. But…

Now there’s word that the GPIO support will be removed from HA!

Removal of GPIO support

I have just noticed that HA is planing to remove GPIO support: Integrations I use a lot e.g. for the BMP280 and BME680 sensors will therefore stop working. I also just bought a MCP23017 I/O Expander board hoping I could use it as a replacement for the not so great Firmata integration. Is perhaps someone already planning a custom integration as a replacement for this change? Is there something already in the pipeline?

Just when I was starting to consider my HA environment to be somewhat mature.