Start a script alongside EmulationStation (not on boot)

Vague Rant

Hi people. I recently got a Raspberry Pi 3 on which I'm running RetroPie, and I also installed Pi-hole, so the rest of my home network relies on the Pi being switched on all the time. I also have PIXEL installed so I can do things like make this post, so I'm frequently in and out of EmulationStation, but only rarely perform reboots.

I'd like to use a Wii Remote/Classic Controller to control EmulationStation and play games, but I only need to have a Wiimote synced when I'm actually planning to use EmulationStation, not on every bootup, and I need to be able to sync a Wiimote without a reboot, since I'll generally not be launching EmulationStation from a fresh boot anyway (because of the Pi-hole).

I already have everything rigged up as per the Wiimote Controller documentation (minus attaching the Wiimote on boot, which I don't need), so I've got an attachwii.sh I can run from the terminal to connect a Wiimote on-demand and only when I need to, but what would be even more convenient would be if attachwii.sh ran every time I launched EmulationStation, so I can jump from "desktop mode" into "games mode", sync a Wiimote and go.

Thanks for any help!

Clyde

@vague-rant The simplest way should be adding a line "emulationstation" at the end of your script and put the script in the directory /home/pi/bin (you may have to create it). This directory is special in that it's part of the path Retropie looks for commands in.

Vague Rant

Thanks, that's sensible enough. Currently I have EmulationStation as my bootup mode, so I'll need to switch that to manually booting via my script, but that's not an issue. I guess my next problem is that once attachwii.sh triggers the "searching" state it absolutely mauls my wifi. That's fine once I've connected the Wiimote (wifi goes back to normal), but once I've finished playing games and disconnect the Wiimote, the Pi goes back to desperately searching for the Wiimote again (hammering Bluetooth and I guess crowding out all wifi connections in the process). I don't know enough to know what exactly is doing this. hcitool? wminput? How can I tell the Pi that I want it to stop searching for the Wiimote again once I've told it to start?

EDIT: For reference, here's my autostart.sh (fake MAC address):

#!/bin/bash
sleep 1 # Wait until Bluetooth services are fully initialized
hcitool dev | grep hci >/dev/null
if test $? -eq 0 ; then
	wminput -d -c  /home/pi/mywminput WM:MA:CA:DD:RE:SS &
else
	echo "Bluetooth adapter not present!"
	exit 1
fi

If anyone could tell me which one of the things in here is eating my wifi and how to make it stop, I'd appreciate it very much. I'm not savvy enough to understand what the script is actually doing, except that there's the if statement that's like "if A, then B (wminput)" ... is that step repeating endlessly until a Wiimote shows up, or does it just occur once?

mitu

@vague-rant said in Start a script alongside EmulationStation (not on boot):

is that step repeating endlessly until a Wiimote shows up, or does it just occur once?

The script does not loop endlessly, it's doing a bluetooth scan for devices and if it founds the wiimote runs the wminput program.

Vague Rant

Hmm. That confuses matters. What's the correct way to disconnect a Bluetooth device? I've just been shutting off the Wii Remote, but perhaps this leaves either wminput or hcipolling for the device and not receiving any response?

EDIT: No, it's not a matter of disconnecting. As soon as I run attachwii.sh my Internet goes to hell, before I connect anything. I can fix it with a sudo pkill wminput.

EDIT2: Connecting a Wiimote also completely fixes my Internet, of course. And disconnecting it kills it again.

EDIT3: @mitu said in Start a script alongside EmulationStation (not on boot):

@vague-rant said in Start a script alongside EmulationStation (not on boot):

is that step repeating endlessly until a Wiimote shows up, or does it just occur once?

The script does not loop endlessly, it's doing a bluetooth scan for devices and if it founds the wiimote runs the wminput program.

At what step is the script checking whether the Wiimote specifically is available? From a lay reading, it kinda looks like it's just running hcitool dev and doing stuff if there's ... a response that's not null? Sorry, I don't follow the grep hci >/dev/null. It's searching the piped output of hcitool dev, but for what exactly? Nothing that identifies the Wii Remote from what I can see. (But I don't know what I'm talking about, I'm getting ahead of myself.)

Basically, doesn't this script just run wminput if hcitool dev gives basically any response at all (like ~~other, non-Wii Remote bluetooth devices~~ itself, hcitool dev lists Bluetooth radios)? EDIT: Yes, all this step is doing is checking that Bluetooth is up.

EDIT4: Yeah, it's that. It greps for hci as in hci0, hci1, etc. I have a Bluetooth ~~keyboard~~ radio on hci0, so this grep sees that and triggers wminput.

pi@retropie:~ $ hcitool dev | grep hci >&1
	hci0	MY:BT:KE:YB:OA:RD

EDIT5: Ultimately this means that the wminput daemon is hammering the attempt to pair with a Wiimote that may or may not be available. Maybe it could instead grep for the Wiimote's MAC address in the output of hcitool dev? I'm going to give that a try.

EDIT6: I now understand that the hcitool dev | grep step is just for checking that Bluetooth is up, not for the availability of the Wii Remote, so it's fine as-is. This leaves open the question of how to handle wminput's network-destroying behavior when it doesn't find the Wii Remote it wants to pair with.

