Phoniebox Fastforward Button leuchtet nicht

  • Hallo,

    ich habe mit meiner fast fertigen Phoniebox noch ein kleines Problem. Ich habe vier Buttons. Prev, Start/Pause, Next und einen Fastforward. Die ersten drei leuchten. Der 4 (Fastforward) leider nicht.

    Ich habe das Script von "Splitti" für die Animation ausgeführt. Leider werden da nur die Gpios von Prev, Start/Pause und Next, Volume up und Volume down angezeigt.

    LED

    Blauer Button = 5 PREV

    Grün Button = 6 Start/Stop

    Gelb Button = 22 Next

    Volumeup = 23

    Volumedown = 24

    Ich habe versucht die Datei "gpiozero_led.py" zu editieren. (Einträge für Fastworward hinzugefügt). Leider hat das aber nicht geklappt.

    Kann man irgendwie "Volumeup" zu FF umbenennen?

    Habt ihr eine Idee wie ich meinen vierten Button zum leuchten bekomme?

    Ich bin leider absoluter Laie was Programmieren angeht.

    Edited once, last by ape650 (October 29, 2024 at 8:05 PM).

  • Hallo ape650,

    splitti79 hat genau heute sein sechsjähriges Jubiläum, war aber seit August hier nicht mehr online, sonst könnte er evtl. selber antworten.

    Ich habe das Thema leider nicht mehr auf dem Schirm. Welches Skript genau hast Du verwendet? Zeig mal bitte die Links zum Skript und auch zur ganzen Anleitung! Vielleicht kann man da etwas herleiten.

  • ape650

    Ändere mal in Deinem angepassten Script folgenden Abschnitt

    Python
            elif pos == 5:
                LED_VOLUP.pulse(n=1, fade_in_time=0.2, fade_out_time=0.5)
                process = getshell()
                direction = 1
                sleep(0.1)
            if pos == 6:
                LED_FASTFORWARD.pulse(n=1, fade_in_time=0.2, fade_out_time=0.5)
                sleep(0.1)
                direction = 0

    in dies (es werden 3 Zeilen geändert: 86, 88, 91):

    Python
            elif pos == 5:
                LED_VOLUP.pulse(n=1, fade_in_time=0.2, fade_out_time=0.5)
                process = getshell()
                sleep(0.1)
            elif pos == 6:
                LED_FASTFORWARD.pulse(n=1, fade_in_time=0.2, fade_out_time=0.5)
                sleep(0.1)
                direction = 1


    Hier die Änderung im Vergleich. So dass vielleicht die Programmlogik (bzw. der Fehler) deutlicher wird.

    Links das Original von splitti, in der Mitte Deine Version und rechts die Korrektur:


    Erst der letzte Button darf die Variable direction von 0 auf 1 schalten, also nun nicht mehr VOLUP (pos 5), sondern Dein neues FASTFORWARD (pos 6).

    Edited 2 times, last by simonz (October 30, 2024 at 7:58 AM).

  • Den getshell()-Aufruf könnte man da auch noch runter ziehen. Es ist zwar eigentlich fast egal bei welchem pos-Wert der gemacht wird, aber den ”am Ende” der (halben) Animation zu machen, ist optisch vielleicht netter.

    Ansonsten mal Maneuverkritik an dem Gesamtprogramm: Die LED-Objekte sollten nicht auf Modulebene definiert werden. Das sind keine Konstanten, sondern Objekte mit einem Zustand der verändert wird, und das reine Importieren des Moduls sollte noch keine zusätzliche Hardware erfordern. Und die Funktionen sollten nicht auf magisch ausserhalb der Funktion existierende Objekte zugreifen.

    Im if __name__ == … sollte nur der Aufruf von main() stehen und der Code der dort davor steht sollte in der main()-Funktion stehen. Dann kann man dort auch die LED-Objekte erstellen und den anderen Funktionen sauber als Argument(e) übergeben. Und eigentlich brauchen die auch gar keine eigenen Namen, denn es wird immer in der gleichen Reihenfolge (fast) das gleiche mit den LED-Objekten gemacht. Da kann man also einfach eine Liste mit Pin-Nummern in eine Liste mit LED-Objekten umsetzen und da dann mit Schleifen drauf operieren und sich eine Menge Code ersparen.

    process mit einem Dummywert zu belegen ist unschön. Das ist eigentlich eine while True:-Schleife wo man die Bedingung in der Schleife prüft und sie an entsprechender Stelle dann mit break verlässt.

    initiate_animation() macht mehr als nur die Animation zu initiieren. getshell() holt keine Shell, sondern testet ob der MPD schon läuft, und so eine Testfunktion sollte keine Zeichenketten zurückgeben, sondern einen Wahrheitswert. process ist auch kein sinnvoller Name für eine Zeichenkette die am Ende aus einem Shell-Prozess heraus fällt.

    Zu diesem externen Prozess: Mit Python kann man Text in Dateiobjekte schreiben, also braucht es da kein externes echo. Und man kann mit Python auch nach einer Text in einer Zeichenkette suchen, dafür braucht man kein externes grep. Damit braucht es dann beim Popen das shell=True und den zusätzlichen Shell-Prozess nicht. Und auch das nc und damit überhaupt einen externen Prozess braucht es nicht, denn Socket-Kommunikation kann man ebenfalls mit Python machen.

    Der Signal-Handler sollte nicht selbst aufräumen, sondern nur das Programmende anstossen. Das Aufräumen passiert dann in einem finally-Block beziehungsweise durch with mit einem Kontextmanager für das schliessen der LED-Objekte. Dann wird nämlich nicht nur bei einem SIGTERM aufgeräumt, sondern auch wenn das Programm durch einen Fehler oder durch Strg+C abgebrochen wird. Ausserdem sollte man den Handler früher registrieren, damit ein Abbruch während der LED-Animation per SIGTERM auch zum aufräumen führt.

    dummy ist kompletter Unsinn und ziemlich Willkürlich was den Wert angeht. Das wäre einfach while True:. Allerdings wäre hier statt einer „busy waiting“-Schleife, ein signal.pause() sinnvoller.

    Ungetestet:

    “The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.”
    — Nathaniel Borenstein

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!