DHT22 Modul misst nicht zuverlässig

  • Hallo zusammen,

    ich bin mittlerweile ratlos, was den Betrieb meines DHT22 Moduls (DHT22-Modul) angeht- hoffentlich könnt ihr mir weiterhelfen:

    Mein System: Raspberry PI 3B+, mit folgenden HATs:

    1. StromPi 3 USV Hat (link)
    2. StromPi 3 Batterie Hat
    3. Relais-Hat (link [Anzeige])
    4. GPIO Hat (link)

    Angeschlossen habe ich folgende Elektronik:

    1. An Relais Hat, Relais #1: 230V Rolladenmotor (Richtung hoch)
    2. Relais #2: 230V Rolladenmotor (Richtung runter)
    3. Relais #3: 12V LEDs

    Das DHT22 Modul habe ich direkt angeschlossen (So hat mir das auch der Kundenservice des Shops erklärt):

    + vom Modul an ein +3.3V GPIO Pin

    - vom Modul an ein GND GPIO Pin

    Signalpin an BCM 4 GPIO Pin (1-Wire Pin)

    Problembeschreibung:

    Wenn ich den Raspberry PI starte, kann ich mit dem Adafruit DHT22 Skript die Temperatur auslesen.

    Nun starte ich meine SpringBoot (Java-Anwendung), welche anschließend minütlich die Temperatur liest und speichert. (Geht auch problemlos)

    Dann betätige ich das Relais, um die Rolladenmotoren anzusteuern- und danach sind keine Messungen mit dem DHT22 Modul mehr möglich...

    Ich habe das ganze auch auf meinem Test-Raspberrysystem nachgestellt, konnte das Verhalten nicht reproduzieren.

    Da habe ich auch eine 230V Lampe an ein Relais gehängt und dieses mehrfach geschalten- die Messungen gingen dort aber problemlos weiter...

    Ich weiß nicht warum das nur draußen an den Rolladen fehlschlägt...Habe schon vermutet dass es an der Verkabelung / Störungen liegen könnte, da recht viel Kabel draußen verlegt sind- aber da finde ich es zu komisch, dass es nach betätigen der Rolladenmotoren immer nicht mehr geht...

    Hier ein Auszug aus dem Anwendungslog, wo man sieht dass nach dem betätigen der Motoren die Temperaturmessungen nicht mehr gehen:

  • Ich weiß nicht warum das nur draußen an den Rolladen fehlschlägt...Habe schon vermutet dass es an der Verkabelung / Störungen liegen könnte, da recht viel Kabel draußen verlegt sind- aber da finde ich es zu komisch, dass es nach betätigen der Rolladenmotoren immer nicht mehr geht...

    Wie lang sind denn die Kabel zum DHT? Welches Kabel hast Du verwendet? Der Widerstand auf Deinem Modul zwischen Data und Vcc ist bestückt? Die Zeit zwischen den (erfolglosen) Leseversuchen ist wie lang?

    Dein Programm (mir unbekannt) versucht evt., den GPIO ebenfalls anzusprechen?

  • Wie lang sind denn die Kabel zum DHT? Welches Kabel hast Du verwendet? Der Widerstand auf Deinem Modul zwischen Data und Vcc ist bestückt? Die Zeit zwischen den (erfolglosen) Leseversuchen ist wie lang?

    Dein Programm (mir unbekannt) versucht evt., den GPIO ebenfalls anzusprechen?

    Habe die Kabel nun mittlerweile auf ca. 30cm gekürzt- sind ganz einfache einadrige Kabel, denke so ca. .14 oder .25mm Durchmesser.

    Einen Widerstand habe ich nicht eingebaut- da der Support von dem Sensorhersteller mir sagte, man kann die direkt an die GPIO Pins anschließen (https://www.az-delivery.de/products/dht22…sor-modul?ls=de)

    Ich lese den Code in meinem Programm mithilfe dieser Methoden aus. Falls es nicht klappt, misst er erneut. Bis zu 20x, dann misst er erst wieder nach einer Minute.

  • Habe die Kabel nun mittlerweile auf ca. 30cm gekürzt- sind ganz einfache einadrige Kabel, denke so ca. .14 oder .25mm Durchmesser.

    Einen Widerstand habe ich nicht eingebaut- da der Support ...

    IFalls es nicht klappt, misst er erneut. Bis zu 20x, dann misst er erst wieder nach einer Minute.

    Je länger die Kabel, um so größer das Risiko,dass es nicht geht. Bei 30cm Länge ist das imho aber unproblematisch.

    Sieh mal bitte nach, ob der Widerstand auf Deinem Modul verbaut ist. Ohne steigt das „geht nicht“ Risiko.

    20x hintereinander abfragen ist keine gute Idee, das kann der DHT nicht. Aus dem Kopf kenne ich die minimale Zeit nicht, ich glaube aber, es waren schon ein paar (2-3) ?Sekunden.

  • Je länger die Kabel, um so größer das Risiko,dass es nicht geht. Bei 30cm Länge ist das imho aber unproblematisch.

    Sieh mal bitte nach, ob der Widerstand auf Deinem Modul verbaut ist. Ohne steigt das „geht nicht“ Risiko.

    20x hintereinander abfragen ist keine gute Idee, das kann der DHT nicht. Aus dem Kopf kenne ich die minimale Zeit nicht, ich glaube aber, es waren schon ein paar (2-3) ?Sekunden.

    Habe nachgeschaut- da sind Widerstände verbaut, auf der Unterseite des Moduls, soweit ich das beurteilen kann.

    Ich rufe in meiner Anwendung die Methode wie oben beschrieben auf- wenn dann kein gültiger Wert zurück kommt, warte ich 2000millisekunden und messe dann erneut. Muss ich hier evtl. vorher die Pins resetten oder ähnliches?

    Habe versucht das Verhalten auf meiner Integrationsumgebung nachzustellen- auch einen PI angeschlossen, zeitlich getriggert die Motoren angesteuert, aber kann diesen Fehler so nie reproduzieren...Bin mittlerweile schon am überlegen, einen Arduino an den PI anzubinden, um die Messung auszulagern...Aber das macht die Infrastruktur nur noch komplexer.

  • 2000millisekunden

    sind IMHO zu kurz, versuchs erst einmal mit 10 Sekunden.

    Was unterscheidet die beiden Umgebungen (die, in der es nicht funktioniert und die Du nachgestellt hast)?

  • sind IMHO zu kurz, versuchs erst einmal mit 10 Sekunden.

    Was unterscheidet die beiden Umgebungen (die, in der es nicht funktioniert und die Du nachgestellt hast)?

    Gute Frage...habe vorgestern alle HAT´s (Wie oben beschrieben) von dem produktiven Raspberry abgemacht und auf den Integrations-Raspberry drauf - anschließend auch genauso an das Relais eine 230V Lampe (Statt wie produktiv den Rolladenmotor) und den gleichen 12V Trafo an das andere Relais angeschlossen.

    Den DHT22 habe ich genauso über das GPIO Breakout Board angeschlossen und dann die Anwendung gestartet- ich konnte aber diese Fehlmessungen nicht reproduzieren...

    Einziger Unterschied ist, dass draußen (produktiv) das Wlan natürlich nicht so stark ist wie drinnen (integration)...

    Ich finde es auch komisch dass immer wenn das Relais produktiv getriggert hat und den Rolladenmotor betätigte, danach ALLE Temperaturmessungen invalide waren, so wie wenn sich der DHT22 auf einmal aufhängte...aber ich weiß nicht warum - und vor allem nicht warum das wie gesagt NIE auf der Integrationsumgebung auftrat.


    Ich glaube nicht dass es mit der Wartezeit zu tun hat- weil ich ja einen zeitlichen Job definiert habe, der zur vollen Minute die Temperaturmessung antriggert- demnach hat er ja mind. 30 Sekunden Wartezeit, bis er erneut misst zwischen zwei Messjobs.

Jetzt mitmachen!

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