Powering off via UI while using a Mausberry Circuit

caver01

@cyperghost The only risk I see with the transistor here is if the momentary button wired to the Mausberry is not connected to ground on one of its poles. Maybe even that does not matter, but the diagrams I have seen including the one linked above has the emitter connected to ground that is common to both the switch and the Pi. I may look at the Mausberry circuit closely to see if I can trace one of the button terminals to ground. If not, I may just try it anyway.

cyperghost

@caver01 Well take a voltmeter and measure switch pins against ground. I hope that there are 3.3V ;)

caver01

@cyperghost Good idea!

caver01

@cyperghost well, that NPN transistor totally worked!

First, I modified my mausberry script by adding another variable for GPIOpin3 which I set to 18.
Then, I added two more echo lines to export the pin and to set its direction to OUT:

#!/bin/bash

# need to call this from /etc/rc.local

# End Emulationstation if condition of running binary is true (v1.59)
# v1.0 07/21/17 by cyperghost - Inital run 
# v1.1 07/22/17 - Added chown command to set right user permission for creating es-shutdown // cyperghost
# v1.2 07/23/17 - Some small improvments, easier to maintain, removed echo, removed else branch // cyperghost
# v1.5 07/27/17 - Great step to exit ES even if emulators is running by runcommand.sh are started // meleu
# v1.55 07/29/17 - all kudos go to @meleu for his alltime genious RegEx hack! // meleu
# v1.56 07/30/17 - All emulators will be detected. // meleu
# v1.58 08/02/17 - generel method: Use PPID to detect child PIDs now (ScummVM fix) // cyperghost
# v1.59 08/03/17 - nothing new, just polishing the code // meleu
# I just checked with SSH command - it saved my metadata! Maybe you need to extend sleeptimer!
# greetings @pjft for his famous favorits and @meleu for his RegEx sniplets and his constant help! 

#this is the GPIO pin connected to the lead on switch labeled OUT
GPIOpin1=23

#this is the GPIO pin connected to the lead on switch labeled IN
GPIOpin2=24

#this is the GPIO pin connected to the 1k-ohm resistor, leading to the base of NPN transistor (emitter and collector to power switch poles)
GPIOpin3=18

echo "$GPIOpin1" > /sys/class/gpio/export
echo "in" > /sys/class/gpio/gpio$GPIOpin1/direction
echo "$GPIOpin2" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio$GPIOpin2/direction
echo "1" > /sys/class/gpio/gpio$GPIOpin2/value
echo "$GPIOpin3" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio$GPIOpin3/direction


while true; do
    power="$(cat /sys/class/gpio/gpio$GPIOpin1/value)"
    if [[ "$power" == 0 ]]; then
        sleep 1
    else
        emucall="$(sed -n 4p /dev/shm/runcommand.info | tr -d '\\"' | tr '^$[]*.()|+?{}' '.')"
        if [[ -n "$emucall" ]]; then
            emupid="$(pgrep -f "$emucall")" 
            pkill -P "$emupid"
            kill "$emupid"
            sleep 4
        fi    

        espid="$(pgrep -f "/opt/retropie/supplementary/.*/emulationstation([^.]|$)")"
        if [[ -n "$espid" ]]; then
            touch /tmp/es-shutdown && chown pi:pi /tmp/es-shutdown
            kill "$espid"
            exit
        fi
        # End Emulationstation if condition of running binary is true

        sudo poweroff
    fi
done

Finally, I added the line:
echo "1" > /sys/class/gpio/gpio18/value to the emulationstation.sh in place of the sudo poweroff in
that file.

I soldered up two components, an NPN transistor and a 1k-ohm resistor. The resistor goes on the middle pin of the transistor, and the outside pins go in parallel to the power switch connected to the mausberry. Then, on the opposite end of the resistor, I connected this to GPIO18 as specified in my updated script.

Now, when I select SHUTDOWN in the ES menu, it completely powers off.

Thanks for all of your help!

caver01

I am going to create a new thread for working on the Python version of the BASH script. I think that makes more sense than burying it here.

meleu

@caver01 said in Powering off via UI while using a Mausberry Circuit:

Finally, I added the line:
echo "1" > /sys/class/gpio/gpio18/value to the emulationstation.sh in place of the sudo poweroff in
that file.

I see a problem here. This line will be lost after the next EmulationStation update you do on your system.

cyperghost

@caver01
Wow that's cool ;) Nice approach ....

As @meleu already said.... on next update the script gots lost. Therefore I would modify the MB shutdown script and set the echo 1 command, before the exit command... maybe with a sleep 0.5. The side effect is, that the mausberry is only shutting down, if the emulationstation binary is running (cause of the if-clause)

@meleu I finished GQ ;)
@meleu What do you think about this shutdown-script here? It should be quicker than the original one.

caver01

@meleu Yes, it will. but what can I do?

@cyperghost I don't see how changing the mausberry script will help with the soft shutdown in ES. meleu is saying that after the update, my ES will lose the custom shutdown I setup which triggers GPIOpin18. No matter what happens, ES updates will always revert to the normal shutdown, while I need it to trigger the pin. Nothing in the mausberry script will fix that. I will have to keep updating emulationstation.sh.

cyperghost

@caver01 ~~No, you set the echo 1 in your mausberry between before the exit command~~ sorry thats wrong!

        espid="$(pgrep -f "/opt/retropie/supplementary/.*/emulationstation([^.]|$)")"
        if [[ -n "$espid" ]]; then
            touch /tmp/es-shutdown && chown pi:pi /tmp/es-shutdown
            kill "$espid"
            # Set here your echo command + && sleep 0.5
            exit
        fi
        # End Emulationstation if condition of running binary is true

meleu

@meleu I finished GQ ;)

Nice! Let's move to Snake Rattle 'n Roll. I'll just try to make some score for Time Pilot (MAME ROW #51).

@meleu What do you think about this shutdown-script here? It should be quicker than the original one.

Good catch at that logic! :-)

@caver01 said in Powering off via UI while using a Mausberry Circuit:

@meleu Yes, it will. but what can I do?

Hold on a little. I'm taking a look into a nice way to do it. ;-)

caver01

@cyperghost Oh, does ES leave a trace in /tmp that a shutdown has been requested by the UI? That's clever. So the MB script will initiate shutdown if the button is pressed, and it will do the echo to the transistor if shutdown is requested by ES. Correct?

Wait a sec, I still don't follow. I need to trigger the transistor when a shutdown is requested from within ES using the UI. I need to do this instead of a soft shutdown, otherwise, the MB circuit won't know that the shutdown has occurred.

cyperghost

@caver01 sorry edited this
maybe @meleu gots a solution ... i know only the emulationstation path

EDIT:
Yes... for restart system, shutdown system and restart ES there are temp files named by the usecase

and that's the way to prove ;) within the mausberry... you're right ;)
My first attempt does not work as the loop is only triggered if the MB-button is pressed. But as it checks some file you can use this via [[ -f /tmp/es-shutdown ]] to do some things ;) I guess to use this check into the power = 0, do loop and to set power = 1... this will end the loop and the shutdown is initiated.

But let @meleu look into... ;) He knows the system much better

cyperghost

@caver01 @meleu

I think the extended "mausberry" script with 3 GPIOs will look like this --> https://ghostbin.com/paste/5f8t6
But it may happen that ES deletes the tmp file BEFORE the mausberry script will catch it (During the 1s sleep) - That's nasty ;)

I think @meleu will introduce the inotify thing now as it acts as an "interrupt for filesystems" ;)

meleu

@caver01 said in Powering off via UI while using a Mausberry Circuit:

@meleu Yes, it will. but what can I do?

