DHT22 hängt immer nach Arduino Firmware Reset

Entwicklung / Development Fehleranalyse / Troubleshooting
27

heißt das jetzt irgendetwas außer dass ich besser in einen anderen sensortypen investiere in der zukunft?
anders gefragt: kann ich auf der basis deines hinweise noch etwas tun oder probieren an der konfiguration der beiden dht22?

31

Ihr Guten,

danke fürs gemeinsame Debugging. Wir fassen zusammen:

  • Kabellängen beachten (@weef, @wtf, @IngoP ).
  • G’scheiten Kondensator einbauen (@weef, @IngoP).
  • Port-Zustand beim Anfahren beachten (@roh) re.

    pullup oder pulldown bzw special modes, insbesondere im ‘bootmoment’

  • Gute Bibliotheken benutzen. Nicht auf DHT.h vs. dht.h on case-insensitive filesystems hereinfallen (@clemens).
  • Jeder nur ein Kreuz. Immer nur einen Sensor pro Port. Nobrainer. (@IngoP)
  • Orthogonal dazu: Gute Sensoren benutzen. BME280 statt DHT22.

Hab’ ich was vergessen? Für mich gibt es hier keine Prioritäten: Alle hier angesprochenen Punkte sollten sitzen [1]. Über die Geschmacksfrage beim abgesetzten letzten Punkt lässt sich streiten.

Thanks and Babutsch.

  1. Disclaimer: Not a hardware guy at all. ↩︎

2 Likes
32

Ist es denn nicht so, dass man mit dem BME280 sogar Ports spart, weil man sich – so wie bei meinem bEgg-Entwicklerboard kennengelernt – zwei BME280 am gleichen I2C-Port leisten kann, weil derjenige eine Einstellmöglichkeit auf zwei Adressen (0x76 vs. 0x78 oder so) zulässt?

@mois: Hilft Dir hier jetzt nicht weiter diese Frage, das ist mir klar – just asking the hardware guys here ;].

2 Likes
33

Gut, der vermeintliche Vorteil ist für mich eigentlich der größte Nachteil. Es sind nur 2 Adressen möglich (0x76&0x77), die dann teilweise auch noch von anderen Sensoren oder Displays usw. benutzt werden. Wenn man mehr als 2 benutzen möchte wird es kompliziert ein 2. I2C Bus ist auch nicht auf jedem Node verfügbar oder durch Systemressourcen belegt/eingeschränkt.

Also haben die DHT22 auch ihre Daseinsberechtigung.

34

Ja, mehr wären natürlich praktisch. Solche Überlegungen kommen mir bekannt vor.

Verstanden. Gibt es eigentlich auch noch weitere Alternativen in dem Bereich / der Liga?

39

Hier wollte ich noch einmal nachhaken. Durch die Beschäftigung mit den Luftdaten sind mir leider ganz andere Ergebnisse vor Augen gekommen, ich konnte vorhin nur nicht so schnell Luft holen.

image
image1000×500 78.3 KB

“Abgesoffene” DHTs, wie sie z.B. hier zu sehen sind, sprechen Bände. Solche Dinge sind nicht hinnehmbar.

Eine Liste von alternativen Bausteinen kam per Brieftaube:
SI7021, HTU21, HDC1080, SHT21, SHT31

Es gibt aber noch zahlreiche mehr, es geht schließlich um die Temperatur, die will jeder wissen.

Warum sie - bzw. welcher derjenigen - im Arduino-Umfeld bereits populärer ist (Treiberunterstützung!) oder populärer werden sollte (Preis-/Leistung!) können vielleicht andere herausfinden oder empfehlen.

Thanks for listening.

@MKO: Nix für ungut. Es geht uns alle an, weil scheinbar immer wieder auf den DHT zurückgegriffen wird, weil… Wir wollten v.a. mit den Beweisfotos noch einmal kollektiv deutlicher machen, dass das wirklich Schrottware ist und von unser aller Tische dringend verschwinden sollte. luftdaten.info hat hier schon Lehrgeld zahlen müssen. Gerade weil wir dort ein klein wenig unsere Nasen drin haben, wissen wir, wie hoch, breit, tief und schlimm (4 Dimensionen!) dieses Thema ist, gerade wenn man massenweise solche Bilder wie oben vor Augen bekommt. Disclaimer: Keiner von uns arbeitet für Bosch.

42

ich probiere also mit dem fehler lesenden sensor die freien pins durch:

frei sind noch:

gpio ergebnis
0    kompletter lesefehler: NAN (temp&hum)
1    kompletter lesefehler: NAN (temp&hum)
12   verification error beim sketch-upload
15   8.01°C falscher konstantwert
16   8.01°C falscher konstantwert 
17   keine messungen, konsole bricht ab: closed by foreign host
d18  keine messungen, konsole bricht ab: closed by foreign host
d19  keine messungen, konsole bricht ab: closed by foreign host

also auch hier kein erfolg.

jetzt könnte ich noch eine extra schaltung/sketch aufbauen mit nur den beiden dht22. und gucken ob es dann klappt, um wechselwirkungen mit dem rest der sensoren auszuschließen und den sketch so einfach wie möglich halten zu können.

aber da hab ich angesichts der tatsache, dass die dhts eher ein auslaufmodell darstellen, eigentlich gar keine so große lust mehr. lieber investiere ich da die zeit in experimente mit zwei besseren sensoren.

ein kriterium bei der empfehlung eines sensortyps könnte auch sein: was lässt sich “bienensicher” verbauen im stock, wo die kleinen propoliskleisterer ständig werkeln. oder ist da der königsweg schon gefunden mit den königinnen-käfigen, wie das @clemens empfiehlt? kleistern die die gitter dieses objekts mittel- bis langfristig nicht auch zu??

43

Ja, aber den kannste besser sauber machen als den Sensor selbst.

46

Vielen Dank für die vielen Vorschläge und Diskussionsansätze. Hab wieder viel gelernt!
Hab mich jetzt aber doch wieder für die saarländische Lösung entschieden:

Relais eingebaut, so dass es die Leitung vom zickenden DHT22 zum Datenpin schalten kann. Derzeit muss ich es nach dem Arduino-Reset noch manuell schalten (aber das ist ja immerhin aus der Ferne möglich, ich brauche also keinen physischen Zugang mehr zur Box).

Jetzt muss ich noch die korrekte Stelle im Sketch finden, um das Relais zum richtigen Zeitpunkt nach dem Hochfahren einmal automatisch Hin und Her schalten zu lassen , am besten nur nach Prüfung, ob der Sensor tatsächlich falsch liest.

Es wird immer schräger: Diese Prüfung ergibt nämlich: Die Variable enthält den richtigen Wert, er wird auf die Konsole ausgespielt. Falsch wird er irgendwo da, wo die Funktion void add_line() auf die Variable zugreift und den Daten-Upload-Link zusammenstellt. Mit anderen Worten: Der selbe (der selbe, nicht nur der gleiche) Sketchdurchlauf schreibt mir t2=20.05°C auf die Konsole und t2=8.01°C in den Telemetriestring. Ursachensuche lasse ich mal, dafür reichts einfach nicht, aber ich will ja auch nur einfach mein Relais steuern.

Ich brauche also eine Steuerung für mein Relais, die ohne Prüfung des Variablenwerts auskommt, z.B. so eine schleife zu beginn des loop:

int counter = 0;
...
if (counter < 2) {                     # während der ersten beiden sketchdurchläufe
   if (counter == 0) {                 # erfüllt im ersten sketchdurchlauf
      digitalWrite(RelayPin, HIGH);    # schalte das relais auf strom aus
      counter = counter + 1;
      delay(2000);
      }
   else {                              # erfüllt im zweiten sketchdurchlauf
      digitalWrite(RelayPin, LOW);     # schalte das relais auf strom wieder ein
      counter = counter + 1;           # schaltet die schleife für alle folgenden durchläufe ab
      }
   }

das sollte so doch gehen, oder?
(geht bestimmt auch eleganter und in einer zeile. bin für verschlankungsvorschläge offen.)

und dann nur noch an dem delay rumexperimentieren, bis es reicht. wenn ich es manuell mache, reichen raus-einundzwanzigzweiundzwanzig-wieder rein - also: zwei sekunden immer.

und: ja, ich habe sowas wie

      digitalWrite(RelayPin, HIGH);
      delay(10000);
      digitalWrite(RelayPin, LOW);

