Kann ich für den DHT22 nicht bestätigen. Ich erhalte immer eine zuverlässige Antwort, auch bei kürzerer Zeit.Zitat von HaWe
Kann ich für den DHT22 nicht bestätigen. Ich erhalte immer eine zuverlässige Antwort, auch bei kürzerer Zeit.Zitat von HaWe
muss nicht, nein, und der 22er ist auch besser als der 11er, aber es KANN passieren. Ich selber frage erst immer nach dem Pollen nach nan, und wenn ja, nochmal probieren, ansonsten weitermachen.
float ftmp = DHT11.readTemperature(); // Temperatur auslesen (Celsius)
delay(10);
if (isnan(ftmp)) {
// error, ggf auch in while() Schleife
}
else {
// ok, weitermachen
}
So, ich habe mich mal wieder mit dem Thema beschäftigen können.
Ein anderes Netzteil bringt keinen Unterschied
Was ich inzwischen herausgefunden habe:
Wenn deepSleep nur einen Durchlauf zulässt, scheint das Senden noch nicht sofort zu funktionieren. Wenn ich 20..30 Pakete vorher an einen anderen Port sende, dann kommt die Nachricht an. (Man könnte die Pakete auch an den gleichen Port senden.) Ich habe diese per For-Schleife geschickt bevor ich meine Nachricht geschickt habe. Ich werde jetzt mal probieren, das deepSleep in eine if-Abfrage zu stecken, damit die loop-Schleife ein paar Runden drehen kann bevor ich meine Nachricht sende. Mal sehen ob ich das morgen mal schaffe. Ich melde mich dazu.
Fakt ist, inzwischen bekomme ich es relativ zuverlässig hin, Pakete per UDP mit deepSleep zu senden. Die Lösung ist bisher allerdings noch etwas hässlich und daher werde ich das oben genannte die Tage mal probieren.
Gruss
Guten Morgen d2x,
prima, dass Du dran geblieben bist!
Stichwort eingesetzte Bibliotheken:
Mit einem ATmega328P habe ich auch Probleme mit den Sleep-Modi. Nicht dass es nicht funktioniert, nur mit der Stromaufnahme, die nicht "weit genug" sinkt. Hier ist es mir so ergangen, dass die "sleep.h" und die "power.h" verwendet werden - jedenfalls in den meisten Beispielen, die ich im Internet fand. Ich fand dann noch eine Anleitung, die diese Bibliotheken umgeht und auch in den Deep-Sleep-Power-Down wechselt und zwar mit deutlich mehr Stromersparnis.
MfG
Geändert von Moppi (23.11.2018 um 08:28 Uhr)
Update:
Die oben genannten Maßnahmen führen zwar dazu, dass zu 95% das Paket ankommt, hin und wieder reichen aber selbst 150 vorab gesendete Pakete nicht aus. Diese sind dann inklusive meinem Paket mit den Daten verloren.
Wenn Du den Sleep-Mode nutzt, geht das doch bei nodeMCU nur per Reset, weil was anderes nicht funktioniert - hatte ich so gelesen.
Probiere mal ohne den Sleep-Modus und mache mit einem Taster am nodeMCU einen längeren Reset. Ob das dann genau so ist oder dann immer funktioniert.
Dann wenn er im Sleep-Mode drin ist, auch mal mit einem Taster am nodeMCU einen langen Reset machen und schauen, wie sich das dann verhält.
Kann es sein, dass das nodeMCU nach einem Reset manchmal nicht richtig "anspringt"?
MfG
Das werde ich mal testen.
"Nicht richtig anspringt" kann grundlegend nicht der Fall sein, da ich über die serielle Schnittstelle jeden Schritt nachvollziehen kann und das ab dem ersten Loopdurchgang.
Lesezeichen