Loosing WiFi connection after X minutes #15
Comments
|
Hey Andreas, For me I commented two lines in app.cpp Since then I have an uptime of more than 2 hours . I will commit this change if it does not interrupt any more in the next hours. |
|
Hey lumapu, I've just flashed my NodeMCU with your potential fix. Thanks for your support and all your efforts with this project! |
|
I took the rest of the day testing .. the ESP chrashed no more. Wait for more responses before closing this issue |
|
@lumapu, yes this is correct the WiFi is running on the same core in the ESP8266. The ESP32 has two cores, hence the WiFi stack is running on one CPU core while most of the user program runs on the other. You have this concept also on the nRF52832/52840 where the BLE stack runs on one core and the user program on the other. Hence you have to feed the watchdog every now and then. You can purposefully feed it using the yield() call method. Though I think you already committed that somewhere. I have also seen that you implemented three tickers , which should be useful to order things in main/app that occur after specific periods, e.g. every 10 seconds or every 5 minutes. I tend to use old school C: as a kind of pseudo scheduler to prevent running some code more often than necessary. |
|
@stefan123t, thank you for your comment - very interesting topic. For the uptime I think the ticker is more precisely because of a fired interrupt (I don't know it exactly but this is my idea how it works) |
|
@lumapu naturally the sky is the limit. Here we have to take the runtime of our individual co-routines into account. hence if they take more than several seconds to complete their tasks that will be the lower limit "sometimes". While if these long running sub routines are not scheduled at the moment, then the loop can complete quite fast, i.e. several times per second. The timers are based on milliseconds as a default so this is the numeric minimum =^D. Regarding the interrupts I am not sure how well they behave as we also have a hardware interrupt for reading the nRF24L01+ and the WiFi is also kicking in via an interrupt. As mentioned this is probably more of an issue on ESP8266 which is why ESP32 having two cores is usually considered more stable. You may also add Debug Level HTTP_SERVER or similar CORE+...+MDNS and use Debug Port Serial to enable the information from the ESP8266WebServer module. I have seen some request being queued on the network / router which seem to be worked by the WebServer after it comes up. Should we also reconsider when to enable and load the individual "webpages" in the WebServer ? Currently it starts the WebServer even before the WiFi connection is up and running. |
|
Early knowledge gained from issues on the esp8266 project by igrr (Ivan Grokhotkov) and others making the same mistakes before us. I have just re-read that and it looks like we have to call yield() or delay() every now and then to feed the watch dog to prevent it from starvation. ❤️ & 🥩 for 🐕 esp8266/Arduino#34 Oh BTW I have been diving deep into the rabbit hole some months ago with a thread called Embed with Elliot on Hackaday. Not sure I understood everything but I assume he got us covered with interrupts the good, the bad and the ugly: https://hackaday.com/2015/09/18/embed-with-elliot-interrupts-the-good/ OT-Bonus: |
|
I just published a version which uses the 'old-school-c' timer as you described before. Testing it over the day had the same result as the ticker variant - we will see if the uptime can grow to more than a day with that implementation. |
|
Mist noch während ich den Kommentar im Forum abgesetzt habe, hat sich der ESP wohl unbemerkt von mir verabschiedet. Version war 0.2.11: Serial Output - Click to expand!The ESP Exception Decoded - Click to expand! |
|
Version 0.3.3 läuft bei mir seit 23:05h ohne Absturz, das Upgrade lohnt sich bestimmt. Die Uhr geht auch nur ein dreiviertel Minute nach - das passt von der Genauigkeit, man kann ja alle 24h einen NTP Update einbauen. |
|
Ich habe auch erfolgreich die 0.3.3 über Nacht laufen lassen und jetzt eine Uptime von über 24h. Aus meiner Sicht ist es damit stabil. Das NTP Update einmal am Tag wäre natürlich noch eine feine Sache. |
|
Ich habe ebenfalls die 0.3.3 auf einem Wemos D1 mini der momentan direkt neben dem AccessPoint liegt und bekomme nur sehr selten Verbindung. Ich habe das Gefühl die WIFI-Verbindung war in den Versionen vor 0.3 schon mal deutlich stabiler. |
|
Den MQTT Fehler sehe ich bei mir auch, das zwickt sich mit der Systemstabilität da es mit dem delay auf MQTT Seite besser funktioniert hat. Interessant ist hier dieser Issue von der MQTT Lib: |
|
Ich habe ihn auch mutmaßlich längere Zeit am Laufen. Nur hat er wegen Empfangsproblemen die Verbindung zum WLAN eingestellt, so daß ich nicht weiß ob er durchgelaufen ist oder einen Reset hatte ... Im Serial Monitor sehe ich nur die Nachrichten alle paar Sekunden. |
|
Der ESP startet auch zwei unterschiedliche WebServer Konfigurationen je nachdem ob er im Setup Modus einen AccessPoint aufmacht oder im WLAN Modus auch das Dashboard und die Statistiken, etc. als URLs anbietet. Evtl. kann man in Zukunft die beiden Oberflächen vereinheitlichen und den Reconnect mit dem WLAN alle X Minuten einstellen oder per Serial Command forcieren? |
|
Gestern habe ich schon mit Version 0.3.5 eine Implementierung veröffentlicht, die immer wieder versucht mit dem WLAN zu verbinden und in der Zwischenzeit für 3 Minuten den Access Point öffnet. |
|
|
|
Hallo Lukas, ich habe die 0.3.6 gestern morgen kompiliert und deployed. Er startet jetzt mit dem AP obwohl er offenbar auch eine WLAN Verbindung bekommt. Also er scanned die Netzwerke und findet auch den WLAN Access Point des Routers, vermutlich klappt es nicht beim ersten Versuch, denn er macht dann gleich den eigenen AP auf und startet den 3x60=180 Sekunden Countdown. Danach passiert meist das Selbe, d.h. es dauert mehrere 180 Sekunden Intervalle bevor es mal beim ersten Versuch gelingt eine Verbindung mit dem Router aufzubauen. Ich hätte erwartet, daß er 30 Sekunden lang versucht eine Routerverbindung aufzubauen und erst dann für 180 Sekunden einen lokalen AP aufmacht und offenhält. Interessant fand ich die Ggf. alle 15 Minuten dann nochmal die Verbindung mit dem Router für 30 Sekunden versuchen, damit wir auch Daten hochladen können ... |
Hi Lukas,
I do not know if it really is matching our WDT resets as in both my StackTrace (click it to open) above and the one supplied for 0.2.9 by @dad401 there is this umm_init on the top of the stack which is for memory handling. But given we removed the delay(500); from our loop the bad practice (that thijsdebont mentioned too) should be gone. |
|
Hallo stefan123t, das mit dem join und leave klingt sehr gut, werde ich mir anschauen. Macht durchaus Sinn, den AP aktiv zu lassen wenn ein Client angemeldet ist. Aufrufe - aber dann nur auf der Setup-Seite, denn dafür war der AP Modus ja mal gedacht. Was ich auch noch gerne hätte, wäre eine Liste der in der Nähe verfügbaren WLANs. |
|
My uptime was nearly 46h but then I got an interrupt. I don't know the issue because of lacking uart logging. The good point is the the ESP automatically reconnected and has a new uptime of more than 9h. (Version 0.3.6) |
|
Wegen der Liste der WLANs in der Umgebung (auch praktisch zur Vorbelegung der Auswahl auf der Setup Seite !) kannst Du Dir gerne mal die wifi.h aus dem tools/NRF24_SendRcv ansehen. Könnten wir die UART Ausgabe auch irgendwie per remote logging (WLAN) ausgeben/schicken ? Vielleicht kann man das ja per WebSerial oder WebSocket verwirklichen. |
|
Die Stabilität hat sich mit der 0.3.8 bei mir verbessert, trotzdem muss ich den ESP mehrmals am Tag stromlos machen und neu starten, da er irgendwo "hängenbleibt". |
|
Bei mir - versorgt von einem USB Netzteil - bootet er einfach neu und ist erreichbar wie zuvor. An den 3.3V habe ich einen Elko und habe das RF24 Modul auf |
|
Habe gerade die 0.4.3 bei mir installiert und bekomme folgendes Logfile. Dabei fällt auf:
Serial Monitor Log - Click to expand! |
|
@lumapu sollen wir analog zu |
|
Hallo Lukas, während ich das Problem mit den WiFi connections näher analysiert und oben beschrieben habe, hat sich der nächste Kannst Du mal meine SDK Angaben vergleichen ? SDK:2.2.2-dev(38a443e) |
|
The boot messages and modes are explained in the board overview: Found this old issue / thread about wdt reset and wrong Pin number assignments should be using e.g. D4, etc. instead of 2 and using some capacitors on external pins
|
|
Join und Leave messages werden jetzt (positiv getestet in 0.4.13) berücksichtigt. Dies führt dazu, daß man mit dem AP verbunden der Timer alle 10 Sekunden wieder auf den ursprünglichen Wert 3*60 bzw. 180 Sekunden zurückgesetzt wird. M.E. genügt hier ggf. auch ein Default von 60 Sekunden, wenn man sich vom AP abmeldet muß man sonst 3 Minuten warten, bis er sich wieder mit dem Router verbindet, aber das kann ich ja in der config.h setzen. |
|
Ich habe aktuell die starke Vermutung dass der MQTT PubSubClient nicht im non-blocking Modus arbeitet. Den anderen Punkt mit den Interrupt Handler Routinen, wie in #53 mit dem Hinweis auf Ach ja einen Patch / PR #63 für die index.html Seite, damit diese auch das Habe auch noch einige Debug Meldungen eingebaut um der Ursache für die Abbrüche irgendwie auf die Schliche zu kommen: |
|
OK ich schaue mir den PR an.
Ich glaube wir brauchen keine Abbruchbedingung, da wir einfach alles zu
spammen bis der nächste vollständige Request kommt. Evtl klappt es ja bis
dahin doch noch eine Payload zusammen zu bekommen, gerade wie bei mir wo
sehr viel verloren geht.
Ich habe schon Mal bzgl. Ping des MQTT Brokers geschaut, das geht aber nur
mit zusätzlichen Libs, ich denke nicht, das MQTT die Fehlerquelle unserer
Abstürze ist, es gibt zum einen hier einige ohne aktives MQTT und ich
verwende es privat zuverlässig in anderen Projekten.
|
|
HI @lumapu,
Ich versuche es morgen im Laufe des Tages nochmal mit einem längeren Test. |
|
Mein ESP8266 lief jetzt mit der 0.4.15 seit 14:38 Stunden ohne WDT Reset, das ist doch schon mal was! Andererseits sehe ich wie gesagt einige der Antwort-Pakete bis zu 4 Mal (siehe oben) Von den HackRF Aufnahmen meine ich keine Mehrfach Pakete vom Wechselrichter gesehen zu haben. |
|
In #53 diskutieren wir im Prinzip das gleiche Thema, ich denke es liegt an dem setRetries der NRF24 Lib. |
|
Hallo Lukas, ich dachte in #53 geht es um die fehlenden Pakete (mW bei HM-1000/1200/1500 fünf statt vier Pakete für den HM-600/700/800).
Hier in #15 und #52 geht es um was anderes nämlich dass die WiFi Verbindung teilweise nicht mehr verfügbar und der ESP nicht mehr erreichbar ist. Das liegt mE daran dass er aus der Schleife die die drei/vier/fünf Pakete für eine Payload zusammenbekommen soll nicht mehr rauskommt.
Das Problem mit den Paketen gehört dann evtl doch in das andere Issue #53 (?) aber jetzt habe ich die Logs hier schon oberhalb eingestellt. Das erklärt zumindest warum ich manche Pakete mehrfach sehe:
void setRetries (uint8_t delay, uint8_t count) Es sind also immer 15 Versuche, von denen bei mir mindestens 1-4 Requests aktuell vom WR empfangen und auch beantwortet werden bzw. deren Antwort ich auch empfange. Wenn man wie bei mir zuviele Antworten bekommt, kann man den retry_count evtl. ja wieder sukzessive -1 bis auf min. 1 erniedrigen. |
|
Ich denke wir sollten es so lassen wie es ist. Ich habe während der Entwicklung der gesamten Payload gesehen, dass es sehr stark schwankt. Manche frames kommen 1x und andere 4x. Komisch ist, dass man tatsächlich maximal 4 sieht, das sollten wir noch erklären können. Meine erste Vermutung ist, das das Intervall zwischen den Retries zu kurz ist und der WR gar nicht so schnell antworten kann. |
|
Hallo Lukas (@lumapu) Aber wie sieht es mit dem 1. Punkt aus ?
|
|
Ach ja, wie Jan-Jonas bereits angemerkt hat sind 3 Retransmits eines Paketes 3 TX Versuche mit je 15 Retries, also 3x16=48 Pakete on-air. Die Zeiten können wir evtl. berechnen bzw. auf den HackRF Screenshots im Forum ablesen. Dort sind auch 15 Retries zu erkennen, daher ist das vermutlich in Ordnung und wir können doppelte Antwortpakete einfach silently ignorieren. |
|
AHoy-ESP V0.4.19 Ich aktualisiere die Werte von meinen 2 Wechselrichtern nur alle 30 Sekunden. Alle anderen Eckdaten sind eigentlich nicht förderlich. |
|
+1 für einen täglichen NTP Refresh Job. |
|
habe immer noch mehrere Reboots am Tag, daher hat mich die fehlerhafte Zeit noch nie gestört. |
|
@lumapu Ja timeout zum NTP time refreshen finde ich gut. |
|
nein, ich glaube dass ist eine kleine Sache, dann schließen wir diesen alten Issue - wir haben noch genug andere issues, die sich um die Stabilität kümmern |
|
@lumapu, hier ist halt die meiste Dokumentation zum Thema WDT resets und vor allem auch zu den evtl. geplanten State Machine vorhanden, oder haben wir das anderweitig (z.B. #78) hinreichend beschrieben ? |
|
Lukas wie machen wir das in Zukunft wenn auch noch Device Control Commands (Active Power Limit) und weitere Device Info Commands (AlarmData und AlarmUpdate) dazukommen. Wir müssen uns etwas zum Schedulen überlegen. Sollten wir da so wie Thomas B arbeiten mit den EVERY_* Timer Makros ? |
|
@andreas5232 bitte mit der v0.5.9 überprüfen und ggf. als gelöst schließen. Danke |
|
Sorry, dass ich hier zwischenzeitlich ausgestiegen bin und auf das letzte Mention nicht reagiert habe. |
Shelly Topic MQTT checker - powermeter.h
Most important: You guys rock! :-)
I'm trying to run ahoy on a NodeMCU board with NRF attached.
Everything is working fine at first. Data is read from HM-600 and displayed correctly on the web interface. But after roundabout 10 minutes the system seems to loose its wifi connection. The web interface is no longer available and the device can't be pinged. The LED on the board keeps blinking in the same interval as before the break down. After a reboot/reset of the board everything is fine again for a few minutes.
I'm not sure if I'll be able to debug this on my own and if it does affect other setups too, so I opened this issue.
Keep up the great work!
Cheers
Andreas
The text was updated successfully, but these errors were encountered: