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.
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?
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.
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.
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??
Ja, aber den kannste besser sauber machen als den Sensor selbst.
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.
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.
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
Vielleicht lässt sich ja an dieser Schraube noch etwas drehen?
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?
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?
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.
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 …
du meinst bei der initialisierung?
hab ich gemacht. hat nichts geändert.
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.
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).
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:
Unabhängig davon will ich hier nochmals die Bibliotheken aus der Feder von Rob Tillaart (hoffentlich!) chronologisch sinnvoll auflisten und die Unterschiede auf Basis der README-Inhalte beschreiben.
However, also might be worth a look.
– Arduino/libraries/DHT12 at master · RobTillaart/Arduino · GitHub
This library is an experimental version of the DHT library that uses 2 pins instead of 1. One pin for all read actions and one pin for write actions.
– Arduino/libraries/DHT2pin at master · RobTillaart/Arduino · GitHub
Halleluja.
I wanted to emphasize this in the spirit of Use realtime systems for reading digital sensors and Protect code when accessing shared resources.
meinst du “Heureka” und empfiehlst mir diese bibliothek auszuprobieren?