FPP Read GPIO in Script

[klammer5]

Wondering what's the best way to set up a GPIO as an input (with pull-up) and read the state into a variable in a script

The use case is I want to trigger a special playlist when 2 buttons are pressed simultaneously.

Thanks in advance!

 

[Croydon Lights]

If you watch Experience Lights push button interactive video at the 17 min mark he discusses how to set up the GPIO pins to run set playlist that might help you


View: https://www.youtube.com/watch?v=mhReT2-l7kM&list=PLSxUSD0b-Qx9l4nb3WXf1X7Xr9FlwKaXo&index=2

 

[klammer5]

Yes, I have set up GPIOs to trigger FPP commands before. However, I need a command to trigger when 2 GPIOs are in a certain state (low). Don't believe I can achieve this with the FPP GPIO UI as I need to know the state of both GPIOs simultaneously to trigger the command. Thus, I need to know how to read a GPIO via a script. I've found functions to set the output state of a GPIO but no luck so far with inputs.

 

[Skymaster]

Have each GPIO run a script on down, and up.
Each script write a flag when the button is pressed, and clear it when it's released.
Once that script has flagged a button as down, check the state of the other button's file. If both are in pressed state, perform your action, if not, do nothing.

You could do it all in one file, with two parameters - UP/DOWN and BTN1/BTN2

 

[dkulp]

The "gpioget" command can be run from a script to get the current value of a gpio line.

 

[Grozzy]

Thinking out aloud. Could you run a python script as a background daemon and as soon as it detects the double press it takes another GPIO pin high/low which FPP detects and runs the playlist.

 

[klammer5]

Thanks all!
I thought about using gpios to set internal flags but that wouldn't particularly scale well; I'd rather have all functionality in a single script. I got the desired effect working using the "gpioget" command,

Cheers,
Kurt

 

[pixelated]

You could wire the two buttons in parallel and use only one input. The input would not go low unless both buttons are pressed at the same time. If the two buttons also perform other functions when pressed separately, then this won't work.

 

[chickda]

Why don't you wire the buttons in series and let it trigger only 1 gpio?

 

[chickda]

You could wire the two buttons in parallel and use only one input. The input would not go low unless both buttons are pressed at the same time. If the two buttons also perform other functions when pressed separately, then this won't work.

You mean series?

 

[klammer5]

I thought about series buttons (which would absolutely work) but I wanted a software-based solution so I can do more than 2 buttons if wanted, change behaviour based on the order they are pressed, etc.

 

[Skymaster]

You mean series?

That I guess depends on how the button is internally made. If it's A Normally Open, closing on press then yes, series is correct.
But if they are normally closed, opening on a press, then parallel is correct.
Both are valid and produce the same result.

 

[pixelated]

Yes, I missed the "low".

 

[TerryK]

This thread is drawing out the logistics of how to manage multiple discrete inputs with the associated Active High or Active Low conditions from NO and/or NC devices. Not mentioned yet is contact bounce and the inherent contact race if 2 or more devices are activated simultaneously. Mechanically speaking, multiple contacts will have a small timing separation and code will need to be written to manage that. Some electronic devices with discrete inputs have the electronics designed to deal with contact bounce but in most cases I've found it does not typically hurt to add de-bounce capabilities in the code.

Another issue is how fast is the script/processor and the/any button presses, that is will the GPIOs change in the middle of the script. A good practice is to strobe the GPIOs to a variable/register and use the register contents during the script execution. The script can also be written to pause a bit after being triggered to remove contact race and bounce before latching the GPIOs.

And last, for multiple inputs a decision to use one or more scripts and the logistics/problems of re-triggering a script before completion and multiple executing scripts. That is when to disable and re-enable them.