Try this solution here: https://retropie.org.uk/forum/topic/12895/ensuring-es-gracefully-finish-and-save-metadata-in-every-system-shutdown

Let me know if you find some problem. ;-)

caver01

@meleu This is cool, and I am going to try setting up the service as it greatly simplifies the Muasberry script (or any shutdown button technology for that matter). However, I don't believe it will satisfy the problem identified in the original post here.

The issue is that the Mausberry circuit does not notice that the shutdown has occurred unless it was triggered by the hardwired button. So, selecting QUIT, and SHUTDOWN in ES leaves the circuit still powered ON, and subsequently, the Pi is in low-power sleep mode. Worse, the MB circuit is now stuck thinking it is ON, and won't cut power to the Pi.

If you trigger the shutdown with the wired power button, the circuit starts paying attention to the GPIO IN pin that you have configured in the mausberry script. Once that drops, it cuts power. But, crucially, it seems to ignore that pin until it detects a short on its wired hardware button/switch.

So far, the only way to get around this problem for me has been to hook into the ES shutdown command and send a signal to another GPIO pin which in turn triggers a transistor wired in parallel with the mausberry switch. Instead of actually shutting down, this makes the mausberry circuit think I just pressed the physical button. It then triggers its GPIO OUT pin, which the mausberry script is watching, does the safe shutdown, and the circuit is now 'listening' for GPIO IN to drop --then it cuts power completely.

It's a clever circuit, and your new service will help simplify things for this and similar solutions, but the locked up circuit after software-triggered shutdown remains.

caver01

@meleu So, now I am thinking that I can simply add my echo command to your service which should give the circuit a 'tap on the shoulder' and get it to start watching for the Pi to do down. Is that your thinking too?

meleu

@caver01 yeah, put that command in the beggining of killes.sh. ;-)

caver01

@meleu that didn't work. So, I reverted emulationstation.sh back to default, then followed your instructions to create the service, setup the killes.sh in /home/pi/bin

As far as I know, it saves the metadata, but what it doesn't do is trigger the mausberry circuit.

I switched back to my original pyton script for the circuit. Then I added these lines at the beginning of killes.sh:

#this is the GPIOpin connected to the 1k-ohm resistor, leading to the base of NPN transistor (emitter and collector to power switch poles)
GPIOpin=18

# Export the GPIOpin and and set direction
echo "$GPIOpin" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio$GPIOpin/direction
# Trigger the transistor on GPIOpin to short the mausberry switch
echo "1" > /sys/class/gpio/gpio$GPIOpin/value

I need to export the pin used for the transistor because I am not using the BASH script, and nothing in the Python script uses the transistor. Even if I did define the transistor pin in the python script, I would still need to export it here (or somewhere) because python interacts with GPIO differently than BASH and does not need the pins exported to user space.

As a test, I can still drop to command prompt and enter the echo commands above manually and it will trigger the circuit and power down, so it should be possible.

I am not certain that shutdown is even invoking the killes.sh.

caver01

I though of another problem incorporating the Mausberry trigger—reboots will become shutdowns. That’s not the end of the world, but worth mentioning.

caver01

@meleu Ok, so I think I know why your solution did not work for my case. I hadn't flagged my killes.sh as executable. I am hoping that resolves the problem (I was inadvertently NOT watching the other thread when you added that step.) I am not at home to try it, but I did the CHMOD remotely and I am anxious to test it. If my addition to the killes.sh triggers my mausberry circuit to turn off, we have a great solution. This would simplify mine and many other 3rd party shutdown needs as handling the metadata issues safely. It's a smart idea.

One bit of fallout I mentioned above with my change is that every restart would trigger my mausberry to cut power. I would lose the reboot ability, but this is a worth sacrifice for simplifying everything else in my opinion.

Also, I plan to drop the use of the mausberry script completely--I am shifting to my GPIO inputs solution--GPIOnext--to handle the shutdown trigger. I will connect the mauseberry's input wire to a 3.3v GPIO rail.