Binary sensor sometimes has false readings on quick changing states

[Misiu]

I’m trying to configure simple action that will allow me to turn on lights in my corridor at night based on motion sensor (standard NC PIR motion sensor used in alarms)

My schematics looks like this:

My configuration entry looks like this:

binary_sensor: 
  - platform: rpi_gpio
    ports:
      12: motion
    pull_mode: "UP"
    bouncetime: 1

From the pieces of information, I found on the internet, for example here, I know that Pi has internal 10k resistor, so I only used a 1k resistor.

Everything works, when the circuit is broken (sensor is “open”) my sensor turn’s on, but with very fast changes I get false reading sometimes.

For tests, I removed the PIR sensor and replaced it with two wires that I connect or disconnect very fast.
Sometimes when wires are disconnected HA is showing that sensor is off (inverted logic) when it should show on and vice-versa - sometimes when I connect wires it shows it is on, but it should show off.

With this behavior, I can’t rely on Pi and HA to turn on light or use it as a simple alarm.

Should I add other resistors to my schema? I’ve tried changing debounce time, but that didn’t help much.

[tom_l]

This has been a known issue with the GPIO binary sensor for 2 years.

See:

Pi GPIO Binary Sesnsor

Hello Im having a bit of touble with binary sensor on Pi GPIO, I have exhausted all hard wiring options, resistors, short wires, long wires, ferrite rings etc connected to various push button types (all normally open going normally closed momentary) in a live house enviroment. I have also tried a momentary relay connected to the GPIO input as this toggles in minimal ms. im fully educated on relays, wires etc as this has been my day to day job for many years, as a IP CCTV/Network Engineer. So …

and

Raspi GPIO binary_sensor produces unreliable responses ("Doorbell Scenario")

[Mutt (Muttley)]

Looking at your circuit, I don’t like it.
I would expect to see a resistor pair involving 3.3v, gnd and the input.
I’ll have to check my standard designs to see what I’d use (it’s been a while since I’ve dabbled)
However, towards the bottom of Tom’s first link it describes using a capacitor (1 microF, though I’d suggest bigger) to extend the down time. (further up the thread) someone else suggested using a 555 timer ic to do pulse stretching (this would be, if all else fails, in my book)
Generally, these examples all seem to be used on the HA machine. I don’t like that either, stray wiring around the house, any wiring incident could screw the pi (and the HA instance). Though I understand the aim to reduce costs.
I’ll look around and see what circuit I’d recommend.

Surely this is hardware, not configuration ?

[tom_l]

The resistor is not required.

The GPIO pullup resistors are large (~50K from memory) for all but the I2C pins (they are 1.8K) so you can short the input directly to ground and less than 1mA will flow.

[Misiu]

Thank you for the link, very sad this hasn’t been fixed for so long.

I found this on GitHub:

Applying a capacitor between GND and GPIO pin of binary sensor solves the problem. I putted a 1uF electrolytic capacitor or a SMD capacitor and with both works very stabil. Before that I had unreliable responses as well.

I have a normally closed circuit, does this apply in my case? Where should I put the capacitor?
I think it should be between GPIO12 and GND, but should it be near Pi or near PIR sensor (or switch, or whatever)

I’ll be really grateful for guidance

[tom_l]

Put the capacitor across the GPIO pin and ground. As close to the GPIO as possible.

[Misiu]

@tom_l thanks for the clarification.
I’ll try that today in the evening. Does it matter is I have NC or NO circuit? ANd PULL UP, PULL DOWN mode?
My second option is this PR but sadly it doesn’t get any attention from the devs.

[tom_l]

If you use pull-up mode the input is weakly pulled up to 3.3V which you are then shorting to ground through the switch to change the state. It is a very weak pull up to 3.3V so you dont need any external resistors to limit current when you short to ground though the switch.

If you used pull-down, the input would be weakly pulled to ground which you then short to ground with your switch. So you aren’t going to measure any change of state in this case. So don’t use this mode for your circuit.

NC means your input will normally be shorted to ground. It will go high (3.3v) when the switch opens because of the internal pull-up resistor. This is good. No need to invert the input in your configuration. On = 3.3V, Off = GND.

The capacitor useless for extending the pulse time and capturing your actual change of state though.

