Lokaler Webserver antwortet kaum

[mrbgfromv]

Hallo!
Habe es mit der Installation der Software ziemlich weit geschafft, denke ich:
Der lokale AP wird gestartet, ich verbinde mich mit meinem WLAN, das Gerät startet neu.

Problem
Leider erhalte ich auf der IP-Adresse selten oder seeeehr langsam eine Antwort.
Nur Webseiten, die eine kurze Anwort vermuten lassen, sind erreichbar, also z.B. IP/reset

Lösungsversuche:
Hardware-Resets, Re-Flashes, EEPROM-wipe
Ich habe mir das Projekt herunter geladen und selbst kompiliert, um der Sache auf den Grund zu gehen:
Selbst wenn ich im Main-Loop alles bis auf den async Webserver auskommentiere, wird es nicht besser.
Der Serial Montior zeigt genau die Ausgaben, die im Setup vorgesehen sind. Der ESP8266 startet also korrekt.
Ich kann auch Debug-Nachrichten per Serial.println absetzen.
Sitze mit dem Modul neben dem Router. Tasmota läuft auf den Modulen wunderbar.

Grundsätzlich scheint es also zu funktionieren, nur halt nicht in allen Bereichen.
Ich vermute, dass es eventuell an der Hardware liegt - verwendet wird ein WEMOS D1 mini.
Von den Dingern habe ich allerdings einige und konnte deshalb wechseln - hat aber auch nichts gebracht.
Im Moment bin ich mit meinem Latein am Ende.

Wäre schön, wenn noch jemand einen Lösungsvorschlag hätte oder auch eine Liste funktionierender ESP8266 Module.

Dnke!

Frank

[DrGalvany]

Hallo, die NodeMCU v2 und v3 geht bei mir.
Die v2 ist zu bevorzugen, da es auf den "CP2102-Chipsatz" entwickelt wurde.
Bei mir dauerte der erste Aufruf auch immer etwas.
"IP/reset" und ein paar Minuten warten, haben bis jetzt immer das Problem nach dem Flashen gelöst.

Gruß

[mrbgfromv]

Die angesprochenen nodemcus hatte ich zwischenzeitlich schon bestellt :)
Wärhend der Wartezeit auf die Päckchen lasse ich den Webserver auf dem WEMOS mal länger laufen.
Bin gespannt!

[CupraBorn]

Der CP2102 Chipsatz hat doch eigentlich eher was mit dem USB Port zu tun dachte ich?

[mrbgfromv]

Deshalb habe ich auch nicht so große Hoffnungen, dass ein anderes Modul funktioniert - war aber eine der letzten Möglichkeiten.
Abwarten hat schon mal nicht geklappt.
Andererseits: Von den esp8266 Modulen selbst gibt es ja auch leicht unterschiedliche Varianten und die Speichergröße kann auch verschieden sein.
Gegen Ende der Woche weiß ich mehr.

[steff393]

Hi, hast du die Dateien unter /data mit auf den ESP geladen?
Also /json, /heap und /edit gehen eigentlich bei mir immer. Welche sind bei dir so langsam?
Seltsam ist, dass schon der Webserver alleine (also restlicher Code auskommentiert) nicht funktioniert. Allerdings hab ich mit dem D1 mini auch noch die gearbeitet. Bin mal gespannt, ob es mit den NodeMCUs anders wird.

[mrbgfromv]

Tataaaa!
Fehler behoben. Konnte mich noch dumpf an eigene Programmier-Probleme erinnern:
Im Main loop muss ganz am Ende ein delay(x); eingefügt werden. Die Größe für x ist ziemlich egal, es tut schon delay(1);
Ich habe mich auf delay(10); geeinigt, das spart dann vermutlich auch etwas Strom.
Jedenfalls reagiert jetzt alles zackig so, wie es sein soll.
Modubus-Konfiguration läuft noch nicht, aber das ist jetzt ein komplett anderes Thema.
Danke für das Projekt!

[CupraBorn]

Mit welchem Compiler hast du die bin erstellt?

[steff393]

Stimmt, das mit dem delay(x) hatte ich auch schon mal gelesen. Aber laut dem hier dürfte es eigentlich keine Rolle spielen, ob am Ende der loop() noch ein kurzes Delay ist oder nicht: https://esp8266-shop.com/esp8266-guide/interrupts-and-timers/
"WiFi and TCP/IP libraries get a chance to handle any pending events each time the loop() function completes, OR when delay() is called."

[mrbgfromv]

Ich habe mit VSCODE gearbeitert.

[mrbgfromv]

Heute kam überraschend schon das Nodemcu 3.4 Modul:
Exakt gleiches Verhalten: Mit sleep(10) geht es, ohne nicht.
Bleibt ja eigentlich nur noch meine build-Umgebung - begebe mich mal auf die Suche, ob man da irgendwo Libraries für den esp8266 aktualisieren kann.
--- Update
Konnte zwar die avr und esp8266 libraries aktualisieren, hat aber auch keinen Unterschied gemacht.

[DrGalvany]

Hallo, "steff393" kannst Du das "sleep(10)" bitte in Deinem nächsten Update miteinbinden.

Danke

[steff393]

Wenn ihr mir genauer erklären könnt, was es macht, dann sehr gerne. Aktuell verstehe ich es noch nicht:

• Am Ende jeder loop() bekommen WiFi & TCP/IP automatisch dran.
• Bei jedem Aufruf von mb_loop() wird zusätzlich auch yield() aufgerufen -> erneute Chance für den Kernel

Das delay(10) ist dann nur busy-waiting, was schlimmstenfalls dazu führt, dass die Modbus-Kommunikation oder eben auch Wifi nicht mehr rechtzeitig dran kommt.
Wenn ich's noch richtig im Kopf habe wird die loop() normal alle ca. 250us durchlaufen. Durch das delay(10) würde sich das um den Faktor 40 reduzieren.
Theorie und Praxis passt da grad irgendwie noch nicht zusammen ;-)
Daher halt ich das noch für etwas riskant/verfrüht.

[DrGalvany]

Hallo, ich kann es Dir leider nicht erklären, da ich mich mit diesem Thema nicht auskenne.
Evtl. kann es "mrbgfromv" erklären.
Ich weiß nur von früher (20Jahre oder so) da wenn ich in "Basic" einen "Loop" hatte und es war kein "sleep(x)" drinnen, war die CPU immer am Limit.

Micha

[mrbgfromv]

Erklären kann ich auch nichts...

Ich kann jedenfalls auch sehr gut verstehen, wenn man seinen Code nicht ändern will, weil jemand meint, es ginge so und so besser. Insbesondere dann, wenn sich niemand sonst mit dem Problem meldet und nicht klar ist, warum und weshalb oder welche negative Folgen die Änderungen haben könnte. Ich wäre da auch sehr vorsichtig.

Nur noch eine kurze Bemerkung: delay(1) reicht anscheinend auch.

Vielleicht wartet man ab und macht eventuell eine Bemerkung in der Anleitung/Wiki oder auf der Projektseite.

[steff393]

Mein Vorschlag wäre: Wir lassen den Issue mal offen, dann hab ich das Thema auf dem Schirm und kann das evtl. beim nächsten Release über einen Parameter steuerbar einbauen, damit es sich für andere (v.a. die mit mehreren Wallboxen) nicht auswirkt.
Vielleicht ergeben sich dann im Laufe der Zeit noch weitere Infos.

[Brekkis]

Hi Leute,
ich war bisher stiller Mitlesen, jetzt habe ich doch mal eine Frage.
Ich habe mir die Wallboxanbindung mit Wbec aufgebaut (NodeMCU und RS485 Platine) funktioniert soweit alles. Habe Verbindung zum Gateway und sehe auch die Werte (z.B. Spannungen). Bekomme die Daten auch über Mqtt in den Iobroker rein.
ein Punkt habe ich, der mir noch nicht klar ist.

Hier wird immer vom Webinterface gesprochen, wenn ich aber so wie im Wiki "xxx.xxx.xxx.xxx/web.html" eingebe, bekomme ich keine Webseite gezeigt, sondern nur "not found". Kann mir da jemand weiterhelfen?

Gruß Stefan

[steff393]

Hi @Brekkis
du kannst über die Seite IP/edit die Dateien, die im data-Ordner liegen hochladen, speziell die web.html und web.js
Das alte Webinterface (index.html und style.css) werd ich demnächst mal rauswerfen. Das war der erste Ansatz, würd ich aber nicht mehr empfehlen, das neue gefällt mir besser.

[Brekkis]

Hi,
danke für die flotte Antwort.
Habe jetzt die beiden Dateien (web.html und web.js) hochgeladen.
Danach einen reset über IP/reset
wenn ich jetzt IP/web.html oder IP/web.js aufrufe öffnen sich die Dateien als Text im Browser....
Sorry, stehe wohl auf dem Schlauch!

[Brekkis]

Ich habs gelöst. hatte was falsches in die web.html kopiert und gespeichert.
Jetzt funktioniert das Webinterface.

Danke für die Hilfe.

Gruß Stefan

[AMiketta]

