DHT22 hängt immer nach Arduino Firmware Reset

Heute frage ich in die Runde, ob wer eine Idee hat, was ich mit einem rumzickenden DHT22 Temperatur/Luftfeuchte-Sensor noch probieren könnte. Ich benutze die Adafruit DHT-sensor-library-master 1.3.4. Mit der 1.3.0 trat der Fehler auch auf.

Was läuft schief?
Ein Bild sagt mehr als viele Worte, die grüne Linie ist die Temperaturmessung eines DHT22:

Mein Problem:
Jedes Mal, wenn ich Firmware flashe oder den Arduino resete oder das ganze System (Yun) neustarte, hängt einer meiner beiden DHT22 bei konstanten 8,01°C. Sonst funktioniert alles.

Ziehe ich dann im laufenden Betrieb das Datenkabel des betroffenen Sensors aus dem Pin und stecke es wieder rein, dann liest er korrekt ab ab dann.

Hardwarefehler oder sowas wie bei @clemens kann ich ausschließen, da ich zwei DHT22 drin hängen habe und, wenn ich sie vertausche, dann liefert der andere den Fehler.

Der gesamt Sketch ist hier in meinem dev-repo.
Mit diversen delays an verschieden Stellen hab ich experimentiert. Half nix.

Hier die DHT22-Ausschnitte aus dem sketch:

...
#include "DHT.h"
#define DHT1PIN 2   
#define DHT2PIN 3
#define DHT1TYPE DHT22   
#define DHT2TYPE DHT22 
DHT dht1(DHT1PIN, DHT1TYPE);
DHT dht2(DHT2PIN, DHT2TYPE);
...
void setup()
{
...
  dht1.begin();
  dht2.begin();
...    }

void loop()
{
...
  h1 = dht1.readHumidity();
  t1 = dht1.readTemperature();
  h2 = dht2.readHumidity();
  t2 = dht2.readTemperature();
...
}
...

Das ganze ist kein Riesenproblem, aber es nervt ein bisschen, weil ich ja mit dem Yun fernwarten will, und dann nicht an den Pins rumspielen kann…

Ich freu mich, wenn wer eine Idee hat und träume schon mal davon.
Gute Nacht!

Hi @mois,

Das ist verständlich und ärgerlich.

Erstmal nur eine Rückfrage: Hast Du das System denn voll am Strom und kannst deshalb auf Deepsleep o.ä. verzichten? Falls ja, versuche doch einmal, vor jeder Messung dhtX.begin() zu rufen und ggf. danach das inverse Pendant dhtX.{end,stop,deinit}() dazu, falls vorhanden.

Viele Grüße,
Andreas.

nee, das hat nichts gebracht, auch mit 2sec delay danach vor der messung nicht (oder ist das eher kontraproduktiv?).

hi,

sorry das ich da nochmal nachhake… du hast die dht vertauscht und der fehler wandert mit?

dann ersetze den dht doch mal (wenigstens testweise) durch einen bisher noch nicht benutzten/neuen/bekannt guten. die haben nicht so den glorreichen track-record ;)

ich hab in deinem code gesehn das du ein ‘richtiges’ loadbridge-frontend einsetzt (ADS1231) … gibt es einen grund keine bme280 fuer temp/hum zu benutzen? muessen ja nicht unbedingt die teuren originale sein, besser als die dht waren die bei mir bisher alle.
ich kenne die dht von den feinstaubsensorkits und die fallen fast alle nach 1-2 jahren aus (oft durch 100% messwerte feuchtigkeit gekennzeichnet) und/oder liefern massiv falsche daten. sind auch laut datenblatt (genauso wie die bme uebrigens) nicht fuer ‘outdoor’ gedacht (also fuer bereiche in welchen die luft auf 100% hum saturiert)

wenn ich dich grade falsch verstanden habe und der fehler quasi ‘am io pin’ bleibt, wuerde ich vorschlagen mal den pin zu wechseln den du benutzt.
ich kenne zwar das yun nicht persoenlich, aber viele devboards/mcu haben bestimmte pins mit fixen pullup oder pulldown bzw special modes, insbesondere im ‘bootmoment’ (wo dann z.b. ein pullup/down zumindest zeitweise angeht) und koennen so einen sensor schon verwirren (bzw die state-machine fuer das onewire)… d.h. einfach einen andren gpio probieren :)

gruss aus berlin

1 Like

Welchen DHT hat du verbaut? Einen nackten oder ist der schon auf einer Platine mit zusätzlichen Bauteilen (Widerstand und / oder Kondensator)?

Hast du den empfohlenen 10k Widerstand verbaut? Ein zusätzlicher Kondensator nahe am Sensor hilft ebenfalls!

Wie lange ist dem Kabel!?

Ggf. aktiviert die lib auch einen (zusätzlichen?!?) pull-up und das ist dann zu viel, siehe auch DHT22 10k Widerstand Einfluss auf Messgenauigkeit? - Mikrocontroller.net

Hatten den Yun auch schon mit einem DHT problemlos im Einsatz aber mit einer anderen DHT lib.

Der Pull Up ist lediglich um die Flanken bei der Datenkommunikation auf saubere HIGH und LOW Signale zu ziehen.

zum Kondensator wichtig wäre schon was für einen meinst Du ? einen Puffer.> ELKO 47uF von +3V3 auf GND … oder einen der die Störungen auf der Signalleitung filtert soll (CERAMIC)

danke der nachfrage, aber:

wenn ich die sensoren umstecke: der fehler bleibt am pin.

und: ich habe von pin 3 auf 15 (a1) gewechselt. selbes verhalten auch auf dem anderen pin.

also: hmmm.

es ist ein komplett auf dem breakout in einem plastikgehäuse verbaut wie bei exp-tech. es heißt:

There is a 5.1K resistor inside the sensor connecting VCC and DATA so you do not need any additional pullup resistors

die kabel sind bei beiden etwa ein meter lang.

der eine funktioniert, der andere nicht. egal wie ich sie stecke. immer funktioniert der, der im sketch als zweiter initialisiert und abgefragt wird, nach dem neustart/reset erst nach aus und wieder einstecken am pin.

wenns an der lib und zu vielen pull-ups läge, dann müsste es doch beide sensoren betreffen, oder?

daher vermute ich, dass es irgendwie am zusammenspiel im sketch liegt, das der zweite das nicht schafft, oder übersehe ich da weitere technische feinheiten in meiner grenzenlosen elektrotechnischen naivität?

1 µF zwischen Vcc und GND

fzz_%20-%20Fritzing%20-%20%5BLeiterplattenansicht%5D

1 Like

Versuche doch mal eine andere lib. Die verwende ich bei mir, auch mit mehreren DHT und auch schon auf dem Yun, und hatte damit noch keine Probleme:

Nimm die oben verlinkte DHTstable, im gleichen Verzeichnis gibt es noch die DHTlib, die nicht immer laufen muss.

Testsketch:
test_humidity_temperature.ino (2.8 KB)

rob tillaarts lib hab ich auch schon probiert. im yun bzw. im aktuellen sketch für den yun gibt die einen kompilierungserror.

interessant wären da detaillilertere fehlermeldungen als das was die arduino ide standardmäßig auswirft, wie komme ich an die ran?

mit dem huzzah hab ich erfolgreich damit rumgespielt, entlang deiner firmware.

mittelfristig experimentiere ich da gerne. hab mir den gestern auch schon mal zum ersten mal genauer angeguckt.

frage: hast du da eine konkrete einkaufsempfehlung, bei der ich möglichst nicht einem minderwertigen klon oder einem zu sparsamen boardaufbau zum opfer falle? (z.b. das angebot eines bestimmten verkäufers bei aliex, mit dem du gute erfahrung gemacht hast)

Hast du die stable verwendet?

zuerst nicht, dann ja.

Hast du noch eine andere Lib mit gleichen Dateinamen installiert? Wie ist denn die Fehlermeldung? Die du bisher verwendet hast hat eine dht.h und die von Rob ebenfalls, lösche mal die erste Lib komplett und versuche es nochmal. IDE dann neu starten schadet auch nicht

Vielleicht könnte ich helfen.

Ja, Stacktraces oder auch nur jegliche andere Fehlerdetails wären dafür hilfreich ;]. Vielleicht kannst Du irgendwo welche rausquetschen bzw. andere können helfen, wie das klappen könnte.

Bin mir relativ sicher, dass es die doppelte lib ist. #include <dht.h> bei Rob und ursprünglich #include "DHT.h". Wenn die alte lib nicht gelöscht wurde knallt es auf einem Windows-System, da nicht case sensitiv.

… aber Dir ist schon Bewusst, dass beide DHT22 ggf die gleiche Adresse haben?
Somit kann es eigentlich nur zu Problemen führen.
Das 1Wire an diesem Sensor ist kein 1Wire nach dem 1W Standard. Ansonsten

Hier zum Kondensator “Filterung” aus dem Datenblatt des Sensors:
“One capacitor valued 100nF can be added between VDD and GND for
wave filtering.”

Ansonsten würde ich einmal testen die Versorgungsspannung auf +5V zu nehmen… und auch dann entsprechend mit einem Filter C und einem Puffer Elko … zwischen Vcc und GND

Das ist eine proprietäre Schnittstelle mit einem proprietären Protokoll - und es gibt dort keinerlei Art von Adressen, jeder Sensor wird explizit durch eine eigene dedizierte Leitung angesprochen.

Dies ist auch oben in @mois’ code zu erkennen:

#define DHT1PIN 2
#define DHT2PIN 3

1 Like

Nein, der DHT hat eine Hardwareadresse
Ja es ist eine Propietäre BUS Verbindung.
Von den DHT22 soltte man eines haben Abstand … Dann lieber einen BME280 und wenn Temperatur reicht 1W Bus mit DS18B20 … die sind stabil Und bei 1W Bus kann man extreme Kabellängen erreichen … Stern Topologie mögen die nicht. Geht aber trotzdem wenn man ein wenig mit den Reflektionen auf dem Kabel testet…