Hi Frank,
i found my python scripts were not exiting so the pi gradually slowed down. If you do try something based on my scripts, you need to add an exit to the python scripts or find some sort of method to avoid running the scripts many times.
Also, in case my previous posting was a bit complicated, here is the simple python script i used to test the basic circuitry outside home assistant (which might help).
Richard
import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BCM)
GPIO.setup(24, GPIO.IN, pull_up_down = GPIO.PUD_UP) # pin 18
status = GPIO.input(24)
print(status)
while True:
status = GPIO.input(24)
print(status)
time.sleep(0.25)
GPIO.cleanup()
Hi Frank,
Have noticed on the most recent release of HA inputs are more responsive.
Are you still having issues?
Rob.
Hi
I give up in the end and not tried them again since. Iam now using ESP modules
Cheers
No probs. Frank,
Sounds like the input pin was floating, and maybe it needed a stronger pull up resistor then the internal weak enabled.
But I also noticed on earlier versions of HA to also not always register a button press as well.
So could be a combo of issues.
Rob.
I don’t know if you resolved your issue yet but I’ve been playing with push-buttons (I’m eventually going to add a 4 output 315MHz receiver and use 4-button fobs to toggle lights).
I was having a similar issue where the button worked PART of the time but wouldn’t reliably indicate “ACTIVE” when pressed and “NOT ACTIVE” when released. Sometimes the sensor icon would hang in “ACTIVE” after the button was released.
I figured out that changing the “bouncetime: 1” gets rid of all debounce processing and then it responded flawlessly (so far).
Warning, BOUNCETIME value must be a minimum of 1. Setting it to zero (0) will cause a soft error which prevents the sensors from showing up and functioning.
Hi Guys
I’m having the same issue as everyone above.
Been testing and trying everything I can think off. Tried a few different settings and the problem stays the same.
I have tried WayneT’s bounce time reduction but even then it only works some time but not always.
I have scripted a quick small script in python to test the hardware side and from that script everything are 100%
My initial idea were to run a small script in the back ground of the Pi to do the switching of the relays for time being while this issue persist in HA but even that has now fallen down the drain as HA does not update the status of the GPIO’s correctly.
It seems like HA only update the sensor status every few milliseconds (good normal practice) but if the switching does not happen it the refresh time HA does not update the status for either Inputs or Outputs.
So whats happening at this stage is
you push the button outside HA’s refresh time and HA does not pick up that the switch are on (even after 5 mins HA still don’t read the switch closed)
now if you play with a few other switches you have the same until it picks up one that changed in the refresh period, once it picks one up all of the inputs are suddenly updated and working but then you have the same again switching them off.
The same on the outputs. you can change the output to be on with python and HA doesn’t see that if you fallen in the blind time frame of not refreshing but as soon as one gets picked up all of the output statuses gets updated in HA.
Surely this are a small error in HA coding around the refreshing of the GPIO statuses.
If there’s anyone out there that might know how to fix this problem or even if there are anyone that can point me in the right direction to someone on the development team, that will be fantastic.
I see a lot of ppl struggle with this issue and it would be nice to get it sorted out.
Hi, may I know if this problem has been resolved? I am having the same issue but cannot find a solution after searching on the forum and web.
Thanks!
I think I found a solution to this eventually.
For those who have the same issue, I would suggest you add a pull up resistor from 5V pin to the input pin. I don’t know what is wrong with the Pi GPIO Binary sensor code (as I do see the internal pull up command in the code) but it looks like the input pin is floating which caused the problem.
Cheers!
That’s dangerous because the GPIOs are only 3V3 compatible.
Raspberry’s GPIOs.
It must be a bug in Home Assistant. With pure python scripts everything works fine also using interrupt instead of polling.
Then we should connect the pull up resistor from the 3.3V pin. In fact, I did this in the first beginning but don’t know why it couldn’t fix the floating problem so I changed it to 5V.
From the GPIO Spec, I found the note “Pins 3 and 5 are pulled up on the board to the 3.3V supply by 1.8 KΩ resistors to enable them to be used easily as I2C communication pins.” So maybe another quick fix is to use pin 3 or 5 if they are empty, but I haven’t tried it yet.
Of course still hope someone can fix the bug in the code…
Right now I don’t need an input pin, I just play a little bit with Home Assistant.
Is there a ticket system for entering bugs?
For me it is working okay, I am using a pull up resistor to 3.3V and a 100nF capacitor from input to ground. As trigger I am using ‘from’ and ‘to’
trigger:
- entity_id: binary_sensor.doorbel
platform: state
from: 'off'
to: 'on'
Sometimes the state stays in ‘on’ instead in ‘off’, but the trigger shown above seems to be robust so far.
I’m having the same problem. Quite often HA is not correctly showing the port input state. It detects the on state perfectly but misses the edge for return to the off state and does not update until there is a further trigger (often misses the return on that too).
There are quite a few reports of this and people (myself included) have tried messing with the debounce time and external pull-up resistors to no avail. Disabling the debounce timer by giving it a value of 1 is not a solution as multiple events are then generated.
This is quite disappointing as I have numerous hard wired PIR sensors already in place from an existing alarm system I wanted to replace with HA. Until the GPIO binary sensor is reliable HA is just not an option for me.
There’s already an open ticket about this but it has seen no activity since October last year.
Success!!
Spent two days testing gpio state for use with alarm sensors. I replace old Ademco, etc. alarm panels with Raspberry Pi. Couldn’t gpio to consistently detect ON/OFF state.(poor edge detection) It would turn ON OK but OFF was inconsistent or not at all.
Finally gave up and just installed and wired the alarm sensors. I had successfully set this up previously and took SD card from that pi and still had failures and figured something was up. It worked when wired in circuit to alarm door and motion sensors.
Problem for me was voltage it seems. Out of circuit gpio pin received 3.29vdc. In circuit it received 3.17vdc.
I use resistors but extra wire resistance from 10’+ wire runs made a big difference. GPIO is set as normally low. I thought 3.29 would be within limit but maybe it must be lower, 3vdc - 3.2vdc.
I’m not following what you are saying. First you say “success” then you say the voltage is too low (it isn’t btw, 3.17v is plenty for logic 1). What did you do to get HA to see the ports to reliably return to the inactive state?
There’s no actual electrical specification for the gpio but some investigation has revealed that an input logic 1 will be detected reliably above 2.15v. A logic 0 must be below 1.15v. Apparently the gpio port can only source 16mA TOTAL (all pins combined) but it can sink 16mA at EACH port. More here: http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications#input-and-output-pin-electrical-specifications.
I have all my inputs (and outputs) isolated with optocouplers. So at the gpio pin I have 0.1v as logic 0 and 3.3v as logic 1 no matter what the length of cable is. This also reduces the input capacitance to pF levels. Long runs of cable may have excessive capacitance which can cause switching transients on the input.
The problem is edge detection when the input returns to the inactive state (inverted logic enabled or not). This is a timing issue with HA. Using a python routine to read the ports does not have this problem. It is only HA.
If your sensors are active for 2 seconds or more (most PIRs will be ok) it seems to be reliable but less than this and the input may not register a change on return to the inactive state. A doorbell switch for example is going to be problematic.
1 Like
Thank’s to everyone on this thread, I created a hopefully simple example of how to read/write gio. Switch drives a LED.
And, per previous comments, I was having alot of issues with triggering working sometimes. Here is gpio port output with no decoupling capacitor https://imgur.com/iD3xGTb
After I added decoupling capacitor to the gpio swith port, the bounce went away. https://imgur.com/yaVrKs3
Thanks again for all of the comments in this thread.
Try pressing your switch for less than a second and see what happens.
Like this?
What is this in your binary_sensor definition?:
scan_interval: 10I haven’t seen that documented anywhere.
Edit/ also I suspect you have very little else tying up the availability of the HA bus. In my system with the full GPIO bus wired to inputs and output plus countless other automations and scripts this becomes a problem,
Sorry for late reply but I wanted to test some things. Also, sorry I am busy and did not have time to check by Oscope but I think my result may be helpful to some. I will try to make clear what happened for me while setting up Binary Sensor as input for my home alarm sensors (only 2 doors so far)
GOAL
My goal was to take existing alarm contacts (door sensor and motions) and use with RasPi and HA Binary Sensor. I previously succeed with this without any problem and expected task to be simple but it was a little complicated
TEST#1 (Fail)
I started by testing on bench(kitchen table) just to verify I could remember the pinout and make sure HA didnt have some error that came along since I last used for this purpose. This had issue where hi/low was not consistently detected (edge detect error).
TEST#2(Fail)
I wanted to test with know good install. I pulled SD Card from the RasPi running my gate using Cover component. This has x1 magnetic sensor and is connected to relay controlling gate Open. When I use this HA Install in my test configured for Binary Sensor my result was same, hi/low not properly detected.
INSTALL#1 (Success)
As stated in previous post, I have done this same setup 5 time previously without problem so I decided to ignore test result and install. I use a RasPi HAT that has screw down terminals for GPIO and standard 5VDC micro USB power supply. Sensor are the standard door reed switch with magnets connected from 3VDC to GPIO input with 1K ohm resistor. This worked without issue. Open/Close resulted in high/low change. I try opening just enough to change state and immediate close (assume <1sec change) and function was OK. I considered this success and post my information. I notice there was lower voltage 3.17vdc when I have success so I thought this useful and put this information.
INSTALL#2 POWER SUPPLY UPGRADE (Fail)
I wanted single supply for Motion Detectors(12vdc) and RasPi(5vdc) so I install power supply that supply both voltage (MEAN WELL RD-65A). Immediately after install this supply I have edge detect problems again.
RESISTOR CHANGE (Success)
I remember for my other Alarm Box changeovers I use 2.2K ohm resistors and decide to change from the current 1K to 3.2k resistance. This worked but I did notice if I try quick open/close (approx 750ms) it did not detect always. I increase resistance to 5.4k and even quick open/close(less than 500ms) is properly detected. After this was working OK I decide to also lower “bouncetime” from 300 to 50
FINAL RESULT (success)
Circuit: 3vdc>>5.4K ohm>>gpio input
binary_sensor:
- platform: rpi_gpio
ports:
17: Garage Great Rm Door
26: Garage Kitchen Dr
pull_mode: DOWN
bouncetime: 50
scan_interval: 10
NOTE
I use HA for Doorbell previously. Basically directly wired button into HA with 2.2K resistor just like an alarm contact. Upon thought I did have some issue for presses less than 1 second, but this is like result I receive before my change from 3.2k to 5.4k. honestly I’ve used GPIO for 4 separate installs/implementations of GPIO with HA and function was always stable enough for production use.
My previous HA Alarm install consisted of 2doors, 4motions and 1 doorbell connected to GPIO.
https://www.amazon.com/gp/product/B005T7EZM8/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1
https://www.amazon.com/gp/product/B01M27459S/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1
1 Like