EDIT7: So hcitool scan is a good way to check if a specific device is available, I would assume we could grep that similar to the grep for hci in order to find if the Wiimote we want is available, any only then start the pairing process ... but this is really the soft end of the problem, if you started attachwii.sh without intending to connect a Wii Remote then what are you even doing. It's a nice safety step in case you're insane I guess, but the real issue is that wminput keeps trying to reconnect after the Wiimote gets disconnected, not that it tries to connect before it's available. I suspect there must be a better solution to this than sudo pkill wminput. Some kind of way to make wminput just give up after 10 seconds of failing to connect to the device it wants? I'll try to look into how wminput works some more.

EDIT8: OK, this looks pretty simple actually. The script is running wminput with -d, which is equivalent to running it with -q (quiet, hides all output but errors), -r (reconnect after wiimote disconnect) and -w (wait indefinitely for wiimote). All that should really be necessary is running the script with -q and maybe -w. This does leave reconnecting down to manually launching attachwii.sh again, but that's infinitely better than "no wifi but you can connect Wiimotes as much as you want" for me. I'll have a test of what wminput does when it fails to find the Wii Remote it wants without -r enabled.

EDIT9: This seems perfectly workable?

Socket connect error (control channel)
unable to connect

This is with just -q, so no "waiting" (pushing to connect forever) and no pushing for the reconnect either. So the Wiimote needs to be ready in the ~10s or so that wminput looks for it before giving up, and if user needs to retry or reconnect again later, they just have to rerun attachwii.sh. My Internet only really goes to hell for the period between starting wminput and the connection going through, which is fine. So, the final attachwii.sh I'm using looks like this:

#!/bin/bash
sleep 1 # Wait until Bluetooth services are fully initialized
hcitool dev | grep hci >/dev/null
if test $? -eq 0 ; then
	wminput -q -c  /home/pi/mywminput WM:MA:CA:DD:RE:SS &
else
	echo "Bluetooth adapter not present!"
	exit 1
fi

EDIT10: To come full circle, this is how I edited my/usr/bin/emulationstation:

clear
tput civis
sudo attachwii
"/opt/retropie/supplementary/emulationstation/emulationstation.sh" "$@"
if [[ 0 -eq 139 ]]; then
    dialog --cr-wrap --no-collapse --msgbox "Emulation Station crashed!\n\nIf this is your first boot of RetroPie - make sure you are using the correct image for your system.\n\nCheck your rom file/folder permissions and if running on a Raspberry Pi, make sure your gpu_split is set high enough and/or switch back to using carbon theme.\n\nFor more help please use the RetroPie forum." 20 60 >/dev/tty
fi
tput cnorm

Minor note: I renamed my attachwii.sh to just attachwii and I threw it in /usr/bin because I'm super lazy.

Clyde

@vague-rant Wow, what a wall of text. =:o ;) So, edits 9+10 are the final solution? Thanks for sharing all of it for others who might have the same problem.

Being lazy is absolutely okay. /usr/bin is as good as ~/bin for this purpose; the pros and cons of both approaches are mostly academical or a matter of taste.

Vague Rant

@clyde That's right, edit 10 solved my initial query from the topic post, and edit 9 solved the second problem of poor wifi performance caused by wminput.

I think for most users who are trying to fix the latter issue, wminput -q -w would be perfectly acceptable. This way, wminput will keep searching (-w, waiting) for the Wiimote until it connects (clobbering wifi in the process). The "risk" here is that you can't find your Wiimote, or it's out of battery or something, so your Internet will go dead until you manage to get it synced. For me, when the entire network is relying on the Pi maintaining its connection, I'm better off with it timing out "just in case" the Wiimote isn't available, vs. the extra convenience of being able to connect any time after EmulationStation starts.

The biggest loss here is not being able to reconnect Wii Remotes after a disconnect, e.g. because of drained batteries, especially if it happens mid-game. Presumably you can SSH in and run attachwii again whenever you're ready to reconnect. Not terribly pretty, but for users who need their wifi up it's the best tradeoff I can see, short of changing how you handle your connections (e.g. wired internet, separate Bluetooth dongle, etc.)

There's probably a middle ground somewhere where you have a version of attachwii running in the background that periodically runs an hcitool scan and greps the result for your Wiimote, launching a wminput -q [-w] to reconnect if it finds it. Depending on how often you ran the scan it might not have the same devastating effect on your wifi, and it would otherwise be similar to running wminput -d, in terms of getting you (re)connected at arbitrary times. I'm just spitballing here though, I'm not sure how much impact hcitool scan has on wifi performance on a Pi 3 or other setups where BT/wifi interference is a major issue. For all I know, running hcitool scan constantly is just what wminput is doing behind the scenes that's causing all the problems.

EDIT: I also quickly threw together /home/pi/RetroPie/roms/ports/Attach Wiimote.sh:

#!/bin/bash
attachwii >/dev/null 2>&1

This can be run from the Ports menu in EmulationStation to sync the Wiimote without having to exit to command line to do it. It's of limited use, basically just if you forget to connect or get disconnected while you're in the EmulationStation menu. It's no help if you get disconnected mid-game, ssh is still the best option there currently.