My apologies again. Two more business trips out west sank a full 2.5-weeks of time I should have been spending on this project...

Anyway, along the work detailed in the last post, I had to overcome some issues and wanted to include that info here.

Issue #1: Debounce

A well-known ECE challenge to overcome w/ any physical toggle button scenario is that of "bouncing" the button press. So I had to dig a bit for the "preferred" solution for debouncing in Python on the RPi's GPIO. (I'll leave it to others to explain the technical aspects of this--simply google "debounce".) In short, the current version of the GPIO library now includes a built-in solution:

When calling the GPIO.add_event_detect(), add the option bouncetime=X. In my case, X=300 ms seemed to be the magic number.

See https://sourceforge.net/p/raspberry-gpio-python/wiki/Inputs/ for more details on input pins.

NOTE: For the end project, this is not even needed b/c the physical buttons will be replaced by virtual ones via a webpage or some such software app interaction. So why did I worry w/ this at all? Simply b/c I wanted to test this out in the garage w/o lugging a monitor/keyboard outside. I wanted to simply apply power to the RPi, give it a minute to boot up, and then test the triggering mechanism via a button push--also emergency "kill program" button.

Issue #2: GPIO Initial States (plus pull-up/down resistors)

I've already mentioned this would probably be a concern earlier, b/c I saw it mentioned several times by other projects. Many of them blamed the problem on "floating pin", which I attempted to address via the built-in pull-up/pull-down resistors of the RPi--did this via the GPIO.setup lines in Python code posted, using option pull_up_down=.

While that is still a good thing to have (and perhaps even better had I rather used an external 100-ohm resistor to manually implement pull-up/pull-down), that was not really the problem--or at least not in my case. The underlying problem was that when the GPIO library is initialized at the beginning of the Python script, it by default sets certain pins high/low--as it should for clean/known-state programming. However, my situation called for the output pin to be set w/ "reverse logic," if you will; because the relay is ACTIVE LOW, the initial setting of the output pin needs to be initial=GPIO.HIGH. Again, see previous post's code where BCM's pin 18 is setup.

See https://sourceforge.net/p/raspberry-gpio-python/wiki/BasicUsage/ for more details on GPIO initial states.

See https://sourceforge.net/p/raspberry-gpio-python/wiki/Inputs/ for more details on pull-up and pull-down resistors.