Hallo zusammen,
vielen Dank erst einmal für eure tolle Unterstützung!
Zitat von
Moppi
Und wie ist das Ergebnis damit?
Leider konnte ich mit WiFi.forceSleepWake(); keinen Unterschied feststellen.
Hier ein kurzer Auszug wie ich es eingebaut habe:
Code:
void setup() {
Serial.begin(115200);
delay(1000);
Serial.println("\n\nSerial connection started");
WiFi.forceSleepWake();
WiFi.mode (WIFI_STA);
//WiFi.config (IPlocal, IPdns, IPgateway, IPsubnetmask);
WiFi.begin(ssid, passphrase);
while (WiFi.status() != WL_CONNECTED)
{
delay(500);
Serial.print(".");
Serial.print(WiFi.status());
}
WiFi.printDiag(Serial);
Serial.print(WiFi.status());
pinMode(12, OUTPUT);
Serial.printf("Now listening at IP %s, UDP port %d\n\n", WiFi.localIP().toString().c_str(), receiveUdpPort);
delay(5000);
}
Zitat von
Moppi
Die serielle Kommunikation (Serial...) bitte mal raus nehmen, die brauchst Du später sowieso nicht. Beschränke mal auf das, was das nodeMCU später tun soll. Nämlich Datenerfassung und per WiFI und UDP verschicken.
Werde ich machen.
Zitat von
Moppi
Und zum Schluss vorerst eine andere Vorgehensweise:
Wenn das nodeMCU startet, sende mal bitte ein Paket an das nodeMCU selber (und nur dieses) und warte bis das angekommen ist. Eigentlich müsste das nodeMCU die Pakete, die per Broadcast gesendet werden, auch wieder empfangen können. Daher würde ich ein Paket mit dem nodeMCU verschicken und prüfen, ob das beim nodeMCU auch an kommt. Wenn nicht, würde ich das Paket nochmal senden und warten ob es dann ankommt. Die Alternative ist eben, das erste "Verfikations"-Paket nur an das nodeMCU zu schicken, dass es auch verschickt. Wenn das erfolgreich war, würde ich schauen, ob danach jedes weitere UDP-Paket im Netzwerk ankommt, das verschickt wird.
Das klingt gut! Ich werde die Pakete an 127.0.0.1 schicken, falls das funktioniert..
Zitat von
HaWe
Der DHT11 ist übrigens auch extrem zickig, er braucht oft bis zu 2sec, bis er nach mehrmaligem Versuch überhaupt Daten liefert, davor ist alles ungültig. Viel bessere Ergebnisse habe ich mit BME280 und BMP280 per i2c.
Das habe ich auch gelesen und habe deshalb ein delay von 3,5s eingebaut.
Zitat von
Moppi
Schön und optimal ist das sicher alles nicht.
Das sehe ich auch so, denn zu starten und mehr oder weniger nur ein UDP-Paket zu senden ist, denke ich, für ein mit WiFi ausgestatter Mikrokontroler keine überragende Leistung .. Komischer Weise scheint ja das Beispielscetch tadellos zu funktionieren. Also, wo ist der unterschied? In erster Linie sehe ich da nur das zuvor empfangene Paket und das Senden an die RemoteIp + RemotePort...
Zitat von
Moppi
Wobei es so sein soll, dass das nodeMCU beim Starten mehr Strom benötigen soll (oder so ähnlich), so dass die Spannungsquelle hier mitspielen muss, dass es nicht zu diffusen Fehlern kommt.
Das werde ich auch noch mal testen. Bisher hing der ESP immer am USB-Port des Laptops (soweit ich weiß ~500mA?! ) Ich werde mal ein 2A starkes Steckernetzteil nehmen.
Zitat von
HaWe
ich würde dazu raten, das Problem ganz neu im
ESP8266 Forum als issue zu melden - und vorher sicherheitshalber auch auf IDE 1.8.6, den neuesten esp core 2.4.2 und auch die neueste esp8266WiFi lib etc. abzudaten, denn es werden die issues nur bei den jeweils neuesten Versionen von den Entwicklern bearbeitet.
Es wird dort auch immer ein minimalistischer lauffähiger Test-Sketch verlangt, den würde ich in jedem Falle mit konstanten oder überprüfbaren randomisierten Werten OHNE DHT11 schreiben.
Ich werde in der Tat mal alles auf den neuesten Versionsstand bringen. Das Melden hebe ich mir noch auf...
Zitat von
Moppi
Diese Seite habe ich auch schon studiert 
Leider habe ich nicht durchgängig viel Zeit um an diesem Problem zu arbeiten, ich bemühe mich aber schnell Neuigkeiten zu berichten
Zitieren
Lesezeichen