In LibreELEC 12 funktioniert das Script für RemotePI (von MSL Digital Solutions) nicht mehr

  • Hallo zusammen,

    ich bin gerade mit dem Raspberry Pi 4 auf LibreELEC 12 umgestiegen. Ich habe auch das sogenannte Hardware-Modul "RemotePi" von MSL Digital Solutions auf dem Rasberry, womit man mit einer IR-Fernbedienung das Geräte ein- und ausschalten kann. Die Seite des Herstellers ist leider down, weil das Geschäft eingestellt wurde. Jedoch hatte ich mir die Anleitung zum Installieren der nötigen Scripte in LibreELEC gespeichert. Bei LibreELEC 11 klappt alles wunderbar. (Ich habe es sogar extra ausprobiert mit einer 11er-Version.) Nur bei der neuen Version klappt es leider nicht.

    Mit der Anleitung geht man in den Ordner ".config". Dort erstellt man dann die drei kleinen Skripte und macht sie mit dem "chmod"-Befehl ausführbar.

    Dadurch kann man mit einer IR-Fernbedienung Kodi ein Signal geben, dass es vernünftig herunterfährt und sich die Hardware danach abschaltet. Oder wenn Kodi per Oberfläche heruntergefahren wird, sendet es ein Signal an die Hardware und diese schaltet sich dann im Anschluss ab.

    Mit LibreELEC 12 passiert leider nichts dergleichen. Die Scripte sind aber da. Das habe ich mit FileZilla überprüft. Es steht auch alles korrekt drin.

    Leider bin ich nicht besonders bewandert in Sachen Linux, aber es hat bisher immer gut funktioniert und ich verstehe auch, was dort gemacht wird.

    Am besten, ich poste hier mal die Anleitung. Vielleicht muss ja nur eine Kleinigkeit geändert werden mit der neuen Version. Soweit ich weiß, wurde auf 64 bit umgestellt mit LE 12. Ich bedanke mich jetzt schon für anregende Lösungsvorschläge.


    Man stellt eine Verbindung mit LibreELEC über putty her (root als Username + Passwort) und befolgt dann diese Anleitung vom Hersteller (Ich habe alle Eingaben als "Code" formatiert. Also die Zeilennummern, die hier erscheinen, sind in der Anleitung nicht vorhanden.):

    The default SSH user name is root, password openelec (password for LibreELEC is libreelec).


    The first part of the instructions below adds the main shutdown script for the RemotePi Board to the autostart.sh file, which enables the script to run when the OS starts.


    Key in (mind the . in front of config !) :

    Code
    cd .config
    Code
    nano autostart.sh

    Copy and paste (use shift+ins to paste in nano) the following into the nano editor window. If there is already something in the file, just add the following as the last lines. If the last line is exit 0, then place the following lines before that line.

    Bash
    #!/bin/bash
    (/storage/.config/irswitch.sh)&

    Press ctrl+x to exit the editor, y to confirm, enter to save the file

    Key in

    Code
    chmod +x autostart.sh


    The next part creates the main RemotePi Board shutdown script. This script shuts down the OS safely, when the button on the RemotePi Board or the off button on the remote is pressed :


    Key in

    Code
    nano irswitch.sh

    Copy and paste the following text into the editor window

    • Press ctrl+x to exit, y to confirm, enter to save the file
    • Key in

      Code
      chmod +x irswitch.sh

    The following additional script enables the RemotePi Board to cut off the power, after OpenElec / LibreELEC has been shut down from the on-screen menu.


    Key in :

    Code
    nano shutdown.sh

    Copy and paste the following contents

    Press ctrl+x to exit, y to confirm, enter to save the file

    Mark the script as executable by keying in

    Code
    chmod +x shutdown.sh 


    Reboot from the OpenElec or LibreELEC OS GUI.

    After reboot you can use the RemotePi Board to power cycle OpenElec / LibreELEC

  • Mit LibreELEC 12 passiert leider nichts dergleichen.

    Ich schaue mir die Scripte gleich noch genauer an. Grundlegend habe ich auch verstanden, was da passieren soll.

    Was ich gern noch wissen würde...du sagst, es passiert nichts dergleichen. Was genau passiert denn nicht? Fährt Kodi nicht runter oder schaltet sich der Pi nicht ab?

    Man könnte noch anfangen ein paar Debug-Infos einzubauen. oder sich schon mal im Vorfeld ein paar Dinge rausziehen bevor das irswitch einsetzt.

    Mich würde zumindest interessieren, was der Inhalt dieser Variablen ist:

    power=$(cat /sys/class/gpio/gpio$GPIOpin1/value)

    Denn irgendwann muss ja in die if-Bedingung gewechselt werden. Nämlich dann, wenn "$power" nicht "0" ist. Also wahrscheinlich ist es "1". Wenn ich es richtig verstehe ist der Pin14 immer auf "0" außer, wenn er ein Shutdown-Signal bekommt... Hast du das geprüft, dass er das Signal bekommt oder vielleicht ist es auch ein anderer Pin.

    In diese Richtung müsste man prüfen, denke ich.

    Ich habe die Scripte mal durch Shellcheck laufen lassen. Grundlegend sieht es erstmal gut aus. In den Scripten sind erstmal technisch keine Fehler. Der Hase wird also fachlich irgendwo im Pfeffer liegen.

    Ich habe noch kein LE12 installiert. Mein Linux-System (Fedora) sagt mir aber, dass das Kommando "usleep" deprecated ist und in Zukunft nicht mehr supported wird. Anstelle von

    usleep 125000

    soll man

    sleep 0.125

    nehmen. Wenn das bei LE12 schon der Fall ist, dass es deprecated ist, dann könnte es sein, dass die Variablen zu schnell geschrieben werden sollen und es da zu Fehlern kommt. Ich würde ggf. das Kommando auf "sleep" ändern und die Werte alle durch 1000000 teilen um auf den gleichen Wert zu kommen.

    Du kannst aber ja schon mal anfangen zu prüfen, welchen Wert die entsprechenden Variablen haben oder ob der Pin14 wirklich noch der ist, der das Shutdown-Signal bekommt

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

    Einmal editiert, zuletzt von DaVu (7. April 2024 um 13:47)

  • könnte mir vorstellen, dass durch den neuen Kernel Änderungen eingetreten sind, sodass die scripte nicht mehr laufen.

    Habe leider keinen Pi hier, aber auf einem x86-er (Intel Nuc) LE12 kann ich hier schon mal nix in, z.b. /sys/class/gpio/export reinschreiben

    Zeile im script ist: "echo "$GPIOpin" > /sys/class/gpio/export"

    nuc:/sys/class/gpio # echo 14 > export 
    sh: write error: Invalid argument


    nuc:/sys/class/gpio # ls -al export 
    --w-------    1 root     root          4096 Apr  7 00:10 export

    trotz writeable Datei und als root eingeloggt !!!

    Ist das auf einem Pi auch so ???

  • Das ist recht einfach zu erklären, denke ich.

    Deine x86 Maschine hat, wie meine auch, keine GPIO Pins ;)

    Ich habe mal das gemacht: chmod 0644 export (natürlich im entsprechenden Verzeichnis). Danach hatte ich Leserechte. Wenn ich dann ein cat export bekomme ich

    cat: read error: Input/output error

    Was klar ist, weil ich halt diese Pins nicht habe. Somit können wir das so mit unseren x86 Maschinen nicht testen oder vergleichen

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

  • Hallo DaVu,

    vielen Dank, dass du dich der Sache angenommen hast. Zuerst möchte ich deine Frage beantworten. Die kleine Hardware-Platine mit dem Infrarotempfänger hat eine Leucht-Diode. Wenn alles richtig programmiert ist, dann drücke ich auf der Fernbedienung die Taste zum Ausschalten und dann fängt die Diode (langsam) an zu pulsieren und nach ca. drei Sekunden sieht man, wie LibreELEC beginnt ordnungsgemäß herunterzufahren. Ca. vier Sekunden nach dem Herunterfahren erlischt die Diode und der IR-Empfänger ist im Standby und wartet auf ein Signal zum Einschalten. Dann würde die Diode wieder angehen und der Raspberry Pi hochfahren.

    Oder das andere Szenario: Wenn alles ordnungsgemäß programmiert ist und ich in Kodi über die Grafikoberfläche "Ausschalten" wähle, dann fährt Kodi sauber herunter (In diesem Fall geht durch die Einstellungen in Kodi auch der TV mit aus.), die Diode pulsiert wieder langsam, bis das Herunterfahren abgeschlossen ist und erlischt dann.

    Das jetzige (nicht korrekte) Szenario ist, als ob das Script nicht eingefügt wurde, wie folgt: Gebe ich dem IR-Empfänger das Signal zum herunterfahren, dann pulsiert die Diode (schnell!) und Kodi macht nichts. Nach 4 Minuten gibt es dann einen Cut zum Strom und der Raspberry wird vom Strom unterbrochen, womit Kodi nicht sauber heruntergefahren ist, sondern "plötzlich der Strom weg ist".

    Oder wenn ich Kodi im jetzigen (falschen) Szenario über die Grafikoberfläche in Kodi mit "Ausschalten" herunterfahre, fährt Kodi sauber herunter, aber die Diode und die Hardware-Platine (RemotePi) bleiben an. Also der Strom wird nicht unterbrochen, womit ich es nicht per Fernbedienung wieder anschalten kann.


    Da vorher alles funktioniert hat, erhoffe ich mir am ehesten einen Erfolg mit dem von dir erwähnten Ändern der "usleep" Befehle.

    Es würde dann ja nur die letzte Datei betreffen, die "shutdown.sh". Denn nur sie enthält "usleep" Befehle.

    Soll ich sie dann ändern in:

    Die vorletzte Zeile müsste dann ja "4" ergeben. (Wahrscheinlich ist "sleep 4" korrekt und man muss alle kürzen, was geht, denn in einer der oberen Datein steht auch schon ein Befehl mit "sleep 3")

    Und muss ich danach nochmal den Befehl "chmod +x shutdown.sh" eingeben, um die Änderungen ausführbar zu machen?

    Mit dem oberen geänderten Code hat es leider nicht funktioniert.

    Deine Frage nach der Variablen

    power=$(cat /sys/class/gpio/gpio$GPIOpin1/value)

    kann ich leider nicht beantworten. Ich weiß nur, dass die Anleitung ganz oben vom Hersteller unter LibreELEC 11 und tiefer immer sauber funktioniert hat. Darum sollte das alles schon gut programmiert worden sein.

    Ich habe daher auch die Änderungen im Kernel in Verdacht, wie auch joeAverage62 geschrieben hat. Diese Spur würde ich gerne als erstes verfolgen. Also schon mal vielen Dank für deine Bemühungen. (Denn dieser Infrarot-Empfänger ist ein wirklich tolles Teil und schafft einfach das bisschen extra Konfort für dieses tolle Mediacenter Kodi auf dem Raspberry. :))

  • Wenn ich aber 125000 durch die von dir erwähnten 100000 teile, komme ich auf 1.25 und nicht auf 0.125. Oder meintest du vielleicht teilen durch 1000000 (eine Million)?

    Ja...ich habe mich vertippt und es oben auch schon korrigiert. Danke für den Hinweis ;)

    Rein mathematisch ist 0.2 das gleiche wie 0.200 oder 0.20000000000000

    Wie viele Nullen nach der/den Zahl(en) hinter dem Komma kommen ist dabei unerheblich.

    Und ja....usleep macht Mikrosekunden

    Edit:

    "sleep" spricht in Sekunden.

    ein "sleep 2" wartet 2 Sekunden. Fedora gibt mir das Umrechnen schon vor, wenn ich alle diese Befehle absetze:

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

    2 Mal editiert, zuletzt von DaVu (7. April 2024 um 13:46)

  • Ok, das abändern des dritten Scripts, wie oben, hat leider keine Änderung bewirkt. Ich habe sogar eine frische SD-Karte mit LibreELEC 12 neu installiert und das alles von vorne mit der abgeänderten dritten "shutdown.sh" probiert. Schade, aber es war einen Versuch wert und ich danke dir für deine Zeit und Mühe. (Falls es am Ende eine Lösung gibt, kann das bestimmt auch anderen Leuten helfen, die das Board gekauft haben mit IR-Empfänger. Es war mal ziemlich beliebt damals.)

    Gibt es vielleicht noch andere Ideen oder Ansätze?

  • Und muss ich danach nochmal den Befehl "chmod +x shutdown.sh" eingeben, um die Änderungen ausführbar zu machen?

    Nein.

    Das "chmod +x <dateiname>" setzt das "x"-Bit zu einer Datei. Das ist es dann für immer, es sei denn, du entfernst es wieder. Das "x"-Bit bedeutet "executable" -> "ausführbar"

    Wenn du das tiefer verstehen möchtest:

    Rechte › Wiki › ubuntuusers.de
    und
    chmod › Wiki › ubuntuusers.de

    Wir werden daber bestimmt noch mehr analysieren müssen. Ich könnte mir vorstellen, dass das über den Thread hier etwas mühselig wird, wenn dein Linux-Wissen eher marginal ist. Ich könnte dir einen Video-Call anbieten und dann kann ich dich "fernsteuern". Zugriff auf deinen PC brauche ich nicht. Ich brauche nur einen "geteilten" Bildschirm ;)

    Ist nur ein Angebot. Wir können es auch über den Thread machen. Dann dauert es nur länger.

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

  • Hätte ich einen Pi, hätte ich gestern das script zu Fuss durchgehechelt oder mit "sh -vx" vorm script

    f.d. ersten Teil:

    echo variable > Datei

    cat Datei

    ...

    ===

    Falls ihr eine remote admin Lösung sucht: anydesk

    für Fedora:

    Install AnyDesk on Linux | Flathub
    Connect to a computer remotely
    flathub.org


    +++ Nachtrag +++

    Anydesk muss unter Xorg laufen, nicht Wayland.

    Ich glaube, dass betrifft aber nur (unsicher) die Gegenseite, aber das ist ja Windows ...

  • Hey DaVu, vielen Dank. Das Angebot mit dem Video-Call und geteiltem Bildschirm würde ich gerne annehmen und probieren. Was benötige ich zur Vorbereitung? AnyDesk könnte ich installieren auf meinem Windows-PC. Mikrofon (Headset) ist vorhanden. Brauche ich auch eine Webcam? Die könnte ich bei Bedarf anschließen. FileZilla ist auch vorhanden, womit man mit grafischer Oberfläche auf die Ordnerstruktur vom Raspberry Pi 4 mit LibreELEC Zugriff bekommt. putty für den Zugriff per Eingabeaufforderung ist ebenfalls vorhanden und als Editor ist Notepad++ installiert.

    Ich kann ja mal zwei eventuell relevante der gespeicherten Webseiten vom Hersteller hier als ZIP-Archiv anhängen. (Erledigt.) Das eine ist die Anleitung vom Hersteller und das andere ist eine "Support-Seite" mit Pin-Belegung usw. Dann siehst du auch mal den Aufbau der kleinen Platine.

    In der Woche könnte ich immer ab 19 Uhr. Nur heute wird es leider nichts bei mir. Oder sonst am Wochenende, da bin ich auch flexibler. Wenn du einen oder zwei Terminvorschläge hättest, würde ich es bei mir zeitlich einrichten. Wenn es bei dir nur früher am Tag geht, dann nehme ich mir mal Home-Office. Aber es ist sicher schwer vorab abzuschätzen, wie viel Zeit beansprucht wird.

    Ich finde das sehr nett mit deinem Angebot. :thumbup: Hab vielen Dank. Das Wiki von ubuntuusers.de habe ich auch mal als Lesezeichen gesetzt. Ein paar Sachen kommen mir sogar bekannt vor von früheren "Experimenten" mit einer gerooteten Android-TV-Box und auch beim Synology-NAS.

  • Ich melde mich nochmal ausführlicher und wahrscheinlich per PN bei dir.

    Du brauchst irgendwas mit Lautsprecher und Mikro. Ob das nun ein Headset oder was anderes ist, ist mir egal.

    Eine Webcam brauchst du nicht. Ich Stelle uns einen Call über Zoom bereit. Vielleicht kann ich den Team-Kodi Account nutzen.

    Ansonsten brauchen wir nur PuTTY um eine Verbindung via SSH aufbauen zu können. FileZilla ist auch gut. Mehr braucht es nicht.


    Wie gesagt...ich melde mich

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

  • RobertMV,

    besteht das Problem noch?

    Wenn ja, probiere mal die Zeilen 3/4 passend zu ändern.
    GPIOpin=527
    GPIOpin1=526

    Hintergrund: Die verwendete Schnittstelle sysfs-gpio gilt schon lange als veraltet und wurde im Kernel größer 6.5 geändert. Bisher wurde ein gpiochip0 instanziert. Wobei die 0 den Index im Speicher angibt. Bei neueren Kerneln werden diese GPIOchips dynamisch erzeugt. Vermutlich ist dies auch zwingend notwendig um z.B. den RP1 des Pi5 adressieren zu können. Hier ein Beispiel von meinem RPi4 mit LE12 beta 1.

    Code: console
    # ls -la /sys/class/gpio/
    total 0
    drwxr-xr-x    2 root     root             0 Feb 27 18:26 .
    drwxr-xr-x   50 root     root             0 Jan  1  1970 ..
    --w-------    1 root     root          4096 Apr  9 18:16 export
    lrwxrwxrwx    1 root     root             0 Feb 27 18:26 gpiochip512 -> ../../devices/platform/soc/fe200000.gpio/gpio/gpiochip512
    lrwxrwxrwx    1 root     root             0 Feb 27 18:26 gpiochip570 -> ../../devices/platform/soc/soc:firmware/soc:firmware:gpio/gpio/gpiochip570
    --w-------    1 root     root          4096 Apr  9 18:17 unexport


    Der gpiochip512 ist der mit den 58 adressierbaren GPIO Pins und entspricht dem bisherigen gpiochip0. Damit man keinen "I/O error" oder "Invalid argument" bekommt, muss man diese Zählweise verwenden: Chipnummer + GPIO Nummer

    Alt: 0 + GPIO14 = 14
    Neu: 512 + GPIO14 = 526

    Da ich nicht sicher bin, ob bei Raspberry Pis kleiner als dem RPi5 immer gpiochip512 angelegt wird, sollte man sicherheitshalber mit ls -la /sys/class/gpio/ nachschauen und ggf. neu berechnen.
    Mit cat /sys/class/gpio/gpiochip512/ngpio (Rückgabewert: 58)

    Code: console
    :~ # cat /sys/class/gpio/gpiochip512/ngpio 
    58

    bzw. cat /sys/class/gpio/gpiochip512/label (Rückgabewert: pinctrl-bcm2711) lässt sich prüfen ob man den Richtigen versucht zu benutzen.

    Code: console
    :~ # cat /sys/class/gpio/gpiochip512/label 
    pinctrl-bcm2711

    Auf der Basis dieser Infos könnte man die Bash Skripte vermutlich auch automatisiert suchen lassen.

    Wenn bei Dir auch der gpiochip512 angelegt wurde, sollten Deine beiden Skripte so angepasst wieder funktionieren:

    Bash: irswitch.sh
    #!/bin/bash
        # this is the GPIO pin receiving the shut-down signal
        GPIOpin1=526
    Bash: shutdown.sh
    #!/bin/bash
        if [ "$1" != "reboot" ]; then
          GPIOpin=527
          GPIOpin1=526
  • HarryH hast du dazu ne Quelle oder hast du es selbst probiert?

    Wäre ja cool, wenn es das wäre. Ich habe RobertMV für morgen oder Freitag einen Vodeocall angeboten. Wenns das aber schon gewesen ist, dann sind wir dir beide dankbar ;)

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

  • Ja, ich habe es lokal bei mir mit LE12 ausprobiert, per echo die GPIO Pins umzustellen. Mit den richtigen Ziffern, kam keine Fehlermeldung mehr zurück und das GPIO Pin wurde exportiert. Es war allerdings nur eine Trockenübung, da ich diese Platine selbst nicht einsetze.

    Auch hatte ich bedenken bei den Infos die ich gefunden habe, ob ich mich ggf. um 1 verzählt habe. Wenn man die Ausgabe von gpioinfo (System-Tools Addon muss installiert sein) benutzt zum Vergleich, passt aber alles zusammen: 58 Pins + Nummerierung ab 0, wobei GPIO14 = 14 ist.

    Edit:
    erfolgreicher Probelauf auf GPIO24:
    Zustand vorher:

    GPIO24 zu Ausgang umkonfigurieren:

    Code: console
    echo "536" > /sys/class/gpio/export
    echo "out" > /sys/class/gpio/gpio536/direction

    GPIO24 ist jetzt auf Ausgang umkonfiguriert:

    GPIO24 Pin zurück auf Input stellen und wieder freigeben:

    Code: console
    echo "in" > /sys/class/gpio/gpio536/direction
    echo "536" > /sys/class/gpio/unexport

    Bitte beachten:
    Es ist vermutlich nur eine Frage der Zeit wann diese Möglichkeit die Pins zu konfigurieren aus dem Kernel endgültig rausgeschmissen wird. In Zukunft könnte die Umstellung auf "pinctrl" notwendig sein oder eine Migration zu Python3 die einzig verbleibende Variante für LE12 werden. Aktuell ist nur noch lgpio und gpiozero in den RPi-Tools enthalten. gpiozero setzt auf lgpio auf und macht es unter Umständen einfacher, aber auch langsamer. Zu allem Überfluss ist lgpio auch mit ein paar fiesen Bugs gespickt...

    PS: Von einem Nutzer im LibreELEC Forum kam gerade die Rückmeldung, dass es bei ihm nach den von mir vorgeschlagenen Änderungen wieder funktioniert.

    Quellen:

    wiringPi broken since kernel 6.5.7 · Issue #5668 · raspberrypi/linux
    Describe the bug Starting with kernel 6.5.7 applications which uses gpios are broken. Steps to reproduce the behaviour e.g. the start of an application which…
    github.com
    Trying to write to /sys/class/gpio/export – write error: Invalid argument
    I have an Intel aaeon upboard and I want to use its GPIO pins. To do that I'm trying the below code: echo 17 &gt; /sys/class/gpio/export But when I run it,…
    superuser.com

    Controlling GPIO from Linux User Space
    The Pins They Are A-Changin’

  • Hallo HarryH,

    das klingt vielversprechend und deine Begründung klingt auch logisch. Danke, dass du auch deine Gedanken zur Herleitung geschildert hast, sodass es zukünftige Leser hier nachvollziehen können. Ich kann heute Abend gegen 20 Uhr eine Rückmeldung geben.

  • HarryH, genau diese von dir berechneten Änderungen der GPIO pin Nummern funktionieren! :)

    Und zwar genau wie früher - in beide Richtungen. Also Ausschalten per Oberfläche fährt herunter und direkt im Anschluss schaltet sich die Platine ab. Und wenn ich per Platine das Signal gebe, fährt LibreELEC ordnungsgemäß herunter und auch dann schaltet sich die Platine im Anschluss ab und wartet auf ein Wiedereinschalten.

    Einfach genial, wie ihr mir (und wahrscheinlich anderen) hier geholfen habt. Sowohl mit eurem Wissen als auch durch die hilfsbereite und freundliche Art.

    Ich sage vielen Dank für eure Zeit und Mühen. Eine Freude, dass es wieder funktioniert.

    Bash: irswitch.sh

    Bash
    #!/bin/bash
        # this is the GPIO pin receiving the shut-down signal
        GPIOpin1=526

    Bash: shutdown.sh

    Bash
    #!/bin/bash
        if [ "$1" != "reboot" ]; then
          GPIOpin=527
          GPIOpin1=526

    Ich habe die gesamte Anleitung für die Zukunft aktualisiert. "usleep" wurde durch "sleep" ersetzt und die GPIO-Pin-Nummern wurden dem neuen Zählsystem angepasst - alles auf deutsch übersetzt.

    Als .htm Datei (im .zip gepackt), damit man mit Zeilenumbrüchen daraus mitkopieren kann.

    "RemotePi (v2015) Shutdown-Skripte für LibreELEC 12.0 und OpenELEC – MSL Digital Solutions" nun hier im Anhang.

  • RobertMV,

    wenn Du mal Langeweile haben solltest, kannst Du bitte die auf pinctrl umgestellte Version auf Funktion prüfen? Die sollte dann auch auf einem RPi5 funktionieren. Außer ich habe noch einen Bug versenkt. ;)

    5 Mal editiert, zuletzt von HarryH (17. April 2024 um 13:40) aus folgendem Grund: Version 1.2 auf sleep umgestellt Versionsinformationen hinzugefügt

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!