Fix Raspi GPIO binary_sensor produces unreliable responses #48170
Conversation
…unreliable responses ("Doorbell Scenario")
Changes overtaken from PR#31788 which was somehow never finished
…unreliable response. Changes taken over from PR31788 which was somehow never finished
|
|
||
| rpi_gpio.edge_detect(self._port, read_gpio, self._bouncetime) | ||
| rpi_gpio.edge_detect(self._port, edge_detected, self._bouncetime) |
There was a problem hiding this comment.
In theory bounce time already processed.
Wouldn't it be better to add two separate callbacks for raising and failing edge?
In that case, you don't need to read the value.
def edge_detect(port, event_callback, bounce):
"""Add detection for RISING and FALLING events."""
GPIO.add_event_detect(port, GPIO.BOTH, callback=event_callback, bouncetime=bounce)There was a problem hiding this comment.
Hi sanyatuning,
thanks for reviewing. As you can read out of the long thread in the related 10498 issue this solution is perhaps not the perfect one because still based on RPi.GPIO, gpiozero seems to be better.
I agree that reading the value could be avoided, but this add more reliability at low cost. Some of the users in the issue thread are reporting missed edged and in this case reading out the value seems to be the only workaround.
At least this solution is tested for month by many users (including me) in a custom component and it works way better then the current implementation on master.
So I would like to keep it like it is.
Home Assistant's rpi_gpio binary sensor captures the pin state directly in the first egde interrupt.
At first glance, it looks logical and, on a real-time platform like Arduino, it would work properly.
On RPi/Linux, however, the timing is unpredictable, so that it might (actually, it often does) happen
that the signal bounces back before the edge handler has been called, and the handler captures a wrong pin
state. To fix it, we just wait until the signal stabilizes itself ("bouncetime" parameter) and capture
the pin state after that.
The changes are taken over from previous PR#31788 + proposal from balloob in discussion which was somehow never finished
Breaking change
Proposed change
Type of change
Example entry for
configuration.yaml:no changes in configuration.yaml
Additional information
Checklist
black --fast homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all..coveragerc.The integration reached or maintains the following Integration Quality Scale:
To help with the load of incoming pull requests: