Starting show with external button

[micropuller]

Last year I've used the FPP with great succes. Now I'd like to expand my show by adding a "start" button.
I haven't used events before, but after some searching I found this topic: http://falconchristmas.com/forum/index.php/topic,1454.0.html
The thing is, that I can't get it to work.

As a test, I uploaded an audio-file.
I made a playlist called "Test" that only has this file in it. When I try and play it on the status page, everything works.
Then, I downloaded the StartPlaylist.sh file, changed the filename to "Test" and uploaded it. When I click the "view" button, it seems everything is ok.
I then added an event that triggers the "StartPlaylist" script (just a quick question: what does event ID stand for? I just left it at 1/2)
Finally, I activated the GPIO input pin and restarted FPPD.

I set up a start button, using the example I found here: http://falconchristmas.com/forum/index.php/topic,1109.msg12394.html#msg12394 and connected it to 3.3V, Gnd and GPIO4 (pin 7)

Could someone please tell me what I'm doing wrong?

[Materdaddy]

You edited the wrong part of the StartPlaylist script.

Change it to this:

#!/bin/sh
###########################################################
# StartPlaylist.sh - Start a playlist on the local system #
#                                                         #
# The Playlist will play once and then stop.              #
###########################################################

# Edit this line to hold the playlist name in quotes
PLAYLISTNAME="Test"

# If you want to start on a specfic numbered entry in the playlist
# then put the entry number inside the quotes on the line below
STARTITEM=""

fpp -P "${PLAYLISTNAME}" ${STARTITEM}

[micropuller]

I actually just figured it out and came back to change my post 
But thanks very much for the reply!

[micropuller]

I'm probably overlooking something again.

I had my board set up like this:
- start button to GPIO4 (falling), triggering an event (Startshow) that started a script (StartPlaylist.sh) to play my playlist "Test"
- two events ("GPIO-On" and "GPIO-Off"), using script "GPIO-On.sh" and "GPIO-Off.sh" to turn Pin 0 (GPIO17) on and off.
- outputs GPIO5 and GPIO6 controlled by the sequence (channel 151 and 152)
Everything was working fine.

Today I've added a PiFace Digital 2 to my setup.
- changed startbutton to use PiFace 1 (200)
- changed events to "GPIO 205 On" and "GPIO 205 Off", using script GPIO_205_On.sh and GPIO_205_Off.sh, to turn pin 205 on and off.
- changed outputs GPIO5 and GPIO6 to GPIO206 and GPIO207
Now, when I push the start button, my playlist starts playing, it activates the soundfile and the sequence and also output 206 and 207 on the Piface (leds light up), but output 205 isn't triggered (turned on at the start and off at the end of the playlist)
I also can't trigger the events "GPIO 205 On" and "GPIO 205 Off" manually.

Is there something I'm doing wrong or forgot to set up?

[CaptainMurdoch]

- changed events to "GPIO 205 On" and "GPIO 205 Off", using script GPIO_205_On.sh and GPIO_205_Off.sh, to turn pin 205 on and off.

This is an issue with the gpio on/off scripts in the repository.  There is another command line option that you must pass when using a PiFace.

Add a "-p" command-line option to the gpio command of your two On/Off scripts so they look like this:

# Make sure the pin is setup for output
/usr/local/bin/gpio -p mode ${PIN} out

# Turn on the pin
/usr/local/bin/gpio -p write ${PIN} 1

That "-p" is only necessary for the PiFace outputs.  I fixed my local copy of these scripts to auto-detect whether to add the -p or not and I'll get the fixed versions committed to the script repository.

[micropuller]

I changed the scripts and now when I trigger the event manually, the output turns on and off.
Strange thing is, that when I incorporate the event into a playlist, the output is turned off as soon as the next entry starts.

[CaptainMurdoch]

Is this the same playlist you showed earlier or a different one?  As far as I know, there shouldn't be any reason the output would turn off unless your channel output config is using that output or some other script is running to turn it off.  I haven't tested that code in a while though.

[micropuller]

Before I added the PiFace, I had it playing a complete sequence synchronized with an MP3 and everything was working as expected.
When I noticed that the led didn't stay lit, I removed the sequence and tested it using just an MP3 file. The led still turned off.
When I put a 5 second pause between turning on the GPIO pin and playing the file, the led stayed on for 5 seconds and then turns off. If I delete the pause, it just flashes briefly.

[CaptainMurdoch]

Can you disable your two GPIO channel outputs and see if that has any effect?

[micropuller]

When I disable the GPIO channels that are used in the sequence, the GPIO channel that is used for the event works as expected (stays on when the next entry starts)

[CaptainMurdoch]

Can you test to see if either GPIO channel output breaks it or if it is a specific one?  That should indicate whether it is a code issue or a config issue.

[micropuller]

It doesn't matter which channel is enabled (I've also tried enabeling channel 204), as soon as a GPIO output is enabled, the GPIO channel that was activated by the event is turned off when the next entry starts.
Just disabling the E1.31 output while leaving the GPIO channels enabled didn't help.

[CaptainMurdoch]

I double checked the FPP code and couldn't see any reason this would be happening so I took a peek at the wiringPi library code which is used to control the GPIO outputs.  The issue you are seeing is a byproduct of what appears to be an optimization in the wiringPi code.  When wiringPi is initialized, it reads in the current state of the PiFace GPIO outputs and stores that state in a cache.  This data is actually stored in a 'byte' value and is read/written as a full byte that holds data for 8 channels.  When a wiringPi write happens, the appropriate bit in this byte cached value is updated and the new byte value is written out.  When you update a GPIO output outside of wiringPi, it's internal cache becomes invalid and it wipes out your change on the next write.  So if you were to start a sequence and then manually turn on a GPIO output, your change would be immediately reverted when the next sequence frame was played.

I have emailed the wiringPi author to see if he has any suggestions.  Removing the cache would mean that every write requires a read which may not be an option because of the performance impact.  This also means that the library is not really thread-safe.  One workaround may be to add a way to toggle the GPIO outputs via the 'fpp' helper program instead of using the 'gpio' utility provided by wiringPi.  fpp would tell the main fppd daemon to toggle the output port.  This would work for this use case and require no modification to wiringPi.  I will add a note to the TODO to look into this.

For now, you could work around this by creating a Pixel Overlay model for one channel and assigning that channel to a 3rd GPIO channel output for GPIO 205.  Then you can use the fppmm helper utility to enable that Pixel Overlay model and turn it's channel on/off.  This will allow you to control the GPIO pin through FPP but from the command line.  I will still add a note to look at the other solution mentioned, but this should get you working for now.

[zoobmarine]

Hi, im trying to do the same I bought a big button, but the switch is a microswitch, im really a newbie in electronics, so I would like to request your advise before I smoke everything up, Im attaching some pictures of what I pretend to connect and hope you can point me in a good direction, thanks



¿Question is, where do I connect the GPIO?

Thank you

[CaptainMurdoch]

For some reason I can't see the image/attachment in Tapatalk, but if you hit F1 while on the GPIO input config page in FPP that will bring up the help for the GPIO inputs.  On that help page is a simple circuit diagram showing how to connect a button to the GPIO inputs.  On the GPIO config screen itself it notes in the right column which header pin should be used for each GPIO input.