im setup() probiert. das relais schaltet zwar - aber ohne den gewünschten effekt.

47

an welchen PINs hast Du den DHT denn angeklemmt. Von welchem Arduino reden wir?

Es gibt PINs die beim Booten des µC blöde Effekte haben … gleiches gilt für die ESPs

Und ja, einfach den DHT weglassen und wie schon vorgeschlagen den Boschsensor nutzen.

48

dragino yun shield 2.4 auf arduino uno.

die pins hab ich schon weiter oben durchprobiert.

ja, genau. das mach ich dann in einem anderen thread.

gruß
m

49

Vielleicht lässt sich ja an dieser Schraube noch etwas drehen?

50

Kannst Du mal genau spezifizieren welche PINS Du genommen hast?
Entweder die PIN Nummer oder aber die µC Bezeichnung

PIN 18 = PD0 = SCL
PIN 19 = PD1 = SDA

was für einen Sketch hast Du auf dem YUN drauf?

51

Hier findest Du einige Pointer zu @mois’ setup mit source code.

1 Like
52

OK.

106 #include <SPI.h> 
107 #include <digitalWriteFast.h> 
108 
109 #include <OneWire.h> 
110 #include <DallasTemperature.h> 
111 #define ONE_WIRE_BUS 4 
112 OneWire OneWire(ONE_WIRE_BUS); 
113 // Pass our OneWire reference to Dallas Temperature. 
114 DallasTemperature sensors(&OneWire);

Also wir haben hier einmal einen proprietären oneWire vom DHT22 und dann den auf Standard basierenden DS18B20.

ist der BOOT Fehler mit angeschlossenem DS18B20 oder ohne?

Im Sketch ist der PIN4 für den 1WBUS definiert. Den hast Du dann jeweils für den DHT22 angepaßt beim Wechsel und neu geflashed?

53

mit.

pin4: 1wbus für ds18b20
pin3: fehlerlesender dht22
pin2: korrekt arbeitender dht22
(vgl. zeile 84f im sketch)

am pin4 mache ich nichts. am pin 3 unterbreche ich bei falschen werten kurz die verbindung (entweder händisch oder jetzt per relais) und dann klappt alles.
am pin 2 mache ich ebenfalls nichts.

54

Also elektrisch sieht das erst mal gut aus.
Vielleicht ein Timing Problem. Kannst Du in dem Sketch einmal zwischen den beiden Sensoren Wartezyklen setzen?
Ich weis auch nicht, wie lange der DHT bei der Initialisierung braucht …

55

du meinst bei der initialisierung?
hab ich gemacht. hat nichts geändert.

56

  1. Drüben bei den Programmierarbeiten am FiPy/ESP32 mussten wir einen Pin/Port auch im Deep-Sleep als PULLUP konfigurieren, damit alles gut mit dem Einschlafen des HX711 klappt [1]. Ich kenne hier sowohl die Specs des auf dem Yun eingebettenen AVR als auch den Quelltext zu wenig im Detail, als dass ich genau beurteilen könnte, ob das nicht kompletter nonsense ist.

  2. In manchen Treiberbibliotheken für Sensoren wird eine entsprechende reset()-Funktionalität implementiert [2], die von Ferne betrachtet auch bei solchen Beobachtungen Sinn machen würde wie sie hier geschildert werden. Auch hier kenne ich leider das Datenblatt der DHTs nicht im Detail, um beurteilen zu können, ob das nicht ebenfalls kompletter nonsense ist – also ob die Sensoren eine solche Reset-Funktionalität überhaupt vorsehen bzw. ob entsprechende Funktionalitäten u.U. auch auf Bus-Ebene implementierbar sein könnten (Bus-Reset).

  1. ↩︎

  2. https://github.com/pycom/pycom-libraries/blob/master/examples/DS18X20/onewire.py#L28-L46 ↩︎

57

Der gute Rob Tillaart versorgt die Arduino-Gemeinde unermüdlich mit Bibliotheken für die DHTs, @clemens und andere beforschen und planen hier downstream schon seit längerem den richtigen Weg.

Er schreibt bei DHT22 with ESP8266 seeing eventual timeout errors – #102: