Eigenartiges verhalten GPIO "1" nach skript restart

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hi....

    hoffe hier bin ich richtig :D

    jedenfalls habe ich ein kleines skript gebastelt welches meinen kleinen lüfter über 50°C einschaltet und bei weniger als 43°C wieder ausschaltet. funktioniert soweit gut. ABER

    wenn der Lüfter bei 50°C angeht und der pi eine Temp von .... z.B. 46°C hat läuft der Lüfter ja noch - alles ok bis hierhin. Wenn ich aber jetzt das Skipt mit STRG+C beende und dann wieder starte, müsste der Lüfter doch erstmal bis zum erreichen der 50°C aus bleiben - macht er aber nicht. Oder ist dies ein Logikfehler?

    hier das Skript:

    ( und wie findet ihr das Skript generell?)

  • Eigenartiges verhalten GPIO "1" nach skript restart? Schau mal ob du hier fündig wirst!

  • ( und wie findet ihr das Skript generell?)

    Schlecht. return ist keine Funktion, sondern ein Statement - behandle es auch so (wobei du es in 4 von 5 Fällen in deinem Code gar nicht brauchst. Ebenso quit()). PEP-8 wird vollkommen ignoriert. os und sys werden importiert, aber nicht genutzt. RPi.GPIO ist relativ alt, da gibt es seit langer Zeit das deutlich schönere und einfachere gpiozero. Warnungen deaktivieren ist einfach nur dämlich, die werden ja nicht ohne Grund ausgegeben.

  • Logikfehler. Du schaltest ja nur aus, wenn er UNTER 43 Grad ist. Und damit bleibt er auf dem alten Stand den der GPIO schon hatte. Wenn du einen definierten Zustand haben willst, musst du immer erstmal ausschalten.

  • Logikfehler. Du schaltest ja nur aus, wenn er UNTER 43 Grad ist. Und damit bleibt er auf dem alten Stand den der GPIO schon hatte. Wenn du einen definierten Zustand haben willst, musst du immer erstmal ausschalten.

    aber die GPIO´s werden doch alle nach dem abbrechen des skripts per cleanup auf "0" gehalten?! und beim neustart des skripts müsste die temp doch erst über 50 steigen damit erstmalig nach dem start der lüfter angeht.... oder?

  • Ich habe das so verstanden, das er trotz Skript-Abbruch noch läuft. Und auch danach nicht ausgeht. Was macht er wenn er läuft & dann day Skript beendet wir?

  • oh

    also skript läuft - lüfter ist aus - temp steigt auf > 50°C - lüfter geht an - temp sinkt auf z.B. 46°C lüfter läuft noch (alles ok bis hier)

    nun breche ich das Skript ab - lüfter hört auf sich zu drehen - ich starte erneut das skript - lüfter dreht wieder (46°C)

    nun... eigentlich sollte der lüfter doch aus sein?! auch zeigt mir das skript ja sonst auch "Lüfter an oder Lüfter aus" aber in diesem speziellen fall nicht

  • Ich verstehe zwar nicht, warum der aus und dann wieder an geht, aber das kann ggf schon so passen. Schlussendlich ist es wie ich sagte: mach ihn halt beim Programmstart aus.

  • Wie ist der Lüfter denn angeschlossen? Welche Bauteile wurden verwendet?

    Eventuell kann dir da der Fehler liegen.

    Es kann bei nicht korrekten Anschluss auch zu seltsamen Verhalten kommen. Eventuell liest das hier noch einer, der sich in der Hinsicht gut auskennt. Lass zur Sicherheit gleich mal alle Infos hier.

    Grüße

    Dennis

    🎧 With the music execution and the talk of revolution, it bleeds in me and it goes 🎧

  • Also ich habe nen Transistor BC 337 verwendet an der Basis ist ein Widerstand mit 560Ohm der dann zum GPIO pin 23 geht.

    Dann hab ich nen Pull-down Widerstand mit 10KOhm Basis zur Masse und eine Freilaufdiode 1N4007 Antiparallel zum lüfter.

    Und der Lüfter geht aus weil ein GPIO.cleanup gemacht wird beim abbrechen des Skripts - so solls auch sein - aber nach dem start des Skriptes sollte der ja auch aus bleiben - zumindest bis zum erreichen / überschreiten der Temperatur von 50°C

  • Ich hatte das was du gerade machst auch mal, allerdings mit einem BC547.

    Angeschlossen wurde dieser so:

    Pluskabel des Lüfters an die GPIO,

    Minuskabel des Lüfters an den Collector,

    Emitter an GND des Pi,

    Basis über einen 1000-Ohm-Widerstand an GPIO

    Kann die Anschlussbelegung nicht genauers interpretieren, habe mir das damals aufgeschrieben und der Person vertraut, die mir dabei geholfen hat.

    So hat es mit einem ähnlich "schlechten" Python-Skript wunderbar funktioniert.

    Weiters kann ich leider nicht mehr helfen,

    viel Erfolg noch.

    Grüße

    Dennis

    🎧 With the music execution and the talk of revolution, it bleeds in me and it goes 🎧

  • Wie oft muss ich dann noch sagen, dass du es dann eben so programmieren musst? Ich habe jetzt keine Lust forensisch durch den Code des rpi GPIO Moduls zu stapfen, um dir den Beweis anzutreten, das es so ist, wie du es beobachtest. Denn was ändert das?

    Schalt den GPIO halt einmal zu Beginn des Programmlaufes definiert auf 0, und gut ist.

  • Schalt den GPIO halt einmal zu Beginn des Programmlaufes definiert auf 0, und gut ist.

    Habe gerade ein Screenshot von meinem damaligen Python-Skript entdeckt.

    Genau das hatte ich auch zu Beginn des Skriptes drin stehen.

    GPIO.output(9, False) (Musst halt dein GPIO anpassen)

    Grüße

    Dennis

    🎧 With the music execution and the talk of revolution, it bleeds in me and it goes 🎧

  • Habe gerade ein Screenshot von meinem damaligen Python-Skript entdeckt.

    Genau das hatte ich auch zu Beginn des Skriptes drin stehen.

    GPIO.output(9, False) (Musst halt dein GPIO anpassen)

    Grüße

    Dennis

    komisch fand ich ja auch dass beim abbrechen und dann aufrufen von gpio readall im terminal alles auf "0" stand und dann beim starten des skriptes dann der lüfter wieder lief - also der GPIO pin auf "1"

    aber deine "Lösung" (bzw. umgehen) des "Problemes" funktioniert, danke - auch wenn mich das WARUM immernoch sehr interessiert.... Sorry aber ich bin eben so - sauge gerne informationen auf wie ein schwamm.

    Und möglicherweise portiere ich das ganze noch für gpiozero - vielleicht ist das ja wirklich etwas besser oder simpler....

  • Dann saug dir den Code des Moduls rein, C-teile inklusive, und versuch es nachzuvollziehen.

  • auch wenn mich das WARUM immernoch sehr interessiert.... Sorry aber ich bin eben so

    kann auch sein, weil es einen undefinierten Temperaturbereich von 43-50°C gibt und du nicht weißt, was der bei Initialisieren des Pins macht.

    Das ist einfach üblich, dass man zu Programmstart die Pins initialisiert und in einen bekannten definierten Zustand bringt.

    Bevor du deine Zeit mit sowas opferst, ließ dir lieber PEP 8 durch und bringe den Code in ein vernünftiges Format.

  • Zum wach werden habe ein bisschen aufgeräumt.


    Ist nicht getestet und möglicherweise sind noch Bugs enthalten.

    Es sollte jetzt weitestgehend PEP8-Konform sein.


    Die Namen

    Code
    CoreTempMin 
    CoreTempMax

    habe ich nicht geändert, auch wenn es gegen PEP8 ist.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!