event-based detection

[aficustree]

Hi,

I have an automationHAT sitting on an RPi3 that's doing a bunch of stuff with relays. I need to hook a doorbell into the system and sense the button presses. I wired the positive lead to 5V and plugged the other side into the buffered input with the pull-down resistor turned on via:

GPIO.setup(21, GPIO.IN, pull_up_down=GPIO.PUD_DOWN).

Right now I have a loop running in a thread to check the input state every .05 seconds. It works but I'd like to move to:

GPIO.add_event_detect(21, GPIO.RISING, callback=myCallback)

but the code never gets the rising event. Is the use of the rising event supported when using a PIN connected to the buffered input? If not, do you have another way that would be better than polling? The CPU is also doing a bunch of transcoding work for other automations so I'm eager to not tax the CPU with the loop.

Thanks!

[shmrymbd]

same with me

[speedeemonkey]

Same here.

[Gadgetoid]

I'll have to investigate this- I don't have a full mental picture of how the software/hardware interacts on Automation HAT. My suspicion is that the Automation HAT software is interfering in some way, and it might be worth testing an RPi.GPIO setup in isolation.

[kiddigital]

@aficustree (and @Gadgetoid), I 'solved' the pollig issue differently by using the Pi's SYSFS. As I also use the automation_hat Python library to set things up, I am looking into the possibility to have the library also initialize the SYSFS exports if needed.

[Gadgetoid]

@aficustree it's highly possible in your case that +5v on an input is simply not a high enough voltage to register as a digital "HIGH" since it will read about 0.4v the other side of the inline protection resistor and it needs to read ~2V to definitively register as HIGH.

This is due to the internal pull resistor being used, creating a voltage-divider in conjunction with the inline protection resistor.

IE: It's not that the code isn't functioning, but rather that the input voltage isn't hitting the right threshold for the Pi hardware to even consider it a logic HIGH.

You should use pull_up_down=PUD_OFF and use an appropriate external resistor between the input and ground to pull your signal low when the switch is open.

[kiddigital]

@Gadgetoid , I am a little confused here. @aficustree says that when using the internal pull-up/down resistor he is able to correctly read the output but using a (polling) loop. This would mean that pressing the doorbell does pull the input HIGH.

What isn't working is that when the input is HIGH, an interrupt activates the registered callback.

Couldn't that be caused by the library also using these same interrupt and somehow overriding the registered callback using the GPIO library directly?

@aficustree , how is your code sequence? First GPIO and than the HAT library calls? Do you have a snippet?

[aficustree]

sorry, I got distracted with another project and life, etc. etc.

the code reads.

GPIO.setmode(GPIO.BCM)
GPIO.setup(21, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
GPIO.add_event_detect(21, GPIO.RISING, callback=flickrelay, bouncetime=2)

I'm using 0.0.4 b/c 1.0.0 seemed to have a race condition. I see you might have fixed it in a later non-versioned commit but my wife will get irritated if it starts annoying her phone again with notifications so I'm sitting on 0.0.4 for now.

Since I can't get the async version to work, I just have a callback that polls every .05sec for a button press and then does a quick debounce check b/c for reasons I can't understand, sometimes when the humidity is particularly high I get an occasional spurious positive read. it just noms through the CPU for no reason.