SOLVED. Try with automation wich reload sensors. In my case every 2 seconds.
HA isn’t designed to capture fast triggers, but using a simple latching type as per below you’ll capture sub millisecond tiggers.
Once the latch is triggered, reset the trigger using an output pin on the GPIO.
Rob.
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.
binary_sensor:
platform: rpi_gpio
ports:
4: pibutton
This might solve the problem for you with 1 gpio but if you have a lot of GPIOs and a lot going on in HA I can guarantee this wont work. It is a software problem.
I also don’t care any more. I am now using an alternative 100% reliable mqtt-gpio bridge.
Which exact solution did you chose @tom_l? I am looking for a reliable solution for sensing 6 wired push buttons.
I use a couple of raspberry pis running a gpio to mqtt bridge:
https://community.home-assistant.io/t/custom-raspi-gpio-interfcae-pcb-project/88269
100% reliable.
Since writing that I’ve moved HA to a mini pc and both pis are running the mqtt bridge software.
I now have esphome, and my binary sensors triggers instantly for my doorbell … Max 2 sec update…
Wanna test rasperry too, but after reading some comments, it’s not a good idea? Since it uses scan interval?
I ran into this Pi HAT: https://www.amazon.com/gp/product/B01FE9EQ88/ref=ox_sc_act_title_1?smid=A1K1YGWF8WQZ7Q&psc=1
It is also a mini breadboard, so the capacitors and pullup resistors can be soldered on it. I will give it a try and let you know.
guys, can someone help me? i was using a nodemcu 8266, configured for smart doorbell, my doorbell gives when someone presses the doorbell 12 , with the schema below, i reduced to 3.0 v, this was working brilliant (10 kohm and 3.3 kohm)
now tried the same with the gpio , with remote gpio component, seems it works, but only for a short while
if i try the doorbell again after like 10 min, i dont see the binary sensor switching anymore
is it maybe because of the resisror choice? should i need to replace 3.3 with 3.8 , to give me 3.3 v ?
binary_sensor:
- platform: remote_rpi_gpio
host: !secret raspberry
ports:
18: doorbell
[Can I write SOLVED !? - at least it works for me 
]
The problem is evident, as in my case, when binary sensor has to notify the buzz of my intercom, which usually should be pushed for less than a second (it depends on how polite are the people 
) so I’ve solved in this way:
CONFIG:
rest_command:
off_bussata:
url: https://YOURIPADDRESS:8123/api/states/binary_sensor.citofono
method: POST
headers:
authorization: !secret my_sensor_secret_token
content-type: 'application/json'
payload: '{"state":"off"}'
verify_ssl: false
binary_sensor:
platform: rpi_gpio
invert_logic: False
ports:
27: Citofono
AUTOMATIONS:
####################################################
# START UP Home Assistant #
####################################################
- id: hassio-start
alias: Home Assistant StartUp
# initial_state: 'on'
trigger:
platform: homeassistant
event: start
action:
service: rest_command.off_bussata
initial_state: true
####################################################
# Notifica di Bussata al Citofono #
####################################################
- id: bussata;
alias: Bussata
trigger:
- entity_id: binary_sensor.citofono
platform: state
from: 'off'
to: 'on'
action:
- data:
message: Hanno Citofonato
service: notify.notifichetelegram
- delay: '1'
- service: rest_command.off_bussata
initial_state: true
Hope this can be helpful for someone. Cheers!
I don’t’ believe “solved” is appropriate as you’ve posted a workaround, not a fix for the underlying system.
people need a solution and in my case it is solved… and with your response the only solution is an update of HA so, what are you talking about? in any case my question on “Solved” was ironic but it is evident that you did not get it. I’ve done my goal and people like me who read this post now have a solution because there is this option without any hardware works, that’s why I’ve shared. Farewell
I’m very new to HA, Pi, coding and home automation (like one week old). I’m having the same problem on my very first sensor. I need the Pi GPIO’s to be reliable. Looks like I’ll have to work around the issue before I’ve even got any sensors working!
I thought I had a broken Pi so I clean installed Rasbian with Node-Red. It detects GPIO state changes just fine, so, like others, I conclude it’s a software issue not a hardware fault.
Consolidating similar/related tickets:
https://github.com/home-assistant/core/issues/10498
https://sourceforge.net/p/raspberry-gpio-python/tickets/143/
https://sourceforge.net/p/raspberry-gpio-python/tickets/157/
I was having issues as well, so I tried the remote method (https://www.home-assistant.io/integrations/remote_rpi_gpio/) even tho on the same Pi and all works nicely with HA.
Interesting. Thank you for posting that!
What did you use for the IP address of your “remote” (actually local) Pi? Did you use its real external address, or localhost?
Maybe someone familiar with the code can explain why this would work differently. I wouldn’t have guessed it would, but I’ve seen stranger things.
I use the local IP address of the Pi itself, I run HA in Docker so localhost probably would resolve to the container. For info, the Pi4 runs Raspbian (Buster).
Would this work also on a Raspberry Pi running Hassio directly?
I am facing the same problem of unreliable edge detection. My use case is for rain measurement - I have a measurement device with a reed switch that would provide a pulse every 1mm of rainfall. The signal will therefore be very short whenever the internal cup swaps from one side to another.
I would hope for a fix since the rpi_gpio approach was simple enough to fit my needs.
I use Raspbian, I doubt if HASSIO has the remote gpio daemon.
Hey Tom,
Are you still using this for GPIO inputs?
Yes I am.