Hi, hab das selbe Problem. Der Webserver antwortet kaum. Im verlinkten Artikel steht es doch "If you have a loop somewhere in your sketch that takes a lot of time (>50ms) without calling delay(), you might consider adding a call to delay function to keep the WiFi stack running smoothly"
Ich bin Softwareentwickler und kann auch nur vermuten das durch das delay der WiFi und TCP/IP library mehr zeit gegeben wird bis der nächste Loop durchlauf gestartet wird. Wenn es Wirkt würde ich es auf jeden fall einbauen, so selten bzw. langsam wie der Webserver im moment antwortet ist es schwer zu ertragen.

Ich habe eben mal die Edit.html getestet es hat 3,8 Minuten gedauert bis ein Response zurück gekommen ist. Dieser war allerdings dann unvollständig. Die meiste zeit wurde auf eine Antwort gewartet (waiting TTFB) der connect ging schnell und der Response hat nach 240ms abgebrochen

[steff393]

Der Punkt ist, die o.g. if-Bedingung ist nicht erfüllt: Es gibt keine Loop die mehr als 50ms braucht. Wir reden hier eher von Größenordnung 250µs für einen Loop-Durchlauf.
Für eingebundene Libraries kann ich das natürlich nicht sicher sagen. Aber selbst wenn, hätte ich ja keine Möglichkeit in diesen Libraries ein delay() oder yield() einzubauen, nur danach. Und ein Delay danach bewirkt nur eine unnötige Verzögerung.

Man muss sich das m.M.n. so vorstellen: Der ESP führt abwechselnd folgende Funktionen aus in einer Endlosschleife:
...
loop()
Kernelfunktionen (WiFi, Watchdog, etc.)
loop()
Kernelfunktionen (WiFi, Watchdog, etc.)
loop()
Kernelfunktionen (WiFi, Watchdog, etc.)
loop()
Kernelfunktionen (WiFi, Watchdog, etc.)
...

Ein delay(1) als letzter Befehl innerhalb der loop() bewirkt, dass

• die Kernelfunktionen aufgerufen werden und prüfen, ob sie was tun müssen
• der restliche Code für 1ms blockiert wird

Ohne das delay(1) hätten aber in dieser ungenutzten Zeit die Kernelfunktionen sogar 3-4 mal die Chance was abzuarbeiten.

Wenn ich mir einen Zeitraum von 100ms anschaue, dann sollten da jetzt die loop() und die Kernelfunktionen ca. 400 mal ausgeführt werden. Mit einem delay(1) nur noch 100mal. Und mit delay(10) nur noch 10mal.

Wie oben gesagt, eine Möglichkeit wäre, es künftig parametrierbar zu machen. Aber vielleicht gibt's auch jemand der's erklären kann.

[AMiketta]

Wie dem auch sei, ich habe jetzt bei mir am ende der loop ein delay(5); eingefügt und das Problem ist weg. Vorher konnte ich die Seite /update nicht aufrufen (10 Minuten Timout, oder Invalid Content lenght), jezt kann ich Sie 10 mal direkt hintereinander aufrufen ohne verzögerungen. Am Di., 15. Feb. 2022 um 22:36 Uhr schrieb steff393 < ***@***.***>:

Der Punkt ist, die o.g. if-Bedingung ist nicht erfüllt: Es gibt keine *Loop die mehr als 50ms* braucht. Wir reden hier eher von Größenordnung 250µs für einen Loop-Durchlauf. Für eingebundene Libraries kann ich das natürlich nicht sicher sagen. Aber selbst wenn, hätte ich ja keine Möglichkeit *in* diesen Libraries ein delay() oder yield() einzubauen, nur danach. Und ein Delay *danach* bewirkt nur eine unnötige Verzögerung. Man muss sich das m.M.n. so vorstellen: Der ESP führt abwechselnd folgende Funktionen aus in einer Endlosschleife: ... loop() Kernelfunktionen (WiFi, Watchdog, etc.) loop() Kernelfunktionen (WiFi, Watchdog, etc.) loop() Kernelfunktionen (WiFi, Watchdog, etc.) loop() Kernelfunktionen (WiFi, Watchdog, etc.) ... Ein delay(1) *als letzter Befehl* innerhalb der loop() bewirkt, dass - die Kernelfunktionen aufgerufen werden und prüfen, ob sie was tun müssen - der restliche Code für 1ms blockiert wird Ohne das delay(1) hätten aber in dieser ungenutzten Zeit die Kernelfunktionen sogar 3-4 mal die Chance was abzuarbeiten. Wenn ich mir einen Zeitraum von 100ms anschaue, dann sollten da jetzt die loop() und die Kernelfunktionen ca. 400 mal ausgeführt werden. Mit einem delay(1) nur noch 100mal. Und mit delay(10) nur noch 10mal. Wie oben gesagt, eine Möglichkeit wäre, es künftig parametrierbar zu machen. Aber vielleicht gibt's auch jemand der's erklären kann. — Reply to this email directly, view it on GitHub <#18 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADVIIZABI7SGXLNUJVOND4DU3LBNHANCNFSM5NADIPQA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

