Problems Reading GPIO Pins

Hardware
1

I’ve done a lot of searching, and posted a few specific questions, and I’m still floundering. Maybe if I ask this more generically someone can point me in the right direction…

Does anybody successfully use GPIO pins for a simple input binary switch? How?

I have a Raspberry Pi 3B+ running a Hass.io and HA at the current version. I have three GPIO pins connected to some relay contacts which are always either “on” (closed) or “off” (open.) It works exactly as designed… usually.

But, at least several times a day, one of the changes (on to off, or off to on) is simply not identified by HA.

I verified that electrically, everything is OK. I moved the relays close so there are no long wires to pick up interference. Even that short run I replaced with Cat6 shielded, twisted pair cable. I added external pull-up resistors. I bought a screw terminal connector so all the connections are tight; no breadboard. I experimented with different “debounce” values.

At this point, based on some reading in this forum and elsewhere, I’ve come to the conclusion that HA sometimes doesn’t detect the “edge” between “on” and “off.”

This was a real shock. Somehow I thought the RPi, and HA, would be looking at the state of the switch, not just the change. The revelation came when I realized that, if it misses the change, say, from on to off, then in HA it will show as “on” forever.

I’d appreciate any suggestions for overcoming this.

Thank you!

2

There has been an issue open for this for two years with no solution in sight.

I gave up and used a separate raspi (two actually, I have a lot of wired sensors) running this (configured easily in yaml) that talks to home assistant via mqtt. It works flawlessly even for very short pulses:

I run it in a VM but see you can now install it in a Docker container. You might even be able to run it on the same pi as Home Assistant if you are running Hassio on rasbian. Or even the Hassio image if you install the Portainer community addon. There could be conflicts with who has access to the GPIO though. So a separate pi would be best.

1 Like
3

Wow. That’s depressing. I started looking at the OpenHAB forums a bit. I had that running at one point but chose HA instead. Now I’m questioning that decision. I did see some reference to similar problems there though, so I’m not even sure that’s a solution.

Before I got to that point, and if I had to add new hardware anyway, I’ll probably buy a few Visonic Zigbee door/window/temperature sensors and replace the reed switch in each with a pair of wires to the relay contact. I did that with my oil burner, and it’s been 100% reliable for six months now.

It seems insane to line up three or four wireless sensors right next to a row of GPIO pins. You’d think the hard-wired solution would be more reliable.

4

Wow. That’s depressing.

Yes it is.

You’d think the hard-wired solution would be more reliable.

It definitely is… just not using the HA GPIO input integration :slight_smile:

GPIO outputs work fine.

1 Like
5

Since you’re the only other one who seems to care…

Am I correct in assuming that the way the HA GPIO input integration works, it never actually reads the state of the GPIO pins, but only waits for some sort of interrupt or signal when a change (edge) is detected? My theory is, if HA is busy doing something else at that moment, the change simply gets ignored.

Would it make sense, and is there a way, to read the current state of the pins at some interval, say every minute? That would be granular enough for my purposes, since the inaccuracy would round out over time.

6

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.

7

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.

8

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:

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.)

9

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.

1 Like
10

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.

11

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.

1 Like
12

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.

0424201418
04242014181776×1310 818 KB
0424201418a
0424201418a2620×4656 2.88 MB
0424201419
04242014192190×1179 1.11 MB

13

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

14

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.

15

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

1 Like
16

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?

17

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

18

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.

19

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

20

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?

1 Like