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?
bei mir laufen die mit 5V.
(ich leide so darunter, dass ich das fritzing meiner schaltung noch nicht hingekriegt habe. zwei anläufe sind daran gescheitert, dass ich die ganzen verwendeten bauteile nicht als fritzing-bilder gefunden habe. aber eine fritzing-tutorial wäre wohl ein eigenes thema wert…)
Bayerische Lösung: Humor.
Das tut mir echt leid – nervt ja auch voll. Demgegenüber ist der Humor natürlich nicht spöttisch gemeint, nur mal so zwischendrin zur Auflockerung.
Die sieht mir nach “result of many years of intensive research” aus. Ich würde sie definitiv ausprobieren, solange man noch nicht von den DHTs wegkommt.
und was soll ich mit dem Halleluja anfangen?
Soll es witzig sein? “zur Auflockerung” dann versteh ich Deinen Humor nicht.
Ja: Endlich hat sich auch bei dieser Bibliothek der Autor der bisher im Arduino-Umfeld oft vergessenen Interruptbehandlung gewidmet à la “da war ja noch was”. Dafür gibt es zu jeder Zeit ein großes Hosianna-artiges Halleluja.
Bevor das bibliotheksseitig nicht ordentlich gelöst ist, braucht man sich über sporadisch auftretende Glitches aufgrund von Timing-Problemen nicht wundern, gerade wenn man nicht mehr selbst exklusiv auf dem Eisen läuft – also die Firmware [1]. Siehe auch Use realtime systems for reading digital sensors und Protect code when accessing shared resources.
Das wiederum ist seit der Ankunft der immer populärer werdenden günstigen 32-Bit MCUs immanent, wo meist noch ein (Echtzeit-)OS drauf läuft und darauf erst die gewohnte Arduino-Umgebung. Sobald also irgendwo ein ESP32 (Dual Core!) aber auch schon ein ESP8266 unter der Haube ist oder man auch klassisch auf dem AVR schon Dinge wie LMIC an Bord holt, ist das Laufzeitverhalten ein grundlegend anderes als von früher gewohnt.
Das fällt aktuell oft erst dann auf, sobald man ausgewachsenere Dinge auf andere Hardware portiert, während es bei einfachen Beispielsketches oft gerade noch so funktioniert. Ich bin heilfroh, dass das nun immer öfters schon upstream von den Hauptautoren erledigt wird, weil sonst die Gefahr hoch ist, dass das Ökosystem fragmentiert, wenn die notwendigen Patches wild zwischen Brennesseln wachsen und nicht wieder zurückgeführt werden. Bei Spring cleaning with multiarch support for the HX711 hatten wir richtig viel Freude – diesmal ironisch ;]. ↩︎
Das mit dem Relais war mein Ernst. Fotobeweis:
Ist aber schon auch ein bisschen lustig. Geb ich zu.
Im Lösungsbeitrag diskutiere ich die Automatisierung der Relais-Steuerung.
Makes my day. Turtles all the way…
Du hast jetzt aber nicht deine Lösung auf diesem Testboard oder ?
Das war nur ein kurzfristiger Testaufbau ?
Die Dinger können einen nämlich in den Wahnsinn treiben … habe ich mal bei nem Portexpander gehabt …
Ich denke Modus ist sich dem durchaus bewusst.
Also eher ein provisorischer Testaufbau, im Langzeitbetrieb.
Wenn du möchtest @mois, kann ich mich mal an deiner Schaltung versuchen und sie gleich ätzen und verzinnen (oldshool).
Müsstest mir nur eine Skizze vom Schaltplan und die verwendeten Bauformen irgendwie zukommen lassen. Würde das dann allerdings mit Eagle und nicht mit fritzing machen.
Ätzt Du die Leiterplatten komplett selbst ? Belichtung etc.?
Was hast Du für eine Ausrüstung?
Ich bin da noch auf den Lochstreifen … da habe ich aber keine Lust mehr drauf…
Vor 2 Jahren habe ich am RaspberryPi auch mit bis zu 10 DHT22 = AM1302 experimentiert und versucht, sie abzugleichen mit verschiedenen Salzlösungen.
Fazit: selten zeigen sie gleiche oder sehr ähnliche Werte an. Ausserdem können sie ganz einfach kaputt gehen und ergeben seltsame Ergebnisse.
Seit Okt. 2018 nutze ich den BME280 an verschiedenen ESP32 und FiPy mit Arduino-IDE und Micropython.
Fazit: Immer saubere Messwerte.
Empfehlung: von DHT22 auf BME280 wechseln
Nicht ganz, Belichtungsgerät usw. hätte ich zwar da. Benutze für kleine Einzelanfertigungen aber meist die Toner Transfer Methode, da ich noch einige Platten habe, wo der Fotolack zu alt ist.
Da mir der ganze Aufwand mit dem Lötstoplack oder Folie zu groß ist, verzinne ich sie anschließend mit Fittinglötpaste. Ist auch damit sie sich anschließend besser löten lassen. Galvanisch geht auch, wird aber nicht ganz so schön und ist wieder viel Chemie.
Geht super. Eine Platine ist nach dem Druck in ca. 20-30 Min fertig geätzt und verzinnt.
Allerdings mache ich hauptsächlich nur Einseitige Platinen, da die Durchkontaktierungen wieder ein Fall für viel Aufwand und Chemie sind.
Also im Layout ein bisschen mehr Hirnschmalz reinstecken.
Benötigt wird eigentlich nicht viel:
Zum Ätzen:
zum Verzinnen (muß nicht gemacht werden, empfehle ich aber):
Wer dann noch Langeweile hat kann dann ebenfalls mit der Transfermethode noch auf der Oberseite die Beschriftung aufbringen.
Will zum Wochenende eh noch eine Develop BoB Platine machen. falls Interesse besteht kann ich ja mal meinen Fotoapparat daneben legen.
