Schalten der ON-Board LEDs

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Okay, die neue Version meines Skripts zum "Blitzen" mittels heartbeat in trigger funktioniert nun.

    Bash: blk.sh
    #!/bin/bash
    current_state=$(cat /sys/class/leds/PWR/trigger | awk -F'[][]' '{print $2}')
    sudo echo heartbeat > /sys/class/leds/PWR/trigger
    sleep 10
    sudo echo $current_state > /sys/class/leds/PWR/trigger

    Jetzt wäre noch die Frage, wie ich das andere Skript mit dem Blinken über brightness zum Laufen bekomme.

    Und noch ein Problem habe ich. Wenn ich solch eine Funktionalität in mein gesamtes Skript einbauen möchte, muss ich es immer mit Root-Rechten starten oder gibt es dafür einen "Ausweg"?

    Edited once, last by Mic2022 (April 23, 2024 at 10:28 PM).

  • Und noch ein Problem habe ich. Wenn ich solch eine Funktionalität in mein gesamtes Skript einbauen möchte, muss ich es immer mit Root-Rechten starten oder gibt es dafür einen "Ausweg"?

    Du verwendest doch sudo im Skript, wozu dann das Skript als ganzes als root starten?


    Jetzt wäre noch die Frage, wie ich das andere Skript mit dem Blinken über brightness zum Laufen bekomme.

    So wie Du das gezeigt hast, würde ich das nicht machen, weil damit unnötige Schreibzugriffe auf den Datenträger generiert werden. Entweder die PWR-LED komplett ab- und wieder anschalten oder die trigger-Variante wählen.

  • Ich habe noch einmal ein wenig mit meinen Skripten herumexperimentiert und auch im Netz gelesen. An sich müsste es ausreichen im Skript einen Befehl mit sudo zu starten, wenn das Skript selbst ohne sudo gestartet wurde. Bei mir funktioniert es aber leider nicht. Was müsste ich denn dafür tun?

    Auch habe ich noch keine Lösung gefunden, wie ich das Skript blinken.sh (mit brightness) sinnvoll laufen lassen und vor allem auch wieder stoppen kann. Wie kann ich die Blink-Funktion im Hintergrund laufen lassen, während im Vordergrund andere Funktionen ablaufen und dann die "Hintergrundfunktion" wieder zuverlässig stoppen?

  • Nabend Mic2022 ,

    wie du einen Zugriff auf die LED's als normaler Nutzer einrichten kannst:

    Eine Gruppe "leds" erstellen, deinen normalen Benutzer der Gruppe "leds" hinzufügen und eine udev-Regel erstellen:

    How can I change the permissions in /sys to alter the state of a LED/light using `udev`?
    I've got a Thinkpad and would like to use the ThinkLight (the white flash light above the screen designed to light up the keyboard) for notifications on…
    unix.stackexchange.com

    Hab dabei gesehen, dass man mit Trigger = "timer" ja die LED auch elegant blinken lassen kann.

    Gruß Martin

  • Damit funktioniert es nun auch, das Blinken mit brightness wieder abzuschalten. Wirklich gut gefällt mir das aber alles nicht. Ich bin noch nicht sicher, ob ich diese Funktionalität in mein Tool übernehmen werde.

  • Ich habs mal mit Trigger : timer probiert, ist das evtl. was du möchtest?

    Gruß Martin

  • Und nochmals... Ich würde nicht im Halbsekundentakt in die Datei /sys/class/leds/PWR/trigger schreiben, sondern einmal 0 und am Ende wieder 255 dort eintragen. Den Rest (blinken) macht die ACT-LED. Wenn mich nicht alles täuscht, dann hatte diese bei meinen Tests gestern an meinem RPi3B sogar die Farbe von gelb auf grün gewechselt.

    Das sind sonst völlig unnötige Schreibzugriffe auf die SD oder was auch immer da an Datenträger verwendet wird. Dann doch lieber die die andere Variante nutzen.

  • Macht es einen Unterschied, in die Datei trigger oder in die Datei brightness zu schreiben? An sich nicht, oder? Das einfache Skript (siehe #41) finde ich am elegantesten, auch wenn man da die Blinkfrequenz nicht einstellen kann. Man schaltet das "Blinken" ein und später schaltet man es wieder aus. Dennoch ist es mir etwas unwohl, dass ich nur dafür mein ganzes Skript mit sudo ausführen muss und dass ich dafür recht tief ins System eingreifen muss.

    Meine Idee war ja, dass ich die LED blinken lassen, währen mein influxBackup (siehe hier) läuft, weil dann das System recht gut ausgelastet ist und ich sehe, dass ich mal eine Weile nicht "daran rumfummeln" sollte. Ich gebe aber framp recht. Dieses Backup läuft bei mir nachts 4:00 Uhr. Da guckt eh niemand nach der LED. Nur während meiner Tests war das "Warten" manchmal etwas nervig.

    Gut finde ich aber, dass es überhaupt funktioniert. Ich denke, ich überleg's mir... 😁

  • An sich nicht, oder?

    Nein, das ist egal. Beide werden direkt vom Kernel ausgewertet und auch deshalb sollte man da nicht unnötig drinnen rumschreiben.

    Dennoch ist es mir etwas unwohl, dass ich nur dafür mein ganzes Skript mit sudo ausführen muss

    Ich dachte nun nicht mehr das ganze Skript? :conf:

    Meine Idee war ja, dass

    Ich kenne die Vorgeschichte und ja, das Skript aus #41 (wenn 10 Sekunden ausreichen und Du mit dem sleep 10 nicht alles lahmlegst) wäre zwar umständlich, aber ok.

  • Ich kenne die Vorgeschichte und ja, das Skript aus #41 (wenn 10 Sekunden ausreichen und Du mit dem sleep 10 nicht alles lahmlegst) wäre zwar umständlich, aber ok.

    Nein, die 10 Sekunden wäre nicht ausreichend. Ich brauche es eher für 20 Minuten oder so. Ich würde es, wenn ich es übernehme, aber auch als Funktionen in mein ganzes Skript einbauen. Statt dem sleep 10 würde dann z.B. meine Backup-Funktion laufen. Man könnte eine Funktion zum Einschalten des Blitzens in das Skript einbauen und eine Funktion zum Auschalten des Blitzens und dann nacheinander aufrufen: function BlitzenA () --> function Backup() --> function BlitzenAus(). Man darf nur nicht vergessen, den "Vorher-Status" der LED von BlitzenAn() nach BlitzenAus() rüber zu retten.

    Der Charme von dieser Variante via trigger - in meinen Augen - ist, dass man keine Funktion als Hintergrundprozess laufen lassen und später wieder "killen" muss. Dies Wäre der Ansatz bei brightness, was ich nicht so mag.

    Quote from @hyle

    Ich dachte nun nicht mehr das ganze Skript? :conf:

    Wie gesagt ohne ein sudo bash blk.sh funktioniert es nicht, auch wenn im Code sudo eingebaut sind. Ist für mich aber auch logisch, sonst könnte man ja diesen Sicherheitsmechanismus mithilfe eines Bash-Skripts leicht aushebeln. (Außer du kennst noch einen anderen Ansatz..?)

  • Hallo zusammen,

    Aber Martin28 hat Dir in #45 doch gezeigt, wie man das als User verwenden kann. Oder funktioniert das bei Dir nicht?

    danke für den Hinweis. Diesen Beitrag hatte ich tatsächlich übersehen. Habe es gleich ausprobiert und es hat tatsächlich auf Anhieb funktioniert. Zusammengefasst muss man dafür folgendes tun:

    Damit funktioniert es bei meinem Raspberry Pi 4, Model B mit Debian Bullseye 64-bit.

    Ich habe diese Funktionalität nun auch in mein Tool influxBackup eingebaut, sodass die rote LED nun blitzt, solange z.B. ein Backup läuft. Wer es sehen möchte, finden den Code dazu hier unter Beitrag #114.

    Danke noch einmal für eure guten Tipps..

    Grüße,
    Mic.

  • Das klingt spannend! Ich habe ebenfalls darüber nachgedacht, wie man die On-Board LEDs auf dem Raspberry Pi steuern kann. In der Regel kann man die grünen und roten LEDs über die GPIO-Pins ansteuern. Mit den richtigen Bibliotheken wie RPi.GPIO oder GPIO Zero lässt sich dies recht einfach in Python umsetzen. Ich bin gespannt auf dein Ergebnis und welche spezifischen LEDs du identifiziert hast. Gibt es bestimmte Anwendungen, die du im Sinn hast? Ich freue mich auf weitere Einblicke!

  • Hi Geff Rush ,

    dieses Thema ist schon ziemlich alt. Ich hab das "flashen" der roten LED bereits für mein influxBackup umgesetzt. Da diese Backups einer InfluxDB-Datenbank immer recht lang dauern und den RasPi arg auslasten, wollte ich sehen, wann er fertig ist. Das hat geklappt. Umgesetzt habe ich alles als SH-Skript (findet man hier auch im Forum).

    Grüße,
    Mic.

Participate now!

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