3D PRINT IT!!!!

(cheer)

Is there something wrong with the products listed when searching for "momentary switch bi-colour led indicator"?

Also, would be interested in your progress - there's a small chance it'll motivate me to do the Pi car audio computer thing that's been sitting on my may-happen-one-day-yeah-right-whatever-meh list for past few years.

Yeah, there was, I searched for 'dual led' and my admittedly short time spent searching at work today yielded no obvious results through Google, so I thought I'd engage the people here and start a conversation - it's rare I've ever been let down when asking something here, plus I can ask follow up questions. :)

Cheers PB though, I'll check the pin outs and see if they're compatible.

Never looked at how those switches work, but it could be a case of running 1 of the leds/colours constantly (acts as shutdown state) and have another turn on via GPIO and a simple bit of code when the Pi boots.

Thanks Ant, I've had a look around and I've decided to just go for a standard button, the LED status isn't going to make much of an impact in practical terms.

I've attached some pictures of the project so far.

Tonight I've been fiddling with some code and getting a power button working (at the moment a fugly switch nicked from an old PC case, but it has the female pin headers, so no breadboard needed :) ).

I had some trouble as when the DAC and Amp are stacked on top of the Pi, they cover all of the GPIO. Some pins are passed up the stack and the Amp on top gives a 10 pin array (pins 1 - 10) to work with. IMG_3284 has the best view of these.

The instructions say to connect the 7" touchscreen up to pins 5 and 6. However, the pins that are hardwired for wake/shutdown are 5 and 6, so I guess this is how they bring the screen on at power on. I've moved the screen to take the 5V power from pin 2 and the GND at pin 9, and fit the switch to cover pins 5 and 6. It's all working and uses this script (albeit mine has a few tweaks in the path append to look in an updated folder on this version of LibreElec, this is cribbed from a site):
 

#!/usr/bin/python
import sys
sys.path.append('storage/.kodi/addons/python.RPi.GPIO/lib')
import RPi.GPIO as GPIO
import time
import subprocess

# we will use the pin numbering to match the pins on the Pi, instead of the 
# GPIO pin outs (makes it easier to keep track of things)

GPIO.setmode(GPIO.BOARD)  

# use the same pin that is used for the reset button (one button to rule them all!)
GPIO.setup(5, GPIO.IN, pull_up_down = GPIO.PUD_UP)  

oldButtonState1 = True

while True:
    #grab the current button state
    buttonState1 = GPIO.input(5)

  # check to see if button has been pushed
  if buttonState1 != oldButtonState1 and buttonState1 == False:
    subprocess.call("shutdown -h now", shell=True, 
      stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    oldButtonState1 = buttonState1

    time.sleep(.1)

What it doesn't do is power off the backlight to the screen. So, the Pi goes off and the screen stays bright white. Using these commands I'm able to turn the screen on and off:
 

echo 0 > /sys/class/backlight/rpi_backlight/bl_power
echo 1 > /sys/class/backlight/rpi_backlight/bl_power 

Echo 0 turns it on, Echo 1 turns it off. What I don't know due to my coding inadequacies is how to shoehorn those commands into the previous script so they work in tandem - so that a push of the power button would wake the system and turn on the backlight, and a subsequent push would shutdown and turn off the backlight. Any ideas anyone please?!

Your final two commands are regular shell (e.g. Bash) whereas your main script is Python (as per the #! line at the start).

What "echo A > B" is does is write content A to file B - the closest equivalent in Python seems to be print:

  print('0',file='/sys/class/backlight/rpi_backlight/bl_power')

But the recommended way appears to be this convoluted thing:

  with open('/sys/class/backlight/rpi_backlight/bl_power','w') as f: f.write('0')

Possibly using buttonState1 instead of 0 and 1 ...and actually looking at the code, I just noticed you've got subprocess.call calling what looks like a shutdown shell command, so you can simply use that for shell commands without needing to translate - possibly changing the shutdown one to:

"echo 1 > /sys/class/backlight/rpi_backlight/bl_power && shutdown -h now"

and adding the inverse for starting up - it seems weird to have this in an endless polling loop (the while true + sleep combo), but maybe that's the only way this stuff works? :/

So I checked and you don't need to (and shouldn't) do the polling method - i.e. constantly checking the status every 0.1 seconds - you can instead simply listens for when changes occur.

See Threaded callbacks in this page: https://sourceforge.net/p/raspberry-gpio-python/wiki/Inputs/

Basically you might be able to swap the while loop for something like this:

def onButtonPress(channel):
	if GPIO.input(channel)
		shell_command = "echo 0 > /sys/class/backlight/rpi_backlight/bl_power && shutdown -h now";
	else
		shell_command = "echo 1 > /sys/class/backlight/rpi_backlight/bl_power";

	subprocess.call(shell_command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

GPIO.add_event_detect(5, GPIO.BOTH, callback=onButtonPress)

That still isn't the greatest code, but it's (possibly) good enough, assuming it works; I don't know Python or understand what I've read of the GPIO stuff, so... *shrug* :)

Definitely interested to see how it all turns out.
I've played with Pis for audio stuff and bought a few DACs and even started making a breakout board for some switches, IR etc.
But had a few too many issues with volumio (I was going headless).

Eventually scraped the idea and went to Chromecast Audios where I want streamed audio.
Stuck them in the bathroom, kitchen, living room, bedroom.

Main use is in the kitchen and occasionally bathroom.

I'll keep the thread updated.

I'll have a go with PB suggestions tonight for the backlight on the screen.

I'm trying to make it as easy to use as possible, so the rest of the family only have to press a power button and then they've got control over the whole thing. To that end, I'll need a volume control as well, so I've been reading this about putting a potentiometer in as a volume knob. It's written for Volumio, but providing I can get the stuff they suggest into Libreelec it should be ok.

In my mind the screen'll be mounted flush (or as flush as can be) in the wall, all wiring hidden away but the power taken to a switched mains socket in a cupboard underneath the worktop. I'll have to find a way to make it easily removable, for upgrades and what not.

I did a wrong. :C

Somehow I've lost all sound. Instead of arseing about trying to put the config right, I'm going to wipe the SD card and start again and put what I know works in, make a backup (!) and then troubleshoot it.

Do you know how to make a backup image of an SD?

Very useful to have at least a basic configured image to go back to if you do a wrong.

I did exactly that to quickly recover from a botched xfce install using fsarchiver. Dunno if that works on an sd card, I've never backed one up.

Aye, I'm gonna get a base setup and make an image - don't really know why I didn't do it the first time round. :C

The method I use is a bit crude but works surprisingly well.
I use "dd" to clone the SD card location (something like /dev/mmblock0) to a network location.

Works on a running system which is nice. You can even run the command through gzip to compress the free space and shrink the storage required for the image. Slows the process down though. Requires a same or larger size SD to restore.

Ah. I was going to suggest the "dd" method but didn't know if it worked on sd cards.

The good old fear of getting if and of the wrong way round

 :-&

Sounds like a really good project. I look forward to seeing the results of it all.

Here's a preview: