Is it possible to call a script by "browsing"?

[didusee]

I am asking myself, if it would be possible to call a script when entering a gamelist (of a certain system) and than to call another one, when back in the "choose system" menu.

I thought, I could do this with the help of using "system-select" under /emulationstation/scripts but

echo system select $1 >> /home/pi/test.txt

gives me an entry each time I am hovering to a system AND when selecting it (to go to the gameslist). Going back to the main menu (where systems can be selected) gives me the same system name.

I would need something that gives me the possiblity to call a script when selecting a system, not when "hovering" over it. Also I would need kind of a variable for the system selection screen.

Background: I would like to achieve different colors of my LED buttons in both, a gamelist and the system selection menu.
I can do so by launching and existing games but I am getting stuck with this.

Any help kindly appreciated.

[didusee]

I got it. Well, kind of.
By putting a script (that changes led button color) in system-start and another one (different colors) into game-start, the button colors are changing when browsing a gamelist.

But: Now each time, a game is selected in a gamelist, the script is called (though its already done its job) which slows down the machine quiet "a bit". System-Select seems to run better, but basically the same problem.

I am asking myself, if there is a way to execute the script only, if the color has not already been changed. Unfortunately, I am not getting back any status or so from the leds. So I am looking for any argument, that I could use.

[mitu]

...
I am asking myself, if there is a way to execute the script only, if the color has not already been changed. Unfortunately, I am not getting back any status or so from the leds. So I am looking for any argument, that I could use.

When you call the button set script can't you store the color you sent to the led in a file ? You can then read the last set color from the subsequent script calls.

[didusee]

Yes, I could, but as I am talking about changing colors of LED buttons with Plasma, that would lead to no results that could help me for what I would like to. At least nothing, that I am aware of. Plasma is not returning any values. You throw a png at it, thats it. There seem to be ways of managing things with python but unfortunately, that s not my cup of tea.

Furthermore, calling plasmactl seems to be quiet ressource intensive. While browsing a gameslist with roms, a script in …/scripts/game-start calls it each time, hovering over (selecting) a game and becomes rather unresponsive.
No fun.

I suspect, it is not a good idea, to call plasmactl from a shell script with the game-start-folder-method

[didusee]

I came up with a different solution with the help of a friend, that implements a daemon and three scripts.

1. Daemon Script
This script monitors the status file and triggers color changes based on the current menu (Systems Menu or Gamelist Menu).
Location: /home/pi/led_ram_daemon.sh

#!/bin/bash
# /home/pi/led_ram_daemon.sh

# Path to the status file in RAM
STATUS_FILE=“/dev/shm/led_ram_status.sh“

# Check if the status file exists. If not, create it.
if [ ! -f "$STATUS_FILE“ ]; then
    echo "SYSTEMSLED=OFF“ > "$STATUS_FILE“
    echo "GAMESLED=OFF“ >> "$STATUS_FILE“
fi

# Function to read the status values and apply them to the LEDs
apply_led_status() {
    # Load the current status
    source "$STATUS_FILE“

    # Check if SYSTEMSLED should be turned ON
    if [ "$SYSTEMSLED“ == "ON“ ]; then
        # Set SYSTEMSLED to the ‚systemscolor‘ pattern (no output to console)
        plasmactl --pattern systemscolor > /dev/null 2>&1
    fi

    # Check if GAMESLED should be turned ON
    if [ "$GAMESLED“ == "ON“ ]; then
        # Set GAMESLED to the ‚gamescolor‘ pattern (no output to console)
        plasmactl --pattern gamescolor > /dev/null 2>&1
    fi
}

# Function to check for status changes
check_status_change() {
    # Save the old status
    old_status=$(cat "$STATUS_FILE“)

    # Monitor status changes in a loop
    while true; do
        # If the status has changed, apply the new LED state
        new_status=$(cat "$STATUS_FILE“)
        if [ "$old_status“ != "$new_status“ ]; then
            apply_led_status  # Apply changes to the LEDs
            old_status=$new_status  # Set the new status as the old status
        fi
        sleep 0.1  # Wait 100 milliseconds before checking again
    done
}

[didusee]

2. Systems-LED Script
Changes LED colors when in system-selection menu
Location:
/opt/retropie/configs/all/emulationstation/scripts/system-select/led_ram_systems.sh

#!/bin/bash
# /opt/retropie/configs/all/emulationstation/scripts/system-select/led_ram_systems.sh

# Path to the status file in RAM
STATUS_FILE=“/dev/shm/led_ram_status.sh“

# Set the System-LED status to „ON“ and the Game-LED status to „OFF“
echo "SYSTEMSLED=ON“ > "$STATUS_FILE“
echo "GAMESLED=OFF“ >> "$STATUS_FILE“

[didusee]

3. Games-LED Script
Changes LED colors when browsing roms / games
/opt/retropie/configs/all/emulationstation/scripts/game-select/led_ram_games.sh

#!/bin/bash
# /opt/retropie/configs/all/emulationstation/scripts/system-select/led_ram_systems.sh

# Path to the status file in RAM
STATUS_FILE=“/dev/shm/led_ram_status.sh“

# Set the System-LED status to „ON“ and the Game-LED status to „OFF“
echo "GAMESLED=ON" > "$STATUS_FILE"
echo "SYSTEMSLED=OFF" >> "$STATUS_FILE"

[didusee]

Excursion: Using a status file under /dev/shm

Saving the status file in /dev/shm (temporary filesystem, stored in RAM) is improving performance and prevent wear on the SD card.

• Speed: Reading from and writing to /dev/shm is faster than accessing files stored on the SD card, which is especially important if the script is running in a loop and frequently checking for status
  changes. This improves the responsiveness of the LED color changes without putting excessive load on the system.

• Temporary Storage: The status file only needs to exist for the duration of the session. Once the system is rebooted, the /dev/shm directory is cleared automatically, so there is no need to manage or clean up the status file manually.

• What is Stored in the Status File?: The status file stores the current state of the LEDs (whether the
  system is in „Systems Menu“ or „Games Menu“).

Specifically, it holds two variables:
SYSTEMSLED: „ON“ or „OFF“ (indicates whether the system LED colorset should be on or off).
GAMESLED: „ON“ or „OFF“ (indicates whether the game LED colorset should be on or off).

The file is written in a simple key-value format:

SYSTEMSLED=ON
GAMESLED=OFF

Whenever the LED state changes, the script updates this file with the new values. The daemon then reads the file, and based on its contents, updates the LED colors accordingly.

[didusee]

Excursion: Tradeoff between performance and responsiveness

The daemon script uses a small delay (sleep 0.1) between each check of the status file to balance performance and responsiveness.

• Why the Delay?
  The delay ensures that the daemon does not overwhelm the system with constant checks, which could lead to excessive CPU usage and lagging while browsing roms / gameslists. By introducing a rather small delay of 100 milliseconds, the script remains quiet responsive enough to changes but does not use too many system resources.

• Adjusting the Delay:
  One can customize the delay to fit personal preferences. To make the script more responsive (i.e., faster reaction to color changes), reduce the sleep time (e.g., sleep 0.05 for 50 milliseconds). Conversely, to improve system performance further, increase the sleep time (e.g., sleep 0.2 for 200 milliseconds). The delay is located in the check_status_change function of the daemon script (under 1.1)

[didusee]

4. Setting up the "LED RAM Daemon"
The daemon should runs automatically on system startup, with the help of systemd service. This service will start the led_ram_daemon.sh script in the background.

Location of the systemd service file:
/etc/systemd/system/led_ram_daemon.service

[Unit]
Description=LED RAM Daemon Service
After=network.target

[Service]
Type=simple
ExecStart=/home/pi/led_ram_daemon.sh
Restart=always
User=pi
Group=pi

[Install]
WantedBy=multi-user.target

Enabing the service:

sudo systemctl enable led_ram_daemon.service

Starting service manually:

sudo systemctl start led_ram_daemon.service

Logging

journalctl -u led_ram_daemon.service

[didusee]

5. Configuring autostart.sh for EmulationStation

In order to make sure that the system starts the daemon on boot and manages the LEDs when starting EmulationStation, there needs to be an addition in the autostart.sh file

Location: /opt/retropie/configs/all/autostart.sh

Include before everything else

cp /home/pi/led_ram_daemon.sh /dev/shm/
/dev/shm/led_ram_daemon.sh &

This setup copies the led_ram_daemon.sh script to /dev/shm/ (a temporary in-memory filesystem) each time the system starts. Running the script from /dev/shm/ can improve its responsiveness, as accessing files in RAM is generally faster than from disk. After copying, the daemon starts in the
background, and EmulationStation launches automatically.

[didusee]

6. Pattern Images for Plasma
Plasma uses png files for LED patterns with plasmactl command
They need to be available in /etc/plasma

gamespattern.png
systemspattern.png

For further infos see the docs

[didusee]

7. Final Steps

Scripts need to be executable!
After placing the scripts in their respective directories, this can be done by running:

chmod +x /home/pi/led_ram_daemon.sh
chmod +x /opt/retropie/configs/all/emulationstation/scripts/system-select/led_ram_systems.sh
chmod +x /opt/retropie/configs/all/emulationstation/scripts/game-select/led_ram_games.sh

Rebooting Pi to ensure the daemon starts properly and the LED color patterns are correctly applied.

## HAVE FUN AND ENJOY!