Problems Reading GPIO Pins

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 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!

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

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.

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

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.

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:

If it’s not working you should comment there.

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.

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

CaptTom, tom_l
I worked to solve this issue.
I have reported my results here:

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

1 Like

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.

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

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.

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,