Für alle die das Selber Problem haben seht euch einmal meinen Fork an da habe ich das Release hinterlegt in dem ich den WebServer gefixt habe und auch gleich die neue Web.html als root callback hinterlegt hab

[AMiketta]

man kann hier an der blauen Linie sehr gut sehen das nach meinem Update gegen 10:00 aus der gepunkteten Line eine durchgehende wird, was bedeutet das jetzt auch die Verbindung mit der Solaranzeige durchgehend funktioniert und bei jeder Anfrage die Daten vom wbec geladen werden konnten.

[botox-100]

Hallo Zusammen,
ich bin auch gerade dabei WBEC einzurichten und bin auf dasselbe Problem wie mrbgfromv und die anderen hier im Thread gestossen.
Heute habe ich dann den neuen Code von steff393 verwendet und jetzt funktioniert der Webserver ohne Probleme bei mir.
Danke für die Anpassung an steff393 und allen viel Erfolg bei der Umsetzung, Thomas

[DrGalvany]

Hallo,
ich bin nicht so tief da drinnen, aber wo kann ich die fertige .bin laden bzw. wie kompiliert man die Daten hier.

Danke Michael

[steff393]

Hallo Michael,
ich werde demnächst ein Release 0.4.4 erstellen, das man dann hier unter Releases herunterladen kann.

[botox-100]

Hallo, ich bin nicht so tief da drinnen, aber wo kann ich die fertige .bin laden bzw. wie kompiliert man die Daten hier.

Danke Michael

Hi Michael,

vielleicht kann ich dir helfen, weil ich mich da dieser Tage auch erst eingearbeitet habe. Dieser kurze Heise Artikel erklärt es eigentlich perfekt: [https://www.heise.de/ct/artikel/Mikrocontroller-bequem-programmieren-mit-PlatformIO-4403209.html]
Kurz mit meinen Worten:

1. Visual Studio Code installieren
2. Das Plugin PlattformIO hinzufügen (wie im Artikel beschrieben)
3. Den Code hier herunterladen und in einem Verzeichnis auf deinem Rechner entpacken
4. Daraus ein PlattformIO Projekt machen und deine NodeMCU anstecken
5. Dann ist unten in der blauen Leiste ein kleiner Pfeil. Wenn man den betätigt werden allen benötigten Module heruntergeladen, alles wird kompiliert und zu guter letzt auf den ESP Chip geladen.

[DrGalvany]

Hallo steff393 & botox-100,
Danke euch beiden.
Es sind zwei sehr erfreuliche Nachrichten.

Michael

[lk3de]

Der Issue ist zwar schon geschlossen, aber das scheint ein generelles Problem des Wemos D1 Mini zu sein. Ich habe v0.5.1 initial geflasht und auch bei mir war der Webserver so schlecht ereichbar, dass ich den Config-Parameter cfgLoopDelay via UI gar nicht erst auf einen Wert von <=10 setzen konnte. Habe jetzt ebenfalls ein statisches delay(1) am Ende von loop() hinzugefügt und damit war das Problem sofort weg.

Vermutlich verhält sich der Wemos D1 Mini an irgendeiner Stelle anders als ein NodeMCU. Um hier tiefer einzusteigen, fehlt mir aber das Know-how.

[abuesen]

auch bei mir war der Webserver so schlecht ereichbar

@lk3de Mit welcher Fehlermeldung oder Fehlerbild im Browser?

[lk3de]

Mit welcher Fehlermeldung oder Fehlerbild im Browser?

Das UI (und auch Endpunkte wie /json oder /bootlog) wurde einfach im Browser gar nicht geladen. Meistens hat dann der Browser irgendwann mit "Seite wurde nicht gefunden" bzw. "Die Verbindung mit dem Server schlug fehl" aufgegeben. Der Webserver hat auch keinerlei HTTP-Statuscode o.ä. zurückgegeben, sondern die Requests einfach überhaupt nicht beantwortet und schlicht ignoriert.

[abuesen]

Danke. Das scheint doch etwas anders zu sein als in #99 , da wurde de Seite auch oft genug gar nicht geladen und es kam "Rejected". Nach der dort beschriebenen Veränderung zurück zu weniger Dateien klappt es wieder. MIt der 5.1 hast Du aber auch den Stand.