Programmable?
-
I googled sh file and it's like a windows bat file. That means we can run any kind of terminal commands from it, including starting background softwares or even directly controlling the LEDs from there. I haven't tested anything yet but this sounds promising.
I'm swamped with stuff to do until saturday, unfortunately. Oh well.
-
Anyone had any luck finding an useful sh file? I found a few but nothing that seems to get called when launching specific game or system etc.
-
I'm going from memory and it's late, but it would seem that in most cases, a system's "/opt/retropi/configs/*/emulators.sh" calls out to "/opt/retropie/supplementary/runcommand/runcommand.sh" for instructions on how to launch a given file based on which emulator you have chosen to launch it with. I've only noticed a few "ports" to deviate from from that, but there are probably only a few others.
I imagine that if you added the LED behavior to "runcommand.sh", then a specified system could theoretically initiate a certain LED despite the emulator chosen. I might be 167% off base with this as it's gleaned from a cursory examination and is now being relayed from memory at 3AM, but it's at least a place to start looking at more closely.
-
First: I didn't even realize that folder existed. "opt" seemed to uncharacteristic. Doh! Well, that runcommand.sh is a big wall of code, so it might take some time to decipher what it's doing and how to tweak it.
I didn't find any emulators.sh but .cfg instead, so I believe what happens is the opposite: runcommand gets called when you open a system, which then reads the corresponding cfg for what exactly to do. Therefore, I foresee this will be a lot more complicated than I first thought because it means we have to add logic to both files; add a new parameter to the cfg containing which leds to lit up, and then logic to the sh to read these values and do something about it.
I'm starting to get a bit pessimistic here. You know what would be ideal? if whatever launches the system looked for a file called customscript.py at the system folder and executed it if existed. That would be neat.
Anyway, I'll keep digging.
-
@diegzumillo said in Programmable?:
so I believe what happens is the opposite
I have been a little unsure of that from the beginning. Good to know.
Anyway, I'll keep digging.
Always the best way to find gold.
-
I hope this isn't considered spamming. But I can't seem to run a python script from the shell. I mean, it runs just fine if I execute the sh from the terminal (ssh) but when I open some random game (and I know it is calling runcommand) the python script doesn't get called apparently.
For example, if I just call ./runcommand.sh it lights up my LED (and nothing else happens, of course, because that's not how runcommand is supposed to be called normally). And the reason I know runcommand is getting called when I open a game is because I can break the file by adding gibberish, so the game throws an error if I try to launch it. So I'm confused.
-
Have you checked "/tmp/runcommand.log"? It might give some insight.
-
Just did. Nothing unusual there though.
edit: I just made a tiny itty bitty progress. I noticed some text flashed at the screen when I launched a game. I was under the impression anything printed to the terminal would appear on my ssh screen, but no. So I tried snapping a picture (only took me like 50 tries) and discovered it wasn't finding the py file! but only when launching a game. So this sh must be called from some other directory. So I added a pwn command, and 50 pictures later I got the result: it's being called from the supplementary/emulationstation/ directory. Putting the py file there works! I launch a game and my LED lits up.
Now to follow the trail. There are two files there that could be calling runcommands. The emulationstation.sh is way too simple and doesn't seem to be it. Then there's a emulationstation file without extension that seems to be some kind of complex file. It's not readable or editable, so there isn't much that can be done there.
-
SUCCESS!! It works!!
Oh boy, I was losing hope on this. OK, so here's how I solved this: I figured this runcommand had to be called by everything, every emulator, port etc, would call runcommand. But I didn't realize immediately that they were calling it with arguments specifying everything. It just so happens that argument $3 is the system. So all I have to do is add the line
sudo python mydumbassscript.py $3 &
and do whatever I want with this information there. Quick note: There might be a more elegant way of doing this but I put the script at the opt/retropie/supplementary/emulationstation/ because that's where the call always comes from apparently. Ideally I would specify a path but I can't seem to make that work.
Anyway, I'm happy this is kinda working! :)
edit: added "&" at the end of the line to make it run in the background.
-
Fantastic diegzumillo, very cool! It's interesting to think of all the possibilities this technique could lead to.
-
It's funny because using a similar approach, I actually created a LED system that can lite 16 RGB LEDs along with 6 regular LEDs (monochrome), I can decide which LED is ON/OFF and which color to display, everything works on a per game basis (similar to a LEDBlinky system)
I built this system when I was first using a RPI2 with retropie, now I use another board but I kept the exact same system to drive the LEDs.
My ARM board is connected to an arduino which has an RGB module plugged onto it, everything is driven by a python script which takes care of the communication.
I can control everything on a per game basis because I also recreated my own system to adjust the games settings (I almost never used runcommand.sh with my Pi2) and so I have included specific settings to control the LEDs in the system.An example of information sent to the arduino to change the LEDs status: GRPY**********WW001111
wich means:- G: rgb LED#1 -> GREEN
- R: rgb LED#2 -> RED
- P: rgb LED#3 -> PURPLE
- Y: rgb LED#4 -> YELLOW
- **********: rgb LED#5 to #14 -> OFF
- WW: rgb LED#15 and #16 -> WHITE
- 00: regular LED#1 and #2 -> OFF
- 1111: regular LED#3 to #6 -> ON
-
Thanks, Mediamogul. I really appreciate your help and all other's in this topic, DxFx and dankcushions too. If you hadn't kept nudging me in the right direction I wouldn't have figured any of this out.
I have a couple more things I'd like to do along the same lines but I think that was the hardest part. Mainly I want to also be able to tell when the system is booting and when the player saved/loaded. Save and load I might even do directly through button press, without messing with retropie logic. We'll see. I'll move on to installing a screen for a few days and come back to this side of the project later.
DxFx, that's some sophisticated way of solving it!
-
@diegzumillo said in Programmable?:
Thanks, Mediamogul.
Thank you, sir. I hope to make good use out of techniques discussed here and it was great fun watching this project fall into place.
-
There might be a more elegant way of doing this but I put the script at the opt/retropie/supplementary/emulationstation/ because that's where the call always comes from apparently. Ideally I would specify a path but I can't seem to make that work.
Excellent job, I have been watching this topic hoping for your success because I too would like to do something like this, light a certain LED depending on the console chosen. Does it matter where you put the python script, could I just put it in the home/pi folder?
-
I "matters", but only in my non elegant way. Ideally you should call the py script with a full address. It really should be easy to do! I tried once, it didn't recognize the path and gave up because I'm lazy. Without the path, the script should be at opt/retropie/supplementary/emulationstation/
-
Thanks for the quick response, then that is where it will go.
-
I have a question, where did place the call to the python scrip in runcommand.sh?
-
I don't think there's a specific place you need to put it. Just outside any function should do. Did you try to put it somewhere and it failed?
-
I first tried putting it at the very end, right before exit and the light came on after I exited the game not when I started it. I then placed the call near the beginning, right before the first if statement and now the light comes on when I start a game.
-
I just recently updated my Raspbian desktop image to the latest version since I saw it was available and decided to tackle getting the PiGlow up and running on the Pi3 and it was a total success! Setting it up was a breeze, however I didn't follow the tutorial I posted verbatim. Instead I followed most of what is provided here: https://github.com/Boeeerb/PiGlow For the sake of posterity here's what I did:
First I enabled I2c interface in raspi-config. Next do sudo apt-get install python-smbus python-psutils -y (psutils isn't really necessary I don't think but is used for an example to display cpu usage) After that use sudo nano /etc/modules to open the modules file. Make sure to add the following:
i2c-dev
i2c-bcm2708Ctrl + x and y to exit save. Now do a reboot. After rebooting go back to the command line and create the directory for PiGlow and then change to it so:
mkdir piglow
cd piglowGet the PiGlow module:
wget https://raw.github.com/Boeeerb/PiGlow/master/piglow.pyDownload the test script:
wget https://raw.github.com/Boeeerb/PiGlow/master/Examples/test.pyNow just run sudo python test.py and if everything goes smoothly you can insert brightness values from 0 to 255 for each led color.
Sorry if this was an unnecessary explanation but I hope it might help anyone else who wants to do something like this with the PiGlow. Now I just need to make up some scripts and put them in the appropriate place in Retropie.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.