DHT22-Sensor muss regelmäßig vom Strom getrennt werden, um Werte zu liefern

  • Hallo zusammen,

    mein DHT22-Sensor macht etwas Probleme...

    Ich messe mit ihm die Innentemperatur sowie rel. Luftfeuchtigkeit.
    Das klappt an sich auch ganz gut.
    Zum auslesen hab ich über WiringPi das Programm loldht kompiliert.

    Angeschlossen hab ich den Sensor mit einer parasitären Stromversorgung - ein 10kOhm-Widerstand ist zwischen 3,3V und der Datenleitung.

    Das Problem, was aber nun aufgetreten ist, ist wie folgt:
    Der Sensor liefert erstmal stabil über mehrere Tage die Werte.
    Soweit so gut.

    Aber irgendwann, eben nach ein paar Tagen, "hängt" sich der Sensor irgendwie auf.
    Ein Reboot hilft gegen diesen Zustand nicht, man muss den Raspberry komplett vom Strom trennen.
    Nachdem man kurz gewartet, den Raspberry wieder mit Strom versorgt hat, liefert der Sensor wieder seine Werte.
    Aber das "Spielchen" beginnt damit von Neuem, was echt lästig ist.

    Kennt einer das geschilderte Problem oder weiß eine Lösung für selbiges?

    Besten Dank im voraus,
    Gruß
    Andreas

  • DHT22-Sensor muss regelmäßig vom Strom getrennt werden, um Werte zu liefern? Schau mal ob du hier fündig wirst!


  • Kannst du bitte dein Script posten sowie wie genau du es ausführst?

    Mein Skript sieht wie folgt aus:

    Bash
    #!/bin/bash
    # Liest Sensordaten aus und speichert sie in einem TXT-File in /tmp
    #
    #
    while true;
       do
       /usr/local/bin/loldht 0 | grep Humidity | cut -d" " -f3,7 | sed 's/ /;/g' > /tmp/loldht_0.txt &
       sleep 60s
       done
    exit 0

    Als Ergebnis erhalte ich "normalerweise" (wenn der Sensor nicht hängt) dann die Ausgabe in o.g. Textdatei geschrieben.
    Das Format der Werte bzw. die Ausgabe schaut so aus:

    Code
    74.70;19.20

    Ein weiteres Skript verarbeitet mir die Textdatei und schiebt mir die Werte zyklisch in meine Datenbank.
    Normalerweise starte ich das Skript einfach mit & hinter den Aufruf, um es im Hintergrund laufen zu lassen.

    Wenn der Sensor allerdings hängt, ist die Ausgabe dann nur noch:

    Code
    Data not good, skip
    Data not good, skip
    Data not good, skip
    ....


    Werte landen dann natürlich nur noch Null-Werte in der DB.

    Einmal editiert, zuletzt von Andreas Meier (10. April 2016 um 13:00)

  • Hast du mal probiert nu den Sensor selbst vom Strom zu trennen & wieder anzuklemmen?


  • Hast du mal probiert nu den Sensor selbst vom Strom zu trennen & wieder anzuklemmen?

    Im laufenden Raspi-Betrieb?
    Ich meine, dass ich das mal probiert hatte, bin mir aber nicht mehr sicher.

    Das Ergebnis ist ja aber m.E. dasselbe, sprich, der Sensor erhält eine Stromlos-Phase.

    Ich mach das lieber über Raspi-herunterfahren, vom Strom trennen, etc.
    Dadurch speichern meine Skripte alle relevanten Daten korrekt und beim Hochfahren laufen alle Skripte auch wieder korrekt hoch.
    Wenn ich nur den Pin von den GPIOs trenne, weiß ich nicht genau, wie meine Skripte reagieren.

    Einmal editiert, zuletzt von Andreas Meier (10. April 2016 um 13:10)

  • Naja wenn es reicht zB GND vom Sensor zu trennen ist das ja eigentlich so als würdest du manuell den Pi stromlos machen - mit dem Unterschied das du ersteres mithilfe eines Transitors automatisieren kannst.

    Eine Frage hätte ich noch: Wie genau hast du den Sensor angeschlossen? Bitte so genau wie möglich beschreiben, vllt. sogar skizzieren.


  • Naja wenn es reicht zB GND vom Sensor zu trennen ist das ja eigentlich so als würdest du manuell den Pi stromlos machen - mit dem Unterschied das du ersteres mithilfe eines Transitors automatisieren kannst.


    Das versteh ich noch nicht, kannst Du das bitte genauer beschreiben?


    Eine Frage hätte ich noch: Wie genau hast du den Sensor angeschlossen? Bitte so genau wie möglich beschreiben, vllt. sogar skizzieren.

    Ich hab gemäß dieser Anleitung zwischen den 3,3V-Pin und den Daten-Pin am Sensor einen 10kOhm-Widerstand verlötet.
    Der Sensor ist dann wie folgt am Pi angeschlossen:

    Code
    3,3V = Pin17
    Daten = Pin 11
    Ground = Pin 9

    Einmal editiert, zuletzt von Andreas Meier (10. April 2016 um 13:27)

  • Naja du kannst einen Transistor zwischen GND vom Pi und GND vom Sensor schalten und auf die Steuerleitung des Transistors liegst du einen GPIO. Wenn du dann den Sensor abfragen willst schaltest du den "Steuer-GPIO" ein, wartest 2 Sekunden um dem Sensor eine gewisse Aufwärmphase zu geben, liest den Sensor aus und schaltest anschließend den Sensor wieder aus. Auf die Weise solltest du dann nie wieder Probleme kriegen
    Dabei kannst du dich an folgendem orientieren, wobei du einfach anstatt Lüfter deinen Sensor setzt: FAQ => Nützliche Links / Linksammlung => Lüftersteuerung per Temperatur + Einbauanleitung

  • Die Frage ob es reicht den Sensor vom Strom zu trennen und wieder anzuklemmen hat nichts damit zu tun, ob das der gewuenschte Endzustand ist, sondern dient der Diagnose. Wenn es NICHT reicht, dann gibt es ein Problem beim PI, wenn es reicht, ist der Sensor das Problem. Und dann kann man sich weitere Schritte ueberlegen. Zb wie von meigrafd angesprochen einen Transistor zum schalten zu nutzen, oder vielleicht einen neuen Sensor zu kaufen, weil es halt eine Fehlfunktion ist.


  • Hallo zusammen,


    Der Sensor liefert erstmal stabil über mehrere Tage die Werte.
    Soweit so gut.

    Aber irgendwann, eben nach ein paar Tagen, "hängt" sich der Sensor irgendwie auf.

    Tach'chen,

    das Problem ist bekannt und lässt sich über einen PowerCycle des Sensors lösen.
    Hier habe ich eine Lösung gefunden: http://abyz.co.uk/rpi/pigpio/examples.html
    (python code vom 2014-07-11, ziemlich weit unten). In den Kommentaren der
    DHT22.py findet man:

    "Optionally a gpio used to power the sensor may be specified.
    This gpio will be set high to power the sensor. If the sensor
    locks it will be power cycled to restart the readings."

    Für die Stromversorgung wird ein GPIO Pin verwendet (ohne Transsistorschaltung).
    Ich habe das mal an einem Pi1 ausprobiert und kann bestätigen, dass damit die lockups
    verschwinden.

    Beste Grüße,

    /luetzel

  • Das ist eine sehr riskante Lösung, da die GPIO's insgesamt nur ca. 51mA ausgeben können und alles drüber würde diese überlasten. Die GPIO's kommen direkt und ungebuffert vom SoC. Kann man sich also ausmahlen was kaputt geht wenn die GPIO's überlastet werden - und wie gesagt gilt diese Obergrenze für alle GPIOs insg., wenn man also noch mehr angeschlossen hat oder anschließen will ist diese Grenze schneller erreicht als man glauben mag, auch wenn der DHT22 nur ca 2mA benörigt.

    Besser wäre wie bereits erwähnt die 3V3 Schiene zu verwenden und dann GND oder 3V3 direkt (wobei GND besser wäre) zu schalten.

  • Ich habe auf meinem einzigen RasPi, der noch einen DHT-Chip abfragt, das gleiche Problem und kenne einen weiteren User, bei dem das gleiche Problem auftritt.
    Das scheint also ein "Design"-Feature beim RasPi zu sein, weil die Sensoren am Arduino/ESP8266 (überall laufen die Sensoren mit 3,3V + 100nF Stütz-C) laufen seit Wochen stabil.

  • Das kann ich nur bestätigen.
    Ich bin Neuling in Raspberry und habe schon aufgegeben in der Thematik Raspberry mit DHT22 als dann der Kontakt mit KrawallKurt zustande gekommen ist.
    Zuhause ging es weitgehen Problemlos mit ca. 40 Meter Kabel 3x1,5 und ca. 60 Meter Kabel Cat.7
    Jetzt habe ich das ganze richtig Installiert mit aktuell 5 Sensoren.
    Einen Sensor der im Hof ist funktioniert wunderbar die anderen Sterben nach etwas 2 Stunden bis 20 Stunden. Dann hilft nur Stecker ziehen 21 22 23 Warten und wieder einstecken.
    Aber der Tipp mit dem Sensor absteckt und wieder neu aufstecken in den laufenden Betrieb werde ich mal versuchen.
    Die Leitungslänge ist von 5 Meter im Hof bis max. 20 Meter Cat.7 Verlegekabel.
    Als Widerstand verwende ich 4,7kOhm mit einem 100nF Kondensator.
    Der Raspberry ist ein älteres Model (RASPBERRY PI B+) aber neu gekauft.

  • Naja wenn man beachtet das es sich beim Pi um ein 3V3 Gerät handelt und nicht nur die I/O's am Strom der 3V3 Schiene nagt, ist die logische Schlussfolgerung das es nicht am Pi selbst liegt wenn man 20 Meter Kabel verwendet :fies:

    Der RaspberryPI bis B+ ist so konstruiert das er über den regulären micro-USB Stromanschluss maximal 1A aufnehmen kann, also auch wenn man ein 5A Netzteil anschließt sorgt eine Sicherung dafür das er maximal 1A "rein lässt". Ab B+ wurde das auf 2A erhöht.

    Da die nackte Hardware 700mA - eher mehr als weniger, man sollte also lieber mit bis zu 800mA rechnen - benötigt, stünden für andere Peripherie (USB-Geräte, GPIO usw) nur noch insg. ca. 200-300mA zur Verfügung. Ab dem B+ entsprechend 1A mehr.

    Es hängt also nicht nur davon ab wie viele Sensoren dran hängen oder wie lang die Kabel sind etc., sondern auch was sonst noch so am Pi angeschlossen ist (Peripherie).


    Beim Arduino wird nur der AVR und ggf USB Chip versorgt, weitere Peripherie gibts nicht. Der AVR arbeitet mit 5V, je nach Model auch mit 3V3.

    Ein reiner Microcontroller ist also nackter und daher nicht wirklich mit einem Computer vergleichbar. Also bitte nicht Äpfel mit Birnen vergleichen!

  • Hallo Meigrafd,

    könntest Du den Widerspruch in der Aussage
    quote='meigrafd' pid='215974' dateline='1460313235']
    Der RaspberryPI bis B+ ist so konstruiert das er über den regulären micro-USB Stromanschluss maximal 1A aufnehmen kann, also auch wenn man ein 5A Netzteil anschließt sorgt eine Sicherung dafür das er maximal 1A "rein lässt". Ab B+ wurde das auf 2A erhöht.
    [/quote]
    bitte auflösen? Meines Wissens hat bereits das Modell B+ die Möglichkeit, 2 A zu nutzen (abzgl. des eigenen Strombedarfs). Du verwendest das Modell B+ sowohl im Zusammenhang, nur 1 A aufnehmen zu können als auch 2A ...
    :s
    Was magst Du nun meinen?

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Andreas: Kennst du nicht den Unterschied zwischen "bis B+" ...und... "ab B+" :huh:

    "bis B+" beziffert alle Modelle davor.
    "ab B+" beziffert alle Modelle inkl. und nach B+

  • "Das Station ist bis auf den letzten Platz ausverkauft"
    Ich kann aber auch nicht sagen:
    "OK dann nehme ich halt den!"

    statt bis B+ wäre vor B+ verständlicher gewesen.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

Jetzt mitmachen!

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