Multi Switch Shutdown Script!

quicksilver

@Initial_G I didn't play with the pulse times, but if you get that part of it working the way you like it id be interested as well.

Quackwalks

@quicksilver I'm also curious to know what steps I should take to have a proper power button and fan with the argon one case.

quicksilver

@Quackwalks place the multi_switch.sh on your pi somewhere like /home/pi/RetroPie/scripts/multi_switch.sh and make sure it has executable permissions. Then modify your argononed.py script (im assuming you have already installed the default argon one script) located at usr/bin/argononed.py and look for this section and modify it to look like this:

if pulsetime >=2 and pulsetime <=3:
		#os.system("reboot")
		os.system("bash /home/pi/RetroPie/scripts/multi_switch.sh --es-restart")
	elif pulsetime >=4 and pulsetime <=5:
		#os.system("shutdown now -h")
		os.system("bash /home/pi/RetroPie/scripts/multi_switch.sh --es-reboot")

The fan script utility is installed and can be modified using the booklet instructions that came with your argon one. I cant find my instructions so youll have to look that up.

Quackwalks

@quicksilver You are awesome.

Rion

@quicksilver said in Multi Switch Shutdown Script!:

@Initial_G I didn't play with the pulse times, but if you get that part of it working the way you like it id be interested as well.

Yea me to. 😊

Ashpool

A general thanks to the folks having an Argon1 and who are tinkering with the argon script to call cyberghosts one!

But I still have some questions: The Argon1 Manual says for action Long Press >=5s the Function is a Forced Shutdown, as this is working even without installing the script, my assumption is: a >=5sec Press simply cuts the power and doesn't provoke any script (So nothing of the save stuff-things, that a controlled shutdown from cyberghosts script will be invoking is performed) :( Inside the argononed.py I cannot even find anything that can be configured 'bout the >=5sec timing.
So, I will state two hypotheses I want to have clarified:
a) a correct shutdown (writing Meta Stuff/etc.) with cyberghosts script would mean something like this

os.system("bash /home/pi/RetroPie/scripts/multi_switch.sh --es-poweroff")

b) a shutdown via the Argon1 Case Button with a press >=5sec is, from within a running system, a worst case scenario as it just cuts the power. So a regular Emulationstation Shutdown should be used instead (If the 3-5sec press is used for a restart)?

cyperghost

@Ashpool You should use a correct name to tag me ;)
Nevertheless, I don't own a ArgoneOne. But there is a small IC that is attached to I2C-bus on this housing. AFAIK it writes only two values to the flash, one for a reboot and one for shutdown. So the case "knows" how to enable/disable the power source.

So you are correct - by using the multi_switch call you can perform a save shutdown but the long press action with the sudden power cut is performed by the ARGON ONE hardware. No chance to change anything with a simple script.

You can take a look to BATOCERA - here the script was modified to perform some more actions. Take a look at the script here

Rion

@cyperghost is correct. Sadly without re flashing the IC there is nothing we can do.

I more in depth explanation can be found here by Spiros Papadimitriou.

Read under hardware protocol.

Maybe something can be learned from Spiros Papadimitriou rewrite of the script?

Ashpool

@cyperghost & @Rion
Thanks for the confirmation that the forced shutdown truly is "hardwired". And the GitHub Link to Spapadim was interesting to read (besides (sorry can't restrain myself here) that he is getting milliseconds wrong). Especially this part is something that I hadn't considered as a possibility so far:

After a "shutdown" request, the board will wait for a brief period of time and then cut off power anyway. Therefore, it is critical that the system shutdown command is issued ASAP. Unfortunately, it seems that this poweroff delay is hardcoded into the board's firmware.
If your shutdown sequence takes longer than 1-2sec (e.g., if you mount network drives that need to be flushed and umounted, for instance), it would be better to avoid using the case's power button to initiate a shutdown.

As I am, at the moment, away from home during the next week, i cannot check the time for multiswitch.sh shutdown on my setup & if maybe the only safe way to perform a shutdown via multiswitch.sh initiated by the argon1 script would be using the double tap call (Edit: At least that would take away the 21..22..23...(24.25)...counting fear)

P.S.: At least for my retroflag cases (Raspi3B(+)) multiswitch.sh is still in the "sliced bread"-(of usefulness)-league ;)

Idelacio

I've installed the script on the NESPi 4 case set up with Retropie on an SSD.

And they work... mostly. One issue though:

When switching off the device correctly shuts down the OS and then... stays on. Lights off etc but the fan is still spinning. I can;t switch it back on from this state either, have to unplug from the power and plug back in.

Something similar happens with the Retroflag scripts, only with those it will boot back up again immediately after shutting down the OS without me doing anything.

Now all this said I should point out that I'm running a 512GB SSD from the USB2 slot so that may be causing issues? Pi 4 just flat out won't boot anthing above a 256GB 2.5" SSD from USB3... I've had no issues through USB2 though.

Any solutions to this issue?

cyperghost

@idelacio you should tag people to get response. Nevertheless it's easy to fix. I have written a solution here. https://github.com/RetroFlag/retroflag-picase/issues/90#issuecomment-676587374

jamrom2

@cyperghost Hello. I have a question on a Mausberry shutdown script I'm hoping to get advice on before I go down the Support road from the manufacturer. I hear the support is not that good, so I'm throwing my last dart.

I converted an Intellivision Flashback unit into a Retropie, using a Mausberry for the shutdown. This is my 2nd unit I've built with no issues. The newest image of Retropie, whatever O/S it's built on, doesn't seem to like the Mausberry script and leaves the shutdown sequence hanging, never powering off.

I tested the Mausberry with and older SD card I had with the previous Retropie build (4.6.7)... works like a charm. The new Retropie image (4.7.1) fails.

Would you have any idea why I would be getting this issue based on your knowledge? I'm completely out of my league. I tried all the mechanical stuff, changing GPIO values in their script. Checking conections... etc. Nothing work. I've used a Mausberry in my other unit for over 5 years, and this one now about 9 months... everything was good until I moved up to the new image.

Regards,

JR

BTW.. I use your script on my 3rd Retropie unit that's built into a MegaPi case. Works like a charm! Thanks!

Here is the shutdown log... minus all the [OK...] statements.

Stopped Dispatch Password Requests to Console Directory Watch
Stopped Forward Password Requests to Wall Directory Watch
Stopping Network Time Synchronization... Stopping Update UTMP about System Boot/Shutdown...
Stopping Load/Save Random Seed...
Stopped Load Kernel Modules.
Stopped Load/Save Random Seed.
Stopped Update UTMP about System Boot/Shutdown.
Stopped Network Time Synchronization.
Stopped Create Volatile Files and Directories. Stopped target Local File Systems.

Unmounting /boot...
Unnounted /boot.

Reached target Unmount All Filesystems. System Check on /dev/disk/by-partuuid/97a6378b-01.
Removed slice system-systemd\x2dfsck.slice.
Stopped target Local File Systems (Pre).
Stopped Create Static Device Nodes in /dev
Stopped Create System Users.
Stopped Remount Root and Kernel File Systems.
Stopped File System Check on Root Device. Reached target Shutdown.
Reached target Final Step.
Started Power-off.
Reached target Power-Off.
Stopping Restore / save the current clock... 59.9899221 reboot: Power down

cyperghost

@jamrom2 looks like there is a overlay file loaded inside your /boot/config.txt

Take a look for a entry like
dtoverlay=gpio-poweroff
and remove this

jamrom2

@cyperghost You nailed it! It was at the bottom of my config.txt...

I had loaded both the Mausberry shutdown script and your script because this build I made will be for 3 different boxes I have. I just "#" it out as I will need it on my MegaPi Case.

Thank you very much, it was the last item on my list and has been troubling me for months.

Many kudos to you and Happy New Year!

JR

cnoto

@cyperghost I am using your generic script above for a shutdown with a momentary button on a pi3a and Im seeing the following message:

Kernel panic - not syncing attempting to kill init!

Any thoughts why im seeing this?

Many Thanks,

Idelacio

@cyperghost

Oops, sorry for the slow reply.

Yup! That worked perfectly. Thanks! <3

ExarKunIv

@cyperghost I have used this to shutdown my pi.
But i have come across a few posts saying that it can be used to shutdown a emulator or restart ES.

Can it be used to finishing killing xinit after exiting a game?

cyperghost

@exarkuniv as long as the call is

Runcommand.sh
Xinit
X Application
And all calls are children of the shell parent process then it is very likely that it will work. But never tested before

ExarKunIv

@cyperghost yes i have the command going through run command to lunch the game

here is my command that i have for my emulator.sh

dhewm3 = "XINIT:/opt/retropie/ports/dhewm3/dhewm3"
default = "dhewm3"

so i know that it calls it correctly. well i think it does

what do i need to do to set the shutdown script up. i have tried to follow your info as best as i could and i still get lost on it.

quicksilver

@exarkuniv there is an issue with dhewm3 that the x window does not close properly after exiting the game. I was going to report it on the github page but never got around to it. It's likely to be a raspberry pi related issue or it could be because we aren't running a full desktop environment. Not sure if the dev would/could help.

There is a setting you can turn on via raspi-config that allows you to kill an x session using cntrl+alt+backspace. That was my workaround when trying to close dhewm3.