Posts by Andreas

    Hallo Hans,


    Du machst es Dir viel zu kompliziert.


    Du liest die ID des Sensor aus ==> gut.

    Du liest die Temperatur zu jeder Sensor ID aus ==> gut


    Du brauchst doch bloß für jede Sensor-ID einen Offset zu definieren und direkt bei der Messung addieren / subtrahieren. ==> Lässt sich recherchieren.


    Da spart Du Dir die ganzen Zeilen mit INDEX-basierten Abfragen. Wenn da mal ein Sensor verloren geht, dann ziehst Du den Korrekturwert vom falschen Sensor ab...



    Beste Grüße


    Andreas

    Hallo Hyle,

    Ein freudscher Verschreiber? ^^ Du meinst Mysterium oder?


    Kannst Du bitte, nur zur um Missverständnisse auszuschliessen, eine Link zu Deinem Netzteil oder dem von Dir gekauften Set zeigen?

    Nee, aber vergessen, "Mysterium" zu erwähnen.

    Zu den Mysterium-Threads gelangt man durch:

    1. Tag "Icon"
    2. Link "Meine Linkliste"
    3. Links auf > 30 Threads zum Thema Mysterium


    Außerdem ... :conf: ... :bravo2: ... muss ich jede sich mir bietende Möglichkeit nutzen, auf :auslachen: Icon und auf :auslachen: Unicon hinzuweisen.



    Beste Grüße


    Andreas

    Hallo amigholla,


    zu 2.: Dann hängt es natürlich von Deiner Konfiguration in /boot/config.txt ab. Da müsstest Du Dich mal einlesen, mit welchen Parametern Du dem Kernel mitteilen kannst, dass auf Nichtvorhandensein von HDMI nicht reagiert werden soll. In der Datei /boot/config.txt ist ein Link auf ein Manual, welche Parameter welche Auswirkungen beim Hochfahren haben.

    Vielleicht ist da was dabei...



    Beste Grüße


    Andreas

    Hallo amigholla,


    hm ... ich bin fast doppelt so alt wie Du und komme aus dem Badischen. Bin aber vor 12 Jahren zugezogen. Linux nutze ich seit 14 Jahren.

    da gibt es mehrere mögliche und denkbare Ursachen, die Deine Beobachtungen plausibel machen.


    Ich zähle einfach mal meine spontanen Gedanken auf.

    1. Das 64-Bit-OS ist möglicherweise noch nicht ganz ausgereift. Das war auch der Grund, weshalb ich nach mehreren 64-Bit-OS-Installationen auf dem RPi 400 ein 32Bit-OS aufgespielt habe. Seitdem läuft es sehr rund.
    2. Beim Hochfahren schaut das OS, was so alles vorhanden ist. Für jede vorgefundene Hardware wird ein sog. Dienst gestartet. Wenn eine Hardware ohne vernünftige Abmeldung am OS "abgezogen" wird, dann stellt der Dienst fest, dass da was fehlt und versucht durch entsprechenden Mehraufwand (Du ahnst es: ein weiterer "Pannendienst" wird gestartet) den vermeintlichen Defekt zu beheben. Der Pannendienst scheitert - und wird bald darauf erneut gestartet. Dein OS ist dann irgendwann mehr mit dem Pannendienst beschäftigt als mit den restlichen Anwendungen.
    3. HDMI war bei den ersten Modellen kein echtes Plug & Play. Wie das beim RPi 400 ist, weiß ich nicht. Ich kann mir aber vorstellen, dass das auch noch so ist - oder nicht vollständig Plug & Play ist.
    4. Eine direkte Folge von 2. ist, dass dadurch der Strombedarf steigt. Je nach Robustheit Deines Netzteils und was Du sonst noch so angeschlossen hast, kann es mit der Spannungsversorgung eng werde und da OS selber deaktiviert den einen oder anderen Dienst. Wenn das OS den Eindruck hat, dass einer der deaktivierten Dienste wieder zugeschaltet werden könnte, wird ein Versuch gestartet. Und wieder ... Und wieder ...


    Wenn Dich 2. und 4. mehr interessiert: Suche mal unter dem Stichwort Tag "Icon" meine Linkliste. Dort habe ich etwas über 30 Threads zum Thema "Mysterium" gesammelt, die in die gleiche Richtung gehen - aber jeweils unterschiedliche Ursachen haben. Vielleicht beobachtest Du noch andere Phänomene, die dann meine Vermutungen untermauern.


    All das und jedes für sich führt zu einer sinkenden Performanz des Gesamtsystems und damit auch zur Verlangsamung des Datenverkehrs.


    Ich bin gespannt, was die Kollegen noch so an Ideen entwickeln.



    Beste Grüße


    Andreas

    Hallo Dietmar,

    ...


    Bevor ich diesen Beitrag erstellt habe, habe ich mich erfolglos bemüht im Internet fündig zu werden. Ich bitte um Entschuldigung, falls ich gegen die Forenregeln verstoßen haben sollte und bin auch hier für Aufklärung dankbar.

    Hallo Dietmar,


    herzlich Willkommen in diesem Forum!


    Für eine Einstiegsfrage hast Du schon mal einen (positiven) Standard gesetzt.


    Der von Dir verwendete Widerstand 4K7 gilt für einen einzigen angeschlossenen DS18B20. Wenn mehrere DS18B20 angeschlosssen sind, ergänzt sich der Widerstand - Dein Widerstand muss dann verringert werden, wenn Sensoren (die mal angezeigt wurden) "verloren" gingen.


    Ich verwende bei meinen Aufbauten zunächst ein Potentiometer 5K, bei dem ich mich mit der maximalen Einstellung (5K) langsam einer Einstellung nähere, bei dem alle DS18B20 noch stabil angezeigt werden. Im Laufe der Zeit (Minuten, Stunden, Tage) ist dann oft ein Nachregeln zu kleineren Widerständen erforderlich.

    Wenn es dann über einen längeren Zeitraum (Wochen, Monate) stabil funktioniert, ersetze ich das Poti durch einen Festwiderstand gleicher Größe wie dann eingestellt.


    Wenn Du Angst haben solltest, dass Du das Poti auf 0 Ohm regeln könntest, dann setze einfach einen Festwiderstand 820 Ohm davor.



    Alternativ gibt es auch programmierbare Widerstände (Digitalpotentiometer, Rheostat) oder steckbare Widerstandsdekaden, um den Widerstand auf ddie Schnelle beliebig anzupassen.


    Ein programmierbarer Widerstand hätte den Vorteil, dass Du bei erkanntem Verlust eines DS18B20 softwaregesteuert nachregeln kannst, bis die Dir bekannte Anzahl an Sensoren wieder angezeigt wird.


    Beispiel:

    • MCP 41HV51-5K mit einer Auflösung von knapp 20 Ohm
    • MCP 4441-502E/ET mit einer Auflösung von knapp 40 Ohm


    Beste Grüße


    Andreas

    Hallo DistroEx,


    dann passt das doch (aus meiner Sicht):

    Das müssten dann andere noch mal testen. Bei mir ist /led1/ für die rote LED.

    Beim RPi 400 leuchtet die PWR-LED grün (bei den anderen Modellen definitiv rot). ==> LED0

    Beim RPi 400 scheint es keine von vorne sichtbare ACT-LED zu geben. Die leuchtete bei den früheren Modellen definitiv grün. ==> LED1


    Beim RPi 400 leuchtet die NUM_LOCK und die CAP_LOCK-Taste rot.



    Beste Grüße


    Andreas

    Moin DistroEx,


    Moin!


    Ist PWR nicht die rote, und ACT die grüne bei 4B? Dann hast Du im Post /led0/ und /led1/ vertauscht?

    Beim RPi 400 leuchtet die PWR-LED grün, während die NUMLock und die CapsLock-LEDs bei Bedarf rot leuchten.

    Die ACT-LED habe ich noch nicht entdeckt.


    Deswegen bin ich mir sicher, dass ich led0 und led1 nicht vertauscht habe (wenn ich mich auf den RPi 400 beziehe). Auf anderen RPi habe ich das Zeug aus #1 nicht getestet.


    Interessant finde ich aber, dass mit diesen Befehlen (nur anderen LED-Bezeichnungen) auch die LEDs einer externen Tastatur geschaltet werden können. Vielen Dank für den Hinweis!



    Beste Grüße


    Andreas

    Moin DistroEx,


    herzlich Willkommen in diesem Forum!


    Moin!


    Die gehen aber nach kurzer Zeit wieder in den Zustand zurück, in dem sie vor dem Befehl waren. Schaltet also nur die LED (kurz) um, nicht Klein/Großschreibung z.B. Ist das beim RPi400 anders?

    Beim RPi 400 leuchten die LEDs so lange, bis ein anderes Kommando den Zustand ändert. Anerenfalls hätte ich das ja nicht als Statusanzeige verwenden können.


    Beste Grüße


    Andreaas

    Hallo Hyle,


    mir ging es NUR darum, die drei LEDs des RPi 400 als Statusanzeige (Fortschritt, Gutteil, Schlechtteil) zu missbrauchen, ohne über die GPIO irgendwelche LEDs auf einer zu erstellenden Platine, Gehäuse etc. anzusteuern.


    Na klar, man kann die LEDs auch dauerhaft ausschalten. War aber nicht das Thema für mich.



    Beste Grüße


    Andreas

    Hallo zusammen,


    angeregt durch diesen Thread, habe ich mich eben damit beschäftigt, ob und falls ja, welche der On-Board LEDs man softwareseitig steuern kann.


    Hier das Ergebnis meiner Recherche. Gilt für RPi 2, 3, 4, Zero


    PWR-LED

    Einschalten

    Code
    sudo su
    echo 1 > /sys/class/leds/led0/brightness

    Ausschalten

    Code
    sudo su
    echo 0 > /sys/class/leds/led0/brightness


    ACT-LED

    Einschalten

    Code
    sudo su
    echo 1 > /sys/class/leds/led1/brightness


    Ausschalten

    Code
    sudo su
    echo 0 > /sys/class/leds/led1/brightness


    CAPS-LOCK-LED (RPI 400)

    Einschalten

    Code
    sudo su
    echo 1 > /sys/class/leds/input1::capslock/brightness


    Ausschalten

    Code
    sudo su
    echo 0 > /sys/class/leds/input1::capslock/brightness



    NUM-LED (RPi 400)

    Einschalten

    Code
    sudo su
    echo 1 > /sys/class/leds/input1::numlock/brightness


    Ausschalten

    Code
    sudo su
    echo 0 > /sys/class/leds/input1::numlock/brightness



    Und die Umsetzung in den Programmierprachen Ion und Unicon sieht dann so aus:


    Code-Deutung:

    Die Funktion bekommt einen Namen und erwartet zwei Argumente. Das erste ist eine Zeichenkette, die die OnBoard-LED bezeichnet (CAPS_LOCK, NUM_LOCK, PWR). Das zweite ist ein Modus, der entweder den Status der LED angibt (0 für aus und 1 für leuchtet) oder leer bleibt. In letzterem Fall soll der Status bei jedem Aufruf hin- und herschalten (sog. toggeln).


    Es werden drei statische Variablen definiert. Diese behalten nach Verlassen der Funktion ihren Wert und stehen beim nächsten Aufruf unverändert zur Verfügung. Die Verwendung statischer Variablen ist eine Möglichkeit, globale Variablen zu vermeiden. Globale Variablen werden in Icon und Unicon nicht so als Teufelszeug betrachtet wie in Python. Aber egal...


    Ursprünglich wollte ich das Schalten der OnBoard-LEDs über kleine Bash-Skripte machen. Das war aber zu langsam.

    Dann zeigte sich das Ganze sehr störrisch im Zusammenspiel mit meiner Anwendung, wenn da plötzlich der Anwender wechselt und kein Weg zurück führt.

    Und in einer Hochsprache in eine Datei eine 0 oder eine 1 zu schreiben, ist jetzt auch nicht so'n Ding.


    Also muss der Weg darüber gehen, dass der Eigentümer der LEDs auf den User pi gesetzt werden muss.



    Dann folgt ein Initial-Block, der nur beim allerersten Aufruf dieser Funktion aufgerufen wird. Hier passiert also etwas, was nur einmalig geschehen soll.

    Hier wird der Eigentümer der LED-Dateien auf den User pi gesetzt


    Dann folgt eine Fallunterscheidung. Je nach zu verwendender LED passiert so ziemlich das Gleiche (hier hätte man den Code auch in eine weitere Funktion ausgliedern können).


    Der Ausdruck /caps_lock := 1 bedeutet, dass die statische Variable caps_lock nur dann auf 1 gesetzt wird, wenn die Variable noch keine Zuweisung auf etwas anderres als &null erfahren hat.


    In der Zeile if /modus then caps_lock := ixor(caps_lock, 1) else caps_lock := modus passiert folgendes:

    Falls beim Funktionsaufruf das Argument modus nicht beachtet wurde, dann soll der Status der LED "getogglet" werden. Dieses Umschalten geht am aller einfachten durch einen Exklusiv-Oder der betreffenden Variablen mit 1. Dadurch wird streg genommen das niederwertigste Bit umgeschaltet.

    Wenn das Argument modus doch einen Wert enthält, dann soll dieser Wert der LED zugeordnet werden.


    Dann wird die betreffende Datei zum Schreiben geöffnet und der Wert, der der LED zugewiesen wurde (also 0 oder 1 ) in die Datei geschrieben. Die LED leuchtet und erlischt.

    Die geöffnete Datei wird dann schnellstmöglich wieder geschlossen.


    Was für CAPS-LOCK gemacht wurde wird analog für NUM_LOCK und PWR wiederholt.


    Dadurch erreicht man, das mit einer Funktion 3 LED unabhängig voneinander gesteuert werden können.



    Beste Grüße


    Andreas

    Hallo Michael,


    Fehlermeldungen beim Bootvorgang sind jedenfalls nicht normal und deuten auf erhebliche Probleme hin, die vorrangig gelöst werden müssen. Wenn da mal ein Hinweis auf irgendwas nicht vorhandenes kommt, was Du eh nicht benötigst, dann spielt das natürlich keine Rolle. Aber zu viele "rote Meldungen" erzeugen wenig Vertrauen in Deine gesamte Installation.


    Die Verwendung eines aktiven USB-Hubs ist eine gute Empfehlung. Solange wir aber nicht wissen, ob durch den aktiven USB-Hub eine sog. Rückspeisung stattfindet, kommen wir bzgl. der Hauptfehlerquelle keinen Schritt weiter.


    Rückspeisung bedeutet, dass die Spannungsversorgung des RPI nicht mehr über das Netzteil des RPi läuft, sondern über das Netzteil des aktiven USB-Hub. Ob das bei den aktuellen RPi noch der Fall ist, weiß ich nicht. Das war auf jeden Fall bei den ersten Modellen der Fall und führte ebenso zu Problemen in der Spannungsversorgung. Deswegen habe ich immer ein Messgerät angeschlossen - insbesondere dann, wenn es eines aktiven USB-Hub bedarf.


    In dem Fall muss eben die Spannungsversorgung des USB-Hub ausreichend dimensioniert sein, um den RPI inkl. allem dort angeschlossenen Geräten plus allem, was am aktiven USB-Hub angeschlossen ist, zu versorgen. Dann solltest Du noch beachten, dass der Anfangsstrom nicht an die - in Deinem Fall 3,5 A - herankratzen darf (Stichwort: Mysterium in meiner Linkliste).

    Üblicherweise berücksichtigt man noch einen Sicherheitspuffer, so dass das Netzteil nur zu etwa 2/3 seines Nennstroms belastet wird.


    Ich denke, dass Du jetzt genug Informationen haben solltest, um DEINE Installation zielführend zu gestalten. Ggf. solltest Du Deine Installation mit einem frischen OS beginnen und nicht mit einer Sicherung, die vielleicht durch einen Absturz bereits geschädigt ist. Auch das könnte die nicht näher genannten Fehlermeldungen erklären.



    Letztlich gibt es auch aktive USB-Hubs mit 7A-Netzteilen. 3,5 A scheint mir in Deinem Fall auch nicht ausreichend zu sein.



    Beste Grüße


    Andreas

    Code
    sudo su
    echo 0 > /sys/class/leds/led1/brightness

    Für alle RPis ab inkl. Modell 2 A, 2B, etc.


    Wenn Du den Raspberry Pi der ersten Generation meinst: Dort ist die PWR LED direkt an 5 V angeschlossen. Da kannst Du die PWR LED nicht schalten.


    Die einzige Möglichkeit, die Dir bleibt (was ich aber nicht zur Nachahmung empfehlen kann), einen Verbraucher an 5V & GND der GPIO-Leiste anzuschließen und darüber soviel Strom zu ziehen, bis die Spannung abfällt. Unterhalb einer gewissen Spannung blinkt die PWR LED, unterhalb einer gewissen Spannung erlischt die LED.

    Allerdings kannst Du mit dem RPI dann nur noch bedingt arbeiten, da er dann nur noch damit beschäftigt ist, mal gestartete Dienste immer wieder zu deaktivieren und zu reaktivieren.

    Hallo FSC830,

    Andreas : Meinst Du diesen Thread: hifi-berry-runterfahren-mittels-schalter?

    Denn unter Dem Stcihwort "Reset-taster" liefert die Suche nicht wirklich etwas. :no_sad:


    Gruss

    nee.


    Wähle den Tag "Icon", dort suchst du nach dem Thread "Reset-Taster am GPIO und Programmierung in Icon".


    Da hast Du Recht, die Suchfunktion ist sehr eigenwillig. Ich habe gestern auch einen Thread von mir gesucht und auch nach phantasiereichen Änderungen der Suchparameter nicht(s) gefunden. Deswegen habe ich im Oktober 2017 auch meine "Link-Liste" zusammengestellt. Die ist übrigens auch über den Tag "Icon" recht leicht auffindbar.


    Die suche mag dann länger dauern - aber man findet wenigstens immer das Passende...



    Beste Grüße


    Andreas

    Hallo Kai,


    schaue mal nach dem Thread "Reset-Taster" von mir.


    Da gibt es eine Schaltung, wie man einen Taster an die GPIO anschließt inkl. Software, wie dadurch bei unterschiedlich langem Gedrückthalten entweder ein Reboot oder ein Shutdown durchgeführt wird.


    Das Booten aus dem stromlosen Zustand lässt sich ganz einfach durch einen Taster am "RUN-Pin" (oder wie auch immer sie bei Deinem Modell heißen mögen) realisieren.


    Somit ist es dann auch "Laien" möglich, den RPi risikofrei auszuschalten und neu zu starten oder bei Bedarf zu rebooten.


    Beste Grüße


    Andreas

    Hallo Michael,


    Deine eingangs gepostete Ausgabe von dmesg bzgl. disconnect USB ... device number ist typisch für eine nicht ausreichende Spannungsversorgung bzw. von zuviel angeschlossener Peripherie bzw. von zu großem Strombedarf der Peripherie. Oder hast Du etwas an USB angeschlossenes entfernt?


    Wie viel Strom verbrauchen denn jetzt die Dongles der Maus M720 und der Tastaturen K800 und K850?


    Beste Grüße


    Andreas