When the switch opens it takes time for the capacitor to charge through the pull up resistor, lengthening the turn on time. When your switch closes it shorts the capacitor directly. No resistor to limit the current. As you are having trouble capturing the turn off state this means the capacitor will not help.

It will help to shunt noise to ground if you have a long cable to your switch though. So not completely useless.

[Misiu]

hmm…so I guess I should add the capacitor after all. The cable is CAT 5e ethernet cable, it’s about 3-5 meters (hard to measure right now because it is already in the wall)

The main problem was with very fast changes.

@tom_l what do You suggest as a solution?
Can I use a python script in HASSOS (HASSIO) I’ve downloaded the image from HA website and burned it into SD, I didn’t install HA manually to the existing system.

I don’t mind pooling the GPIO every x seconds if this will help and solve that problem.

[tom_l]

Bouncetime makes no difference to this problem. I tested it extensively. Read the links above.

[tom_l]

The only solution I found was to give up on the Home Assistant GPIO integration and use this instead:

flyte/pi-mqtt-gpio

Runs on two other raspis ( I have a lot of wired i/o) and communicates with home assistant via MQTT. It captures very short transitions. Been running for over a year without issue.

[Misiu]

I only need single GPIO for now, so if I won’t get any results with capacitors and this PR: https://github.com/home-assistant/home-assistant/pull/27198 I think I’ll use Wemos D1 and connct it to MQTT. But I think it is an overkill for just one input. This should be fixed long time ago

BTW did You saw this PR? Any chance You could take a look at it? I’d like to give it more attention form the devs. There is a potential solution for 2 years old bug.

[tom_l]

A D1 mini (or even an ESP01) is also an excellent solution. Do you know about ESPhome?

You’ll be up and running in less than 30 minutes.

Yes I had seen that PR. I don’t believe it is the best solution. Far better to use interrupts than polling.

[Misiu]

I’ve used ESP Easy some time ago, I guess they are very similar.
I’m aware that solution with interrupts is far better, but the current implementation doesn’t work, so any thing that helps if far much better that non working solution, even as a temporary option untill we get a proper fix.
I’m also not sure if this bug requires changes in raspberry-gpio-python library or can this be fixed in Home Assistant source.

[Mutt (Muttley)]

Ask the guy who suggested his quick and dirty solution how he did it

[Misiu]

@Mutt the PR I linked adds polling option, but I’m wondering where is the source of the problem. Is it in HA code or in raspberry-gpio-python library.
Unfortunately, there are no codeowners in rpi_gpio integration - https://github.com/home-assistant/home-assistant/blob/0463349f0284ea6d8e72d1727a9fbc952cdab2ba/homeassistant/components/rpi_gpio/manifest.json#L9 so I don’t know who will have the best knowledge about this integration.

[Mutt (Muttley)]

I’m guessing here but
You are running HA 0.100.+ on hass.io 189 hosted by hassos 2.12 ?
That’s pretty much as vanilla as you can get. (it’s what I run).
The fact that the issue is fairly widely known, has been outstanding for 2 years, has a proposed (though maybe crappy solution, ie someone could easily clean it up) and yet it still hasn’t been fixed. Suggests that it isn’t high on anyone’s priority list.
All of the above platform is (or is as close as makes no difference) as in house as you can get. So any of the devs could take a look at this.
I don’t really want to spam anyone but I’ll risk it on this occasion.

@pnbruckner, sorry about tagging you but you know the systems about as well as anyone (cept Tink and balloob of course), can you suggest a course of action (to Misiu) on the gpio issue ?
Thanks in advance even if the answer is no.

Edit: tom_l - just realised (I’m getting senile) that you were already on the thread and would be also be able to offer an opinion on progression on this issue (my apologies)

[Mutt (Muttley)]

Off Topic !

Tom, Noticed the signiture change a while ago.
Do you know it likes different accordind to platform ?

In one you look cool in the other, kinda startled !!!

[pergola.fabio]

i am seeing the same issue, i was using last month a espohome nodecmu, now tried gpio, that needs to read 3v ,
sometimes it works , sometimes not… verry strange
i am using the remote gpio configuration, but i think its the same
so for a doorbell that only triggers like 1-2 sec, its a nogo