Ich kann wirklich nicht auf Programmierebene darüber sprechen, aber es scheint mir, dass das WLAN mit Ausnahme der statischen IP-Adresse beim Einrichten einer "nagelneuen" Einheit zu funktionieren scheint fein. Ich habe keine Verbindungsprobleme bei "frischen" Installationen mit den neuesten Firmwares festgestellt. Webseiten werden schnell geladen und das Ganze scheint schnell und reaktionsschnell zu sein. Wenn Sie versuchen, ein Upgrade durchzuführen, scheinen die meisten dieser Probleme aufzutreten. Beim Upgrade auf eine neuere Firmware scheint es ein Korruptionsproblem zu geben.

Mir ist auch aufgefallen, dass viele von Benutzern kompilierte Firmwares WLAN-Probleme haben. Allein durch das Durchlesen all dieser Themenbeiträge habe ich diesen Eindruck. Da könnte ich aber auch komplett falsch liegen. Ich versuche das nicht als Tatsache zu behaupten, sondern nur als Möglichkeit.

Ich kann nicht mit MQTT sprechen, weil ich es nicht benutze.

Nur meine 2 Cent wert.....

Wenn Sie zu Option 3 tendieren, unterstütze ich Sie voll und ganz. Ich würde es hassen, wenn wir die Verbesserungen, die uns Ihr veranstaltungsbasiertes WLAN gebracht hat, fallen lassen. Core 2_4_x ist möglicherweise einfacher zurückzusetzen/zum Upstream zu wechseln?

Aus Sicht eines Nutzers:
Ich würde so schnell wie möglich den neuen Core 2.4.1 verwenden.
Die Benutzer können immer ältere Versionen verwenden.

Nicht vergessen, Core 2.4.x behebt einige Probleme:
PWM-Flimmern ist Geschichte (#1156 ist mit Core 2.4.0) behoben
Serien mit großem Paket sind auch behoben...
Irgendwann müssen wir den Übergang zum neuen Kern schaffen. Zurück zu 2.3.0 bedeutet nur, das Problem zu verschieben. Am Ende müssen wir die Arbeit sowieso machen. Meine ESPs sind mit 2.4.0 definitiv besser

Aus meiner Sicht wird der Kern 2_4_x passieren, aber derzeit vielleicht nicht notwendig. Wir haben eine schlechte Entscheidung getroffen, als wir gleichzeitig mit der Kernaktualisierung und dem ereignisbasierten WLAN-Ansatz fortgefahren sind. Wir hätten sie nacheinander machen sollen. Als wir dann zeitgleich ein Update in den globalen Einstellungen hatten, war das Problem außerordentlich schwer zu lokalisieren. Ich unterstütze nachdrücklich die Idee, während der Fehlerbehebung der WLAN-Stabilität + der Korrektur der Einstellungsverfälschung zu 2_3_0 zurückzukehren.

Danach können wir hoffentlich v2.1.0 veröffentlichen und uns dann darauf konzentrieren, Core 2_4_x für v2.2.0 stabil zu machen

Nach dem Löschen der Einstellungen und dem Hochladen der Version vom 22.04. Bisher funktioniert alles. Zumindest vorerst :) Nur freier Speicher reicht auch im NORMAL nicht aus. Wir werden sehen, wie es weitergeht.

Ich muss @Budman1758 und @melwinek zustimmen : Ich habe auch festgestellt, dass es ab einem sauberen Gerät überhaupt keine Probleme mit Wifi, statischer IP und Einstellungen gibt.
Das Hauptproblem ist die Tatsache, dass ich jetzt zum Upgrade alle Einheiten manuell reinigen, neu flashen und ihre Konfiguration neu aufbauen muss.

Ich denke, wir sollten nicht vergessen, dass wir offiziell immer noch dabei sind, von Stable R120 auf Stable 2.1.0 umzusteigen und die Einstellungen zwischen diesen beiden Releases nicht konvertiert werden, sodass Sie sowieso von vorne anfangen müssen. Was wir mit dem Update von Core 2_4_x gemacht haben, war, noch einmal einen "Breakpoint" zu setzen. Wenn wir damit leben können, ist das kein Problem. Ich stimme zu, dass eine saubere Installation wirklich stabil ist (zumindest auf NORMAL, das ich am häufigsten teste). Und NORMAL ist der einzige Teil, der tatsächlich im Release enthalten sein wird, Test und Dev sind sowieso nur im Development Nightly Release.

Was ich meine ist: Wenn die aktuell entwickelte Firmware funktioniert und auf einem sauberen Setup stabil ist, dann bedeutet dies, dass daran nichts auszusetzen ist. Ich würde nicht zu 2.3 oder zum alten WLAN zurückkehren.

Ja, ich höre dich und ich stimme irgendwie zu. Die einzige Sache ist, dass wir einen weiteren Breakpoint erstellen, was meiner Meinung nach in Ordnung ist, da es sich noch in der Beta-Phase befindet.

Obwohl es ein Rückschritt ist, den ich nicht mag, fürchte ich, dass es wirklich besser wäre, vorerst zu Kern 2_3_0 zurückzukehren, da ich denke, dass einige seltsame Probleme aufgrund des Mangels an freiem Speicher auf 2_4_0 auftreten können.

@giig1967g Da stimme ich dir zu. Ich glaube jedoch, dass es einige Korruptionsprobleme gibt. Könnte sein, was das WLAN vermasselt, während es viele inhärente Probleme hat.

Es gibt noch Optionen, um die Speicherauslastung auf einen akzeptablen Punkt zu bringen.
Ich denke, ich kann etwa 3 - 4 kB mehr Speicher in etwa einem Abend Programmieren bekommen. (müssen jedoch alle Plugin-Dateien ändern)
Und der MQTT-Import ist auch etwas, das wirklich ein Schmerz ist, der bald behoben werden sollte.
Und das Switch-Plugin hat selbst zu viele Funktionen, die aufgeteilt werden sollten.

Ich werde heute darüber nachdenken, was wir tun sollen, also füge bitte weitere Vorschläge/Argumente hinzu :)

@TD-er Sie haben Recht mit SWITCH.
Die meisten Leute verwenden nur EIN / AUS für Schalter / Relais.
Und in diesem Plugin steckt ein Servo, Dimmer und wahrscheinlich sowas.
Das könnte getrennt sein.

Es behandelt auch Dinge, die sehr spezifisch für MQTT und/oder Domoticz sind. Das sollte nicht Teil des Plugins sein.

@TD-er In vielen Fällen würde es mir helfen, mich selbst zu kompilieren, nach dem Entfernen unnötiger Plugins benötige ich in vielen Fällen nur SWITCH, FHEM Controller, DHT.
Aber nach diesen Abenteuern mit Einstellungen habe ich Angst mich selbst zu kompilieren. Vor allem nach deinem Post: https://github.com/letscontrolit/ESPEasy/issues/1292

Hast du dir angeschaut, wie WLAN in anderen Projekten (zB Tasmota) realisiert wird?

Über das Gedächtnis: Ich habe es dir gesagt :smile:
Ich finde, es gibt viel zu viele selten genutzte Features im Core - die Entscheidung, ob ein Core Feature Request implementiert wird, sollte viel strenger sein - jetzt ist es für alle ein bisschen wie Weihnachten...
Vielleicht würde ein Voting mit einem gewissen Limit helfen.

Wenn möglich, sollte der Kern zuerst von den selten genutzten Features gereinigt (oder in ein Plugin umgewandelt) und dann optimiert werden. Außerdem könnte man über zusätzliche Schnittstellen für Plugins nachdenken, um mehr Funktionalität außerhalb des Kerns auszutauschen.

@M0ebiu5 Zustimmen .
Was passieren sollte ist, dass neue Features in einem separaten Branch entwickelt werden, dann einige davon sammeln und diese zu einem Release Candidate Branch zusammenführen und diese testen.
Geben Sie dann die verwendeten Funktionen frei und führen Sie sie im Master-Zweig (oder dev-Zweig, oder wie auch immer Sie es nennen) zusammen.

Und eine Sache, die ich gelernt habe, ist, zweimal zu fragen, was beobachtet wird, was beobachtet werden sollte und welche Version verwendet wird. Das macht vieles klarer und führt zu weniger Fehlern.
Ein Teil davon muss im Code selbst erfolgen, um eine Art Fußabdruck zu erstellen, um sehen (und protokollieren) zu können, welche Software verwendet wird.

Auch Plugins sollten nur Plugins sein, um einen Sensor mit einigen Ausgabewerten zu verbinden.
Vielleicht sollten Plugins, die Ausgaben generieren (wie Displays), nicht wie die Eingabe-Plugins verwendet werden.
Wir bekommen also etwas wie:

• Sensor zum Auslesen eines Geräts und zum Generieren von Messungen
• Ausgabe (Anzeige?) zu aktuellen Werten. Dies kann auch etwas anderes als eine Anzeige sein, beispielsweise JSON oder ein Bild.
• Controller als Schnittstelle zur Außenwelt (Input und Output)
• Regeln zur Verarbeitung von Daten und Ereignissen.
• Benachrichtigungen zum Konvertieren von Ereignissen in etwas anderes. Eigentlich klingt es nach einem aufwendigeren Controller.
• Befehle, um einige grundlegende Einstellungen oder temporäre (nicht persistente) Änderungen/Updates vorzunehmen und einige Aktionen auszuführen (z. B. Neustart)
• Webseite, um sie alle zu konfigurieren.

Aber eine solche Neugestaltung wird einiges an Aufwand erfordern.

@TD-er Sie haben Recht, aber ich würde die Änderungen in kleinen Schritten vornehmen - da die meisten Teile stabil funktionieren und große Änderungen diese Stabilität gefährden könnten.

Neue Schnittstellen zum Kern sind ein möglicher Weg. Sie werden das aktuelle Verhalten nicht beeinflussen und nur neue oder stark geänderte Plugins verwenden sie. Die Transformation zu einer sauberen Architektur wird länger dauern, jedoch mit einem geringeren Risiko und der Aufwand wird sich auch über die Zeit verteilen.

Ich stimme zu, dass diese Änderungen in Ruhe durchgeführt werden sollten.
Es ist eher ein Ausblick auf die Neugestaltung für die Zukunft.

Der Knoten vom 22.04 hat jedoch die Verbindung verloren.
Das Zurücksetzen des Routers hilft nicht.
ESP-Reset wird helfen, aber ich bin weit weg.
Die beste Version auf meinen Knoten ist also mega-20180410.
Vielleicht, weil es auf Kern 2.3 ist?
Vielleicht wäre es aber eine gute Lösung, für einige Zeit zurück zu 2.3 zu gehen?

Nein, letzte Nacht habe ich das Problem gesehen (im Code und bei meinen eigenen Einheiten).
Meine Knoten stellten keine erneute Verbindung her, als sie einen „Beacon-Timeout“-Fehler erhielten, was ein recht häufiger Grund für die Trennung ist. Es ist ein logischer Fehler im Code, aber es war bereits nach 1:30 Uhr und ich wollte ihn in diesem Moment nicht beheben. Die nächtliche Bauzeit wäre sicherlich vorbei gewesen, um das Problem zu beheben, also spielte das keine Rolle mehr ;)

verwandt: #1064

Ich habe gerade 6 Geräte mit der aktuellen Version ESP_Easy_mega-20180425_test_ESP8266_4096.bin geflasht.

Ich denke, mit dieser Version sind wir an einem absoluten Tiefpunkt angelangt.
Alle Geräte waren nach einigen Stunden im Netz nicht erreichbar.

Deshalb werde ich - so oder so - zu einer funktionierenden WLAN-Version zurückkehren.

Vielleicht sollten wir auch den Build von heute entfernen, nur um zu verhindern, dass andere dasselbe laden.

Ich würde vorschlagen, jetzt eine neue Version 04.25 auf Core 2.3.0 zu bauen und die aktuelle zu ersetzen :)

Ich habe keine Kontrolle über den Build-Server.
und 2 Versionen mit derselben Build-Nummer ist nie eine gute Idee.

Ich weiß, dass @Grovkillen den heutigen Build entfernen kann.

Meinst du, ich sollte es entfernen @TD-er ? Morgen wird ein neues gebaut.

Anscheinend ist es noch schlimmer im Vergleich zum gestrigen Build.
Also ja, entferne es.

Fertig

Und die platformio.ini wird auch geändert.
Was auch immer passiert, der Build von morgen wird nicht so schlecht sein wie der heutige.

Ich spüre hier Panik. Keine Sorge, es gibt noch Hoffnung.
Lass uns zuerst ein :bier: oder :beers:
danke @TD-er, dass du trotz deiner Sorgen so unruhig nach vorne gestürmt bist, danke

Davon abgesehen, lassen Sie mich Folgendes sagen:

1. Meiner Erfahrung nach ist an neueren Core-Versionen nichts auszusetzen, außer 2.4.1, das ein Wificlient-Speicherleck (und einen Workaround) hat.
2. Ältere Versionen des Master-Zweigs bis zu dem Punkt, an dem entschieden wurde, 2.0 aufzugeben, funktionierten mit diesen Kernversionen recht stabil. Und schnell.
3. Wir sollten uns wirklich (Hervorhebung auf wirklich!) auf Stabilität konzentrieren. Keine neuen Funktionen für eine Weile (außer die Stabilität zu verbessern) weniger ESP32 und weniger Speichersuche, weniger Beschleunigung weniger alles außer Stabilität. Nehmen wir an, wir planen, zum Mond zu fliegen. Wirklich. Das Ding muss funktionieren. Es muss Einzelbitfehler, Neustarts, Stromschwankungen und Temperaturbelastungen tolerieren.
   Ich meine fehlertolerante Programmierung. Es getan. Es kann Spaß machen, wenn Sie sich darauf konzentrieren.

Was kommt als nächstes ? Wenn ich ein Core-Entwickler wäre, würde ich mich für diese json-basierte Konfiguration entscheiden. Schnellstmöglich. Scheint die aktuelle Wurzel des Bösen zu sein, genau wie der speicherintensive Webserver vor einiger Zeit.

Ich spüre hier Panik. Keine Sorge, es gibt noch Hoffnung.
Lassen Sie uns zuerst ein 🍺 oder 🍻 haben.
danke @TD-er, dass du trotz deiner Sorgen so unruhig nach vorne gestürmt bist, danke

100 % zustimmen !!!

Ich weiß nicht, ob dieser Fehler schon bekannt ist:
Nach ein oder zwei Tagen scheint der Webserver nicht mehr zu funktionieren. Die MQTT-Veröffentlichung funktioniert noch.
Ich verwende die normale Version vom 22.04.

@TD-er persönlich werde ich für etwas Neues wie 2.4.1 stimmen, um es auszuprobieren.

1+

1+

Ich spüre hier Panik. Keine Sorge, es gibt noch Hoffnung.

Es ist keine Panik, es ist pure Frustration ;)
Die Sache ist die, dass ich hier wirklich Sachen teste und innerhalb von Minuten (zumindest fühlt es sich so an) Builds noch schlimmer als zuvor scheitern.
Ich bin es gewohnt, gegen Blackboxes zu programmieren, und auch Rev. konstruiere diese Blackboxes.
Aber es fühlt sich so an, als ob sich das Feedback, das ich in den Protokollen sehe, völlig von der Realität unterscheidet.
Jetzt ist klar, dass es in den letzten Wochen mehrere Probleme gab, die auf Fehler in den Kernbibliotheken, beschädigten Einstellungen und ein paar Änderungen, die ich vorgenommen habe, zurückzuführen waren, schienen mit einigen Fehlern in der AP-Firmware zusammenzuhängen.

Und meine persönliche Meinung zu Software ist, dass sie absolut stabil sein sollte und Geschwindigkeit an zweiter Stelle steht.
Aber in den letzten Wochen ist die Geschwindigkeitssteigerung in Ordnung, aber die Stabilität wurde von Tag zu Tag schlechter, egal was ich versuchte.

Jetzt ist es an der Zeit, einen festen Halt zu machen und sich zunächst auf die Stabilität zu konzentrieren. Man könnte das "Panik" nennen, aber eigentlich ist es eine Art Rückschritt, um sich wirklich auf das zu konzentrieren, was vor sich geht.
Ich weiß jetzt viel mehr über WLAN als noch vor einem Monat, also sollte ich in der Lage sein, ein gut gestaltetes Paket zu erstellen. Aber das braucht Zeit und ich möchte wirklich einen Punkt der Stabilität erreichen und einen Moment der Ruhe in meinem Kopf bekommen, damit es so funktioniert, wie es sollte.
Und dann gibt es noch viel Platz, um Sachen noch schneller zu machen, weil ich gesehen habe, wie ik noch schneller verbindet :)
Aber das ist für die nächste Version.

Zu den restlichen Hauptproblemen:

• Speichernutzung
• JSON-Import/Export von Einstellungen
• Neugestaltung des MQTT-Imports
• einige Plugins wie P001-switch sollten geändert werden.
• Was ist übrig.

für mich (und wahrscheinlich nur für mich) hat sich der Wechsel auf 2.4.1 oder sogar GIT Core nicht verbessert, das Gegenteil war der Fall. Ich habe ungefähr 20 verschiedene Kombinationen von Core-Version, Mage-Commits und LwIP-Versionen ausprobiert. Die Rückkehr zu 2.3.0, insbesondere lwIP 1.4, war die einzige Möglichkeit, es stabil zum Laufen zu bringen. Aber nochmal, nur meine Ansicht dazu in meinem speziellen Umfeld...

Und ja, vielen Dank @TD-er und

Danke euch allen, @TD-er fasst den Weg nach vorne ziemlich gut zusammen.

Zu den restlichen Hauptproblemen:
• Speichernutzung
• JSON-Import/Export von Einstellungen
• Neugestaltung des MQTT-Imports
• einige Plugins wie P001-switch sollten geändert werden.
• Was ist übrig.

Und wir werden für die morgige Version zu 2.3.0 zurückkehren und das eine Weile testen.

Die meisten meiner selbstgebauten Images basieren auf Core-Rev. 491c9b8b (2.4.1 + x).
Das einzige, was ich sehe, sind zufällige Neustarts mit meinem Sonof 4ch-Gerät. Leider ist es Teil meiner Teichsteuerung, daher keine Möglichkeit eine serielle Schnittstelle zur besseren Überwachung anzuschließen, Syslog ist ziemlich unbrauchbar, da die relevanten Informationen ausgespuckt werden, bevor das WLAN funktioniert.

Es ist ziemlich brauchbar - solange Sie die lwIP-Bibliothek 'v2 Higher Bandwith' verwenden.
Andernfalls treten Probleme mit der MTU-Fragmentierung mit Paketen > 512 Byte auf (außer Betrieb, mit falschen Fensterinformationen).

Die funktionierenden ESPEasy Revs (meine Repos) sind

begehen 3576619181926b3adff5a1a133390eb71e808ae9
Zusammenführen: 9038bd2 d083a58
Autor: Susis Strolch
Datum: Fr. 13. Apr. 17:07:30 2018 +0200

Merge remote-tracking branch 'upstream/mega' into mega

* upstream/mega:
  automaticly updated release notes for mega-20180413
  [wifi] Event based wifi, fix set AP and crash on start

und
begehen daf39a064d3633fe1eccfa33576fafbccd7611a7
Zusammenführen: 2a96218 806a275
Autor: Susis Strolch
Datum: Mo 9. April 09:15:52 2018 +0200

Merge remote-tracking branch 'upstream/mega' into mega

* upstream/mega:
  automaticly updated release notes for mega-20180409
  Both reset/factoryreset option
  Factory Reset (not enabled yet)

Jedes ESPEasy nach dem 13. April zeigt schreckliche - sprechende nicht funktionierende - Ergebnisse, selbst wenn der gesamte Flash gelöscht wird, bevor die Binärdatei (über Arduino IDE) geflasht wird.

Ich würde also vorschlagen, mit 2.4.1 (oder höher) zu gehen und ESPEasy (WIFI und config) aufzupolieren.
Core selbst scheint soweit in Ordnung zu sein.

lol @Freitag, der 13., in der Tat ein
Was ist also "ESPeasy polieren (WIFI und Konfiguration)." ?
Eine andere Filiale..?
Polen aka Polish oder Polish wie in Buff & Shine, ha

@susisstrolch Wie solche Fehler ab?
"Probleme mit MTU-Fragmentierung mit Paketen > 512Bytes (außer Betrieb, mit falschen Fensterinformationen)."

Senden Sie einfach eine vorbereitete Anfrage an den espeasy-Webserver, mit zusätzlichem Header mit mindestens 512 Zeichen

@Oxyandy : Beim Ausführen von tcpdump auf meinem FHEM-Server und bei der Analyse mit WireShark stellte ich fest, dass die letzten 512 Byte einer ~ 700 Byte großen JSON-Antwort zuerst gesendet wurden, gefolgt vom HTTP-Header.
Und bei diesen beiden Paketen fehlten einfach die TCP-Fensterinformationen.
Kann auf Anfrage weitere Details zusenden...
Polieren wie in Buff & Shine

Bei mir läuft die Version vom 22.04.2018 mit Core 2.4.1 ganz gut.

Könntest du auch meine gestrige Arbeit überprüfen, die dann aber auf 2.4.1 aufgebaut ist?
https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability

In 2.3.0 hatte ich noch Probleme mit statischer IP.
Habe den AP-Modus mit der Setup-Seite noch nicht getestet.

Ich habe gerade ein Wemos mit deiner Version geflasht
[wifi] Versuch, ereignisbasiertes WLAN einfacher zu machen).

Version läuft .....

Was sollte ich jetzt tun?

Scheiße, aus meinem letzten Test (22.04.1018) legten 4 von 8 Geräten nach ca. 7 Stunden auf.

Ich schätze, kein Protokoll? :(
Sind die Knoten abgestürzt (hängen) oder einfach nicht wieder verbunden?
Antworten sie auf Ping, und somit ist nur der Webserver deaktiviert oder zu beschäftigt (MQTT-Reconnect benötigt viele Ressourcen) ?

Inzwischen hängen 5 Geräte.
Ich habe kein Protokoll. Der Webserver ist nicht erreichbar. Ping geht auch nicht.

sie sind einfach tot.

Sie sollten wirklich versuchen, es zu loggen. Es könnte uns einige nützliche Hinweise geben

Ich logge die Version von Gijs. Es läuft jetzt seit 55 Minuten. :)

oh, das kann ich schlagen! Ich habe 12 Geräte, die zwischen 45 und 263 Min. in der Gijs-Version laufen (mit esp-Kern von GIT) 😀 und immer noch alle glücklich...

Ja, die Zeiten haben sich geändert.
In der Vergangenheit liefen meine Geräte wochenlang.

Heute bin ich froh, wenn sie ein paar Stunden arbeiten. :)

Eines meiner Geräte zu Hause führt immer noch den Build aus, den ich 20171231 erstellt habe, und geht heute auf 60 Tage Betriebszeit über.

Also ich weiß was du meinst :(

Dann nehmen wir einfach das Release 2017123, dann können wir uns auf andere Dinge konzentrieren. :)

Ortszeit: | 26.04.2018 17:47:23
Betriebszeit: | 0 Tage 2 Stunden 27 Minuten
Belastung: | 10% (LC=9371)
Freies Mem: | 10336 (9544 - sendContentBlocking)
IP: | 192.168.0.201
WLAN-RSSI: | -67 dB

Hey, warum nimmst du nicht diese 60-Tage-Version, markierst sie mit 2.0 und schreibe einige Stichpunkte zu bekannten Problemen (keine fehlenden Funktionen).

@s0170071 brauchen wir wirklich 75% funktionierendes Produkt und viele Probleme, die nach der Veröffentlichung behoben werden?

Vielleicht müssen Sie nicht so weit zurückgehen ... Dies ist der neueste manuelle Neustart:

Betriebszeit: 21 Tage 3 Stunden 32 Minuten
Last: 32 % (LC=6281)
Free Mem: 14328 (13392 - parseTemplate3)

Bauen | 20100 - Mega (Kern 2_3_0)
GIT-Version | mega-20180308
Plugins | 72 [Normal] [Testen] [Entwicklung]
Build Md5 | eb5a94ae675cb343cc387319fd8c4f9a
Md5 Schach | bestanden.
Bauzeit | 8. März 2018 03:05:36
Binärer Dateiname | Firmware.bin

6 Geräte laufen seit 5 Stunden - ein neuer Rekord.

Das sind schon über 30 Stunden ;)

Ich habe jetzt fast alle (12+) Geräte auf @TD-er's Änderungen von heute laufen. Alle Wemos D1 Minis mit einer Vielzahl von angeschlossenen Sensoren und Relais (alle unterschiedlich). Die meisten von ihnen haben jetzt mehr als 10 Stunden Betriebszeit. Die letzten werde ich jetzt auch flashen.
Ich hatte zwei oder drei spontane Neustarts von einem oder zwei Geräten, aber dies könnte auch von Plugins oder fehlerhaften Sensoren kommen (ich verwende auch einige Entwickler-Plugins und habe sogar die Konfiguration geändert, um 24tasks zu unterstützen und esp GIT-Kern zu verwenden, einige sogar ohne das Löschen der zuerst konfigurieren). Aber sie kamen immer wieder hoch und haben sich erfolgreich mit dem Netzwerk verbunden!

Für mich ist dies die stabilste Version, die ich bisher hatte. ähnlich zu dem, was ich vor 2.4.0 Kern hatte.

Daher würde ich dafür stimmen, @TD-er-Änderungen von heute Abend zusammenzuführen, es testen zu lassen und von dort aus fortzufahren ... Aber das ist nur MHO ...

Und danke an @TD-er für die schnelle Fehlerbehebung (versuchen)!! Bei mir hat es funktioniert!!

Ich hatte auch einen Neustart auf einem Gerät, aber es wurde sofort wieder verbunden.
Alle Geräte sind Wemos D1 mini.

Ich habe die Testversion hier mit 71 Plugins ausgeführt.
An den Geräten befinden sich fast nur BME280, Pir, MH-Z19 sowie ein Staubsensor und einige Leds.

Der Webserver reagiert sehr schnell.
Im Moment bin ich mit dieser Version und Core 2.4.1 sehr zufrieden.

Vielleicht ist es bereits bekannt (wenn ja, ignorieren Sie es bitte)
Ich habe ein ESP pro mini mit ESP_Easy_mega-20180422_normal_ESP8266_4096.bin (Kern 2.4.0) installiert.
Es läuft seit 3 ​​Tagen !
Die GUI ist nicht mehr erreichbar, nur nach Kaltstart. (getestet mit einem anderen esp)
Ping ist ok, mqtt-Publishing funktioniert auch, GPIO-Switch über http funktioniert auch.
Das "einzige" Problem, die GUI ist nicht erreichbar.
Mit anderen Worten, das ESP arbeitet blind, alles ist in Ordnung, nur die GUI reagiert nicht.
Nachdem Sie die IP im Browser eingegeben haben, erhalten Sie:

ily: serifenlose; Schriftgröße: 12pt; Rand: 0px; Füllung: 0px; Box-Größe: Bordüre-Box; } h1 {Schriftgröße: 16pt; Farbe: #07D; Rand: 8px 0; Schriftgewicht190 ; Farbe: #07D; }.button {Rand: 4px; Polsterung: 4px 16px; Hintergrundfarbe: #07D; Farbe: #FFF; Textdekoration: keine; Randradius: 4px; Grenze:190 190 ativ; Cursor: Zeiger; Schriftgröße: 12pt; -webkit-user-select: keine; -moz-user-select: keine; -ms-u

Ich habe die Protokollierung mit meinem zweiten Gerät nach dem Kaltstart aktiviert, nachdem das Gerät nicht mehr reagiert, wird das Protokoll hier gemeldet, wenn gewünscht.

Könntest du auch den Speicherverbrauch protokollieren? Nur um zu sehen, ob es in 2.4.1 ein Speicherleck gibt, wie von einigen berichtet.

Ja, genau das gleiche habe ich mit der Version vom 22.04.2018.
Das Gerät läuft, aber der Webserver ist nicht erreichbar.

Ich werde versuchen, es zu loggen.
Scheint konstant zu sein.

Freies Mem: | 9792 (9008 - sendContentBlocking)

Meinst du Sysheap?

@uzi18 Sie können nicht beides haben, Schneide und Stabilität. Die 60-Tage-Version ist stabil, oder?

@TD-er Wenn Sie das Regelfenster einige Minuten geöffnet lassen, verschwinden alle Regeln.

Das ist mit 2.3.0?

Ich habe 2.4.1

Hallo,
Ich teste 20180426. Funktioniert, ist aber im Vergleich zu 20180424 wirklich langsam.
Für mich funktionierte Core 2.4.0 einwandfrei und stabil.
Mit der neuen Version dauerte MQTT mehr als 1 Minute, um eine Verbindung herzustellen, während die vorherige Version die Hälfte der Zeit war.
Habe ich mit Core 2.4.0 nur Glück? Oder ist es nur eine Frage der Konfiguration?

Ich finde die Version von @TD-er von gestern mit Core 2.4.1 extrem schnell.

Nach dem Einschalten der Spannung dauert es nur wenige Sekunden bis das Webinterface erreicht wird.
Die MQTT-Nachrichten kommen sofort.

nur für die interessierten. Ich verfolge CPU, Speicher und RSSI. Anbei eine Grafik aller Einheiten. Sie können deutlich an der Speichernutzung erkennen, als ich das Upgrade auf den 2.4.x-Kern durchgeführt habe. Der Speicher scheint jedoch stabil zu sein (zB kein Leck)...
Die Geräte 1-11 & 16 sind "in Gebrauch" mit Sensoren usw. die anderen sind einfach D1's ohne angeschlossene Geräte.

Hi @micropet : wie kann ich die gestrige Version mit Core 2.4.1 verwenden?

Ich fange an zu denken, dass Wemos vielleicht stabiler ist als SONOS?
Ich benutze auch Wemos

Mit:
https://github.com/TD-er/ESPEasy/commits/bugfix/wifi_stability
und in Plattform:
[core_2_4_1]
Plattform = [email protected]

@micropet und @TD-er: Ich habe gerade den WLAN-Stabilitätszweig mit Kern 2.4.1 kompiliert.
BEEINDRUCKEND. Erstaunlich schnell.
Werde es die nächsten 3 Tage laufen lassen und dann berichten. Es enthält recht komplexe Regeln...
Vorerst: 7 Sekunden zum Verbinden mit MQTT im Vergleich zu 60 mit 2.3.0 Version 20180426.

Ich sehe einige Wiederverbindungen im MQTT-Import.

104 : INIT : Free RAM:20040
104 : INIT : I2C
104 : INIT : SPI not enabled
1213 : INFO : Plugins: 72 [Normal] [Testing] [Development] (ESP82xx Core 2_4_1)
1214 : EVENT: System#Wake
1289 : WIFI : Set WiFi to STA
mode : sta(60:01:94:8e:ba:c9)
                             add if0
                                    1292 : WIFI : Connecting KeepOut attempt #0
1293 : IP   : Static IP : 192.168.1.206 GW: 192.168.1.1 SN: 255.255.255.0 DNS: 8.8.8.8
1405 : EVENT: System#Boot
1412 : ACT  : gpio,14,1
1414 : SW   : GPIO 14 Set to 1
1416 : ACT  : gpio,12,1
1417 : SW   : GPIO 12 Set to 1
1420 : ACT  : gpio,13,1
1420 : SW   : GPIO 13 Set to 1
1422 : ACT  :
1431 : ACT  : taskvalueset 1,1,1
1441 : ACT  : taskvalueset 1,2,1
1453 : ACT  : taskvalueset 1,3,1
1465 : ACT  : taskvalueset 1,4,1
1474 : ACT  :
1482 : ACT  :
1489 : ACT  : timerset,4,60
1568 : WD   : Uptime 0 ConnectFailures 0 FreeMem 18616
1682 : Dummy: value 1: 1.00
1683 : Dummy: value 2: 1.00
1683 : Dummy: value 3: 1.00
1683 : Dummy: value 4: 1.00
1684 : EVENT: Relay1#r1=1.00
1753 : EVENT: Relay1#r2=1.00
1824 : EVENT: Relay1#r3=1.00
1890 : EVENT: Relay1#r4=1.00
2251 : SYS  : 0.00
2253 : EVENT: SysInfoUptime#UptimeDays=0.00
3188 : IMPT : MQTT 037 Intentional reconnect
3562 : IMPT : MQTT 037 Intentional reconnect
scandone
        state: 0 -> 2 (b0)
                          5130 : Dummy: value 1: 25.80
5130 : Dummy: value 2: 27.20
5130 : Dummy: value 3: 27.40
5130 : Dummy: value 4: 0.00
5131 : EVENT: temp#t1=25.80
state: 2 -> 3 (0)
                 5158 : ACT  : timerset,1,2
state: 3 -> 5 (10)
                  add 0
                       aid 5
                            cnt
                                5174 : ACT  : lcd,1,20,*

connected with KeepOut, channel 9
                                 ip:192.168.1.206,mask:255.255.255.0,gw:192.168.1.1
   5239 : EVENT: temp#t2=27.20
5266 : ACT  : timerset,2,3
5276 : ACT  : lcd,1,20,*
5335 : EVENT: temp#t3=27.40
5365 : ACT  : timerset,3,4
5375 : ACT  : lcd,1,20,*
5428 : EVENT: temp#t4=0.00
5503 : Dummy: value 1: 18.00
5504 : Dummy: value 2: 11.00
5504 : Dummy: value 3: 12.00
5504 : Dummy: value 4: 0.00
5505 : EVENT: local#LSet1=18.00
5575 : EVENT: local#LSet2=11.00
5645 : EVENT: local#LSet3=12.00
5715 : EVENT: local#empty=0.00
6553 : Current Time Zone:  DST time start: 2018-03-25 02:00:00 offset: 120 minSTD time start: 2018-10-28 03:00:00 offset: 60 min
6554 : EVENT: Time#Initialized
6627 : EVENT: Clock#Time=Thu,22:59
6702 : IMPT : MQTT 037 Intentional reconnect
6964 : IMPT : Connected to MQTT broker with Client ID=ESPT6-Import
6965 : EVENT: MQTTimport#Connected
6981 : ACT  : publish /ESPT6/dummy/requestedTempUpdate,0
7059 : IMPT : [import1#Set1] subscribed to /OH2/status/nSetTemp1
7061 : IMPT : [import1#Set2] subscribed to /OH2/status/nSetTemp2
7062 : IMPT : [import1#Set3] subscribed to /OH2/status/nSetTemp3
7063 : IMPT : [import1#master] subscribed to /OH2/status/nMasterCaldaia
7065 : WIFI : Connected! AP: KeepOut (BC:EE:7B:EF:A3:38) Ch: 9 Duration: 3911 ms
7065 : EVENT: WiFi#ChangedAccesspoint
7144 : WIFI : Static IP: 192.168.1.206 (ESPT6-16) GW: 192.168.1.1 SN: 255.255.255.0   duration: 1940 ms
7173 : EVENT: Time#Set
7247 : EVENT: WiFi#Connected
7316 : Webserver: start
7332 : IMPT : MQTT 037 Intentional reconnect
7587 : IMPT : Error subscribing to /OH2/status/nSetTemp1
7588 : EVENT: Rules#Timer=1
ping 1, timeout 0, total payload 32 bytes, 1067 ms
                                                  7648 : [if 0=1]=false
7650 : else = true
7651 : ACT  : timerset,5,6
7688 : EVENT: Rules#Timer=1 Processing time:100 milliSeconds
7690 : MQTT : Intentional reconnect
7704 : MQTT : Connected to broker with client ID: ESPClient_60:01:94:8E:BA:C9
7707 : Subscribed to: /ESPT6/#
7708 : EVENT: MQTT#Connected
7722 : ACT  : publish /ESPT6/dummy/requestedTempUpdate,0
7813 : EVENT: MQTT#Connected Processing time:105 milliSeconds
7828 : IMPT : [import1#Set1] : 18.00
7828 : EVENT: import1#Set1=18.00
7882 : ACT  : taskvalueset,6,1,18
7893 : ACT  : timerset,1,2
7904 : ACT  : lcd,1,20,*
7955 : EVENT: import1#Set1=18.00 Processing time:127 milliSeconds
8065 : MQTT : Topic: /ESPT6/status/LWT
8065 : MQTT : Payload: Connected
8075 : IMPT : [import1#Set2] : 11.00
8075 : EVENT: import1#Set2=11.00
8131 : ACT  : taskvalueset,6,2,11
8143 : ACT  : timerset,2,3
8152 : ACT  : lcd,1,20,*
8199 : EVENT: import1#Set2=11.00 Processing time:124 milliSeconds
8206 : MQTT : Topic: /ESPT6/dummy/requestedTempUpdate
8207 : MQTT : Payload: 0
8218 : MQTT : Topic: /ESPT6/Relay1/r1
8218 : MQTT : Payload: 0
8219 : MQTT : Topic: /ESPT6/Relay1/r2
8219 : MQTT : Payload: 1
8220 : MQTT : Topic: /ESPT6/Relay1/r3
8220 : MQTT : Payload: 1
8220 : MQTT : Topic: /ESPT6/Relay1/r4
8220 : MQTT : Payload: 1
8221 : MQTT : Topic: /ESPT6/SysInfoUptime/UptimeDays
8221 : MQTT : Payload: 0.1
8222 : MQTT : Topic: /ESPT6/status/LWT
8222 : MQTT : Payload: Connected
8223 : MQTT : Topic: /ESPT6/dummy/requestedTempUpdate
8223 : MQTT : Payload: 0
ping 1, timeout 0, total payload 32 bytes, 1112 ms
                                                  8320 : IMPT : [import1#Set3] : 12.00
8320 : EVENT: import1#Set3=12.00
8376 : ACT  : taskvalueset,6,3,12
8387 : ACT  : timerset,3,4
8396 : ACT  : lcd,1,20,*
8441 : EVENT: import1#Set3=12.00 Processing time:121 milliSeconds
8565 : IMPT : [import1#master] : 0.00
8565 : EVENT: import1#master=0.00
8581 : ACT  : timerset,1,2
8591 : ACT  : timerset,2,3
8600 : ACT  : timerset,3,4
8608 : ACT  : lcd,1,20,*
8684 : EVENT: import1#master=0.00 Processing time:119 milliSeconds
8696 : EVENT: MQTTimport#Disconnected
8774 : EVENT: MQTTimport#Disconnected Processing time:78 milliSeconds
8775 : IMPT : MQTT 037 Connection lost
9712 : IMPT : Connected to MQTT broker with Client ID=ESPT6-Import
9713 : EVENT: MQTTimport#Connected
9725 : ACT  : publish /ESPT6/dummy/requestedTempUpdate,0
9809 : EVENT: MQTTimport#Connected Processing time:96 milliSeconds
9813 : IMPT : [import1#Set1] subscribed to /OH2/status/nSetTemp1
9813 : IMPT : [import1#Set2] subscribed to /OH2/status/nSetTemp2
9814 : IMPT : [import1#Set3] subscribed to /OH2/status/nSetTemp3
9815 : IMPT : [import1#master] subscribed to /OH2/status/nMasterCaldaia
9817 : MQTT : Topic: /ESPT6/dummy/requestedTempUpdate
9817 : MQTT : Payload: 0
9931 : IMPT : [import1#Set1] : 18.00
9931 : EVENT: import1#Set1=18.00
9985 : ACT  : taskvalueset,6,1,18
9996 : ACT  : timerset,1,2
10005 : ACT  : lcd,1,20,*
10053 : EVENT: import1#Set1=18.00 Processing time:122 milliSeconds
10173 : IMPT : [import1#Set2] : 11.00
10174 : EVENT: import1#Set2=11.00
10228 : ACT  : taskvalueset,6,2,11
10239 : ACT  : timerset,2,3
10248 : ACT  : lcd,1,20,*
10295 : EVENT: import1#Set2=11.00 Processing time:121 milliSeconds
10414 : IMPT : [import1#Set3] : 12.00
10414 : EVENT: import1#Set3=12.00
10470 : ACT  : taskvalueset,6,3,12

@giig1967g Gibt es eine Möglichkeit, eine bin-Datei dafür zu erstellen, die ich herunterladen könnte? 4-Meg-Version? Ich lerne immer noch den Kompilierungsprozess....

Firmware.zip

@giig1967g, wie gesagt - extrem schnell und es sieht auch noch stabil aus.

Ich hatte jetzt eine Reconnect in 7 Stunden.

@giig1967g Beim Ausführen einer statischen IP
Vor allem bei der Ausführung mit MQTT.
DHCP scheint gut zu funktionieren.

Morgen wird ein sehr arbeitsreicher Tag für mich, denn es ist "Königstag" und die königliche Familie wird in Groningen sein. Außerdem bin ich eingeladen, dort zu sein, um -vielleicht- dem König von unseren Problemen hier zu erzählen.
Also werde ich jetzt ins Bett gehen und mein Vorschlag ist, den Code heute nicht in den Hauptzweig zu mischen. Morgen werden wir die Entwicklung fortsetzen und den bestmöglichen WLAN-Verbindungscode erstellen :)

Ok, ich habe ein Problem sowohl bei 20180426 (2.3.0) als auch bei WifistabilityBranch (2.4.1) gefunden.
Wenn ich den Router aus- und wieder anschalte, verbindet sich das Gerät nicht wieder mit dem Wifi, obwohl es auf seriell "Wifi#Connected" schreibt. Gerät funktioniert (Seriell und Regeln ok), aber keine WiFi-Verbindung, also kein Webinterface.

@TD-er, lass uns das machen. Grüße an den König - vielleicht hat er noch eine andere Idee. :)
Und gute Nacht.

@TD-er: Viel Glück bei deinen Problemen im wirklichen Leben ...

Einige hier, wenn ich das WIFI für 0,2 Sekunden trenne:

29113846 : ACT : TimerSet,1,60
29115651 : MQTT : Verbindung verloren
29115652 : EREIGNIS: MQTT#Getrennt
29115689 : MQTT : Verbindung zum Broker fehlgeschlagen
29115690 : EREIGNIS: WLAN#Getrennt
29115706 : WIFI : Getrennt! Grund: '(1) Unspecified' Verbunden für 8h04m <-------- !!
29116189 : MQTT : Verbindung zum Broker fehlgeschlagen
29116939 : MQTT : Verbindung zum Broker fehlgeschlagen
29117860 : WD : Betriebszeit 485 Verbindungsfehler 6 FreeMem 16416
29117881 : MQTT : Verbindung zum Broker fehlgeschlagen
29117938 : MQTT : Verbindung zum Broker fehlgeschlagen
29119189 : MQTT : Verbindung zum Broker fehlgeschlagen
29120689 : MQTT : Verbindung zum Broker fehlgeschlagen
29120736 : DS : Temperatur: 19,94 (28-ff-b8-ea-b4-16-3-ed)
29120738 : EREIGNIS: DS18b20#Temperatur=19.94
29122440 : MQTT : Verbindung zum Broker fehlgeschlagen
29124440 : MQTT : Verbindung zum Broker fehlgeschlagen
29126441 : MQTT : Verbindung zum Broker fehlgeschlagen
29128442 : MQTT : Verbindung zum Broker fehlgeschlagen

@giig1967g
Sie könnten nach der Funktion zum Starten/Stoppen des Webservers suchen und ein return; in die erste Zeile dieser Funktion einfügen.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585

Ich denke, es gibt ein Problem beim Aufrufen der Funktion 'gotIP', wenn eine statische IP verwendet wird.
Das ist auch der Grund für die Instabilität beim Ausführen von MQTT + statischer IP.

Aber das ist wohl für @TD-er eine Kleinigkeit. :)

Hm, ich schaue nicht durch.
Ich denke, das machst du morgen besser.
Außerdem arbeite ich hier mit DHCP.

Für mich scheint die Stabilität mit meiner Hardware mit 2.3.0-Core-Builds immer "besser" (nicht perfekt) zu sein

• 2.4.0 & 2.41 probiert -- sie sind schlimmer...

0403 mega normal - scheint einfach zu funktionieren & Versionen vorher..
Jemand, der noch Probleme wie ich hat, kann bitte 0403 versuchen.
@susisstrolch & @uzi18 - danke beiden für eure Antworten
Danke

Meins läuft jetzt fast 17 Stunden. Einzelverbindung

Update von meinen Geräten (Name|Verfügbarkeit in Minuten|letzte Disk. Grund|WLAN verbunden in ms):
wemos_mini_01_sysinfo | 1220 | 200 | 6462869
wemos_mini_02_sysinfo | 1223 | 1 | 19359544
wemos_mini_03_sysinfo | 657 | 1 | 1018597
wemos_mini_04_sysinfo | 1078 | 201 | 439668
wemos_mini_05_sysinfo | 650 | 6 | 9194816
wemos_mini_06_sysinfo | 927 | 1 | 955432
wemos_mini_07_sysinfo | 1142 | 1 | 14078412
wemos_mini_08_sysinfo | 730 | 1 | 7848454
wemos_mini_09_sysinfo | 1005 | 1 | 5536489
wemos_mini_10_sysinfo | 550 | 201 | 465734
wemos_mini_11_sysinfo | 662 | 4 | 15658520
wemos_mini_12_sysinfo | 1211 | 1 | 17915701
wemos_mini_13_sysinfo | 1211 | 1 | 17896590
wemos_mini_14_sysinfo | 1210 | 1 | 17882406
wemos_mini_15_sysinfo | 753 | 1 | 58904600
wemos_mini_16_sysinfo | 1197 | 1 | 17210855

ein Neustart von Unit 10 (könnte auch mit Plugins zusammenhängen). alle Geräte mit DHCP- und FHEM-Controller sowie regelmäßige JSON-Status-Updates (Aufruf über HTTPMOD von fhem).
Webserver auf allen läuft noch und ist sehr reaktionsschnell. Nie benutzte statische-IP oder Setup-Seite.

Also für mich scheint dies eine ziemlich stabile Version zu sein.

da ich die nächsten 4 Tage meistens offline bin, schaue ich nächste Woche wie viele noch am Leben sind

Ach, und Grüße an den König! Ich hoffe, er steht auch auf IoT

@clumsy-stefan diese Version? https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability
und welcher kern?
Hast du versucht den Router neu zu starten?

@melwinek git-Commit: d582cab938f041f622f2d4d8016b3d4bada55580 vom esp8266-Master-Zweig (also neuestes Commit für den Master-Zweig von der Kernentwicklung).

@clumsy-stefan core 2.3.0, 2.4.0 oder 2.4.1 ?

neuestes GIT-Commit! (also gehe davon aus, dass es Kern 2.4.1+ ist)

Ich kann dieses Commit nicht finden.
Neueste ist: https://github.com/letscontrolit/ESPEasy/commit/d780f1a07fdcd4eec394a0677866c2a9778eb696
Können Sie einen Link bereitstellen?

@clumsy-stefan Ich verstehe, du hast Git bis ins Mark geschrieben.
Welchen ESPEasy-Commit kompilieren Sie?

ESPEasy Commit f9be283 von https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability branch
esp8266 Commit d582cab von https://github.com/esp8266/Arduino

@TD-er:

@giig1967g
Sie könnten nach der Funktion zum Starten/Stoppen des Webservers suchen und eine Rückgabe hinzufügen; in der ersten Zeile dieser Funktion.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585

Ich denke, es gibt ein Problem beim Aufrufen der Funktion 'gotIP', wenn eine statische IP verwendet wird.
Das ist auch der Grund für die Instabilität beim Ausführen von MQTT + statischer IP.

Hallo, das Problem ist nicht der Webserver, sondern das Gerät, das mit Wifi verbunden zu sein scheint, aber es ist nicht. Kein Ping möglich, kein MQTT senden usw.

Der neueste Github läuft hier perfekt auf Core 2.4.1. Keine Verbindungsprobleme, keine Mitgliederlecks

@mvdbro Verwenden Sie ein esp32- oder ein esp8266-Gerät?

Ich verwende sowohl ESP8266 als auch ESP32. Beides funktioniert gut.

Randnotiz:
Immer statische IP verwenden
Nur Plugins verwenden, die ich benötige (hält RAM auf einem sicheren Minimum. Ich denke, der Standardsatz hat zu viele Plugins geladen)

Toll! :Lächeln:
Ich probiere Core 2.4.1 auch auf meinem esp8266 aus.
Statisch und DHCP funktioniert.
DNSserver und Captive Portal funktionieren.
ntp funktioniert!

@Feuerreiter : hast du versucht, den Router einzuschalten , um zu sehen, ob sich das Gerät wieder verbindet?
In meinem Fall steht im Protokoll, dass die Verbindung wiederhergestellt wurde, dies jedoch nicht der Fall war.

@giig1967g Ich würde es später zu Hause ausprobieren. Ich habe den Test in meinem Auto mit meinem Handy als Hotspot gemacht. ;-)

@mvdbro

Ich denke, der Standardsatz hat zu viele Plugins geladen

Ich stimme zu. Es sollte eine Vorauswahl für Plugins geben, oder vielleicht eine bessere Überprüfung aller Plugins, um nicht mehr Speicher als unbedingt erforderlich zu verwenden, wenn sie nicht verwendet werden.
Und es gibt viel Speicher zu gewinnen, wenn man sich die großen Strukturen genau ansieht, die Informationen über die verfügbaren Plugins enthalten.

[PlatformIO] Aktualisierter Kern auf 2.4.1
1+

Ich denke, das ist eine gute Entscheidung.
Ich habe seit gestern Nachmittag keine Probleme mehr.

Wie ich in einem anderen Thread geschrieben habe:
Für diejenigen, die ein wenig Hilfe beim Erstellen benötigen, habe ich gerade eine Version des Patches erstellt, die ich vor 2 Tagen geschrieben habe, aber jetzt mit Kern 2.4.1:
TD-er_wifi_stability_core-2.4.1

Der Speicher bleibt ziemlich konstant.
Es sinkt in den ersten 15 Minuten ein wenig.
(Sie sind hier nicht zu sehen)
19:05:33 ESP-206/SYSHEAP 11536
19:08:34 ESP-206/SYSHEAP 11536
19:11:36 ESP-206/SYSHEAP 11536
19:14:37 ESP-206/SYSHEAP 11536
19:17:40 ESP-206/SYSHEAP 11536
19:20:42 ESP-206/SYSHEAP 11536
19:23:45 ESP-206/SYSHEAP 11536
19:26:47 ESP-206/SYSHEAP 11536
19:29:50 ESP-206/SYSHEAP 11536
19:32:52 ESP-206/SYSHEAP 11536
19:35:54 ESP-206/SYSHEAP 11536
19:38:57 ESP-206/SYSHEAP 11536
19:41:59 ESP-206/SYSHEAP 11536
19:45:01 ESP-206/SYSHEAP 11536
19:48:04 ESP-206/SYSHEAP 11536
19:51:06 ESP-206/SYSHEAP 11536
19:54:09 ESP-206/SYSHEAP 11536
19:57:11 ESP-206/SYSHEAP 11536
20:00:13 ESP-206/SYSHEAP 11536
20:03:16 ESP-206/SYSHEAP 11536
20:06:17 ESP-206/SYSHEAP 11536
20:09:29 ESP-206/SYSHEAP 11656
20:12:19 ESP-206/SYSHEAP 11592
20:15:21 ESP-206/SYSHEAP 11592
20:18:23 ESP-206/SYSHEAP 11592
20:21:24 ESP-206/SYSHEAP 11592
20:24:25 ESP-206/SYSHEAP 13192
20:27:27 ESP-206/SYSHEAP 11592
20:30:30 ESP-206/SYSHEAP 11592
20:33:31 ESP-206/SYSHEAP 11592
20:36:34 ESP-206/SYSHEAP 11592
20:39:36 ESP-206/SYSHEAP 11592
20:42:39 ESP-206/SYSHEAP 11592
20:45:40 ESP-206/SYSHEAP 11592
20:48:43 ESP-206/SYSHEAP 11592
20:51:45 ESP-206/SYSHEAP 11592
20:54:48 ESP-206/SYSHEAP 11592
20:57:50 ESP-206/SYSHEAP 11592
21:00:52 ESP-206/SYSHEAP 11592
21:03:54 ESP-206/SYSHEAP 11592
21:06:56 ESP-206/SYSHEAP 11424
21:09:58 ESP-206/SYSHEAP 13024
21:13:01 ESP-206/SYSHEAP 11424
21:16:03 ESP-206/SYSHEAP 13024
21:19:06 ESP-206/SYSHEAP 11424
21:22:08 ESP-206/SYSHEAP 11448
21:25:10 ESP-206/SYSHEAP 11424
21:28:13 ESP-206/SYSHEAP 11424
21:31:15 ESP-206/SYSHEAP 11424
21:34:18 ESP-206/SYSHEAP 11424
21:37:20 ESP-206/SYSHEAP 11424
21:40:22 ESP-206/SYSHEAP 11424
21:43:24 ESP-206/SYSHEAP 11424
21:46:27 ESP-206/SYSHEAP 11424
21:49:28 ESP-206/SYSHEAP 13024
21:52:31 ESP-206/SYSHEAP 11424
21:55:33 ESP-206/SYSHEAP 11424
21:58:36 ESP-206/SYSHEAP 11424
22:01:38 ESP-206/SYSHEAP 11424

Mittlerweile laufen seit gestern Mittag 8 Geräte.
Keiner von ihnen blieb hängen.

Einer war für ca. 15 Minuten nicht erreichbar - plötzlich war er wieder im Netz.
Insgesamt ein erfreuliches Ergebnis.

Sehr gut zu hören.
Hoffen wir, dass @Oxyandy auch ähnliche positive Ergebnisse mit dem neuesten Build teilen kann, den ich geteilt habe.
Seine Knoten waren die kritischsten bei der Verwendung von 2.4.x

@TD-er Morgen, habe endlich diesen Beitrag gefunden, nachdem ich mich aufgeholt habe
0403 mit 2.4.1 lief die ganze Nacht super.
Jetzt blinkt von Ihrem neuesten rar normal 1024 8266
verbindet beim ersten Versuch, aktualisiert die Zeit sofort, keine WLAN-Fehler (bisher) & bleibt verbunden (bisher),
Webserver antwortet jedes Mal..
Brauche noch ein bisschen Zeit zum Testen, aber sieht gut aus

Das ist gut zu hören :)

Ich werde mir das von @giig1967g gemeldete NTP-Problem
Lass uns auf das Beste hoffen.

Es wäre wirklich toll, wenn wir das WLAN so lassen könnten, wie es ist und mit dem Rest fortfahren könnten.

Ich hoffe, Sie könnten ein paar Dinge verfeinern, zu denen ich Feedback gebe, sobald sich die Dinge wieder als stabil zeigen.
Ich werde ein paar spezifische Tests mit Ihrer wifi_stability_core-2.4.1-Quelle von Github versuchen
& vielleicht Korrekturen gegen meine langjährigen Probleme, wenn sich die Quelle nicht so radikal geändert hat

Wenn Sie einige Fixes haben, teilen Sie diese bitte mit.

@giig1967g Ich habe die Tests machen lassen. Sehr kurze Verbindungsabbrüche sind kein Problem. AP aus und sofort an. Mein mcunode verbindet sich, wenn der AP wieder da ist. Mein PC hat sich bereits mit einem anderen AP verbunden.

Habe auch gerade mit dem Testen mit D1-Mini und BME280 begonnen

ESPEasy: begehen 2abec2b0bb74018ea76203886f683761796091a2
Zusammenführen: 16d3a9f 29f89b6
Autor: Susis Strolch [email protected]
Datum: Sa. 28. April 10:26:14 2018 +0200

Merge remote-tracking branch 'upstream/mega' into mega

* upstream/mega:
  automaticly updated release notes for mega-20180428

Kern: Commit 41a64707f149d01ace37c903f448d5e3f1cee5d8
Autor: Marcel Stör [email protected]
Datum: Do 26. Apr 01:46:17 2018 +0200

Fix WiFi status formatting issue (bullet list) (#4671)

Benutzerdefiniert.h:
`#warning " ** Einstellungen aus Custom.h-Datei verwenden * "

falls definiert (ESP8266)

// Arduino OTA-Update aktivieren.
// Hinweis: Dies fügt der Firmware-Größe etwa 10 kb und 1 kb zusätzlichem RAM hinzu.
// #define FEATURE_ARDUINO_OTA

// mDNS-Modus aktivieren (fügt ungefähr 6 KB RAM und einige Bytes IRAM hinzu)
// #define FEATURE_MDNS

endif

undef PLUGIN_BUILD_NORMAL

undef PLUGIN_BUILD_TESTING

undef PLUGIN_BUILD_DEV

PLUGIN_BUILD_CUSTOM definieren

undef BUILD_UPLOADER

falls definiert(BUILD_UPLOADER)

#warning "**** Building ESP8285 Uploader image ***"

anders

// Definiere unsere eigenen Plugins
#define USES_P001 // Schalter
#define USES_P002 // ADC
#define USES_P004 // Dallas
#define USES_P005 // DHT
#define USES_P013 // HCSR04
#define USES_P026 // SysInfo
#define USES_P028 // BME280
#define USES_P033 // Dummy

#define USES_C008   // Generic HTTP
#define USES_C009   // FHEM HTTP
#define USES_C013   // ESPEasy P2P network

endif

undef BUILD_GIT

definiere BUILD_GIT "2abec2b"`

Anscheinend gibt es einige Probleme mit NTP:
`
INIT : Boot-Version: 2abec2b (ESP82xx Core 41a64707)

80 : INIT : Warmstart #2

81 : FS : Montage...

106 : FS : Mount erfolgreich, verwendet 76053 Byte von 957314

115 : CRC : Keine Prüfsumme des Programmspeichers gefunden. Überprüfen Sie die Ausgabe von crc2.py

144 : CRC : Sicherheitseinstellungen CRC ...OK

227: INIT: Freier RAM:32208

227 : INIT : I2C

227 : INIT : SPI nicht aktiviert

232 : INFO : Plugins: 8 (ESP82xx Core 41a64707)

233 : EREIGNIS: System#Wake

241 : WIFI : WLAN auf STA setzen
242 : WIFI : Verbindungsversuch mit SusiconStrolch #0
355 : EREIGNIS: System#Boot
364 : WD : Betriebszeit 0 Verbindungsfehler 0 FreeMem 31504
3987 : BMx280 : BME280 . erkannt
5575 : BME280: Taupunkt 8,03C
5576 : BME280 : Adresse: 0x76
5576: BME280: Temperatur: 18,49
5576: BME280: Luftfeuchtigkeit: 50,75
5576: BME280: Luftdruck: 1010,58
5583: EREIGNIS: BMx280#Temperatur=18.49
5592: EREIGNIS: BMx280#Feuchte=50.75
5597: EREIGNIS: BMx280#Druck=1010.58
5853 : Aktuelle Zeitzone: DST-Zeitstart: 2018-03-25 02:00:00 Offset: 120 minSTD-Zeitstart: 2018-10-28 03:00:00 Offset: 60 min
5853 : EREIGNIS: Zeit#Initialisiert
5862 : EREIGNIS: Clock#Time=Sa,10:52
5866 : ACT : Aufgabenwertsatz 12,1,0
5872 : ACT : Aufgabenwertesatz 12,2,-58
5877 : ACT : Aufgabenwertesatz 12,3,29912
5883 : ACT : Aufgabenwertesatz 12,4,39164
5888 : WIFI : Verbunden! AP: SusiconStrolch (38:10:D5:B2:22:1E) Ch: 13 Dauer: 3783 ms
5888 : EREIGNIS: WiFi#ChangedAccesspoint
5894 : WIFI : DHCP IP: 192.168.254.71 (D1pro-01-11) GW: 192.168.254.1 SN: 255.255.255.0 Dauer: 17 ms
5913 : Aktuelle Zeitzone: DST-Zeitstart: 2036-03-30 02:00:00 Offset: 120 minSTD-Zeitstart: 2036-10-26 03:00:00 Offset: 60 min
5914 : EREIGNIS: Zeit#Set
5921 : EREIGNIS: WLAN#Verbunden
5928 : Webserver: starten
5935 : EREIGNIS: Clock#Time=Do,07:28
`
5853 : Aktuelle Zeitzone: DST Zeitbeginn: 2018-03-25 02:00:00
5913 : Aktuelle Zeitzone: DST-Zeitstart: 2036-03-30 02:00:00 Offset: 120 minSTD-Zeitstart:

Das ist ein bekannter -1 Fehlercode und immer noch in einen Zeitfehler umgewandelt.

Hmm, ich frage mich immer noch, wie der Anruf bei NTP zu einer -1 führen kann.

@susisstrolch
Welche Version ist das? ESPeasy verwendet den BUILD_GIT-Wert, um zu bestimmen, was in den Einstellungsdateien und möglicherweise auch in anderen Dateien gepatcht werden soll. Es ist eine Art interne Version, die verwendet wird, um die benötigten Patches zu bestimmen. (wenn überhaupt)
Wenn Sie diesen Wert ändern, kann dies zu seltsamen Dingen führen.

Ich vermute, es hängt mit UDP zusammen. Ich sehe keines meiner anderen Geräte. Und umgekehrt.

@susisstrolch Das ist mit statischer IP oder mit DHCP?

@TD-er-Patching basierend auf BUILD_GIT ist eine schlechte Idee, da es sich auf Forks, Branches und lokale Commits ändert.
Es sollte einen anderen Typ/eine andere Variable geben - kann BUILD_FEATURE sein - die ein solches Verhalten steuert.

Da ich meinen AP fast nie neu starte, blieb es unbemerkt, dass eine erneute Verbindung mit der neuesten Github-Quelle (20180428) fehlschlägt. Ich habe versucht, einen internen Status abzurufen, um zu sehen, was los ist:

Nach dem Booten:
Aufruf an Wifi.status() : 3 bedeutet WL_CONNECTED
Variable wifiStatus: 3 bedeutet ESPEASY_WIFI_SERVICES_INITIALIZED

Nach dem Neustart des AP
Aufruf an Wifi.status() : 3 bedeutet WL_CONNECTED
Variable wifiStatus: 0 bedeutet ESPEASY_WIFI_DISCONNECTED

dies ändert sich im Laufe der Zeit nicht und das ESP verbindet sich nie wieder

Ich frage mich nur, warum der Wifi.status()-Aufruf an Core immer noch einen Status 3 (WL_CONNECTED) meldet.
Liegt das daran, dass das ereignisbasierte WLAN den internen Core-Status stört?

Das Verhalten ist auf Kern 2_3_0 und 2_4_1 gleich

Das ist mit DHCP

Und ich würde nach dem normalen Neustart erwarten:

Aufruf an Wifi.status() : 3 bedeutet WL_CONNECTED
Variable wifiStatus : 1 bedeutet ESPEASY_WIFI_CONNECTED

anstatt:
Aufruf an Wifi.status() : 3 bedeutet WL_CONNECTED
Variable wifiStatus: 3 bedeutet ESPEASY_WIFI_SERVICES_INITIALIZED

Hmm, das ist eine gute Frage @mvdbro
Vielleicht wird der Status WL_CONNECTED nie aktualisiert, weil er die Funktion zum Aktualisieren dieses Status nicht aufruft.
Nur aus dem Gedächtnis würde ich sagen, dass die Funktion in der Kernbibliothek aufgerufen wird, wenn das Ereignis "got IP" verarbeitet wird.
Ich werde mir diesen Bereich des Kernbibliothekscodes ansehen.
Danke fürs bemerken.

@susisstrolch OK, ich werde es hier auch mit DHCP versuchen.
Meine Testgeräte können sich über die interne ESPeasy UDP-Kommunikation sehen, laufen aber derzeit auf statischer IP, da dies in letzter Zeit die meisten Probleme gab.

@TD-er Hold on - prüft, ob es sich um ein kernbezogenes Problem handelt.

@mvdbro
Hier ist der Code:
https://github.com/esp8266/Arduino/blob/836c7da8cc1ad11a66e0be1f30d35a92b5317bcc/libraries/ESP8266WiFi/src/ESP8266WiFiSTA.cpp#L497 -L513

Solange der interne Status nicht auf 'got IP' gesetzt ist, wird WL_CONNECTED nicht zurückgegeben.

Über den Unterschied der Variablennamen zwischen den Enum/Defines in ESPeasy und der Core-Bibliothek.
Die Zustände der Kernbibliothek spiegeln nicht wirklich den wahren Zustand wider, da Sie verbunden sein können und keine IP haben.

Vielleicht ist es besser, diesen Thread nur für WLAN-Verbindungs-/Wiederverbindungsprobleme zu behalten, damit dies überhaupt behoben werden kann.

Ich denke, dies sind die effektiv verwendeten Codes:

Wifi.status()-Codes:
WL_IDLE_STATUS 0
WL_NO_SSID_AVAIL 1
WL_SCAN_COMPLETED 2
WL_VERBUNDEN 3
WL_CONNECT_FAILED 4
WL_CONNECTION_LOST 5
WL_DISCONNECTED 6

wifiStatuscodes:
ESPEASY_WIFI_DISCONNECTED 0
ESPEASY_WIFI_CONNECTED 1
ESPEASY_WIFI_GOT_IP 2
ESPEASY_WIFI_SERVICES_INITIALIZED 3

Ich vermute, dass es sehr gut mit dem Problem der WLAN-Verbindung/Wiederverbindung zusammenhängen kann.
Bei statischer IP gibt es einfach kein Ereignis für "got IP", daher kann die aktuelle Verarbeitung unvollständig sein, was einige dieser Probleme verursacht.

Also nach dem Neustart des AP
Aufruf an Wifi.status() : 3 bedeutet WL_CONNECTED
Das ist nicht richtig.

Wenn Wifi.status() nicht wie erwartet funktioniert, wäre dies ein schwerwiegender Fehler im Arduino-Kern. Sollte dies nicht auf ihrem Github Issue Tracker gemeldet werden?

@susisstrolch Habe gerade das gleiche erlebt. Ein bekanntermaßen funktionierendes und fertig konfiguriertes Gerät wurde aktualisiert. Habe keine anderen Einheiten entdeckt.

Lösung: Überprüfen Sie den UDP-Port-Eintrag. (65500) Meins war gerade weg. Noch ein Neustart und es funktionierte.
Wir sollten uns wirklich für die JSON-basierte Konfiguration entscheiden !!!

@mvdbro Das habe ich gerade gefunden, siehe oben auf Seite 39:
https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf
Ich werde jetzt testen, ob wir die IP-Konfiguration (wieder) nach der Verarbeitung des Connect-Ereignisses setzen müssen.

Kann jemand den Code in dieser PR testen: https://github.com/letscontrolit/ESPEasy/pull/1328

@s0170071 - bestätigt - Einstellung des UDP-Ports geändert.

@TD-er über #1328:

INIT : Booting version: 62e6317 (ESP82xx Core 41a64707)
75 : INIT : Warm boot #1
76 : FS   : Mounting...
101 : FS   : Mount successful, used 76053 bytes of 957314
111 : CRC  : No program memory checksum found. Check output of crc2.py
142 : CRC  : SecuritySettings CRC   ...OK 
248 : INIT : Free RAM:31624
248 : INIT : I2C
248 : INIT : SPI not enabled
253 : INFO : Plugins: 8 (ESP82xx Core 41a64707)
254 : EVENT: System#Wake
261 : WIFI : Set WiFi to STA
        mode : sta(5c:cf:7f:f1:bb:e1)
        add if0
264 : WIFI : Connecting SusiconStrolch attempt #0
267 : OTA  : Arduino OTA enabled on port 8266
379 : EVENT: System#Boot
390 : WD   : Uptime 0 ConnectFailures 0 FreeMem 30112
        scandone
        state: 0 -> 2 (b0)
4014 : BMx280 : Detected BME280
        state: 2 -> 3 (0)
        state: 3 -> 5 (10)
        add 0
        aid 3
        cnt 
        connected with SusiconStrolch, channel 13
        dhcp client start...
        ip:192.168.254.71,mask:255.255.255.0,gw:192.168.254.1
5602 : BME280: dew point 8.12C
5603 : BME280 : Address: 0x76
5603 : BME280 : Temperature: 20.25
5603 : BME280 : Humidity: 45.75
5603 : BME280 : Barometric Pressure: 1010.14
5611 : EVENT: BMx280#Temperature=20.25
5620 : EVENT: BMx280#Humidity=45.75
5626 : EVENT: BMx280#Pressure=1010.14
5884 : Current Time Zone:  DST time start: 2018-03-25 02:00:00 offset: 120 minSTD time start: 2018-10-28 03:00:00 offset: 60 min
5884 : EVENT: Time#Initialized
5893 : EVENT: Clock#Time=Sat,16:10
5898 : ACT  : taskvalueset 12,1,0
5903 : ACT  : taskvalueset 12,2,-60
5908 : ACT  : taskvalueset 12,3,28376
5914 : ACT  : taskvalueset 12,4,58217
5921 : WIFI : Connected! AP: SusiconStrolch (38:10:D5:B2:22:1E) Ch: 13 Duration: 3788 ms
5921 : EVENT: WiFi#ChangedAccesspoint
5927 : IP   : Static IP : 192.168.254.71 GW: 192.168.254.1 SN: 255.255.255.0 DNS: 192.168.254.1
        STUB: dhcp_stop
5932 : WIFI : Static IP: 192.168.254.71 (D1pro-01-11) GW: 192.168.254.1 SN: 255.255.255.0   duration: 1879 ms
5957 : Current Time Zone:  DST time start: 2036-03-30 02:00:00 offset: 120 minSTD time start: 2036-10-26 03:00:00 offset: 60 min
5957 : EVENT: Time#Set
5964 : EVENT: WiFi#Connected
5971 : Webserver: start
5979 : EVENT: Clock#Time=Thu,07:28
5989 : ACT  : taskvalueset 12,1,0
5999 : ACT  : taskvalueset 12,2,-59
6006 : ACT  : taskvalueset 12,3,26040
6014 : ACT  : taskvalueset 12,4,26896
6019 : EVENT: Clock#Time=Thu,07:28 Processing time:40 milliSeconds
        ping 1, timeout 0, total payload 32 bytes, 1064 ms
        ping 1, timeout 0, total payload 32 bytes, 1065 ms
7269 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
8088 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
8396 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
11998 : Dummy: value 1: 0.00
12000 : Dummy: value 2: -59.00
12000 : Dummy: value 3: 26040.00
12001 : Dummy: value 4: 26896.00
12006 : EVENT: sysinfo#uptime=0.00
12015 : EVENT: sysinfo#uptime=0.00 Processing time:9 milliSeconds
12016 : EVENT: sysinfo#RSSI=-59.00
12025 : EVENT: sysinfo#RSSI=-59.00 Processing time:8 milliSeconds
12025 : EVENT: sysinfo#sysheap=26040.00
12034 : EVENT: sysinfo#sysheap=26040.00 Processing time:9 milliSeconds
12034 : EVENT: sysinfo#syssec_d=26896.00
12043 : EVENT: sysinfo#syssec_d=26896.00 Processing time:9 milliSeconds
12068 : HTTP : connecting to 192.168.254.27:8383
12275 : HTTP : closing connection
        pm open,type:2 0
14437 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
18430 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
18533 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
25189 : UDP  : 60:01:94:83:B1:70,192.168.254.80,10
30390 : WD   : Uptime 1 ConnectFailures 0 FreeMem 24816
30391 : UDP  : Send Sysinfo message
34917 : UDP  : 5C:CF:7F:9E:CC:3D,192.168.254.98,8
37273 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
38092 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
38501 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
44441 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
48436 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
48641 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
49979 : EVENT: Clock#Time=Thu,07:29
49987 : ACT  : taskvalueset 12,1,1
49994 : ACT  : taskvalueset 12,2,-57
50001 : ACT  : taskvalueset 12,3,25544
50009 : ACT  : taskvalueset 12,4,26940
50014 : EVENT: Clock#Time=Thu,07:29 Processing time:35 milliSeconds
55193 : UDP  : 60:01:94:83:B1:70,192.168.254.80,10
60390 : WD   : Uptime 1 ConnectFailures 0 FreeMem 24816
60392 : UDP  : Send Sysinfo message
64922 : UDP  : 5C:CF:7F:9E:CC:3D,192.168.254.98,8
66569 : BME280: dew point 8.10C
66571 : BME280 : Address: 0x76
66572 : BME280 : Temperature: 20.28
66572 : BME280 : Humidity: 45.58
66573 : BME280 : Barometric Pressure: 1010.10
66576 : EVENT: BMx280#Temperature=20.28
66587 : EVENT: BMx280#Temperature=20.28 Processing time:11 milliSeconds
66588 : EVENT: BMx280#Humidity=45.58
66594 : EVENT: BMx280#Humidity=45.58 Processing time:6 milliSeconds
66595 : EVENT: BMx280#Pressure=1010.10
66602 : EVENT: BMx280#Pressure=1010.10 Processing time:7 milliSeconds
66627 : HTTP : connecting to 192.168.254.27:8383
66833 : HTTP : closing connection
67277 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
68096 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
68403 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
72860 : Dummy: value 1: 1.00
72861 : Dummy: value 2: -57.00
72862 : Dummy: value 3: 25544.00
72863 : Dummy: value 4: 26940.00
72865 : EVENT: sysinfo#uptime=1.00
72872 : EVENT: sysinfo#uptime=1.00 Processing time:7 milliSeconds
72872 : EVENT: sysinfo#RSSI=-57.00
72878 : EVENT: sysinfo#RSSI=-57.00 Processing time:6 milliSeconds
72879 : EVENT: sysinfo#sysheap=25544.00
72887 : EVENT: sysinfo#sysheap=25544.00 Processing time:8 milliSeconds
72888 : EVENT: sysinfo#syssec_d=26940.00
72897 : EVENT: sysinfo#syssec_d=26940.00 Processing time:9 milliSeconds
72924 : HTTP : connecting to 192.168.254.27:8383
73129 : HTTP : closing connection
74446 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
78747 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
78950 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
85197 : UDP  : 60:01:94:83:B1:70,192.168.254.80,10
90390 : WD   : Uptime 2 ConnectFailures 0 FreeMem 24816
90391 : UDP  : Send Sysinfo message
94925 : UDP  : 5C:CF:7F:9E:CC:3D,192.168.254.98,8
97280 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
98101 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
98407 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
104448 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
108852 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
108954 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
110842 : EVENT: Clock#Time=Thu,07:30
110849 : ACT  : taskvalueset 12,1,2
110856 : ACT  : taskvalueset 12,2,-54
110864 : ACT  : taskvalueset 12,3,24504
110871 : ACT  : taskvalueset 12,4,27000
110876 : EVENT: Clock#Time=Thu,07:30 Processing time:34 milliSeconds

Wie Sie sehen, wird DHCP auch bei statischer IP gestartet...

Und hier ist mein JSON

{"System":{
"Build":20102,
"Git Build":"62e6317",
"Local time":"2036-02-07 07:33:33",
"Unit":11,
"Name":"D1pro-01",
"Uptime":5,
"Load":1,
"Load LC":10747,
"Free RAM":25280
},
"WiFi":{
"Hostname":"D1pro-01-11",
"IP":"192.168.254.71",
"Subnet Mask":"255.255.255.0",
"Gateway IP":"192.168.254.1",
"MAC address":"5C:CF:7F:F1:BB:E1",
"DNS 1":"192.168.254.1",
"DNS 2":"0.0.0.0",
"SSID":"SusiconStrolch",
"BSSID":"38:10:D5:B2:22:1E",
"Channel":13,
"Connected msec":319382,
"Last Disconnect Reason":1,
"Last Disconnect Reason str":"(1) Unspecified",
"RSSI":-59
},
"Sensors":[
{
"TaskNumber":4,
"Type":"Environment - BMx280",
"TaskName":"BMx280",
"TaskValues": [
{"ValueNumber":1,
"Name":"Temperature",
"Value":20.31},
{"ValueNumber":2,
"Name":"Humidity",
"Value":44.70},
{"ValueNumber":3,
"Name":"Pressure",
"Value":1010.10}]
},
{
"TaskNumber":12,
"Type":"Generic - Dummy Device",
"TaskName":"sysinfo",
"TaskValues": [
{"ValueNumber":1,
"Name":"uptime",
"Value":5},
{"ValueNumber":2,
"Name":"RSSI",
"Value":-60},
{"ValueNumber":3,
"Name":"sysheap",
"Value":25464},
{"ValueNumber":4,
"Name":"syssec_d",
"Value":27180}]
}
]
}

99 : CRC : Keine Prüfsumme des Programmspeichers gefunden. Überprüfen Sie die Ausgabe von crc2.py
130 : CRC : Sicherheitseinstellungen CRC ...OK
211 : INIT : Freier RAM: 21016
211 : INIT : I2C
211 : INIT : SPI nicht aktiviert
1042 : INFO : Plugins: 71 [Normal] [Testing] (ESP82xx Core 2_4_1)
1042 : EREIGNIS: System#Wake
1089 : WIFI : WLAN auf STA setzen
1091 : WIFI : SMC-Verbindungsversuch #0
1103 : EREIGNIS: System#Boot
1111: ACT: ESP-201/IP,0.0.0.0 . veröffentlichen
1124 : ACT : TimerSet,1,60
1152 : WD : Betriebszeit 0 Verbindungsfehler 0 FreeMem 20160
1183 : DS : Temperatur: 20,37 (28-ff-b8-ea-b4-16-3-ed)
1184: EREIGNIS: DS18b20#Temperatur=20,37
4887 : WIFI : Verbunden! AP: SMC (78:8A:20:D1:9B:D9) Ch: 1 Dauer: 3795 ms
4888 : EREIGNIS: WiFi#ChangedAccesspoint
4910 : IP : Statische IP : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4911 : WIFI : Statische IP: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 Dauer: 25 ms
5009 : Aktuelle Zeitzone: DST-Zeitstart: 2018-03-25 02:00:00 Offset: 120 minSTD-Zeitstart: 2018-10-28 03:00:00 Offset: 60 min
5010 : EREIGNIS: Zeit#Initialisiert
5027: EREIGNIS: WLAN#Verbunden
5044 : Webserver: starten
5127 : MQTT : Beabsichtigte erneute Verbindung
5182 : MQTT : Mit dem Broker verbunden mit der Client-ID: ESPClient_5C:CF:7F:0B:68:52
5184 : Abonniert: ESP-201/#
5185 : EREIGNIS: MQTT#Verbunden
5846 : EREIGNIS: Clock#Time=Sa,16:19

@susisstrolch Das ist seltsam beim Starten von DHCP, da ich kürzlich einen Patch dafür geschrieben habe.
Vielleicht hat sich in 2.4.1 etwas geändert?

Was haben Sie getan, um die zusätzlichen Debug-Informationen zu erhalten?

Ich habe einfach den Debug-Level auf „Debug more“ gesetzt...

@susisstrolch Sie scheinen auch andere Debug-Ausgaben von der
Ich sehe das nicht in meinem Log auf der seriellen Schnittstelle.

Bearbeiten:
Gefunden, wird Serial.setDebugOutput von Setup() aufgerufen. Ein einfacher Neustart hat also gereicht :)

Hier ist ein Zusammenspiel von SYSHEAP und Uptime.

Ich bin gespannt, wie dieses Sysheap-Diagramm nach ein oder zwei Tagen aussehen wird.

Wenn er nicht versagt, werden wir es sehen. :)

Die Diagramme sehen alle anders aus: Dies ist das Gerät mit Ihrer letzten Änderung und einer statischen IP.

Welche Version war das vorherige Diagramm?

Die erste Grafik, die Sonderversion von dir von gestern Abend. Mit DHCP

Interessant.
Ich werde meinen Knoten auch einige Sysheap-Protokollierung hinzufügen.

Ich logge mich mit openHAB ein. Es ist auch großartig mit Grafana.

Soll ich deine aktuellen Commits flashen? Dann ist mein Diagramm auf dem ESP-201 verloren.

Ich denke, WLAN-Stabilitätstests sind im Moment wichtiger.

OK mach ich.

Okay, ist online.

INIT : Boot-Version: (ESP82xx Core 2_4_1)
92 : INIT : Warmstart #2
94 : FS : Montage...
118 : FS : Mount erfolgreich, verwendet 76806 Byte von 957314
131 : CRC : Keine Prüfsumme des Programmspeichers gefunden. Überprüfen Sie die Ausgabe von crc2.py
162 : CRC : Sicherheitseinstellungen CRC ...OK
243 : INIT : Freier RAM: 20984
243 : INIT : I2C
243 : INIT : SPI nicht aktiviert
1073 : INFO : Plugins: 71 [Normal] [Testing] (ESP82xx Core 2_4_1)
1073 : EREIGNIS: System#Wake
1120 : WIFI : WLAN auf STA setzen
1152 : WIFI : SMC-Verbindungsversuch #0
1153 : IP : Statische IP : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
1155: WIFI: SDK-Stationsstatus unterscheidet sich vom Arduino-Status. SDK-Status: 1 Arduino-Status: 6
1172 : EREIGNIS: System#Boot
1178 : ACT : NeoPixelAlle,0,0,0,0
1189: ACT: ESP-201/IP veröffentlichen,192.168.0.201
1201 : ACT : TimerSet,1,60
1226 : WD : Betriebszeit 0 Verbindungsfehler 0 FreeMem 20088
1257 : DS : Temperatur: 20,25 (28-ff-b8-ea-b4-16-3-ed)
1259: EREIGNIS: DS18b20#Temperatur=20,25
4952 : WIFI : Verbunden! AP: SMC (78:8A:20:D1:9B:D9) Ch: 1 Dauer: 3798 ms
4953 : EREIGNIS: WiFi#ChangedAccesspoint
4974 : IP : Statische IP : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4975: WIFI: SDK-Stationsstatus unterscheidet sich vom Arduino-Status. SDK-Status: 5 Arduino-Status: 3
4980 : WIFI : Statische IP: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 Dauer: 24 ms
5102 : Aktuelle Zeitzone: DST-Zeitstart: 2018-03-25 02:00:00 Offset: 120 minSTD-Zeitstart: 2018-10-28 03:00:00 Offset: 60 min
5103 : EREIGNIS: Zeit#Initialisiert
5123 : EREIGNIS: WLAN#Verbunden
5140 : Webserver: starten
5141: WIFI: SDK-Stationsstatus unterscheidet sich vom Arduino-Status. SDK-Status: 5 Arduino-Status: 3
5223 : MQTT : Beabsichtigte erneute Verbindung
5261 : MQTT : Mit dem Broker verbunden mit der Client-ID: ESPClient_5C:CF:7F:0B:68:52
5264 : Abonniert: ESP-201/#
5265 : EREIGNIS: MQTT#Verbunden
5912 : EREIGNIS: Clock#Time=So,00:14
31226 : WD : Betriebszeit 1 Verbindungsfehler 0 FreeMem 15968

Ich habe auch die Informationen auf der Sysinfo-Seite erweitert.
Wiederverbindungszähler hinzugefügt und Static/DHCP-Einstellung verwendet (und die SDK-Version)

Ebenfalls enthalten ist eine erzwungene Überprüfung der erneuten Verbindung, die eine erneute Verbindung herstellt, wenn sie für eine Weile nicht verbunden ist.

Soll ich WIFI für 0,2 Sekunden unterbrechen?

Bitte versuche es zum Absturz zu bringen :)

OK

244302 : ACT : ESP-201/IP veröffentlichen, 192.168.0.201
244318 : ACT : ESP-201/MAC veröffentlichen,5C:CF:7F:0B:68:52
244331 : ACT : ESP-201/Zeit,00:18:18 . veröffentlichen
244343 : ACT : ESP-201/Uptime veröffentlichen,4
244355 : ACT : ESP-201/RSSI,-62 veröffentlichen
244367 : ACT : ESP-201/SSID,SMC veröffentlichen
244379 : ACT : ESP-201/BSSID veröffentlichen,78:8A:20:D1:9B:D9
244391 : ACT : ESP-201/CH,1 . veröffentlichen
244406 : ACT : ESP-201/SYSHEAP veröffentlichen, 12616
244422 : ACT : TimerSet,1,60
255542 : EREIGNIS: WLAN#Getrennt
255560 : WIFI : Getrennt! Grund: '(1) Unspecified' Verbunden für 4 m 10 s
255560: WIFI: SDK-Stationsstatus unterscheidet sich vom Arduino-Status. SDK-Status: 5 Arduino-Status: 3
255571 : MQTT : Verbindung verloren
255572 : EREIGNIS: MQTT#Getrennt
255610 : MQTT : Verbindung zum Broker fehlgeschlagen
256110 : MQTT : Verbindung zum Broker fehlgeschlagen
256860 : MQTT : Verbindung zum Broker fehlgeschlagen
257860 : MQTT : Verbindung zum Broker fehlgeschlagen
259110 : MQTT : Verbindung zum Broker fehlgeschlagen
260610 : MQTT : Verbindung zum Broker fehlgeschlagen
262360 : MQTT : Verbindung zum Broker fehlgeschlagen
264360 : MQTT : Verbindung zum Broker fehlgeschlagen
266360 : MQTT : Verbindung zum Broker fehlgeschlagen
268360 : MQTT : Verbindung zum Broker fehlgeschlagen
270360 : MQTT : Verbindung zum Broker fehlgeschlagen
271226 : WD : Betriebszeit 5 Verbindungsfehler 22 FreeMem 17224
271247 : MQTT : Verbindung zum Broker fehlgeschlagen
272360 : MQTT : Verbindung zum Broker fehlgeschlagen
274360 : MQTT : Verbindung zum Broker fehlgeschlagen
276360 : MQTT : Verbindung zum Broker fehlgeschlagen
278360 : MQTT : Verbindung zum Broker fehlgeschlagen
280360 : MQTT : Verbindung zum Broker fehlgeschlagen
282360 : MQTT : Verbindung zum Broker fehlgeschlagen
284360 : MQTT : Verbindung zum Broker fehlgeschlagen
286291 : EREIGNIS: Clock#Time=So,00:19
286359 : MQTT : Verbindung zum Broker fehlgeschlagen
288360 : MQTT : Verbindung zum Broker fehlgeschlagen
290360 : MQTT : Verbindung zum Broker fehlgeschlagen

Könnten Sie es nur für diese Überprüfung 4 Minuten in diesem Zustand belassen?
Ich werde das Tickerintervall für diese Überprüfung reduzieren (ist derzeit 240 Sek.)

OK mache ich.

240 Sekunden sind sehr lang

Ja ich weiß, ich werde es ändern.
Habe gerade die Idee aus dieser Ausgabe übernommen: https://github.com/esp8266/Arduino/issues/4445

nichts....

432148 : MQTT : Verbindung zum Broker fehlgeschlagen
434148 : MQTT : Verbindung zum Broker fehlgeschlagen
436148 : MQTT : Verbindung zum Broker fehlgeschlagen
438147 : MQTT : Verbindung zum Broker fehlgeschlagen
440148 : MQTT : Verbindung zum Broker fehlgeschlagen
442147 : MQTT : Verbindung zum Broker fehlgeschlagen
444148 : MQTT : Verbindung zum Broker fehlgeschlagen
446148 : MQTT : Verbindung zum Broker fehlgeschlagen
448148 : MQTT : Verbindung zum Broker fehlgeschlagen
450147 : MQTT : Verbindung zum Broker fehlgeschlagen
451222 : WD : Betriebszeit 8 Verbindungsfehler 446 FreeMem 17384
451243 : MQTT : Verbindung zum Broker fehlgeschlagen
452148 : MQTT : Verbindung zum Broker fehlgeschlagen
453907 : EREIGNIS: Clock#Time=So,00:29
454148 : MQTT : Verbindung zum Broker fehlgeschlagen
456148 : MQTT : Verbindung zum Broker fehlgeschlagen
458148 : MQTT : Verbindung zum Broker fehlgeschlagen

Ich gehe schlafen, bis morgen.

habe gerade ein anderes Problem gefunden, möglicherweise im Zusammenhang mit UDP:
Verwenden Sie auf einem einfachen neuen Gerät zum Zurücksetzen auf die Werkseinstellungen die seriellen Befehle
WLAN-Schlüssel
WLAN
speichern

Starten Sie neu, gehen Sie dann zu den erweiterten Einstellungen und überprüfen Sie ssdp. Neustart.
Es geht dann in eine Bootschleife:

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v41a64707
~ld
⸮U87 : 


INIT : Booting version: (custom) (ESP82xx Core 41a64707)
88 : INIT : Warm boot #741
89 : FS   : Mounting...
114 : FS   : Mount successful, used 75802 bytes of 957314
120 : CRC  : No program memory checksum found. Check output of crc2.py
152 : CRC  : SecuritySettings CRC   ...OK 
258 : INIT : Free RAM:27288
258 : INIT : I2C
258 : INIT : SPI not enabled
272 : INFO : Plugins: 49 [Normal] (ESP82xx Core 41a64707)
273 : WIFI : Set WiFi to STA
304 : WIFI : Connecting MNET attempt #0
306 : WIFI  : SDK station status differs from Arduino status. SDK-status: 1 Arduino status: 6
311 : WD   : Uptime 0 ConnectFailures 0 FreeMem 26448

Exception (28):
epc1=0x40208931 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000004 depc=0x00000000

Decoding 14 results
0x40208931: UdpContext::next() at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
0x40249cf8: HardwareSerial::write(unsigned char const*, unsigned int) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/HardwareSerial.cpp line 69
0x4024a055: Print::write(char const*) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/Print.cpp line 220
0x4024a2f1: Print::printNumber(unsigned long, unsigned char) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/Print.cpp line 220
0x4024ac4f: String::changeBuffer(unsigned int) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/WString.cpp line 714
0x40249cf8: HardwareSerial::write(unsigned char const*, unsigned int) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/HardwareSerial.cpp line 69
0x401071a2: millis at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_wiring.c line 183
0x4024a27c: Print::println(char const*) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/Print.cpp line 220
0x40213ece: LogStruct::add(char const*) at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
:  (inlined by) addLog(unsigned char, char const*) at /home/john/Arduino/scetchbooks/ESPEasy/Misc.ino line 1395
0x4023545d: runEach30Seconds() at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
0x4020c678: timeOutReached(unsigned long) at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
0x4023eac5: loop at /home/john/Arduino/scetchbooks/ESPEasy/ESPEasy.ino line 436
0x4024bcc8: loop_wrapper at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_main.cpp line 125
0x40100739: cont_wrapper at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/cont.S line 81

Guten Morgen alle.
Bei mir funktioniert das erneute Verbinden noch nicht.

INIT : Boot-Version: (ESP82xx Core 2_4_1)
92 : INIT : Warmstart #8
94 : FS : Montage...
118 : FS : Mount erfolgreich, verwendet 76806 Byte von 957314
131 : CRC : Keine Prüfsumme des Programmspeichers gefunden. Überprüfen Sie die Ausgabe von crc2.py
162 : CRC : Sicherheitseinstellungen CRC ...OK
243: INIT: Freier RAM:20968
243 : INIT : I2C
243 : INIT : SPI nicht aktiviert
1073 : INFO : Plugins: 71 [Normal] [Testing] (ESP82xx Core 2_4_1)
1074 : EREIGNIS: System#Wake
1121 : WIFI : WLAN auf STA setzen
1153 : WIFI : SMC-Verbindungsversuch #0
1154 : IP : Statische IP : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
1155: WIFI: SDK-Stationsstatus unterscheidet sich vom Arduino-Status. SDK-Status: 1 Arduino-Status: 6
1173 : EREIGNIS: System#Boot
1179 : ACT : NeoPixelAlle,0,0,0,0
1190 : ACT : ESP-201/IP veröffentlichen, 192.168.0.201
1201 : ACT : TimerSet,1,60
1226 : WD : Betriebszeit 0 Verbindungsfehler 0 FreeMem 20072
1258: DS: Temperatur: 19,75 (28-ff-b8-ea-b4-16-3-ed)
1259: EREIGNIS: DS18b20#Temperatur=19.75
4925 : WIFI : Verbunden! AP: SMC (78:8A:20:D1:9B:D9) Ch: 1 Dauer: 3770 ms
4926 : EREIGNIS: WLAN#ChangedAccesspoint
4947 : IP : Statische IP : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4947: WIFI: SDK-Stationsstatus unterscheidet sich vom Arduino-Status. SDK-Status: 5 Arduino-Status: 3
4953 : WIFI : Statische IP: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 Dauer: 23 ms
5066 : Aktuelle Zeitzone: DST-Zeitstart: 2018-03-25 02:00:00 Offset: 120 minSTD-Zeitstart: 2018-10-28 03:00:00 Offset: 60 min
5066 : EREIGNIS: Zeit#Initialisiert
5087 : EREIGNIS: WLAN#Verbunden
5104 : Webserver: starten
5104: WIFI: SDK-Stationsstatus unterscheidet sich vom Arduino-Status. SDK-Status: 5 Arduino-Status: 3
5186 : MQTT : Beabsichtigte erneute Verbindung
5222 : MQTT : Mit dem Broker verbunden mit der Client-ID: ESPClient_5C:CF:7F:0B:68:52
5225 : Abonniert: ESP-201/#
5226 : EREIGNIS: MQTT#Verbunden
5906 : EREIGNIS: Uhr#Zeit=So,10:01
31227 : WD : Betriebszeit 1 Verbindungsfehler 0 FreeMem 16336
47905 : EREIGNIS: Uhr#Zeit=So,10:02
61229 : WD : Betriebszeit 1 Verbindungsfehler 0 FreeMem 16336
61926 : DS : Temperatur: 19,75 (28-ff-b8-ea-b4-16-3-ed)
61928: EREIGNIS: DS18b20#Temperatur=19.75
61972 : EREIGNIS: Regeln#Timer=1
61983 : ACT : ESP-201/IP veröffentlichen, 192.168.0.201
61999 : ACT : ESP-201/MAC veröffentlichen,5C:CF:7F:0B:68:52
62015 : ACT : ESP-201/Zeit, 10:02:14 . veröffentlichen
62030 : ACT : ESP-201/Uptime veröffentlichen,1
62044 : ACT : ESP-201/RSSI veröffentlichen,-62
62060 : ACT : ESP-201/SSID,SMC veröffentlichen
62076 : ACT : ESP-201/BSSID veröffentlichen,78:8A:20:D1:9B:D9
62091 : ACT : ESP-201/CH veröffentlichen,1
62107: ACT: ESP-201/SYSHEAP,13536 . veröffentlichen
62120 : ACT : TimerSet,1,60
67292 : EREIGNIS: WLAN#Getrennt
67310 : WIFI : Getrennt! Grund: '(1) Nicht spezifiziert' Verbunden für 1 m 2 s
67310: WIFI: SDK-Stationsstatus unterscheidet sich vom Arduino-Status. SDK-Status: 5 Arduino-Status: 3
67316 : MQTT : Verbindung verloren
67317 : EREIGNIS: MQTT#Getrennt
67357 : MQTT : Verbindung zum Broker fehlgeschlagen
67856 : MQTT : Verbindung zum Broker fehlgeschlagen
68606 : MQTT : Verbindung zum Broker fehlgeschlagen
69607 : MQTT : Verbindung zum Broker fehlgeschlagen
70857 : MQTT : Verbindung zum Broker fehlgeschlagen
72357 : MQTT : Verbindung zum Broker fehlgeschlagen
74107 : MQTT : Verbindung zum Broker fehlgeschlagen
76106 : MQTT : Verbindung zum Broker fehlgeschlagen
78107 : MQTT : Verbindung zum Broker fehlgeschlagen
80107 : MQTT : Verbindung zum Broker fehlgeschlagen
82106 : MQTT : Verbindung zum Broker fehlgeschlagen
84106 : MQTT : Verbindung zum Broker fehlgeschlagen
86107 : MQTT : Verbindung zum Broker fehlgeschlagen
88106 : MQTT : Verbindung zum Broker fehlgeschlagen
90107 : MQTT : Verbindung zum Broker fehlgeschlagen
91228 : WD : Betriebszeit 2 Verbindungsfehler 30 FreeMem 17368
91250 : MQTT : Verbindung zum Broker fehlgeschlagen
92107 : MQTT : Verbindung zum Broker fehlgeschlagen
94107 : MQTT : Verbindung zum Broker fehlgeschlagen
96106 : MQTT : Verbindung zum Broker fehlgeschlagen
98107 : MQTT : Verbindung zum Broker fehlgeschlagen
100107 : MQTT : Verbindung zum Broker fehlgeschlagen
102107 : MQTT : Verbindung zum Broker fehlgeschlagen
104106 : MQTT : Verbindung zum Broker fehlgeschlagen
106107 : MQTT : Verbindung zum Broker fehlgeschlagen
107905 : EREIGNIS: Uhr#Zeit=So,10:03
108107 : MQTT : Verbindung zum Broker fehlgeschlagen
110107 : MQTT : Verbindung zum Broker fehlgeschlagen
112107 : MQTT : Verbindung zum Broker fehlgeschlagen
114107 : MQTT : Verbindung zum Broker fehlgeschlagen
116107 : MQTT : Verbindung zum Broker fehlgeschlagen
118107 : MQTT : Verbindung zum Broker fehlgeschlagen
120007 : MQTT : Verbindung zum Broker fehlgeschlagen
121228 : WD : Uptime 2 ConnectFailures 62 FreeMem 17368
121249 : MQTT : Verbindung zum Broker fehlgeschlagen
121926 : DS : Temperatur: 19,75 (28-ff-b8-ea-b4-16-3-ed)
121927: EREIGNIS: DS18b20#Temperatur=19.75
122107 : MQTT : Verbindung zum Broker fehlgeschlagen
122905 : EREIGNIS: Regeln#Timer=1
122915: ACT: ESP-201/IP,0.0.0.0 . veröffentlichen
122927 : ACT : ESP-201/MAC veröffentlichen,5C:CF:7F:0B:68:52
122939 : ACT : ESP-201/Zeit, 10:03:15 . veröffentlichen
122950: ACT: ESP-201/Uptime veröffentlichen,2
122961 : ACT : ESP-201/RSSI veröffentlichen,0
122972 : ACT : ESP-201/SSID veröffentlichen,--
122983 : ACT : ESP-201/BSSID veröffentlichen,00:00:00:00:00:00
122994 : ACT : ESP-201/CH,0 . veröffentlichen
123005 : ACT : ESP-201/SYSHEAP veröffentlichen,16992
123015 : ACT : TimerSet,1,60
124107 : MQTT : Verbindung zum Broker fehlgeschlagen
126106 : MQTT : Verbindung zum Broker fehlgeschlagen
128107 : MQTT : Verbindung zum Broker fehlgeschlagen
130107 : MQTT : Verbindung zum Broker fehlgeschlagen
132107 : MQTT : Verbindung zum Broker fehlgeschlagen
134107 : MQTT : Verbindung zum Broker fehlgeschlagen
136107 : MQTT : Verbindung zum Broker fehlgeschlagen
138107 : MQTT : Verbindung zum Broker fehlgeschlagen
140107 : MQTT : Verbindung zum Broker fehlgeschlagen
142107 : MQTT : Verbindung zum Broker fehlgeschlagen
144107 : MQTT : Verbindung zum Broker fehlgeschlagen
146107 : MQTT : Verbindung zum Broker fehlgeschlagen
148107 : MQTT : Verbindung zum Broker fehlgeschlagen
150107 : MQTT : Verbindung zum Broker fehlgeschlagen
151228 : WD : Uptime 3 Verbindungsfehler 94 FreeMem 17368
151249 : MQTT : Verbindung zum Broker fehlgeschlagen
152107 : MQTT : Verbindung zum Broker fehlgeschlagen
154107 : MQTT : Verbindung zum Broker fehlgeschlagen
156107 : MQTT : Verbindung zum Broker fehlgeschlagen
158107 : MQTT : Verbindung zum Broker fehlgeschlagen
160107 : MQTT : Verbindung zum Broker fehlgeschlagen
162107 : MQTT : Verbindung zum Broker fehlgeschlagen
164107 : MQTT : Verbindung zum Broker fehlgeschlagen
166107 : MQTT : Verbindung zum Broker fehlgeschlagen
167905 : EREIGNIS: Clock#Time=So,10:04
168107 : MQTT : Verbindung zum Broker fehlgeschlagen
170107 : MQTT : Verbindung zum Broker fehlgeschlagen
172107 : MQTT : Verbindung zum Broker fehlgeschlagen
174106 : MQTT : Verbindung zum Broker fehlgeschlagen
176106 : MQTT : Verbindung zum Broker fehlgeschlagen
178107 : MQTT : Verbindung zum Broker fehlgeschlagen
180107 : MQTT : Verbindung zum Broker fehlgeschlagen
181228 : WD : Uptime 3 Verbindungsfehler 126 FreeMem 17368
181250 : MQTT : Verbindung zum Broker fehlgeschlagen
181926 : DS : Temperatur: 19,75 (28-ff-b8-ea-b4-16-3-ed)
181927: EREIGNIS: DS18b20#Temperatur=19.75
182107: MQTT: Verbindung zum Broker fehlgeschlagen
183905 : EREIGNIS: Regeln#Timer=1
183915: ACT: ESP-201/IP,0.0.0.0 . veröffentlichen
183927 : ACT : ESP-201/MAC veröffentlichen,5C:CF:7F:0B:68:52
183938 : ACT : ESP-201/Time, 10:04:16 . veröffentlichen
183950: ACT: ESP-201/Uptime veröffentlichen,3
183961: ACT: ESP-201/RSSI veröffentlichen,0
183972 : ACT : ESP-201/SSID veröffentlichen,--
183983 : ACT : ESP-201/BSSID veröffentlichen,00:00:00:00:00:00
183994 : ACT : ESP-201/CH,0 . veröffentlichen
184005: ACT: ESP-201/SYSHEAP veröffentlichen,16992
184015 : ACT : TimerSet,1,60
184107 : MQTT : Verbindung zum Broker fehlgeschlagen
186106 : MQTT : Verbindung zum Broker fehlgeschlagen
188107 : MQTT : Verbindung zum Broker fehlgeschlagen
190106 : MQTT : Verbindung zum Broker fehlgeschlagen
192107: MQTT: Verbindung zum Broker fehlgeschlagen
194106: MQTT: Verbindung zum Broker fehlgeschlagen
196106: MQTT: Verbindung zum Broker fehlgeschlagen
198106: MQTT: Verbindung zum Broker fehlgeschlagen
200106 : MQTT : Verbindung zum Broker fehlgeschlagen
202106 : MQTT : Verbindung zum Broker fehlgeschlagen
204106 : MQTT : Verbindung zum Broker fehlgeschlagen
206106 : MQTT : Verbindung zum Broker fehlgeschlagen
208106 : MQTT : Verbindung zum Broker fehlgeschlagen
210106 : MQTT : Verbindung zum Broker fehlgeschlagen
211228 : WD : Uptime 4 Verbindungsfehler 158 FreeMem 17368
211249 : MQTT : Verbindung zum Broker fehlgeschlagen
212106 : MQTT : Verbindung zum Broker fehlgeschlagen
214106 : MQTT : Verbindung zum Broker fehlgeschlagen
216106 : MQTT : Verbindung zum Broker fehlgeschlagen
218106 : MQTT : Verbindung zum Broker fehlgeschlagen
220106 : MQTT : Verbindung zum Broker fehlgeschlagen
222106 : MQTT : Verbindung zum Broker fehlgeschlagen
224106 : MQTT : Verbindung zum Broker fehlgeschlagen
226106 : MQTT : Verbindung zum Broker fehlgeschlagen
227905 : EREIGNIS: Clock#Time=So,10:05
228107 : MQTT : Verbindung zum Broker fehlgeschlagen
230107 : MQTT : Verbindung zum Broker fehlgeschlagen
232107 : MQTT : Verbindung zum Broker fehlgeschlagen
234107 : MQTT : Verbindung zum Broker fehlgeschlagen
236106 : MQTT : Verbindung zum Broker fehlgeschlagen
238106 : MQTT : Verbindung zum Broker fehlgeschlagen
240106 : MQTT : Verbindung zum Broker fehlgeschlagen
241228 : WD : Uptime 4 Verbindungsfehler 190 FreeMem 17368
241249 : MQTT : Verbindung zum Broker fehlgeschlagen
241925 : DS : Temperatur: 19,75 (28-ff-b8-ea-b4-16-3-ed)
241927: EREIGNIS: DS18b20#Temperatur=19.75
242107 : MQTT : Verbindung zum Broker fehlgeschlagen
244106 : MQTT : Verbindung zum Broker fehlgeschlagen
244908 : EREIGNIS: Regeln#Timer=1
244918: ACT: ESP-201/IP,0.0.0.0 . veröffentlichen
244930 : ACT : ESP-201/MAC veröffentlichen,5C:CF:7F:0B:68:52
244942 : ACT : ESP-201/Zeit, 10:05:17 . veröffentlichen
244953 : ACT : ESP-201/Uptime veröffentlichen,4
244964 : ACT : ESP-201/RSSI veröffentlichen,0
244975 : ACT : ESP-201/SSID veröffentlichen,--
244986 : ACT : ESP-201/BSSID veröffentlichen,00:00:00:00:00:00
244997 : ACT : ESP-201/CH,0 . veröffentlichen
245008 : ACT : ESP-201/SYSHEAP veröffentlichen,16992
245018 : ACT : TimerSet,1,60
246107 : MQTT : Verbindung zum Broker fehlgeschlagen
248106 : MQTT : Verbindung zum Broker fehlgeschlagen
250106 : MQTT : Verbindung zum Broker fehlgeschlagen
252106 : MQTT : Verbindung zum Broker fehlgeschlagen
254106 : MQTT : Verbindung zum Broker fehlgeschlagen
256106 : MQTT : Verbindung zum Broker fehlgeschlagen
258106 : MQTT : Verbindung zum Broker fehlgeschlagen
260106 : MQTT : Verbindung zum Broker fehlgeschlagen
262106 : MQTT : Verbindung zum Broker fehlgeschlagen
264106 : MQTT : Verbindung zum Broker fehlgeschlagen
266107 : MQTT : Verbindung zum Broker fehlgeschlagen

ESP32 - letzte Änderungen (28-04-2018) MQTT stoppt die Arbeit, NTP stoppt die Arbeit
(Statische IP)

@flexiti
MQTT verliert jede Sekunde die Verbindung, wenn Sie nicht abonnieren und einfach versuchen, zu veröffentlichen.

52898 : MQTT : Connection lost
52925 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
52926 : Subscribed to: 
53176 : MQTT : Connection lost
53203 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
53204 : Subscribed to: 
53498 : MQTT : Connection lost
53527 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
53528 : Subscribed to: 
53778 : MQTT : Connection lost
53806 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
53807 : Subscribed to: 
54058 : MQTT : Connection lost
54086 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54087 : Subscribed to: 
54337 : MQTT : Connection lost
54363 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54364 : Subscribed to: 
54615 : MQTT : Connection lost
54642 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54643 : Subscribed to: 
54894 : MQTT : Connection lost
54921 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54922 : Subscribed to: 
55172 : MQTT : Connection lost
55199 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
55200 : Subscribed to: 
55630 : FILE : Saved config.dat
55692 : FILE : Saved config.dat
55861 : MQTT : Connection lost
55889 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2

Versuchen Sie, etwas in die Abonnementzeile einzugeben, auch wenn Sie es nicht verwenden. Hat bei mir funktioniert.

55630 : FILE : Saved config.dat
55692 : FILE : Saved config.dat
55861 : MQTT : Connection lost
55889 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
55890 : Subscribed to: SMA
60404 : WD   : Uptime 1 ConnectFailures 354 FreeMem 19224
90404 : WD   : Uptime 2 ConnectFailures 353 FreeMem 19224
120404 : WD   : Uptime 2 ConnectFailures 352 FreeMem 19224
150404 : WD   : Uptime 3 ConnectFailures 351 FreeMem 19224
180404 : WD   : Uptime 3 ConnectFailures 350 FreeMem 19224
210404 : WD   : Uptime 4 ConnectFailures 349 FreeMem 19224

@TD-äh
Dieser Thread wird etwas überlastet und es scheint mehrere WLAN- / Stabilitätsprobleme zu geben. Ich schlage vor, alle Ausgaben in eine separate Github-Ausgabe zu verschieben und sie mit einem Schlüsselwort zu versehen, zB
[WIFICORE] ssdp
[WIFICORE] MQTT subscription needed
[WIFICORE] Unit not found - port setting vanished
[WIFICORE] ticker interval

Nur um zu berichten, gerade von mega-20180428 auf mega-20180429 aktualisiert.

In mega-20180428 war das WLAN insgesamt stabil, konnte aber nach einer Trennung nicht wieder verbunden werden.
in mega-20180429 ist das WLAN sehr instabil und ich kann es nicht pingen, ohne viele Lese-Timeouts zu bekommen.

Ich verwende ein Sonoff-Basic, das die Releases mit #define PLUGIN_SET_SONOFF_BASIC selbst kompiliert, um den Bin klein genug für OTA zu machen.
Ich bin mir nicht sicher, ob es hilft, in der Zwischenzeit zu Mega-20180428 zurückzukehren.

@louis-lau Könnten Sie es mit dem neuesten Commit+Merge, das ich gerade gemacht habe, erneut testen?

Dies ist auf dem neuesten Commit

@louis-lau Und das Protokoll vom Knoten selbst?
Wenn es versucht, sich wieder mit einem MQTT-Broker zu verbinden, ist die Antwort langsamer und es gibt derzeit einen Reconnect-Handler im Hintergrund, um die Verbindung wiederherzustellen, wenn viele MQTT-Neuverbindungsfehler auftreten.
Oh, und manchmal ist es am besten, nach einem Flash-Versuch einen Reset des Knotens durchzuführen (keine Einstellungen zurücksetzen, genau wie das Drücken der Reset-Taste). Manchmal ist nach dem Flashen noch etwas übrige Konfiguration auf dem Knoten vorhanden, was zu seltsamen Ergebnissen führen kann.

@louis-lau ein Sonoff-Basic?
ich auch ich liebe 0429, 0428 war schrecklich
Kann ich bitte mehr über Ihre 'Gesamteinstellungen' erfahren?
Und wie selbst kompiliert, ist es mit 2.4.1 Core kompiliert?
Ich habe gerade 0429 Fresh Flash auf einem leeren Knoten getestet und es läuft perfekt.
Mein vorheriger Versuch mit 0429 war ein Update auf einen vorkonfigurierten statischen Satzknoten. auch perfekt
Meine Boards sind vom 5-5-2017 datiert

@oxyandy
2.4.2 Kern????

Das ist alles, was mir relevant erscheint:

04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected
04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: Subscribed to: /sonoff_lavalamp/#
04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:71:68:FB
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set Processing time:46 milliSeconds
04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP replied: 20 mSec
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP host time.google.com (216.239.35.8) queried
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
04-29-2018  15:43:06    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: SW   : GPIO 12 Set to 0
04-29-2018  15:43:06    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected Processing time:1132 milliSeconds
04-29-2018  15:43:06    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: else = false
04-29-2018  15:43:06    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: SW   : GPIO 13 Set PWM to 1023
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: [if 0=0]=true
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,4,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,3,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,2,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,1,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: Subscribed to: /sonoff_lavalamp/#
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:71:68:FB
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set Processing time:47 milliSeconds
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP replied: 20 mSec
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP host time.google.com (216.239.35.8) queried
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
04-29-2018  15:42:53    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: WD   : Uptime 3 ConnectFailures 2 FreeMem 19456
04-29-2018  15:42:53    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: 2: lowest: 12320  parseTemplate3-> 17112 ruleMatch-> 17088 ruleMatch2-> 17040 parseTemplate-> 17176 parseTemplate3-> 17112 ruleMatch-> 17072 ruleMatch2-> 17008 rulesProcessingFile2-> 17160 sendContentBlocking-> 17184 sendConten
04-29-2018  15:42:47    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected Processing time:1131 milliSeconds
04-29-2018  15:42:47    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: else = false
04-29-2018  15:42:47    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: SW   : GPIO 13 Set PWM to 1023
04-29-2018  15:42:46    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: [if 0=0]=true
04-29-2018  15:42:46    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,4,0

@Oxyandy Ich werde es mit einem

Du hast Recht, funktioniert mit den Werkseinstellungen einwandfrei 😄 .

Ich werde versuchen, es wiederherzustellen, sehen, ob es wieder kaputt geht.

Es sieht nur nach einem Neustart aus?

Im Weblog bekommst du etwas mehr Zeilen, da dieses einen Puffer von 15 Zeilen hat.
Auch auf der Sysinfo-Seite erhalten Sie weitere Informationen.

Die aufgezeichneten Protokolle auf dem Syslog-Server sind möglicherweise nicht vollständig, da dieser keine Daten empfängt, wenn das WLAN getrennt wird.

Okay, passierte wieder, als ich den mqtt-Controller aktivierte.
Und hörte auf, als ich es deaktiviert habe.

Ich werde versuchen, ein besseres Protokoll zu erhalten, es ist ein bisschen schwierig, wenn Sie die Hälfte der Zeit keine Verbindung herstellen können.
Welcher Log-Level? debuggen?

MQTT-Verbindungen werden auch auf der Info-Ebene angezeigt.
Info zeigt Fehler + Info an.
Auf diese Weise füllen Sie den Protokollpuffer des Weblogs nicht zu schnell, um angezeigt zu werden.

Okay, wenn ich den mqtt-Server beende, funktioniert er auch normal, nur wenn der Server läuft, läuft die Verbindung ab.

Das ist alles, was ich dem Log entnehmen konnte:

Was ist das für ein MQTT-Controller? Domoticz? OpenHAB?

Oder versuchen Sie importMQTT zu tun?

Auf der Webseite, auf der das Protokoll angezeigt wird, befindet sich auch eine Schaltfläche zum Kopieren.
Diese Seite wird alle N Sekunden aktualisiert, sodass Sie den Text zwischen den Aktualisierungen in einen Texteditor einfügen können.
Es ist nicht perfekt, ich weiß, aber es ist besser als nichts :)

Bearbeiten:
Bitte schauen Sie sich auch die Regeln an, wenn diese vollständig sind.
Es gibt immer noch ein Problem beim Speichern der Regeln. Diese Speicherung ist möglicherweise nicht der komplette eingegebene Regelsatz.

Mit dem neuesten Githib (07bfec42347d13ad49dda907654a36bf747df3bc) verbindet sich Wifi problemlos auf allen meinen Knoten. Verbindet sich jetzt auch nach einem AP-Neustart wieder ordnungsgemäß. Kern verwenden 2.4.1.

Hehe, sobald es tatsächlich geladen ist, habe ich sehr wenig Zeit, also habe ich einfach einen Screenshot gemacht. Ich benutze den Openhab mqtt Controller, der Server ist Mosquitto.

EDIT: Verwenden Sie derzeit keine Regeln. Nur um sicherzustellen, dass das nicht das Problem ist.

Hier gilt das gleiche. Versuchen Sie, ein beliebiges Thema zu abonnieren. Das hat mein Problem behoben.

-------- Ursprüngliche Nachricht --------
Von: Louis Laureys [email protected]
Gesendet: 29. April 2018 16:23:54 MESZ
An: letscontrolit/ESPEasy [email protected]
CC: s0170071 [email protected] , Erwähnung erwä[email protected]
Betreff: Re: [letscontrolit/ESPEasy] WLAN-Probleme - unendliche Geschichte- zurück zu nicht ereignisbasiertem WLAN? (#1302)

Hehe, sobald es tatsächlich geladen ist, habe ich sehr wenig Zeit, also habe ich einfach einen Screenshot gemacht. Ich benutze den Openhab mqtt Controller, der Server ist Mosquitto.

--
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/letscontrolit/ESPEasy/issues/1302#issuecomment -385255207

@s0170071 Wo soll dieses Abonnement erfolgen?
Wenn das in einer Art Standardeinstellung ist, sollten wir das vielleicht hinzufügen.

Beträgt die Zeit zwischen MQTT-Reconnects etwa 15 - 16 Sekunden? Dann könnte es sein, dass Mosquito dich rausschmeißt und dann weiß ich, wo ich das reparieren kann.

In den Openhab-Controller-Einstellungen. Es gibt das Abonnieren-Feld.

Mit dem neuesten Githib (07bfec4) funktioniert MQTT auch hier ohne Probleme mit Openhab-Controller und Verbindung zu Mosquitto. Kern verwenden 2.4.1.

@td-er siehe einige Beiträge oben.

Ich habe /sonoff_lavalamp/# bereits abonniert, wie Sie in den Protokollen sehen können.

Ich habe es bemerkt, als ich # abonniert habe (also alle Themen). Das WLAN ist stabil, aber das macht mqtt unbrauchbar ;)

Mosquitto sollte den Benutzer nicht rausschmeißen, der Benutzer, den ich verwende, hat Berechtigungen für alle Themen.

Dies ist das Mückenprotokoll:

1525014154: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014168: New connection from 192.168.2.22 on port 1883.
1525014168: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014168: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014168: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014196: New connection from 192.168.2.22 on port 1883.
1525014196: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014196: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014196: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014214: New connection from 192.168.2.22 on port 1883.
1525014214: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014214: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014214: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014226: New connection from 192.168.2.22 on port 1883.
1525014226: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014226: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014226: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014255: New connection from 192.168.2.22 on port 1883.
1525014255: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014255: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014255: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014270: New connection from 192.168.2.22 on port 1883.

Es scheint sich wieder zu verbinden und Mosquitto schließt die alte Verbindung.

Ich habe nach der Quelle von PubSubClient gesucht.
Es scheint, dass innerhalb des Timeout-Zeitraums eingehende und ausgehende Aktivitäten vorhanden sein müssen.
Wenn einer von ihnen fehlschlägt, trennt PubSubClient die Verbindung und ESPeasy verbindet sich daher erneut.

Ich werde versuchen, eine Art automatischen Ping hinzuzufügen. Es gibt bereits einige, aber es kann sein, dass die Überprüfung durchgeführt wird, bevor der Ping zurückgekehrt ist.

@louis-lau Kannst du die verwendete Keep-Alive-Zeiteinstellung in deinem Mosquito irgendwie finden?

Es sieht so aus, als ob die von uns verwendete MQTT-Timeout-Einstellung 15 Sekunden beträgt.
Es ist definiert als: #define MQTT_KEEPALIVE 15

Siehe auch https://github.com/knolleary/pubsubclient/issues/239

Wow, du hast es geschafft @TD-er !!!!!

467279 : EREIGNIS: Clock#Time=So,17:24
467588 : WD : Betriebszeit 8 Verbindungsfehler 0 FreeMem 16304
481935 : MQTT : Verbindung verloren
481935 : EREIGNIS: MQTT#Getrennt
481953 : EREIGNIS: WLAN#Getrennt
481969 : WIFI : Getrennt! Grund: '(1) Unspecified' Verbunden für 7 m 40 s
482278 : WIFI : SMC-Verbindungsversuch #0
482278 : IP : Statische IP : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
483304 : EREIGNIS: WLAN#Getrennt
483322 : WIFI : Getrennt! Grund: '(202) Authentifizierungsfehler' Verbindung für 1018 ms
484291 : WIFI : SMC-Versuch Nr. 1 verbinden
484292 : IP : Statische IP : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
488073 : WIFI : Verbunden! AP: SMC (78:8A:20:D1:9B:D9) Ch: 1 Dauer: 3780 ms
488074 : IP : Statische IP : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
488078 : WIFI : Statische IP: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 Dauer: 6 ms
488099 : EREIGNIS: WLAN#Verbunden
488245 : MQTT : Mit dem Broker verbunden mit der Client-ID: ESPClient_5C:CF:7F:0B:68:52
488247 : Abonniert: ESP-201/#
488248 : EREIGNIS: MQTT#Verbunden
489111 : EREIGNIS: Zeit#Set

@TD-er Sind Sie sicher, dass der Pubsubclient Probleme hat? Mein Gerät empfängt nichts, sendet nur alle 30 Sekunden Analogwert. Keine MQTT-Verbindungsprobleme. Wenn es ein Problem mit der Bibliothek gäbe, würden sich dann nicht viel mehr Benutzer beschweren?

Vielleicht ist es eine Rennbedingung...

Der MQTT-Broker muss einen Client beim 1,5-fachen des Timeouts als getrennt betrachten.
Pubsubclient sendet einen Ping, wenn die letzte Aktivität mehr als 15 Sekunden zurückliegt.
Wenn also das Standard-Timeout von Mosquito (10s) verwendet wird, wird das Timing ziemlich kritisch.

Bei meinem Setup sehe ich viel MQTT-Verkehr aller Knoten hier, die auf demselben (domoticz) Kanal chatten.
Das Timeout ist hier also nie ein Problem.
Wenn es jedoch nur einen Knoten gibt, gibt es viel weniger Verkehr und mit dem standardmäßigen ESPeasy-Timeout auf genau das 1,5-fache des standardmäßigen Mosquito-Timeouts kann dies etwas kritisch sein.

Dann könnte er versuchen, alle 5 Sekunden einen Dummy-Analogwert zu senden, um zu überprüfen, ob das Problem behoben ist...

Oder benutze mein letztes Commit ;)

Meine Reconnects waren sehr schnell, jede Sekunde oder so

Das scheint dem MQTT-Entwickler nicht zu gefallen:
Ich bin nicht geneigt, den Standardwert zu ändern. Über 7 Jahre waren es 15 Sekunden. Wenn überhaupt, werden wir die Anpassung vereinfachen und uns nicht auf die Bearbeitung der Header-Datei verlassen.

Die Definition wird mit #ifdef . umschlossen
Es besteht also die Möglichkeit, es in anderen Teilen des Codes zu definieren.

Auf der Github-Seite von PubSubclient gibt es auch ein Problem mit der Konfigurierbarkeit.

Noch ein Kommentar des Autors:
Im MQTT-Protokoll bestimmt der Client den für eine Verbindung verwendeten Keepalive-Wert. Da hat der Makler nichts zu sagen.

Die einzige Keepalive-Konfigurationsoption auf mosquitto ist sein Bridge-Keepalive – wo es als Client fungiert, das sich mit einem anderen Broker verbindet – https://mosquitto.org/man/mosquitto-conf-5.html

Ich habe meine Moskito-Konfiguration überprüft. Keine Timeout-Option für Verbindungen gefunden

In diesem Dokument wird das Timeout-Verhalten erläutert.

Und das Dokument sagt dasselbe:

Der MQTT-Client ist dafür verantwortlich, den richtigen Keep-Alive-Wert festzulegen. Er kann beispielsweise das Intervall an seine aktuelle Signalstärke anpassen.

Woher kommt die 10-Sekunden-Mosquitto-Zeit? Ist es hartcodiert?

https://mosquitto.org/man/mosquitto-conf-5.html

keepalive_interval Sekunden
Legen Sie die Anzahl der Sekunden fest, nach denen die Bridge einen Ping senden soll, wenn kein anderer Datenverkehr aufgetreten ist. Der Standardwert ist 60. Ein Mindestwert von 5 Sekunden ist zulässig.

Diese Einstellung dient nur zur Überbrückung

Denken Sie daran, dass dies 20180428 kein Problem war :)

EDIT: Ich werde deinen neuesten Commit ausprobieren, wenn ich zu Hause bin.

Sie könnten versuchen, connectionCheckHandler zu deaktivieren.

Um zu sehen, was sich am letzten Tag geändert hat: https://github.com/letscontrolit/ESPEasy/compare/mega@%7B1day%7D...mega

Gerade auf https://github.com/letscontrolit/ESPEasy/commit/4e6e31fdae11476a2f3dfce00e01ed77d1858c00 aktualisiert und WLAN ist jetzt stabil. Es verbindet sich jetzt auch wieder, wenn ich meinen AP neu starte! Danke 😄

(Übrigens, gibt es eine Möglichkeit, die Wifi-Status-LED-Einstellung mithilfe von Regeln umzuschalten? Zum Beispiel möchte ich sie nur aktivieren, wenn mqtt getrennt ist, und sie für den Relaisstatus verwenden, wenn verbunden.)

Bei der Status-LED bin ich mir nicht sicher. Es wird von der MQTTconnect-Funktion und von einigen anderen Stellen aufgerufen.
Aber vielleicht könnten Sie ein Problem hinzufügen, um auswählbar zu machen, was über diese LED angezeigt wird?

Und gut zu hören, dass MQTT-Probleme durch das verringerte Timeout behoben zu sein scheinen.
Wir müssen es möglicherweise auswählbar machen.

Könnten Sie das LOG-Fenster etwas länger machen?
Ich meine, erhöhen Sie die Anzahl der Zeilen.

Ansonsten läuft es jetzt sehr gut.

Ich habe sie nur reduziert.
Es waren 20 Zeilen, aber mit 2.4.0 musste es etwas mehr freies Mem geben, also reduzierte ich es auf 10 Zeilen für dev/test und 15 für normal.

Ich werde diese Woche den Speicherverbrauch untersuchen und @Grovkillen sucht nach einer Möglichkeit, ein richtiges Protokollfenster zu erhalten.

Ok, ich gehe schlafen.
Vielen Dank für Ihre Mühe!!

Über dieses Fenster. Aus meiner Sicht gibt es drei Möglichkeiten.

1. Verwenden Sie so viel RAM wie verfügbar, um die Informationen bis zur Anforderung aufzubewahren. Könnte dynamisch sein, abhängig davon, wie viele Plugins aktiv sind.
2. Streamen Sie es zum Webbrowser.
3. Komprimieren Sie es vorübergehend und stellen Sie es auf Anforderung wieder her. Verwenden Sie zB mehr Zahlencodes. Es ist natürlich weniger lesbar.

Ich mag 2. Bietet auch eine reibungslose Webanzeige. Es ist jedoch nicht so einfach.

Die Idee ist, eine Art JavaScript zu verwenden, um das Protokoll zu sammeln und im Browser zu speichern.
Es gibt mehrere Optionen, um die Daten an den Browser zu übermitteln, z. B. eine offene Verbindung aufrechtzuerhalten oder andere Techniken.
Damit bleiben nur wenige Protokollzeilen übrig, die im Speicher gehalten werden müssen.
Und dieser Puffer kann auch verwendet werden, um das Protokoll an Syslog zu übertragen.

Das Log-Cache-Objekt ist derzeit nicht so effizient mit dem Speicher. Viel Raum für Verbesserungen.

Ich frage mich jetzt auch, ob verschiedene Versionen von Moskitos
die auf verschiedenen Betriebssystemen ausgeführt werden, haben ein unterschiedliches Verhalten?
Ich weiß, dass ESPeasy flexibel sein sollte, aber würde ein Moskito-Update für einige Probleme lösen.

Nur zum Verständnis...
Warum bekomme ich direkt nach dem Booten meines ESP Folgendes:

Last Disconnect Reason str |  (1) Unspecified
Number reconnects | 1

Im Syslog sehe ich zwei IP STATIC-Meldungen und Uptime 0 ConnectFailures 0:

INIT : Booting version: mega-20180430 (ESP82xx Core 2_4_1)
104 : INIT : Warm boot #1
105 : FS   : Mounting...
130 : FS   : Mount successful, used 75802 bytes of 957314
419 : CRC  : program checksum       ...OK
426 : CRC  : SecuritySettings CRC   ...OK 
532 : INIT : Free RAM:23528
532 : INIT : I2C
532 : INIT : SPI not enabled
546 : INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_1)
546 : WIFI : Set WiFi to STA
578 : WIFI : Connecting im6shop attempt #0
579 : IP   : Static IP : 192.168.1.17 GW: 0.0.0.0 SN: 0.0.0.0 DNS: 0.0.0.0
585 : WD   : Uptime 0 ConnectFailures 0 FreeMem 22688
4342 : WIFI : Connected! AP: im6shop (30:B5:C2:EB:DB:7D) Ch: 9 Duration: 3763 ms
4343 : IP   : Static IP : 192.168.1.17 GW: 0.0.0.0 SN: 0.0.0.0 DNS: 0.0.0.0
4346 : WIFI : Static IP: 0.0.0.0 (ESP-Easy-7) GW: 0.0.0.0 SN: 0.0.0.0   duration: 3 ms
4356 : Webserver: start
4710 : WIFI : Static IP: 192.168.1.32 (ESP-Easy-7) GW: 192.168.1.1 SN: 255.255.255.0   duration: 356 ms

Vielleicht ist der Begriff "Reconnect" nicht gut gewählt.
Es ist eher wie "(re)connect" oder "Connect-Versuche"
Counter beginnt bei 0 und bei jedem Verbindungsversuch ist es ein Counter++.

Ich habe den Zähler geändert, indem ich ihn auf '-1' initialisiert habe. Beim ersten Verbindungsversuch wird es also auf 0 gesetzt, daher macht das Label "Number reconnects" jetzt wieder Sinn :)
Ich konnte mir keinen besseren Namen vorstellen, also habe ich den gemeldeten Wert geändert ;)

Die richtige Benennung ist immer noch der schwierigste Teil der Programmierung.

Es klingt gut !

Verbindung versuchen x

Leider funktioniert der neueste Build 20180503 (4096 dev) bei mir nicht - das ESP-Web öffnet sich nicht, stattdessen reagiert es in der seriellen Konsole nicht mehr (nach dem Versuch, das Web zu öffnen). Die Einstellungen werden auf die Standardeinstellungen zurückgesetzt und nur die WifiSSID und der Schlüssel über die serielle Konsole eingestellt. PING funktioniert, keine Neustarts, keine Fehlermeldung.

Hast du nach dem Flashen einen Kaltstart durchgeführt?
Ich hatte etwas ähnliches direkt nach dem Flashen.
Ein Power Cycle hat es dann gelöst.

Ja, ich habe mehrere Male einen Kaltstart versucht, es ist immer noch dasselbe. Getestet von MSIE und Firefox auf Win7. Ich werde das Gerät ein paar Minuten später an einem anderen Ort testen (anderer PC / Betriebssystem, anderer AP).
Direkt nach dem Flashen startete es neu und hängte sich auf.

Ich habe es jetzt mit der normalen Version probiert. Auf meiner Seite keine Probleme. Es war kein Power-On-Reset erforderlich.

Es ist seltsam, dass an einem anderen Ort das ESP-Web des gleichen Geräts funktioniert (Win10 + Firefox / MS Edge, anderer AP), aber die serielle Konsole sieht "nur lesen" aus... :-/
Update - versuchte eine andere Terminal-App - das gleiche, serielle Konsole schreibgeschützt. Führen Sie dann Putty (das ist meine Standard-Terminal-App) erneut aus und sehen Sie, wie das Gerät neu gestartet wurde, sobald ich mich mit Putty an den entsprechenden COM-Port angeschlossen hatte. Jetzt nimmt die serielle Konsole Befehle an und das Web funktioniert auch... Ich verstehe nichts...

Vielleicht mal den Flash komplett löschen und nochmal programmieren?
Es scheint einen Zusammenhang mit der WLAN-Verbindung zu geben und ob der serielle Port gelesen wird. Ich habe gesehen, dass das jemand in einem Thread erwähnt hat. Ich bin mir nicht sicher, ob das am PlatformIO-Problem oder an LWIP lag.
Ich habe in letzter Zeit viel gelesen ;)

Ja, das werde ich mit einem nächsten Build versuchen, diesen möchte ich noch einmal an einem anderen Ort testen, um zu sehen, ob es immer noch das gleiche Problem ist (die Gerätekonfiguration wurde in der Zwischenzeit ein wenig aktualisiert).
Übrigens. Wenn ich die Einstellungen zum ersten Mal zurücksetze (nach diesem Build-Flashen durch Ausgeben des Reset-Befehls von der seriellen Konsole), wurden die Einstellungen tatsächlich NICHT zurückgesetzt, obwohl "Flash formatieren" usw. stand. Das Gerät wurde neu gestartet und zumindest die WLAN-Einstellungen waren noch vorhanden wie ich in der seriellen Konsole Verbindungsversuche zum AP gesehen habe ... Der zweite Reset-Versuch von der seriellen Konsole löschte die Einstellungen ...

Ja, die Kernbibliothek speichert die WLAN-Einstellungen in einem Bereich außerhalb des SPIFF.
Dies kann sich auf WLAN-Verbindungsversuche auswirken.

Ich habe bereits im (Kern-)Code gelesen, dass es jetzt bis zu 5 WLAN-Einstellungen unterstützt, die Sie auswählen können.
Vielleicht werde ich diesen Speicherbereich auch aktiv nutzen, um sicherzustellen, dass er nicht mit unseren eigenen Einstellungen in Konflikt steht.
Ich habe nur Angst, dass diese Einstellungen zu oft geschrieben werden. Ich muss nachsehen, wann das geschrieben wird.
Aber es kann die WLAN-Verbindung etwas vorhersehbarer machen, wenn dieser Bereich auch mit ESPeasy berücksichtigt wird.

@Oxyandy Ich werde jetzt die PlatformIO.ini-Änderung pushen, um LWIP2_LOW_MEMORY zu verwenden.
Könntest du das bitte testen?
Und auch die Frage, ob Sie Task/Gerät 12 verwendet haben?
Ich habe es gerade auf meinem Knoten getestet und fast sofort wurde die Verbindung getrennt + sich geweigert, wieder online zu gehen.
Das war mit LWIP1.4

Und auch die Frage, ob Sie Task/Gerät 12 verwendet haben?

In Tests nicht nur der erste, ein einzelner Schalter
Ja, es gibt 15 geänderte Dateien in GitHub Desktop, die jetzt gezogen werden

Gut kompiliert, Webserver großartig, mit LWIP2_LOW_MEMORY, dem F5-Test, einfach großartig.
keine Spur von
Ich hatte alle Einstellungen auf dem Node gelöscht, werde ihn aber "zurücksetzen" und den Vorgang durchlaufen, alle Merkwürdigkeiten melden.
Wifi sofort verbunden..

nur aufpassen mit lwIP2 low memory, ich musste die lwIP2 high bandwith verwenden, sonst werden große Pakete abgeschnitten (zB Sensoren mit mehreren Werten), zumindest wenn fhem als Server/Controller verwendet wird...

Ich verwende derzeit den Mega-Zweig mit esp-Kern von GIT und lwIP2 hoher Bandbreite, der gut läuft, außer dass einige Geräte nach einiger Zeit die Sensorwerte nicht mehr lesen können und sie daher nicht an den Controller senden. das Gerät selbst sowie das Webinterface laufen aber flüssig... Ich recherchiere noch, hatte das noch nie in Commits vor Mai..

Wir haben LwIP2 mit hoher Bandbreite ausprobiert und das haben POST-Nachrichten durcheinander gebracht.
Beispielsweise wurden Speicherregeln > 1520 Byte abgeschnitten.

ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Ist als DoS-Angriff auf Zeitserver gedacht?
Nachdem ich geflasht habe, wurde ich weggerufen, ich habe Seiten & Seiten dieser Schleife

INIT : Booting version: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
105 : INIT : Cold Boot
106 : FS   : Mounting...
113 : FS   : Mount successful, used 76053 bytes of 113201
15:40:37: 410 : CRC  : program checksum       ...OK
417 : CRC  : SecuritySettings CRC   ...OK 
418 : CRC  : binary has changed since last save of Settings
433 : INIT : Free RAM:23448
434 : INIT : I2C
434 : INIT : SPI not enabled
449 : INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
449 : EVENT: System#Wake
458 : WIFI : Set WiFi to STA
mode : sta(5c:cf:7f:72:96:ec)
add if0
491 : WIFI : Connecting MAD_IOT attempt #0
492 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
STUB: dhcp_stop
505 : EVENT: System#Boot
514 : SW   : Switch state 1 Output value 1
517 : EVENT: Float_SW#Switch=1.00
530 : ACT  : Publish domoticz/in,{"idx":66,"nvalue":0,"svalue":"FLOAT_SWITCH_1_00:00:00"}
541 : Command: publish
1004 : WD   : Uptime 0 ConnectFailures 0 FreeMem 22736
15:40:39: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:40:41: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
4480 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 3986 ms
4485 : EVENT: WiFi#ChangedAccesspoint
4497 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
4499 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 19 ms
4517 : EVENT: WiFi#Connected
4525 : Webserver: start
4526 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
5015 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
5066 : NTP  : NTP replied: 50 mSec
5068 : Current Time Zone:  DST time start: 2018-10-07 01:00:00 offset: 660 minSTD time start: 2018-04-01 01:00:00 offset: 600 min
5071 : EVENT: Time#Initialized
5082 : EVENT: Time#Initialized Processing time:11 milliSeconds
5083 : EVENT: Clock#Time=Fri,15:40
5089 : EVENT: Clock#Time=Fri,15:40 Processing time:6 milliSeconds
5091 : MQTT : Intentional reconnect
5091 : LoadFromFile: config.dat index: 28672 datasize: 336
5221 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
5222 : Subscribed to: domoticz/out
5224 : EVENT: MQTT#Connected
5234 : EVENT: MQTT#Connected Processing time:9 milliSeconds
15:40:43: ping 1, timeout 0, total payload 32 bytes, 1365 ms
15:40:48: bcn_timout,ap_probe_send_start
15:40:50: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
13912 : EVENT: WiFi#Disconnected
13919 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9432 ms
13930 : MQTT : Connection lost
13931 : EVENT: MQTT#Disconnected
14514 : WIFI : Connecting MAD_IOT attempt #0
14515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
15:40:51: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:40:52: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
16258 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 1738 ms
16260 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
16269 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
16288 : EVENT: WiFi#Connected
16295 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
16389 : LoadFromFile: config.dat index: 28672 datasize: 336
16425 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
16426 : Subscribed to: domoticz/out
16427 : EVENT: MQTT#Connected
16434 : EVENT: MQTT#Connected Processing time:6 milliSeconds
16557 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
16599 : NTP  : NTP replied: 40 mSec
16600 : EVENT: Time#Set
16606 : EVENT: Time#Set Processing time:5 milliSeconds
15:40:54: ping 1, timeout 0, total payload 32 bytes, 1022 ms
15:40:59: bcn_timout,ap_probe_send_start
15:41:01: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
25176 : EVENT: WiFi#Disconnected
25183 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 8919 ms
25194 : MQTT : Connection lost
25195 : EVENT: MQTT#Disconnected
25514 : WIFI : Connecting MAD_IOT attempt #0
25515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:41:02: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
26186 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 666 ms
26189 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
26197 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
26217 : EVENT: WiFi#Connected
26224 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
26318 : LoadFromFile: config.dat index: 28672 datasize: 336
26344 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
26345 : Subscribed to: domoticz/out
26346 : EVENT: MQTT#Connected
26353 : EVENT: MQTT#Connected Processing time:7 milliSeconds
15:41:04: ping 1, timeout 1, total payload 0 bytes, 1022 ms
27623 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
27664 : NTP  : NTP replied: 41 mSec
27665 : EVENT: Time#Set
27671 : EVENT: Time#Set Processing time:6 milliSeconds
27672 : EVENT: Clock#Time=Fri,15:41
27677 : EVENT: Clock#Time=Fri,15:41 Processing time:5 milliSeconds
ping 1, timeout 0, total payload 32 bytes, 1024 ms
15:41:07: 31004 : WD   : Uptime 1 ConnectFailures 4 FreeMem 19304
15:41:10: bcn_timout,ap_probe_send_start
15:41:12: pm open,type:2 0
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
36143 : MQTT : Connection lost
36144 : EVENT: MQTT#Disconnected
36151 : EVENT: WiFi#Disconnected
36156 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9948 ms
36514 : WIFI : Connecting MAD_IOT attempt #0
36515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:41:13: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
37145 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 625 ms
37147 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
37155 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 10 ms
37176 : EVENT: WiFi#Connected
37182 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
37276 : LoadFromFile: config.dat index: 28672 datasize: 336
37296 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
37297 : Subscribed to: domoticz/out
37298 : EVENT: MQTT#Connected
37306 : EVENT: MQTT#Connected Processing time:8 milliSeconds
37551 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
37592 : NTP  : NTP replied: 41 mSec
37593 : EVENT: Time#Set
37599 : EVENT: Time#Set Processing time:6 milliSeconds
15:41:15: ping 1, timeout 0, total payload 32 bytes, 1046 ms
15:41:20: bcn_timout,ap_probe_send_start
15:41:22: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
46076 : MQTT : Connection lost
46076 : EVENT: MQTT#Disconnected
46083 : EVENT: WiFi#Disconnected
46089 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 8921 ms
46514 : WIFI : Connecting MAD_IOT attempt #0
46515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

Mit aktuellem Core (Master, ESP82xx Core 41a64707, NONOS SDK 2.2.1(cfd48f3)) treten die MTU-Probleme nicht mehr auf.
10 ESPs (Sonoff, NodeMcu, W1pro) laufen seit dem 1. Mai ohne Probleme.

Zu Ihrer Information ... Flashen Sie den neuesten offiziellen Build, setzen Sie die Einstellungen über die serielle Schnittstelle auf die Standardeinstellungen zurück, geben Sie die WiFiSSID und die Schlüssel ein. Es konnte keine Verbindung zum primären AP hergestellt werden, obwohl es sichtbar war (aber ein schwaches Signal über -82). Dann abgestürzt, wie Sie unten sehen können.
An einem anderen Standort wurde das Gerät ohne Probleme schnell mit dem sekundären AP verbunden und bisher funktioniert es (aber keine Plugins konfiguriert, keine Regeln aktiv).
....
....
458745 : WIFI : Verbindungsversuch mit IOTAP1 #57
458749 : AP-Modus: Client getrennt: xx:xx:xx:xx:xx:xx Verbundene Geräte: 0
458810 : WIFI : Getrennt! Grund: '(201) Kein AP gefunden' Verbindung für 64 ms
459360 : AP-Modus: Client verbunden: xx:xx:xx:xx:xx:xx Verbundene Geräte: 1
471739: WIFI: AP-Modus-ssid ist ESP_Easy_0 mit Adresse 192.168.4.1
471739 : WIFI : Verbindungsversuch mit IOTAP2 #58

Ausnahme (29):
epc1=0x4000e1c3 epc2=0x00000000 epc3=0x40000f68 excvaddr=0x00000018 depc=0x00000000

ctx: sys
sp: 3ffffc50 Ende: 3fffffb0 Offset: 01a0

Stapel>>>
3ffffdf0: 3fff5108 1f385062 401021e6 3fffa2b0
3ffffe00: 402706a6 402705c4 3fff9454 40100eb6
3ffffe10: 3ffeb6d5 401042bb 3ffef160 4026a718
3ffffe20: 00000018 3ffefb30 3ffefaac 00000000
3ffffe30: 40270767 3ff20a00 3fff9454 3ffedf1a
3ffffe40: 3ffedf00 00000000 00000000 00000006
3ffffe50: 00000021 1f4328f4 401021e6 3ffedf00
3ffffe60: 3ffedf1a 0000002c 00000008 401004f4
3ffffe70: 3ffedf0a 3fff6454 4026d324 3ff20a00
3ffffe80: 3fff9454 3fff55c4 00000015 4026d1f7
3ffffe90: 3fffc278 40101f80 3fffc200 00000022
3ffffea0: 3ffebf74 00000000 00000000 3fff4fe4
3ffffeb0: 40000f68 00000030 00000010 ffffffff
3ffffec0: 40000f58 00000000 00000020 00000000
3ffffed0: 3ffef7d4 7fffffff 00000000 3ffeed30
3ffffee0: 3ffef138 00000006 00000000 3fffdab0
3ffffef0: 00000000 3ffffdcc0 00000040 00000030
3fffff00: 40274fd1 ffffffe0 00000000 00000000
3ffff10: 4026ca2f 3ffedf00 3ffef160 3fff9454
3fffff20: 00000000 3ffedf0a 3ffedf20 4026a4d1
3fffff30: 4027fac5 00000001 00000000 3ffedf0a
3fffff40: 4027ec78 00000092 3ffedef4 3fff6454
3fffff50: 3ffedef4 00000000 00000040 4027e5a2
3ffff60: 3ffef160 3ffedef4 3fffdcc0 3ffeb710
3fffff70: 3ffedf10 3fff752c 00000040 3ffeb710
3fffff80: 00000040 3ffef160 00000002 00000000
3fffff90: 4027de7f 3fffdab0 00000000 40283f5f
3fffffa0: 3ffeb710 40000f49 3fffdab0 40000f49
<<

ets 8. Januar 2013, erste Ursache:2 , Bootmodus:(3,7)

laden 0x4010f000, len 1384, Raum 16
Schwanz 8
Prüfsumme 0x2d
Summe 0x2d
v614f7c32
~ld
-U88 :

INIT: Boot-Version: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
89 : INIT : Warmstart #6
90 : FS : Montage...
116 : FS : Mount erfolgreich, verwendet 75802 Bytes von 957314
436 : CRC : Programmprüfsumme ...OK
442 : CRC : Sicherheitseinstellungen CRC ...OK
548 : INIT : Freier RAM: 21464
549 : INIT : I2C
549 : INIT : SPI nicht aktiviert
565 : INFO : Plugins: 72 [Normal] [Testing] [Entwicklung] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
566 : WIFI : WLAN auf STA setzen
599: WIFI: Verbindungsversuch mit IOTAP1 #0
607 : WD : Betriebszeit 0 Verbindungsfehler 0 FreeMem 20616
3461 : WIFI : Getrennt! Grund: '(201) Kein AP gefunden' Verbindung für 2861 ms
3604 : WIFI : Verbindungsversuch mit IOTAP1 1
6466 : WIFI : Getrennt! Grund: '(201) Kein AP gefunden' Verbindung für 2862 ms
6604 : WIFI : IOTAP2-Verbindungsversuch #2
9467 : WIFI : Getrennt! Grund: '(201) Kein AP gefunden' Verbindung für 2862 ms
9604 : WIFI : Verbindungsversuch mit IOTAP2 3
12467 : WIFI : Getrennt! Grund: '(201) Kein AP gefunden' Verbindung für 2862 ms
12604 : WIFI : Verbindungsversuch mit IOTAP1 #4
15466 : WIFI : Getrennt! Grund: '(201) Kein AP gefunden' Verbindung für 2862 ms
15604 : WIFI : Verbindungsversuch mit IOTAP1 Nr. 5
18466 : WIFI : Getrennt! Grund: '(201) Kein AP gefunden' Verbindung für 2862 ms
18604 : WIFI : WLAN auf AP+STA . einstellen
19524: WIFI: AP-Modus-ssid ist ESP_Easy_0 mit Adresse 192.168.4.1
19524 : WIFI : Verbindungsversuch mit IOTAP2 #6
22388 : WIFI : Getrennt! Grund: '(201) Kein AP gefunden' Verbindung für 2863 ms
22603: WIFI: AP-Modus-ssid ist ESP_Easy_0 mit Adresse 192.168.4.1
22603 : WIFI : Verbindungsversuch mit IOTAP2 #7
25463 : WIFI : Getrennt! Grund: '(201) Kein AP gefunden' Verbindung für 2860 ms
25602 : WIFI : AP Mode ssid ist ESP_Easy_0 mit Adresse 192.168.4.1
25603 : WIFI : Verbindungsversuch mit IOTAP1 #8
28464 : WIFI : Getrennt! Grund: '(201) Kein AP gefunden' Verbindung für 2860 ms
28602 : WIFI : AP Mode ssid wird ESP_Easy_0 mit Adresse 192.168.4.1 . sein
28603 : WIFI : Verbindungsversuch mit IOTAP1 #9
30606 : WD : Betriebszeit 1 Verbindungsfehler 0 FreeMem 18176
...
...

Ich habe gestern auch den Fehler "Kein AP gefunden" gesehen.
Es scheint mit einigen falschen oder beschädigten Einstellungen zusammenzuhängen. Nicht nur die Einstellungen, die wir speichern, sondern vielleicht auch die Einstellungen, die in einem anderen Teil des Flashs gespeichert sind, von der Kernbibliothek.

@Oxyandy NTP-Updates sollten erst nach einer Stunde durchgeführt werden oder wenn es nicht eingestellt wurde.

@susisstrolch Könnten Sie testen, um eine
Die LWIP2-Version mit hoher Bandbreite beschädigte die HTTP-POST-Anforderungen, wenn sie eine MTU-Größe überschritten.

Hallo Gijs,
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Wenn Sie das Protokoll gesehen haben, ist es ein Muster, verbindet sich immer, MQTT verbindet sich, aktualisiert die Zeit

bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
2515788 : EVENT: WiFi#DisconnectedDisconnected! Reason: '(200) Beacon timeout' Connected for 8919 ms

alle 10 bis 12 Sekunden, stundenlang so geloopt, oops

Regelgröße meines Pondctrl-Geräts: Aktuelle Größe: 1859 Zeichen (max. 2048)
MTU: 534 (Low-Mem-Lwip 2.x)
Keine Probleme - diese Woche mehrmals geändert.

Wir verwenden derzeit LwIP 2.x mit geringem Speicher, da die Version mit hoher Bandbreite diese Probleme aufwies.
@Oxyandy Ich werde mir den Code bezüglich der
Dieses Thema wird immer mehr zum Thema :(

Ich verstehe es nicht, das, was ich (heute Morgen) nach Ihrer Anfrage zusammengestellt habe, hat super funktioniert.
Als dann die offizielle Veröffentlichung verfügbar war, dachte ich, ich sollte das besser gebrauchen, ich war schockiert über den Unterschied.
Nun zu Ihrer letzten Antwort.. Zeitaktualisierung ist in Ordnung..
die offizielle Version von heute verbindet sich problemlos mit WLAN, verbindet MQTT, ruft die Zeit ab, bricht dann die Verbindung mit "(200) Beacon Timeout" ab und wird alle 11 Sekunden wiederholt
Verbinden - WLAN, MQTT, Zeit, trennen, wiederholen
Schauen Sie also nicht auf "Zeitaktualisierung", wenn es verbunden bleiben würde, wäre es in Ordnung ...

Das ist seltsam. Der Build-Prozess von PlatformIO hat etwas wirklich Funky.
Mir ist auch schon ein paar Mal aufgefallen, dass der zweite Bau tatsächlich einen Unterschied macht.
Es ist so, als ob auf der Linker-Ebene in PlatformIO etwas nicht stimmt.
Es ist wirklich seltsam, was hier passiert.

es liegt wahrscheinlich an den Compiler- oder Linker-Flags. Optimierung kann eine Hündin sein.
Die Arduino IDE hat diese Konfigurationsdatei (platform.txt)

# ESP8266 platform
# ------------------------------

# For more info:
# https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification

name=ESP8266 Modules
version=2.5.0-dev

runtime.tools.xtensa-lx106-elf-gcc.path={runtime.platform.path}/tools/xtensa-lx106-elf
runtime.tools.esptool.path={runtime.platform.path}/tools/esptool

compiler.warning_flags=-w
compiler.warning_flags.none=-w
compiler.warning_flags.default=
compiler.warning_flags.more=-Wall
compiler.warning_flags.all=-Wall -Wextra

build.lwip_lib=-llwip_gcc
build.lwip_include=lwip/include
build.lwip_flags=-DLWIP_OPEN_SRC

build.vtable_flags=-DVTABLES_IN_FLASH

build.float=-u _printf_float -u _scanf_float
build.led=

compiler.path={runtime.tools.xtensa-lx106-elf-gcc.path}/bin/
compiler.sdk.path={runtime.platform.path}/tools/sdk
compiler.libc.path={runtime.platform.path}/tools/sdk/libc/xtensa-lx106-elf
compiler.cpreprocessor.flags=-D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ "-I{compiler.sdk.path}/include" "-I{compiler.sdk.path}/{build.lwip_include}" "-I{compiler.libc.path}/include" "-I{build.path}/core"

compiler.c.cmd=xtensa-lx106-elf-gcc
compiler.c.flags=-c {compiler.warning_flags} -Os -g -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -falign-functions=4 -MMD -std=gnu99 -ffunction-sections -fdata-sections

compiler.S.cmd=xtensa-lx106-elf-gcc
compiler.S.flags=-c -g -x assembler-with-cpp -MMD -mlongcalls

compiler.c.elf.flags=-g {compiler.warning_flags} -Os -nostdlib -Wl,--no-check-sections -u app_entry {build.float} -Wl,-static "-L{compiler.sdk.path}/lib" "-L{compiler.sdk.path}/ld" "-L{compiler.libc.path}/lib" "-T{build.flash_ld}" -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,spi_flash_read

compiler.c.elf.cmd=xtensa-lx106-elf-gcc
compiler.c.elf.libs=-lhal -lphy -lpp -lnet80211 {build.lwip_lib} -lwpa -lcrypto -lmain -lwps -laxtls -lespnow -lsmartconfig -lairkiss -lwpa2 -lstdc++ -lm -lc -lgcc

compiler.cpp.cmd=xtensa-lx106-elf-g++
compiler.cpp.flags=-c {compiler.warning_flags} -Os -g -mlongcalls -mtext-section-literals -fno-exceptions -fno-rtti -falign-functions=4 -std=c++11 -MMD -ffunction-sections -fdata-sections

compiler.as.cmd=xtensa-lx106-elf-as

compiler.ar.cmd=xtensa-lx106-elf-ar
compiler.ar.flags=cru

compiler.elf2hex.cmd=esptool
compiler.elf2hex.flags=

compiler.size.cmd=xtensa-lx106-elf-size

compiler.esptool.cmd=esptool
compiler.esptool.cmd.windows=esptool.exe

# This can be overriden in boards.txt
build.extra_flags=-DESP8266

# These can be overridden in platform.local.txt
compiler.c.extra_flags=
compiler.c.elf.extra_flags=
compiler.S.extra_flags=
compiler.cpp.extra_flags=
compiler.ar.extra_flags=
compiler.objcopy.eep.extra_flags=
compiler.elf2hex.extra_flags=

## generate file with git version number
## needs bash, git, and echo
recipe.hooks.core.prebuild.1.pattern=bash -c "mkdir -p {build.path}/core && echo \#define ARDUINO_ESP8266_GIT_VER 0x`git --git-dir {runtime.platform.path}/.git rev-parse --short=8 HEAD 2>/dev/null || echo ffffffff` >{build.path}/core/core_version.h"
recipe.hooks.core.prebuild.2.pattern=bash -c "mkdir -p {build.path}/core && echo \#define ARDUINO_ESP8266_GIT_DESC `cd {runtime.platform.path}; git describe --tags 2>/dev/null || echo unix-{version}` >>{build.path}/core/core_version.h"
## windows-compatible version without git
recipe.hooks.core.prebuild.1.pattern.windows=cmd.exe /c mkdir {build.path}\core & (echo #define ARDUINO_ESP8266_GIT_VER 0x00000000 & echo #define ARDUINO_ESP8266_GIT_DESC win-{version} ) > {build.path}\core\core_version.h
recipe.hooks.core.prebuild.2.pattern.windows=

## Build the app.ld linker file
recipe.hooks.linking.prelink.1.pattern="{compiler.path}{compiler.c.cmd}" -CC -E -P {build.vtable_flags} "{runtime.platform.path}/tools/sdk/ld/eagle.app.v6.common.ld.h" -o "{runtime.platform.path}/tools/sdk/ld/eagle.app.v6.common.ld"

## Compile c files
recipe.c.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.cpreprocessor.flags} {compiler.c.flags} -DF_CPU={build.f_cpu} {build.lwip_flags} {build.debug_port} {build.debug_level} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" {build.led} {compiler.c.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Compile c++ files
recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpreprocessor.flags} {compiler.cpp.flags} -DF_CPU={build.f_cpu} {build.lwip_flags} {build.debug_port} {build.debug_level} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" {build.led} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Compile S files
recipe.S.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.cpreprocessor.flags} {compiler.S.flags} -DF_CPU={build.f_cpu} {build.lwip_flags} {build.debug_port} {build.debug_level} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" {build.led} {compiler.c.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Create archives
recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/arduino.ar" "{object_file}"

## Combine gc-sections, archives, and objects
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" -Wl,-Map "-Wl,{build.path}/{build.project_name}.map" {compiler.c.elf.flags} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" -Wl,--start-group {object_files} "{build.path}/arduino.ar" {compiler.c.elf.libs} -Wl,--end-group  "-L{build.path}"

## Create eeprom
recipe.objcopy.eep.pattern=

## Create hex
#recipe.objcopy.hex.pattern="{compiler.path}{compiler.elf2hex.cmd}" {compiler.elf2hex.flags} {compiler.elf2hex.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.hex"

recipe.objcopy.hex.pattern="{runtime.tools.esptool.path}/{compiler.esptool.cmd}" -eo "{runtime.platform.path}/bootloaders/eboot/eboot.elf" -bo "{build.path}/{build.project_name}.bin" -bm {build.flash_mode} -bf {build.flash_freq} -bz {build.flash_size} -bs .text -bp 4096 -ec -eo "{build.path}/{build.project_name}.elf" -bs .irom0.text -bs .text -bs .data -bs .rodata -bc -ec

## Save hex
recipe.output.tmp_file={build.project_name}.bin
recipe.output.save_file={build.project_name}.{build.variant}.bin

## Compute size
recipe.size.pattern="{compiler.path}{compiler.size.cmd}" -A "{build.path}/{build.project_name}.elf"
recipe.size.regex=^(?:\.irom0\.text|\.text|\.data|\.rodata|)\s+([0-9]+).*
recipe.size.regex.data=^(?:\.data|\.rodata|\.bss)\s+([0-9]+).*
#recipe.size.regex.eeprom=^(?:\.eeprom)\s+([0-9]+).*

# ------------------------------

tools.esptool.cmd=esptool
tools.esptool.cmd.windows=esptool.exe
tools.esptool.path={runtime.platform.path}/tools/esptool
tools.esptool.network_cmd=python
tools.esptool.network_cmd.windows=python.exe

tools.esptool.upload.protocol=esp
tools.esptool.upload.params.verbose=-vv
tools.esptool.upload.params.quiet=
tools.esptool.upload.pattern="{path}/{cmd}" {upload.verbose} -cd {upload.resetmethod} -cb {upload.speed} -cp "{serial.port}" {upload.erase_cmd} -ca 0x00000 -cf "{build.path}/{build.project_name}.bin"
tools.esptool.upload.network_pattern="{network_cmd}" "{runtime.platform.path}/tools/espota.py" -i "{serial.port}" -p "{network.port}" "--auth={network.password}" -f "{build.path}/{build.project_name}.bin"

tools.mkspiffs.cmd=mkspiffs
tools.mkspiffs.cmd.windows=mkspiffs.exe
tools.mkspiffs.path={runtime.platform.path}/tools/mkspiffs

Um Probleme mit platformIO zu vermeiden, habe ich den .pioenvs-Ordner gelöscht und trotzdem 'Clean' ausgeführt
Seit dem Build von heute Morgen haben sich 2 Dateien geändert
ESPEasy-Globals.h & Misc.ino (Korruption der Aufgabeneinstellungen beheben)

Um dies zu tun: Meine aktuelle Ordnerstruktur ist GitHub/ESpeasy
Ich kopiere den ESpeasy-Ordner und benenne ihn um, damit er das Datum enthält, bevor ich einen Abruf durchführe. Dies hilft mir, Änderungen lokal zu vergleichen.

FritzBox hat ein automatisches Firmware-Update durchgeführt. Alle ESPs sind ohne Probleme auf den alternativen Mesh-AP umgestiegen.

@TD-er Sie sagten: "Haben Sie dieses Beacon-Timeout mit 0504 auf einem beliebigen Knoten oder nur einigen?"
Ok, um fair zu sein, werde ich mir ein frisches Modul schnappen und das flashen und in Zukunft jede neue Firmware mit 2 Nodes flashen.
Ich habe Zeit übrig, da es in Ihrem Teil der Welt erst 16 Uhr ist

Ok, ein brandneuer Node, gelöscht.
Geflasht mit ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Das folgende Protokoll hat das gleiche Verhalten wie der andere Knoten.
Kannst du das Muster im Log sehen?

INIT : Booting version: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
104 : INIT : Cold Boot
105 : FS   : Mounting...
111 : FS   : Mount successful, used 76053 bytes of 113201
408 : CRC  : program checksum       ...OK
419 : CRC  : SecuritySettings CRC   ...OK 
420 : CRC  : binary has changed since last save of Settings
439 : INIT : Free RAM:23448
440 : INIT : I2C
440 : INIT : SPI not enabled
455 : INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
455 : EVENT: System#Wake
464 : WIFI : Set WiFi to STA
mode : sta(5c:cf:7f:72:97:2a)
add if0
497 : WIFI : Connecting MAD_MOB attempt #0
498 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
STUB: dhcp_stop
511 : EVENT: System#Boot
519 : SW   : Switch state 1 Output value 1
522 : EVENT: Float_SW#Switch=1.00
536 : ACT  : Publish domoticz/in,{"idx":26,"nvalue":0,"svalue":"FLOAT_SWITCH_1_00:00:00"}
547 : Command: publish
00:23:56: 1004 : WD   : Uptime 0 ConnectFailures 0 FreeMem 22752
00:23:59: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
00:24:01: 
connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
5287 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 4787 ms
5293 : EVENT: WiFi#ChangedAccesspoint
5304 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
5306 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 19 ms
5324 : EVENT: WiFi#Connected
5332 : Webserver: start
5332 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
5423 : MQTT : Intentional reconnect
5424 : LoadFromFile: config.dat index: 28672 datasize: 336
5500 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
5501 : Subscribed to: domoticz/out
5502 : EVENT: MQTT#Connected
5512 : EVENT: MQTT#Connected Processing time:10 milliSeconds
5796 : NTP  : NTP host au.pool.ntp.org (27.124.125.251) queried
5867 : NTP  : NTP replied: 70 mSec
5869 : Current Time Zone:  DST time start: 2018-10-07 01:00:00 offset: 660 minSTD time start: 2018-08-05 01:00:00 offset: 600 min
5871 : EVENT: Time#Initialized
5879 : EVENT: Time#Initialized Processing time:8 milliSeconds
5881 : EVENT: Clock#Time=Sat,01:24
5887 : EVENT: Clock#Time=Sat,01:24 Processing time:6 milliSeconds
00:24:02: ping 1, timeout 0, total payload 32 bytes, 1023 ms
00:24:07: bcn_timout,ap_probe_send_start
00:24:09: pm open,type:2 0
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
14289 : EVENT: WiFi#Disconnected
14296 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9002 ms
14311 : MQTT : Connection lost
14311 : EVENT: MQTT#Disconnected
14519 : WIFI : Connecting MAD_MOB attempt #0
14520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
00:24:11: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
16497 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 1972 ms
16499 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
16507 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 10 ms
16527 : EVENT: WiFi#Connected
16533 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
16608 : NTP  : NTP host au.pool.ntp.org (27.124.125.251) queried
00:24:12: 16679 : NTP  : NTP replied: 70 mSec
16680 : EVENT: Time#Set
16686 : EVENT: Time#Set Processing time:6 milliSeconds
16688 : LoadFromFile: config.dat index: 28672 datasize: 336
16713 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
16714 : Subscribed to: domoticz/out
16715 : EVENT: MQTT#Connected
16724 : EVENT: MQTT#Connected Processing time:9 milliSeconds
00:24:14: ping 1, timeout 0, total payload 32 bytes, 2070 ms
00:24:18: bcn_timout,ap_probe_send_start
00:24:21: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
25349 : EVENT: WiFi#Disconnected
25356 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 8852 ms
25371 : MQTT : Connection lost
25371 : EVENT: MQTT#Disconnected
25519 : WIFI : Connecting MAD_MOB attempt #0
25520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
25683 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 158 ms
25686 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
25694 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
25714 : EVENT: WiFi#Connected
25721 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
25815 : LoadFromFile: config.dat index: 28672 datasize: 336
25836 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
25838 : Subscribed to: domoticz/out
25838 : EVENT: MQTT#Connected
25845 : EVENT: MQTT#Connected Processing time:7 milliSeconds
00:24:22: 26585 : NTP  : NTP host au.pool.ntp.org (27.124.125.251) queried
26656 : NTP  : NTP replied: 70 mSec
26657 : EVENT: Time#Set
26663 : EVENT: Time#Set Processing time:6 milliSeconds
ping 1, timeout 0, total payload 32 bytes, 1010 ms
00:24:26: 31005 : WD   : Uptime 1 ConnectFailures 4 FreeMem 19304
00:24:28: bcn_timout,ap_probe_send_start
00:24:30: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
35077 : EVENT: WiFi#Disconnected
35083 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9394 ms
35094 : MQTT : Connection lost
35095 : EVENT: MQTT#Disconnected
35519 : WIFI : Connecting MAD_MOB attempt #0
35520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
35685 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 160 ms
35687 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
35696 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
35715 : EVENT: WiFi#Connected
35721 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
35816 : LoadFromFile: config.dat index: 28672 datasize: 336
35844 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
35845 : Subscribed to: domoticz/out
35846 : EVENT: MQTT#Connected
35855 : EVENT: MQTT#Connected Processing time:9 milliSeconds
00:24:32: 36735 : NTP  : NTP host au.pool.ntp.org (144.48.166.166) queried
ping 1, timeout 0, total payload 32 bytes, 1016 ms
37739 : NTP  : No reply
00:24:39: bcn_timout,ap_probe_send_start
00:24:41: pm open,type:2 0
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
46238 : EVENT: WiFi#Disconnected
46244 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 10 s
46260 : MQTT : Connection lost
46261 : EVENT: MQTT#Disconnected
46519 : WIFI : Connecting MAD_MOB attempt #0
46520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
00:24:42: 
connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
46679 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 154 ms
46681 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
46689 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 10 ms
46709 : EVENT: WiFi#Connected
46715 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
46809 : LoadFromFile: config.dat index: 28672 datasize: 336
46843 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
46844 : Subscribed to: domoticz/out
46845 : EVENT: MQTT#Connected
46851 : EVENT: MQTT#Connected Processing time:6 milliSeconds

Ah, ich denke, es ist an der Zeit, einen speziellen Zugangspunkt einzurichten, auf dem Wireshark läuft

Mit GitHub Desktop habe ich die neueste "Live"-Quelle, die nur 2 geänderte Dateien enthält, von https://github.com/letscontrolit/ESPEasy/commit/92680c5542b76a15db16af198a3a07ed17618c4e seit meiner Arbeitskompilierung von heute Morgen abgerufen, eine Abendversion erstellt und sie funktioniert perfekt ..
Warum unterscheiden sich die nächtlichen Builds, wenn es sich um dieselbe Quelle handelt, was passiert auf GitHub anders?

Benutzt jemand Arduino IDE?
Können Sie einen "ESP8266 normal 1024" aus dem aktuellen src bauen und hier ablegen?
Danke

Ich bin mir nicht sicher, ob dies mit einigen der zufälligen Probleme zusammenhängt, die wir sehen, aber ich habe festgestellt, dass meine Einheiten nach einiger Zeit keine Daten mehr an den Controller senden. Das Webinterface ist jedoch noch in Betrieb, zeigt aber eine IP-Adresse von 0.0.0.0 an. (siehe Screenshot). Sieht das noch jemand?

Welche Build-Version ist das?

@oxyandy

Warum unterscheiden sich die nächtlichen Builds, wenn es sich um dieselbe Quelle handelt, was passiert auf GitHub anders?

Das frage ich mich auch.
Ich denke, es hat damit zu tun, dass wir es manchmal auch zweimal bauen müssen, wenn wir es selbst bauen.
Es scheint etwas mit der Art und Weise, wie wir Dinge kompilieren, oder mit dem Compiler nicht zu stimmen.
Das mag vielleicht auch erklären, warum wir in den letzten Wochen so viele Dinge sehen, die nur sehr schwer, wenn nicht gar unmöglich zu reproduzieren sind.

Ich habe dies auch mit @arendst von Tasmota besprochen, und er hat bestätigt, dass er auch ab und zu neu
Ich werde @psy0rz fragen, ob es möglich ist, die nächtlichen Builds testweise zweimal zu bauen.

selbst zusammengestellt von mega-20180503
Bauen | 20102 - Mega
Bibliotheken | ESP82xx Core 76a14b1f, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3

Könnten Sie versuchen, es zweimal zu erstellen, bevor Sie es in den Knoten schreiben?
Kein Clean zwischen den Builds, einfach bauen und neu bauen.

sicher, aber ich verwende Arduino SDK auf einem Mac, nicht PlatformIO ... immer noch einen Versuch wert?

Ja, bitte, da wir noch keine Ahnung haben, woran es liegt.
Stellen Sie nur sicher, dass Sie die gleichen Kernbibliotheken wie wir verwenden, da die Arduino IDE nicht auf die in PlatformIO festgelegten festen Versionen schaut.
Die aktuell von uns verwendeten Versionen sind:
ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3

ok, das probiere ich jetzt mal aus und flashe ein paar Einheiten. Ich melde mich sobald was passiert... oder gar nichts ;)

Übrigens. Der aktuelle Build kann jederzeit abgestürzt werden, indem F5 im Webbrowser zumindest auf den Geräte- oder Benachrichtigungsseiten (wahrscheinlich auf jeder ESP-Webseite) einige Sekunden lang gedrückt gehalten wird. Ich kann es jederzeit von Firefox auf Win10 wiederholen:
...
...
39543696 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39551825 : LoadFromFile: config.dat Index: 27648 Datengröße: 320
39557599 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39566681 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39566879 : Ram-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39567105 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39567490 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39567690 : Ram-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39567883 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39568086 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39568287 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39568495 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39568701 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39568910 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39569112 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39569324 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39569530 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39569739 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39569948 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39570158 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39570366 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39570582 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
39570742 : Webseite übersprungen: wenig Speicher: 1784
39570832 : Webseite übersprungen: wenig Speicher: 1784
39570906 : Webseite übersprungen: wenig Speicher: 1784
39570992 : Webseite übersprungen: wenig Speicher: 1784
39571074 : Webseite übersprungen: wenig Speicher: 1784
39571161 : Webseite übersprungen: wenig Speicher: 1784
39571240 : Webseite übersprungen: wenig Speicher: 1784
39571322 : Webseite übersprungen: wenig Speicher: 1784
39571401 : Webseite übersprungen: wenig Speicher: 1784

Ausnahme (28):
epc1=0x4025cb66 epc2=0x00000000 epc3=0x401003f2 excvaddr=0x00000000 depc=0x00000000

ctx: Fortsetzung
sp: 3fff4690 Ende: 3fff4b20 Offset: 01a0

Stapel>>>
3fff4830: 00000000 3ffe90c0 3fff48a4 40253308
3fff4840: 00000000 3ffe90c0 3fff48d4 40257c32
3fff4850: 00000000 3ffe90c0 00000043 4021ada8
3fff4860: 00000000 00000000 00000000 000006c0
3fff4870: 000006f8 00000000 00000000 00000000
3fff4880: 00000000 00000000 00000000 40107b18
3fff4890: 00000000 000003e8 3fff48f0 00000000
3fff48a0: 00000000 00000000 00000000 00000000
3fff48b0: 4029cdfc 00000007 3fff48f0 3fffbfdc
3fff48c0: 0000000f 0000000b 3fff815c 0000000f
3fff48d0: 00000000 3fffb8a4 0000025f 0000025c
3fff48e0: 00000001 3fff16d4 3fff6294 40227cb4
3fff48f0: 3fffb414 0000000f 00000007 4010053d
3fff4900: 3fff4d6c 00000855 00000855 3fff4d6c
3fff4910: 00000010 00000010 00000000 3fff36d4
3fff4920: 00000010 3fff5d14 3fff5d14 40257a6f
3fff4930: 3ffe8ea1 00000000 3fff5d14 40257abb
3fff4940: 00000000 00000010 3fff5d14 3fff4d6c
3fff4950: 40107b70 ffffffff 00000000 40253308
3fff4960: 3fff3a14 00000001 3fff6294 4022fc8d
3fff4970: 00000010 3fff49e0 3ffe8ea1 40207ae8
3fff4980: 00000000 3fff49e0 3fff1868 4028577b
3fff4990: 4025653c 00000001 3fff1868 40253308
3fff49a0: 3fff4d6c 00000c35 00000c35 4010020c
3fff49b0: 00000001 00000001 3fff49e0 40107b70
3fff49c0: ffffffff 40107b70 00000000 40257a14
3fff49d0: 4020a8ca 00000001 3fff6294 4022fd96
3fff49e0: 00000000 00000000 00000000 40253308
3fff49f0: 00000001 00000001 3fff6294 4022fe80
3fff4a00: 00000001 00000001 3fff4a30 40259cfa
3fff4a10: 3fff4d6c 00000112 3fff6294 402532fe
3fff4a20: 3fff6294 3fff366c 3fff6294 4025333a
3fff4a30: 00000000 00000000 00000000 40257c18
3fff4a40: 3fff6294 3fff366c 3fff3628 402533c1
3fff4a50: 3fff5afc 0000000f 00000008 00000000
3fff4a60: 00000000 3fff4ab0 3fff362c 4024ca28
3fff4a70: 3fff366c 00000001 00000000 4024d200
3fff4a80: 00000001 00000000 40251b18 0000000d
3fff4a90: 00000000 3fff7b4c 3fff3628 3fff3af4
3fff4aa0: 00000001 3fff3650 3fff3628 40253618
3fff4ab0: 40107910 00000000 00001388 3fff3b00
3fff4ac0: 00000000 3fff7b4c 00000000 40256abd
3fff4ad0: 3fffdad0 00000000 3fff1944 4023742a
3fff4ae0: 3fffdad0 00000000 3fff19c4 40240380
3fff4af0: 00000000 00000000 00000001 40258a31
3fff4b00: 3fffdad0 00000000 3fff3aee 40258a5c
3fff4b10: Feefeffe Feefeffe 3fff3b00 40100700
<<

ets 8. Januar 2013, erste Ursache:2 , Bootmodus:(3,7)

laden 0x4010f000, len 1384, Raum 16
Schwanz 8
Prüfsumme 0x2d
Summe 0x2d
v614f7c32
~ld
U88 :

INIT: Boot-Version: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
89 : INIT : Warmstart #3
90 : FS : Montage...
115 : FS : Mount erfolgreich, verwendet 75802 Bytes von 957314
437 : CRC : Programmprüfsumme ...OK
469 : CRC : Sicherheitseinstellungen CRC ...OK
575: INIT: Freier RAM:21464
575 : INIT : I2C
575 : INIT : SPI nicht aktiviert
1677 : INFO : Plugins: 72 [Normal] [Testing] [Entwicklung] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
1678 : EREIGNIS: System#Wake
1682 : WIFI : WLAN auf STA setzen
...
...

Gerät dann erfolgreich mit AP verbunden. Noch ein Absturz:

973 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
279178 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
279387 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
279590 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
279798 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
280321 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
280558 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
280785 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
Schwerwiegende Ausnahme 28 (LoadProhibitedCause):
epc1=0x4025cb66, epc2=0x00000000, epc3=0x40100408, excvaddr=0x00000000, depc=0x00000000

Ausnahme (28):
epc1=0x4025cb66 epc2=0x00000000 epc3=0x40100408 excvaddr=0x00000000 depc=0x00000000

ctx: Fortsetzung
sp: 3fff4690 Ende: 3fff4b20 Offset: 01a0

Stapel>>>
3fff4830: 00000000 3ffe90c0 3fff48a4 40253308
3fff4840: 00000000 3ffe90c0 3fff48d4 40257c32
3fff4850: 00000000 3ffe90c0 0000002f 4021ada8
3fff4860: 00000000 00000000 00000000 000007e8
3fff4870: 00000820 00000000 00000000 00000000
3fff4880: 00000000 00000000 00000000 40107b18
3fff4890: 00000000 000003e8 3fff48f0 00000000
3fff48a0: 00000000 00000000 00000000 00000000
3fff48b0: 4029cdfc 00000007 3fff48f0 3fff9af4
3fff48c0: 0000000f 0000000b 3fff9adc 0000000f
3fff48d0: 00000004 3fffb7bc 0000025f 00000130
3fff48e0: 00000001 3fff16d4 3fff773c 40227cb4
3fff48f0: 3fff83ac 0000000f 00000007 4010053d
3fff4900: 3fff4d6c 00000a67 00000a67 3fff4d6c
3fff4910: 00000010 00000010 00000000 3fff36d4
3fff4920: 00000010 3fff9014 3fff9014 40257a6f
3fff4930: 3ffe8ea1 00000000 3fff9014 40257abb
3fff4940: 00000000 00000010 3fff9014 3fff4d6c
3fff4950: 40107b70 ffffffff 00000000 40253308
3fff4960: 3fff3a14 00000001 3fff773c 4022fc8d
3fff4970: 00000010 3fff49e0 3ffe8ea1 40207ae8
3fff4980: 00000000 3fff49e0 3fff185c 4028577b
3fff4990: 4025653c 00000001 3fff185c 40253308
3fff49a0: 3fff4d6c 00000628 00000628 4010020c
3fff49b0: 00000001 00000001 3fff49e0 40107b70
3fff49c0: ffffffff 40107b70 00000000 40257a14
3fff49d0: 4020a8ca 00000001 3fff773c 4022fd96
3fff49e0: 00000000 00000000 00000000 40253308
3fff49f0: 00000001 00000001 3fff773c 4022fe80
3fff4a00: 00000001 00000001 3fff4a30 40259cfa
3fff4a10: 00000000 00000000 3fff773c 402532fe
3fff4a20: 3fff773c 3fff366c 3fff773c 4025333a
3fff4a30: 00000000 00000000 00000000 40257c18
3fff4a40: 3fff773c 3fff366c 3fff3628 402533c1
3fff4a50: 3fff9594 0000000f 00000008 00000000
3fff4a60: 00000000 00000000 3fff362c 4024ca28
3fff4a70: 3fff366c 00000001 00000000 4024d200
3fff4a80: 00000001 00000000 40251b18 0000000d
3fff4a90: 00000000 3fff9b0c 3fff3628 3fff3af4
3fff4aa0: 00000001 3fff3650 3fff3628 40253618
3fff4ab0: 40107910 00000000 00001388 3fff3b00
3fff4ac0: 00000000 3fff9b0c 00000000 40256abd
3fff4ad0: 3fffdad0 00000000 3fff1944 4023742a
3fff4ae0: 3fffdad0 00000000 3fff19c4 40240380
3fff4af0: 00000000 00000000 00000001 40258a31
3fff4b00: 3fffdad0 00000000 3fff3aee 40258a5c
3fff4b10: Feefeffe Feefeffe 3fff3b00 40100700
<<

ets 8. Januar 2013, erste Ursache:2 , Bootmodus:(3,7)

laden 0x4010f000, len 1384, Raum 16
Schwanz 8
Prüfsumme 0x2d
Summe 0x2d
v614f7c32
~ld
U89 :

INIT: Boot-Version: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
89 : INIT : Warmer Stiefel #8
91 : FS : Montage...
116 : FS : Mount erfolgreich, verwendet 75802 Bytes von 957314
438 : CRC : Programmprüfsumme ...OK
469 : CRC : Sicherheitseinstellungen CRC ...OK
575: INIT: Freier RAM:21464
576 : INIT : I2C
576 : INIT : SPI nicht aktiviert
1678 : INFO : Plugins: 72 [Normal] [Testing] [Entwicklung] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
1678 : EREIGNIS: System#Wake
1683 : WIFI : WLAN auf STA setzen
...

Nun, das ist mit 72 Plugins, wie wäre es, wenn sich das normal verhält ;)

Das ist normal, wenn Sie den IP-Stack mit Anfragen überfluten. Da hilft nur, den Webserver öfter zu warten, damit der Eingangspuffer wieder freigegeben wird.

Zumindest ist es gut, dass es wiederherstellbar ist - ein vollständiges Aufhängen wäre schlimmer als ein Neustart ... Aber es ist seltsam, dass die Boot-Ursache nicht jedes Mal gleich war - ich habe auch Ursache 4 gesehen.

ESP_Easy_mega-20180504_test_ESP8266_1024.bin
Ich kann WLAN herstellen, um eine Verbindung herzustellen (erster Versuch) und in Verbindung zu bleiben
F5 (Geräteseite) verursacht keine Fehler oder Absturz
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Verbindet und fällt in einem 11-Sekunden-Zyklus immer wieder aus - (200) Beacon-Timeout
ESP_Easy_mega-20180504_normal_ESP8266_1024_(Self_Compiled).bin
Perfekt

@Oxyandy Langsame automatische
Meine stürzt auf jeder Webseite ab, die ich versucht habe.

@ghtester Ich werde auf meinem PC ein Set mit dem gesamten aktuellen Code erstellen. Der Aufbau dauert etwa 30 Minuten.

@TD-er Vielen Dank für deine Mühe, ich werde es testen, wenn der neue Build fertig ist.

@TD-er hat meine Einheiten (16) jetzt mit ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3 vor dem Flashen zweimal gebaut... Ich werde morgen sehen, ob sie noch am Leben sind und senden Daten... Ich musste lwIP2 hohe Bandbreite nehmen sonst werden die über den FHEM-Controller gesendeten Daten abgeschnitten!
aber muss jetzt schlafen.... n8

Beachten Sie die HTTP POST-Probleme bei der Version mit hoher Bandbreite.

Mein Build läuft jetzt zum dritten Mal (hatte ein ESP32-Problem, das behoben werden musste und wollte sicherstellen, dass nur die Verknüpfung im letzten Build erfolgt)
Es wird also in wenigen Minuten eine ZIP-Datei geben.
Dann gehe ich auch ins Bett.

Siehe den Build: https://github.com/letscontrolit/ESPEasy/releases/tag/mega-20180505_TD-er

TD-er, dein Build, meine Hardware, kein Problem mit dem (normal 1024 8266)
Warten auf das Erscheinen des täglichen Builds wird das als nächstes versuchen ;)

@TD-er Vielen Dank, schnell getestete 4096-Entwicklungsversion (wird fortgesetzt), das Neustartproblem "F5" ist immer noch vorhanden (erster Versuch hat das Gerät vollständig aufgehängt) und die Firmware-Info sagt, dass die MD5-Prüfung fehlgeschlagen ist (ich nehme an, es liegt an Testaufbau). Trotzdem ist alles andere soweit in Ordnung und es verbindet sich perfekt und schnell mit AP.

Build 20102 - Mega
Bibliotheken ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3
GIT-Version
Plugins 72 [Normal] [Testen] [Entwicklung]
Build Md5 4d44355f4d44355f4d44355f4d44355f
Md5-Prüfung fehlgeschlagen!
Bauzeit 5. Mai 2018 00:33:21
Binärdateiname ThisIsTheDummyPlaceHolderForTheBinaryFilename...

Wie auf GitHub erstellt und veröffentlicht, diese beiden BINs im Abstand von 1 Tag (1 Build).
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Bestätigt 'fehlerhaft' auf viele verschiedene Arten, Zurücksetzen, verschiedene Knoten usw.
die Probleme konsistent (201 Beacon Timeout) in einer 11-Sekunden-Schleife
Homebrew funktioniert perfekt aus derselben Quelle.
zu
ESP_Easy_mega-20180505_normal_ESP8266_1024.bin
Funktioniert einwandfrei, die Änderungen in der Quelle sind minimal
sagt mir, dass die GitHub-Versionen "irgendwo" einen Fehler beim Kompilieren haben.
Erster Versuch mit Wifi verbunden, sofortiges Zeit-Update, Wifi nicht einmal unterbrochen,
MQTT hält die Verbindung aufrecht
usw usw -
nichts zu bemängeln ;)

Das bedeutet also, dass viel Zeit in den letzten Wochen (???) auf Kompilierungsprobleme zurückzuführen ist?
Das ist bedauerlich, aber es gibt mir zumindest die Gewissheit, dass ich nicht den Verstand verliere, wenn ich sehe, dass alle Arten von Problemen gemeldet werden, die ich weder reproduzieren noch erklären konnte.

Was das Problem mit f5 angeht: Versuchen Sie es mit lwip mit hoher Bandbreite, da es größere Puffer hatte. Es kann etwas später abstürzen.

Compile-Probleme: Sie laufen mit 80 MHz, oder?

80 MHz ist die Standardeinstellung, denke ich.

Ich weiss. Das Einstellen auf 160 kann jedoch zu seltsamem Verhalten führen.

Ja, das "F5"-Problem ist das einzige ernsthafte Problem, das ich bisher in diesem speziellen Build sehe. In der Tat, wenn ich nur mehrmals schnell darauf drücke, um die ESP-Webseite zu aktualisieren, macht es Probleme:

18084332 : EREIGNIS: Clock#Time=Sa,08:47 Verarbeitungszeit :2 Millisekunden
18091174 : WD : Betriebszeit 302 Verbindungsfehler 0 FreeMem 14504
bcn_timout,ap_probe_send_start
18112119 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18115167 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18116976 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18119084 : LoadFromFile: notification.dat Index: 0 Datengröße: 996
18119089 : LoadFromFile: notification.dat Index: 1024 Datengröße: 996
18119092 : LoadFromFile: notification.dat Index: 2048 Datengröße: 996
18119129 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18121330 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18121337 : WD : Betriebszeit 302 Verbindungsfehler 0 FreeMem 13584
18128862 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18130833 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18135120 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18136605 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18138356 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18140067 : LoadFromFile: notification.dat Index: 0 Datengröße: 996
18140076 : LoadFromFile: notification.dat Index: 1024 Datengröße: 996
18140078 : LoadFromFile: notification.dat Index: 2048 Datengröße: 996
18140152 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18144694 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18144700 : EREIGNIS: Clock#Time=Sa,08:48
18144702 : EREIGNIS: Clock#Time=Sa,08:48 Verarbeitungszeit :2 Millisekunden
18148558 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18151336 : WD : Betriebszeit 303 Verbindungsfehler 0 FreeMem 12568
18153230 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18153763 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18155000 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18155592 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18156416 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18156838 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18164949 : Ram-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18165234 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18165587 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18170770 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18170947 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18171120 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18171300 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18171733 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18177686 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
bcn_timout,ap_probe_send_start
18181336 : WD : Betriebszeit 303 Verbindungsfehler 0 FreeMem 10832
18182865 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18183367 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18188878 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18190025 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18203237 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18203809 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18203817 : EREIGNIS: Clock#Time=Sa,08:49
18203819 : EREIGNIS: Clock#Time=Sa,08:49 Verarbeitungszeit :2 Millisekunden
bcn_timout,ap_probe_send_start
bcn_timout,ap_probe_send_start
bcn_timout,ap_probe_send_start
18496844 : RAM-Nutzung: Nur Webserver: 0 einschließlich Core: 0
18496850 : WD : Betriebszeit 304 Verbindungsfehler 0 FreeMem 8736
18496856 : EREIGNIS: Clock#Time=Sa,08:53
18496858 : EREIGNIS: Clock#Time=Sa,08:53 Verarbeitungszeit :2 Millisekunden

Nach den letzten drei bcn_timout,ap_probe_send_start Meldungen war das Gerät auch in der seriellen Konsole für ca. 60 Sekunden eingefroren, dann funktionierte es ohne Neustart weiter.

Ja, es läuft mit 80 MHz - Systeminfo sagt: ESP Chip Freq: 80 MHz

Die ESP-Webantworten sind wirklich schnell, bis ich versuche, zu schnell zu aktualisieren ...

Morgen alles... meine Geräte laufen jetzt seit ungefähr 10 Stunden stabil. jedoch traten die Probleme manchmal erst nach ein oder zwei Tagen auf, also lasse ich sie so laufen. ein Gerät wurde nachts zweimal neu gestartet (von 16 D1), was mit dem Plugin zusammenhängen könnte oder so ... die Sonoff-Grundlagen laufen auch reibungslos.

Ich weiß, dass Sie TD-er nicht sehen oder erklären konnten, aber haben Sie die GitHub-Builds als Test verwendet?
Ich könnte die Quelle für Veröffentlichungen im letzten Monat noch einmal durchgehen und mit Homebrew vergleichen
Ich hatte viel, das ich für nutzlos hielt, eine meiner Registerkarten in Notepad ++ enthält die Liste

Über F5 ist nicht wirklich ein Problem - ich verwende es als Benchmark, ich habe keine automatische Aktualisierung für die F5-Taste,
Also drücke ich es manuell und beobachte gleichzeitig die RAM-Nutzung und die serielle Protokollausgabe.
"lwip hohe Bandbreite" aus dem Speicher hatte fast sofort
LmacRxBlk:1 Fehler, die nicht korrigierbar waren.
Was mich daran erinnert, dass ich dazu bestimmt bin, etwas zu schreiben über .. auf der To-Do-Liste ..
Und ich werde als Maßnahme noch einmal verschiedene Compile-Einstellungen ausprobieren

Hmm, ich weiß nicht, ob der Grund dafür war, dass ich ein LCD-Display auf Position 12 konfiguriert habe, aber kurz darauf habe ich die Verbindung zum AP verloren und kann keine erneute Verbindung herstellen (Kein AP gefunden, obwohl er per Wifiscan sichtbar ist). Nach Neustart das gleiche Problem. Dann wechselte das Gerät in einen AP-Modus, aber vielleicht aufgrund von Unterstreichungen im SSID-Namen sagte es:

1127917 : WIFI : Fehler beim Starten des AP-Modus mit SSID: ESP_01_1 IP: 192.168.4.1

Aber das Gerät war als AI-THINKER_XXXXXXX sichtbar, ich konnte es verbinden, aber als ich versuchte, den Gerätenamen usw. zu ändern, verlor ich die Verbindung zum Gerät, stürzte ab und startete neu usw. :-(

Update - nach mehreren Versuchen habe ich das Gerät umbenannt, um die Unterstreichung zu entfernen, aber es ist immer noch vor der Gerätenummer:
599417 : WIFI : Fehler beim Starten des AP-Modus mit SSID: ESP-001_1 IP: 192.168.4.1
Und das Gerät ist immer noch als AI-THINKER_XXXXXXX sichtbar
ÇKeine Verbindung mehr zu meinem AP als Client... Ich werde versuchen, die Werkseinstellungen zurückzusetzen...

Update2 OK... Werksreset, Gerät als ESP_Easy_0 AP sichtbar... WifiSSID und WifiKey über serielle Konsole einstellen, Gerät sofort mit AP verbunden...

die meisten meiner Units laufen immer noch gut... aber ich glaube nicht wirklich, dass es eine Sache ist, zweimal zu kompilieren... der einzige Unterschied ist, dass einige Bibliotheken nur das erste Mal kompiliert werden, und danach, wenn das SDK dies sieht nicht geändert wird nicht neu kompiliert...

Eine andere Sache, die ich jetzt versuchen werde, ist, anstatt die "D1 Mini" -Platine in arduino anzugeben, stelle ich alle Parameter selbst ein und verwende das Modul "generic 8266" ... wir werden sehen, ob dies einen Unterschied macht ...

das einzige, was ich derzeit sehe, sind einige spontane Neustarts von bestimmten Einheiten... aber das könnte mit anderen Dingen zusammenhängen...

eine frage von mir: sonoff basic hat nur 1M speicher ... gibt es eine chance, diese dinge OTA zu aktualisieren? es behauptet offensichtlich immer "nicht genügend Speicher" ... irgendwelche Ideen?

PS: Was das Kompilieren angeht, ich habe von Anfang an immer selbstkompilierte Binärdateien (andere Plugins) verwendet und hatte die "gleichen" Stabilitätsprobleme ... also könnten einige von ihnen wirklich mit PlatformIO zusammenhängen, andere waren meiner Meinung nach "echte" Probleme. ..

Sie können beim Kompilieren weniger Plugins verwenden. Siehe https://github.com/letscontrolit/ESPEasy/blob/mega/src/define_plugin_sets.h

Sie werden nie in der Lage sein, OTA direkt zu nutzen, aber auf diese Weise ist es zumindest klein genug für OTA in zwei Stufen. Schau mal im Wiki nach :)

genau das habe ich gemacht... deshalb kompiliere ich immer selbst... aber selbst mit nur 2 aktivierten Plugins verwendet der Sketch 500k...
deshalb suche ich nach einer anderen Lösung (zB kein Webinterface... etc.)..

500k ist klein genug. Wie gesagt, zweiteiliges OTA. Sie können nicht direkt aktualisieren. Schau mal im Wiki :)

thx.. suche.... ;)

hinzufügen: irgendwie habe ich den Zweischritt-Teil verpasst....

Bei 1M Sonoffs müssen Sie einen Initial Uploader verwenden, der das DOUT-Flag im Header hat.
aus dem Gedächtnis ist das im Wiki nicht, aber möglicherweise vor kurzem aktualisiert worden.

Ich erinnere mich an so etwas, habe gerade gesucht und ich verwende dieses für OTA: https://github.com/soif/EspBuddy/blob/master/firmwares/ESPEasyUploader.OTA.1m128.esp8266.bin

Ja, überprüft, das ist DOUT
Hier ist eine, die ich zusammengestellt habe, sie ist kleiner
Initial_Firmware_Uploader_Sonoff_1M_DOUT.zip

Ich sagte, ich würde es tun, weil ich sehr neugierig war........
Als Vergleich zu Self_Compiled mega-20180422 auf GitHub veröffentlicht, bisher - ich habe nur einen ausprobiert
ESP_Easy_mega-20180422_normal_ESP8266_1024.bin
Ich habe einen Kommentar hinterlassen und mich hier über sein Verhalten angemeldet https://github.com/letscontrolit/ESPEasy/issues/1301#issuecomment -383433822 (GitHub veröffentlicht)
Selbe Quelle selbst zusammengestellt, keine Überraschung, ich sehe ein anderes Verhalten als das Nightly.
Es blieb verbunden, Schock Horror!
GitHub hat mega-20180422 veröffentlicht, übertrieben, genau das gleiche Verhalten, das ich beim ersten Versuch berichtet habe.
Würde nicht in Verbindung bleiben, WIFI : Disconnected! Reason: '(200) Beacon timeout' Radfahren immer und immer wieder
Die Ursache muss untersucht werden ... seufz
GitHub freigegeben = nicht vertrauenswürdig?

Ich habe die Arduino-Compiler-Flags gestern oder so gepostet. Welche Flaggen verwendet Travis?

Ich habe 16 D1s und 3 Basics, die auf f69e476 laufen, selbst kompiliert, Core 2.4.1, lwIP2 High-Bandbreite.
Fast alle mit einer Betriebszeit von >900Min. jetzt und funktioniert immer noch gut. 2 von ihnen sind vor etwa einer Stunde in den AP-Modus geschaltet und haben sich bis jetzt nicht wieder verbunden. Ich werde bis heute Abend warten und sehen, ob sie sich erholen.

leider ist das verhalten nicht wirklich reproduzierbar und ich kann auch nicht wirklich belegen wo die probleme ankommen, aber ich suche weiter nach fehlern und melde sie wenn ich was finde...

@Oxyandy : Ich habe auch einen Upload für meine einwandfrei ! Nochmals vielen Dank, dass Sie mich in die richtige Richtung gewiesen haben.. ;)

@s0170071
Sie werden in .travis.yml & platformio.ini . gespeichert
Ich habe es schnell durchgelesen, tada, schau, was ich gefunden habe
skip_cleanup: true
Bearbeiten: Weitere Lektüre Ich bin mir nicht sicher, ob sich dies auf das Erstellen eines
Ich gebe zu ist alles neu für mich... ??? Caching deaktivieren?

Travis führt jedes Mal einen sauberen Build durch, da es sogar die Python-Umgebung usw. herunterlädt.

Die nächtlichen Builds werden von @psy0rz gemacht , nicht von Travis

Okee dokee, sind sie also saubere Builds?
Versuchen Sie zu verstehen, warum sie sich anders verhalten?

Wie sieht es mit dem Vergleich von MD5 von bin1 und bin2 aus?
Es zeigt an, ob es sich um ein Kompilierzeit- oder Laufzeitproblem handelt...

@susisstrolch meinst du, wenn du dich selbst kompilierst? Das liegt daran, dass MD5 nach der Kompilierung berechnet wird. Es gibt ein Skript, das das für Sie erledigt.
https://github.com/s0170071/CRC4ESP

-edit: @susisstrolch Ich habe dich vielleicht falsch verstanden :-)
ja, man kann die md5 vergleichen, sie sollten identisch sein. Wenn Sie dies offline tun, können Sie die Binärdateien auch bitweise vergleichen. Auf diese Weise können Sie sogar erkennen, wo die Abweichung liegt. Wenn Sie fortgeschritten sind, können Sie dies sogar zum Code zurückverfolgen. Die .elf-Datei sollte alle Informationen enthalten.

Mir ist es sowieso nicht so wichtig, was sich genau unterscheidet. Ich denke, es ist wichtiger, sicherzustellen, dass alle auf derselben Binärdatei gespeichert sind - egal, wer sie kompiliert hat.

Also noch einmal, was sind die Kompilierungs-Flags für Arduino, Platformio, Nightly und Travis? Win/Linux,.

Nein - ich meine, anstatt über Unterschiede in der Compilerausgabe in automatisierten Builds zu spekulieren, vergleichen Sie einfach die MD5 beider Builds. So können Sie genau erkennen, ob sie sich unterscheiden.

Flags für Arduino IDE unter Linux sind:

build.lwip_lib=-llwip_gcc
build.lwip_include=lwip/include
build.lwip_flags=-DLWIP_OPEN_SRC
build.vtable_flags=-DVTABLES_IN_FLASH
build.float=-u _printf_float -u _scanf_float


compiler.cpreprocessor.flags=-D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ "-I{compiler.sdk.path}/include" "-I{compiler.sdk.path}/{build.lwip_include}" "-I{compiler.libc.path}/include" "-I{build.path}/core"

compiler.c.cmd=xtensa-lx106-elf-gcc
compiler.c.flags=-c {compiler.warning_flags} -Os -g -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -falign-functions=4 -MMD -std=gnu99 -ffunction-sections -fdata-sections

compiler.S.cmd=xtensa-lx106-elf-gcc
compiler.S.flags=-c -g -x assembler-with-cpp -MMD -mlongcalls

compiler.c.elf.flags=-g {compiler.warning_flags} -Os -nostdlib -Wl,--no-check-sections -u app_entry {build.float} -Wl,-static "-L{compiler.sdk.path}/lib" "-L{compiler.sdk.path}/ld" "-L{compiler.libc.path}/lib" "-T{build.flash_ld}" -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,spi_flash_read

compiler.c.elf.cmd=xtensa-lx106-elf-gcc
compiler.c.elf.libs=-lhal -lphy -lpp -lnet80211 {build.lwip_lib} -lwpa -lcrypto -lmain -lwps -laxtls -lespnow -lsmartconfig -lairkiss -lwpa2 -lstdc++ -lm -lc -lgcc

compiler.cpp.cmd=xtensa-lx106-elf-g++
compiler.cpp.flags=-c {compiler.warning_flags} -Os -g -mlongcalls -mtext-section-literals -fno-exceptions -fno-rtti -falign-functions=4 -std=c++11 -MMD -ffunction-sections -fdata-sections

@ s0170071 Ich habe versucht, Edwin zu fragen, aber er hat noch nicht geantwortet.
Im Moment wissen wir also nicht genau, was für die nächtlichen Builds getan wird.
Und trotzdem bleibt das seltsame Verhalten (das ich auch bei meinem Setup erlebt habe), dass das zweimalige Kompilieren unterschiedliche Ergebnisse liefert.
Die Binärdateien zwischen Builds können nicht über eine Prüfsumme verglichen werden. Es ist ein Build-Zeitstempel enthalten, der für jeden Build unterschiedlich ist. Wenn Sie also dieselbe Quelle 100 Mal kompilieren, erhalten Sie 100 verschiedene Prüfsummen.
Aber zumindest sollte es die gleiche Funktionalität bieten und das scheint (manchmal) nicht zwischen dem ersten und zweiten Build zu passieren. Und _das_ ist nicht so, wie es sein sollte.

Also, zu Testzwecken und um es festzunageln, würde ich das Setzen aller Vorkompilierungsänderungen zwischen diesen aufeinanderfolgenden Kompilierungen überspringen, um eine vergleichbare src zu erhalten.

@ s0170071 Wir erhalten also viele Debug-Informationen aufgrund der Option -g beim
Vielleicht ein Punkt, um die Größe zu reduzieren ...

Wir müssen uns in Zukunft mit der Größenreduzierung befassen, aber Sie müssen beim Umschalten der Optimierungsflags vorsichtig sein. Einige können zu noch schwerer reproduzierbaren Problemen führen.

die beiden Einheiten erholten sich einige Stunden später im Laufe des Tages, aber andere versagen zufällig ... zwei Dinge, die ich bis jetzt gefunden habe:
Ich bekomme Einträge im Log, die sagen:
96493069 : IP blockiert: 0.0.0.0 Erlaubt: 10.0.0.0 - 10.0.255.255
96517068 : WD : Betriebszeit 1608 Verbindungsfehler 0 FreeMem 11544
die erste Zeile kommt mir seltsam vor, was versucht mit IP 0.0.0.0 zu verbinden? Dies könnte mit den Problemen zusammenhängen, die ich vor einigen Tagen gesehen habe, dass das Gerät erreichbar ist, aber es sagt mir, dass es die IP 0.0.0.0 hat.

Zweitens, obwohl in den letzten 24 Stunden nichts getan wurde, sehe ich plötzliche Sprünge in der CPU-Last, selbst bei "kleinen" Geräten, die nur die Switch-Funktionalität verwenden (zB Nr. 7 in der beigefügten Grafik).

Gibt es eine Chance herauszufinden, warum diese plötzlichen Änderungen der CPU-Last auftreten? das Log sagt nichts konkretes.. (CPU Load von heute und gestern)...

Springt die CPU-Last im Moment eines Neustarts?
Etwas seltsam ist nur die Art und Weise, wie die CPU-Last berechnet wird.
Es dauert, wie oft die Hauptschleifenfunktion in 30 Sekunden ausgeführt wird.
Dies wird mit der beobachteten maximalen Zählung verglichen.
Dies bedeutet, dass während des Betriebs die beobachtete maximale Anzahl ansteigen kann, aber auch, dass sie nach einem Neustart plötzlich sinken kann.

nein, nicht bei einem Neustart... nur "zufällig" irgendwann... interessanterweise passiert es mehreren Einheiten gleichzeitig... Ich habe keine Ahnung, was dort passiert ist (war damals nicht zu Hause)... besonders Einheiten 12- 14 sind wirklich einfache Boards ohne Aufgaben außer rssi, load, uptime und mem... auch Speicherdiagramme zeigen keine Anzeichen von signifikanten Änderungen...
immer noch zeigt die Auslastung einiger Einheiten ~50% an, aber das Webinterface ist schnell.

Außerdem habe ich auf einem Gerät eine nfx-gesteuerte Uhr, die jede Sekunde die Zeigerposition ändert. interessanterweise blieb die Uhr irgendwann stehen, aber das Gerät funktionierte weiterhin ohne Probleme... als ob diese Aufgabe nicht mehr ausgeführt wurde... deutet wohl auf probleme hin...

aber wie gesagt, ich habe momentan absolut keine Ahnung, woher all diese Probleme kommen können.. wirklich nur herumstöbern und versuchen, etwas zu finden.

trotzdem vielen dank für eure mühe und hilfe... falls ich was vernünftiges finde melde ich mich...

Es könnte auch bedeuten, dass alle Dienste zu einem bestimmten Zeitpunkt die Verfügbarkeit geändert haben.
Entweder wurde es verfügbar, was dazu führte, dass die Knoten tatsächlich mehr Arbeit verrichteten.
Oder es war nicht mehr verfügbar. ESPeasy versucht, einen Ping-Befehl an einen Host zu senden, um dessen Verfügbarkeit zu erkennen. Wenn dieser Ping fehlschlägt, wird der Knoten während der Zeitüberschreitung angehalten.

wie wird das "ping" gemacht? weil ich von Zeit zu Zeit "Host unbekannt" sehe... könnte es sein, dass diese Zeitüberschreitung ziemlich groß ist? oder hat der ping ord DNS-Lookup zu kurzen Timeouts? Eigentlich verwende ich keine FQDNs mehr, sondern nur IPs, daher ist DNS weniger wahrscheinlich ein Problem ...

Ich aktualisiere gerade mit dem neuesten Commit ... einige Einheiten sind einfach zu aktualisieren und ziemlich schnell, andere sehr langsam ...

Ich habe 4 APs, die auf derselben SSID laufen, kann es auch sein, dass es manchmal einen schlechteren auswählt und dann Geschwindigkeitsprobleme hat?

Ich hatte vor, die Art und Weise, wie ein Ping ausgeführt wird, in einen asynchronen Ping zu ändern.
Beim Versuch, eine Verbindung herzustellen, wird geprüft, ob der Host verfügbar ist. Das geht per Ping.

und das ist ein blockierender Anruf?

Es ist in der Tat, deshalb möchte ich es in eine asynchrone Variante ändern.

hmm.. das könnte erklären, wenn die Netzwerkverbindung schwach ist, dass die Dinge nicht wirklich "fließend" sind... besonders wenn versucht wird, einen neuen Sketch hochzuladen... ist es möglich, den Ping-Timeout zu erhöhen, wenn das Netz viel hat? der Latenz?

Dies geschieht nur beim Herstellen einer Verbindung.
Die erfahrene Belastung einer MQTT-Verbindungswiederholung, die fehlschlägt, ist viel auffälliger.
Es gibt nicht wirklich viele Hosts, mit denen wir eine Verbindung herstellen, daher sollte möglicherweise im Hintergrund eine asynchrone Verfügbarkeitsprüfung ausgeführt werden, um zu entscheiden, ob eine erneute Verbindung hergestellt werden soll oder nicht.
Hinweis: Eine DNS-Suche kann auch ziemlich blockieren, wenn sie schließlich fehlschlägt.

kann es sein, dass 0.0.0.0 der sekundäre DNS ist?

Das habe ich mit DNS realisiert, deshalb verwende ich jetzt nur noch IP-Adressen... MQTT nutze ich gar nicht, nur fhme-Controller-Plugin sowie normale json-Abfragen (von fhem mit HTTPMOD-Plugin).

Eine Sache, die ich wahrscheinlich versuchen werde, ist das Deaktivieren von UDP-Inter-ESPEasy-Netzwerken ... Ich kann das Gefühl nicht loswerden, dass dies einen gewissen Einfluss auf die Einheiten hat, insbesondere wenn 15+ Einheiten laufen, die regelmäßige Updates senden. ..

Nachdem alle Units auf den neuesten Mega-Commit aktualisiert wurden, waren alle CPU-Lasten wieder "normal" ... heute morgen gegen 8 habe ich Nr. 4 und 9 und sehen Sie, was mit der CPU-Last passiert ist, fast alle Einheiten hatten eine Spitze von etwa 30 Minuten. und ging danach wieder normal....

nur eine kurze Idee: ist es möglich, dass empfangene Inter-ESPEasy-UDP-Ereignisse an andere Einheiten "umverteilt" werden und daher eine Schleife erzeugen und den Netzwerkstapel füllen könnten?

Ich habe mir den Code dieser 'Inter-ESPeasy-Kommunikation' nie angesehen, daher kann ich dazu nichts sagen.
Ich würde erwarten, dass dieses Protokoll nur seine eigenen Daten sendet und den Rest nicht echot.
Dieses Protokoll besteht aus 2 Teilen:

1. Die eigene Präsenz angeben.
2. Senden von Parameterwerten von Plugins über das, was früher "Global Sync" war.

Letzteres wird nun durch "controller c_013" ersetzt.

Aber ich bin mir nicht sicher, ob eine Schleife nicht möglich ist. Zum Beispiel mit Dummy-Geräten, MQTT-Import etc.
Es kann auch ein unterschiedliches Verhalten zwischen alten Versionen und neuen Versionen sein, die "Controller 13" verwenden.

ok danke für die schnelle antwort... ich schalte es jetzt aus bzw. Setzen Sie den UDP-Port auf 0 und sehen Sie, ob sich etwas ändert ...

Hinzufügen: Nach dem Ändern sehe ich, dass etwa 50% der Geräte neu gestartet werden (ohne dazu aufgefordert zu werden)... und einige "HTTP: Verbindung fehlgeschlagen" im Protokoll....

Ich habe ein ähnliches Problem mit der CPU-Last festgestellt. Auf dem wemos läuft eine selbst kompilierte FW mit 13 Plugins. Ich verwende die Rest API mit Pimatic. Wie Sie aus irgendeinem Grund sehen können, steigt die Auslastung auf 90% und mehr.

zur Info: Seit ich das Inter-ESPEasy-Netzwerk deaktiviert habe, indem ich den Port in den erweiterten Einstellungen auf 0 gesetzt habe, scheinen (die meisten) meine Probleme verschwunden zu sein! alle 20 geräte haben betriebszeiten >20min. und melden nach wie vor regelmäßig Werte. web-wenn betriebsbereit. auch die CPU-Grafik zeigt diese plötzlichen Sprünge nicht mehr an. Nur eine Einheit wechselte in den AP-Modus, ich werde sehen, ob sie sich erholt.
wahrscheinlich muss dies untersucht werden (in der Quelle) ... bei vielen Geräten überlastet das UDP-Zeug wahrscheinlich den Netzwerkstapel ...
Hoffe das hilft anderen, die mit ähnlichen Problemen konfrontiert sind...

Hier meine Erfahrung:
6 Einheiten, alle mit statischer IP und aktivem Inter-ESPeasy-Netzwerk.
Die zuletzt geladene Firmware war "Mega 20180505 Handbuch zweimal gebaut". (aber frühere Firmwares funktionierten auch sehr gut).
Sie laufen seit fast 3 Tagen ohne Probleme.

Das ist einer der Gründe, warum ich ein paar Tage warten möchte, bevor ich ein paar WLAN- / Netzwerk-Fixes mache. Lassen Sie es einfach eine Weile laufen, um zu sehen, was tatsächlich falsch ist, und versuchen Sie, einige Probleme auf der Arduino-Problemliste zu lesen.
Mir ist bereits aufgefallen, dass eine Reihe von Problemen darauf hindeutet, die Energieverwaltung für einige WLAN-Konfigurationen zu deaktivieren. Anscheinend funktionieren einige Kombinationen von ESP8266 + Accesspoint nicht gut mit aktivierten Energieverwaltungsfunktionen (die standardmäßig aktiviert sind).
Das ist also eine Option zum Hinzufügen zu ESPeasy.

Ich suche in den nächsten Tagen nach weiteren Ideen und Freitag/Samstag habe ich mehr Zeit zum Programmieren.

Als Referenz ist mein Access Point ASUS RT-AC68U mit Merlin-Firmware

Ich denke, die meisten Probleme liegen bei der werkseitig voreingestellten Firmware für die preisgünstigeren Modelle und vielleicht etwas älteren Accesspoints, die die Energiesparoptionen moderner WLAN-Geräte nicht kennen.
Es bleibt die Frage, ob es möglich ist, solche Funktionen auszuhandeln, um diese Funktionen automatisch zu erkennen.

Was ist, wenn Sie standardmäßig deaktiviert lassen und nur aktivieren, wenn dies auf der Einstellungsseite angefordert wird?
Die Energiesparoptionen sind wohl nur für batteriebetriebene Geräte sinnvoll.

Sie sind auch für andere Zwecke sinnvoll.
Mehr Leistung bedeutet mehr Wärme und einige sind mit Sensoren umschlossen.... ;)

Hinzu kommt die hohe Prozessorlast. Ich ging zurück zu einer FW vom 16/03 mit 2.3.0 Core und alles wurde wieder normal. Belastet jetzt max. 25%. Auch die Reaktionszeit des wemos ist wieder deutlich besser. Sowohl beim 08/05 als auch beim 16/03 habe ich keine WLAN-Verbindungen. Noch keine Ahnung, was die hohe Last verursacht hat. Auch habe ich in beiden Fällen nicht von udp Gebrauch gemacht.

seit der Deaktivierung von UDP laufen die Geräte ohne Probleme, außer denen, die ein LCD angeschlossen haben. Ich denke, wenn Sie viele Einheiten haben, die sprechen (> 20), sind sie entweder zu beschäftigt damit, alle UDP-Nachrichten zu dekodieren oder haben einen Speicherverlust oder ähnliches. Das würde auch die spontanen Neustarts von Geräten nach dem Start eines anderen erklären. nur MHO ... muss mehr debuggen, um sicher zu sein ...

Es kann auch damit zusammenhängen, dass bei einigen Anrufen von yield() längere Aufgaben ohne Zeit erledigt werden, was auch beim Anrufen von delay() geschieht.
Ich kann mir vorstellen, dass das LCD-Plugin (und vielleicht auch einige andere) einige Aufgaben erledigt, die > 10 ms dauern.

die geräte mit LCD scheinen mit der zeit geschäftiger zu werden... wenn ich versuche zu reflashen muss ich sie zuerst neu starten, da das hochladen nach einigen stunden nicht mehr funktioniert (oder ewig dauert...)

alle anderen Geräte laufen jetzt einwandfrei, aber wie gesagt, die Inter-ESP-Ansage muss deaktiviert werden...

zumindest ist WiFi so stabil, keine anderen Probleme mit der Konnektivität bisher ... (mit mittlerweile mehr als 20 Einheiten)

Sie haben die Protokollierung Sie auf der seriellen Schnittstelle aktiviert?
Könnten Sie vielleicht, dass auf „None“ eingestellt?

hmm .. interessanter Punkt, habe ich die default „Info“ auf der seriellen Port-Protokollierung, aber den Serialport vollständig Förther unten deaktiviert ... könnte, die zu Problemen führen?

Ich werde es bei den Geräten auf "none" ändern, ich werde sehen, ob das einen Unterschied macht.

Ich habe bereits Berichte gehört, dass sich Daten anhäufen, die nicht aus den seriellen Puffern geholt werden.
Und ich habe gerade selbst bemerkt, dass ich auf einem laufenden Knoten, wenn ich den seriellen Monitor angeschlossen habe, Daten zurück zum Zeitpunkt des Bootens erhielt, wie eine Minute zuvor.

Hiermit der Unterschied zwischen Core 2.3.0 und 2.4.1 10. Mai habe ich die FW von 2.4 zurück auf 2.3 geändert. Die Einstellungen und Regeln für beide sind genau gleich.

@jopiekr : Welche Software verwenden Sie, um die CPU-Last zu drucken?

@gii1967g es ist pimatisch. Lassen Sie es problemlos über ein Jahr auf einem OrangePi One laufen. Als Backup auch auf einem Raspberry Pi. pimatic.org

Habe jetzt alle Serial-Logs auf keine geändert... Ich werde sehen, was passiert...

Bemerkenswert ist auch die WLAN-RSSI.. Wenn die Geräte ein schwaches Signal erhalten, können sie ziemlich nicht reagieren eins....

Ich habe festgestellt, dass sie über -77 dB nicht mehr reagieren. Auch wenn sie nicht batteriebetrieben sind, überprüfen Sie die Mietzeitverlängerung Ihres Routers. Ich habe eine Regel aufgestellt, um sie nach 12000 Minuten neu zu starten.

Sie sollten sich wieder mit dem letzten verbinden. Der erste Neuverbindungsversuch erfolgt mit der BSSID der letzten aktiven Verbindung.
Aber ich denke, wir sollten die BSSID zu den Einstellungen hinzufügen.

In den letzten Tagen habe ich viel über die WLAN-Probleme nachgedacht und mir eine Art Workaround für die Fehler ausgedacht, die wahrscheinlich entweder in der Core-Lib oder in Kombination mit den AP-Firmware-Versionen vorhanden sind
Derzeit führt die Kernbibliothek einen Scan durch, wenn versucht wird, eine Verbindung nur mit SSID + pwd herzustellen.
Auf diese Weise ist es viel schneller, wenn Sie beim Verbinden den BSSID + -Kanal angeben.
Denn dann muss es nicht scannen.
Warum also nicht selbst scannen, die bekannte SSID finden, alle BSSIDs + Kanal für die passenden Netzwerke speichern und dann versuchen, nur über BSSID + Kanal eine Verbindung herzustellen.
Dann haben Sie auch das automatische Failover und haben die volle Kontrolle darüber, wann eine Verbindung zu erneuern ist. (und damit Dienste neu starten)

Sie kennen auch den stärksten RSSI, also verbinden Sie sich zuerst mit dem stärksten und versuchen Sie immer, den zuletzt verwendeten zuerst wiederzuverwenden
Und wenn die Verbindung instabil ist, versuchen Sie, die Energiesparfunktion zu deaktivieren, die standardmäßig im 2.4.x-Kern aktiviert ist.
Diese Energiesparfunktion kann zu erneuten WLAN-Verbindungen führen, beim Surfen durch die Webseiten zum Stillstand kommen oder sogar beim Verbinden verworfen werden.

Bei aktivierter Energiesparfunktion wird das WLAN für eine Weile ausgeschaltet und dann rechtzeitig wieder aktiviert, um das Beacon-Signal des Accesspoints zu empfangen.
Wenn diese nicht synchron sind, kommen einige Pakete möglicherweise nicht beim ESP an und werden erst beim Empfang des nächsten Beacon-Signals erneut übertragen. (was eine Weile dauern kann)

Ich weiß nicht viel über die Besonderheiten dieser Energiesparprobleme, aber ich weiß genug über die Firmware-Entwicklung, um zu wissen, dass Standards bei den Anbietern möglicherweise nicht gleich implementiert werden. Daher ist es sehr wahrscheinlich, dass einige Hardwarekombinationen mit aktivierten Energiesparfunktionen weniger optimal funktionieren. Es kann sogar ein anderes WLAN-Gerät sein, das das WLAN-Beacon-Intervall des Accesspoints verzögert. Es gibt einfach zu viele Variablen.

Eine solche vorübergehende Trennung kann sich auch auf DNS-Lookups und andere Verbindungsunterbrechungen auswirken, die das ESP für eine Weile blockieren können. Dies könnte sich auch auf die CPU-Last auswirken, da dieser (schlecht definierte) Wert darauf basiert, wie oft die loop()-Funktion in 30 Sekunden ausgeführt wird. Wenn ein Aufruf einer DNS-Auflösungsanforderung den ESP zum Stillstand bringt, wird die Schleifenanzahl dann ziemlich niedrig sein und somit eine hohe CPU-Last gemeldet.

@jopiekr Sie könnten auch einen Neustart durchführen, denke ich
Ich werde zuerst versuchen, die Energiesparoptionen zu deaktivieren (und sie natürlich auswählbar zu machen).

@TD-er zum WLAN-Handling: Ich stimme der Power-Management-Funktion voll und ganz zu. Man sollte es ausschalten können, da es wirklich seltsame Probleme und verzögerte Geräte verursachen kann...

Bei der Wiederverbindung zum AP sehe ich das anders, ich würde immer versuchen, mich mit dem stärksten AP zu verbinden, um eine gute Verbindung zu gewährleisten. erst danach würde ich wohl den letzten nehmen. Einfach weil, wenn der "Haupt"-AP abstürzt/neu bootet/nicht antwortet usw. das Gerät sich mit einem anderen verbinden würde. Von diesem Punkt an wird es immer das (schlechtere) nehmen, bis auch dieses versagt... es wird nie wieder zum Starken zurückkehren, auch wenn dieses wieder hochkommt... , es könnte sein, dass er den vorherigen AP auswählt, obwohl dieser viel weiter weg ist/ein schwächeres Signal hat...

Ich stimme jedoch zu, Ihren Code zu scannen und dann zu entscheiden, welcher basierend auf RSSI und bekannter BSSID verwendet werden soll...

Es ist nur der erste Versuch, sich wieder mit der letzten bekannten BSSID zu verbinden.
Dies führt zu einer stabileren Verbindung bei der Verwendung von Repeatern.
Diese Repeater können manchmal Verbindungen abbrechen, wenn sie zu beschäftigt mit anderen Aufgaben sind, und sie können beim Scannen weniger stark erscheinen. Die billigen haben nur ein Funkgerät zum Empfangen und Senden. Wenn sie also Daten empfangen, kann es sein, dass sie ihr Beacon-Signal in dem Moment, in dem ein Scan durchgeführt wird, nicht ausstrahlen. Dann kann der RSSI eines anderen AP in diesem Moment stärker erscheinen.

ok, wie wäre es mit einem "normalen" Scan, der die Stärke verfolgt? oder zumindest nach einem Neustart sollte es neu bewerten, welchen Accesspoint es wählt...

Beim Neustart und wenn der erste Versuch, eine Verbindung wiederherzustellen, fehlschlägt, wird ein Scan durchgeführt und die stärkste Übereinstimmung für die eingestellte SSID ausgewählt.

Ich werde das ändern, indem ich die BSSID des bevorzugten AP in den Einstellungen speichere, damit diese BSSID immer die bevorzugte ist.
Die Reconnects sind wirklich schnell, wenn der Kanal auch bekannt ist. (unter 200 ms sind möglich, abhängig vom verwendeten AP)
Auch das Einstellen der statischen IP dauert ungefähr 20 - 25 ms, im Vergleich zu DHCP, das 2,5 - 10 Sekunden dauert.
Das wäre ideal für batteriebetriebene Geräte.

Es gibt also Raum für Verbesserungen :)

Klingt sehr vielversprechend. Bis jetzt habe ich 2 Monate Batterielebensdauer mit 2AA-Batterien bis zu 3.3V und einem DHT-Sensor, der alle 900s sendet. Dies ist auf einer RobotDyn ESP Pro-Platine mit entferntem Spannungsregler.

@TD-er Habe gerade den Build von gestern ausprobiert. Ich kann keinen Unterschied in den Verbindungszeiten feststellen, wenn ich eine statische IP oder DHCP verwende. Beide Verbindungen dauern nach dem Zurücksetzen etwa 3 Sekunden.

Dann haben Sie einen schnellen DHCP-Server.
Meine Fritzbox braucht etwa 2,5 Sekunden für das DHCP, nach den 2,5 Sekunden die Verbindung zum WLAN.
Die Einrichtung der MQTT-Verbindung + NTP-Zeit dauert also etwa 6 - 6,5 Sekunden ab dem Booten.

Fritzbox 7490.

Schnelles Update: Nachdem ich InterESP UDP deaktiviert habe (und C13 von 1M-Einheiten entfernt habe) und das serielle Protokoll auf "non" gesetzt habe (auch den seriellen Port deaktiviert habe), laufen fast alle meine Einheiten in den letzten 30+ Stunden stabil ... eine Mischung aus D1 Mini, D1 pro, Sonoff Basic, Dual und 4ch... 20+ Einheiten... laufen auf Commit von mega-20180511, selbst kompiliert mit Arduino IDE...

Ich habe das 7581 als Modem und 3* 1750E als Accesspoints.

Übrigens: Ich laufe auf Mikrotik-APs (und einem wirklich alten USR). Ich werde die Einheiten jetzt mit dem neuesten Commit von heute Abend aktualisieren ...

Die neuesten Commits befassen sich derzeit nur mit dem JSON-bezogenen Code (Log-Viewer + Update-Sensorwerte).
Noch nicht mit dem WLAN-Code.

Sicher, aber WLAN scheint mit den neuesten Commits "stabil genug" zu sein, daher möchte ich mit meinen Einheiten auf dem Laufenden sein ;)

Entschuldigung, dass ich das nochmal ansprechen muss, aber ich erlebe immer noch das Problem, dass der ESP denkt, dass er eine IP von 0.0.0.0 hat und aufhört, mit dem Server zu kommunizieren, auf Netzwerk- und Webebene ist alles in Ordnung! siehe angehängter Screenshot, habe es mit verschiedenen Versionskombinationen von ESPEasy und esp8266 probiert...
hat das noch jemand erlebt?

In der Tat sehr seltsam, da ich mich frage, wie man die Webseite mit einer solchen IP-Konfiguration überhaupt sehen kann.
Oder verbindest du dich über dessen Accesspoint-Funktion mit dem ESP?

nein, direkt über das Netzwerk verbunden. Ping und http funktioniert ohne Probleme, schnell (siehe Client-IP ist 10.0.0.10, das ist mein Laptop, internes Netz ist 10.0.0.0/16) ... ja, aber ziemlich seltsam.
Könnte mit DHCP zusammenhängen oder so.. nach einem Neustart ist alles wieder in Ordnung..

könnte es damit zusammenhängen, dass ich nur einen Controller (FHEM) und keinen MQTT-fähigen Controller aktiviert habe? Ich habe viel mqtt-Code in den Quellen gesehen, außerhalb des Controller-Plugins ... nur eine Vermutung ... aber ich denke, es hängt nicht wirklich zusammen ...

Vielleicht ist DHCP abgelaufen und wurde nicht erneuert?

könnte sehr gut sein... wahrscheinlich hat der Netzwerkstack noch eine aktive IP, aber wenn die Erneuerung fehlschlägt, wird die entsprechende Konfiguration auf Null gesetzt... nicht sicher, wie der DHCP-Code funktioniert, aber es könnte den Status erklären, den ich sehe.

Außerdem habe ich festgestellt, dass die Einheiten nach einiger Zeit mit dem Neustart beginnen, wenn der Server (in meinem Fall fhem) nicht schnell genug reagiert. könnte ein Problem im Plugin-Code oder dem zugrunde liegenden TCP-Stack sein... Ich habe am Server einige Performance-Optimierungen vorgenommen, seitdem laufen die Einheiten viel stabiler (einige haben jetzt Betriebszeiten über 48h)..

Ich habe mit den neuesten Versionen bereits mehr als 10 Tage Verbindungs-Uptime (Uptime ohne erneute Verbindung) gesehen.
Es ist möglich, die Einheiten mit vielen Anfragen dazu zu bringen, ihren RAM aufzufüllen.
Und ich habe gesehen, wie die LWIP bei vielen Anfragen seltsame Dinge tat. (Lesen aus dem Speicher, der keine Daten enthält, die sich auf diese Anfrage beziehen.)

Heute reagiert ein Knoten wieder nicht mehr. Er hat sich vom WLAN getrennt. Ich konnte keine Verbindung zum "esp"-Netzwerk herstellen. Er hat aufgehört, Daten an den Controller zu senden. Ich musste ihn neu starten. Vielleicht wäre ein Watchdog eine gute Lösung. Wird zum Beispiel eine Stunde vom WLAN getrennt, startet es neu. Oder vielleicht geht es mit Regeln, aber ich weiß nicht wie :)

Heute habe ich viele Watchdog-Aktionen beim Debuggen eines Plugins erlebt.
Und ich weiß jetzt, dass ein Knoten manchmal angehalten bleiben kann, wenn der Watchdog eingreift.
Ein Watchdog ist also nicht die perfekte Lösung.

Ist es möglich, dass dein hängender Knoten nach dem Flashen nie neu gestartet wurde? (drücken Sie Reset oder Power Cycle)

Möglicherweise gab es nach dem Flashen keinen Neustart. Aber es war ein Blinken über www, keine Serie.

OK, dann sollte es egal sein, ob du OTA geflasht hast.
Solange nach dem seriellen Flashen ein ordnungsgemäßer Reset/Reboot stattgefunden hat.

Nun, nachdem ich mit den neuesten Firmware-Versionen mit vielen Stabilitätsproblemen und seltsamen WLAN-Problemen gekämpft hatte, musste ich am Ende zu früheren Versionen zurückkehren. Bis zum Stromausfall vor kurzem arbeitete beispielsweise ein alter ESP12E-Knoten mit mega-20180311dev 70 Tage lang und sendete Temperaturdaten an ThingSpeak.
Auf einem anderen Knoten nach dem Upgrade auf mega-20180522dev erlebte ich trotz Zurücksetzen auf die Standardeinstellungen alle 24 Stunden einen Neustart aufgrund einer Ausnahme, der nur ohne konfiguriertes Gerät ausgeführt wurde, kein NTP konfiguriert, kein Controller ... Nie überlebte 48 Stunden. Nach dem Downgrade auf mega-20180324 vor zweieinhalb Tagen die Konfiguration beibehalten, NTP einfach wieder aktiviert und soweit läuft es. Obwohl es in diesen älteren Versionen einige Fehler und fehlende Funktionen gibt, ist es für mich derzeit die beste Wahl.

Es gibt nicht viel, was jemand tun kann, wenn die Probleme nicht zuverlässig reproduzierbar sind.
Was ein wenig hilft, ist, jeden Abend einen Neustart zu planen. Dafür können Sie die Regeln verwenden.

Ich weiß, aber ich bevorzuge einen stabilen Knoten ohne geplante Neustarts. Ich weiß nicht, ob die Stabilität durch den Wechsel zu Core 2.4.1 (der vielleicht noch nicht ausgereift genug ist) erheblich verringert wurde oder ob es mit dem ESP Easy-Redesign zusammenhängt, aber es geschah trotz des maximalen Einsatzes aller ESP Easy-Mitwirkenden. Ich schätze die harte Arbeit von Ihnen allen sehr, aber derzeit kann ich die neuesten ESP Easy-Versionen nicht mehr verwenden.

Ich denke, es hängt auch mit dem verwendeten Plugin oder vielleicht einer Kombination von Plugins zusammen.

Letzte Woche habe ich daran gearbeitet, die Auswirkungen von Timings zu untersuchen, und ich bin sicher, dass dies erhebliche Auswirkungen auf zeitkritische Aufgaben haben wird.

Ich habe mir gerade einige meiner Knoten angesehen, auf denen alle offizielle Builds ausgeführt werden:

Binärer Dateiname ESP_Easy_mega-20180513_normal_ESP8266_4096.bin

Einheit 3

• Betriebszeit 16 Tage 18 Stunden 26 Minuten
• Verbunden 5d23h07m
• Letzter Verbindungsabbaugrund (201) Kein AP gefunden
• Nummer verbindet sich wieder 2

Teil 5

• Betriebszeit 11 Tage 5 Stunden 22 Minuten
• Verbunden 5d22h57m
• Letzter Verbindungsabbaugrund (201) Kein AP gefunden
• Nummer verbindet 4

Einheit 6

• Betriebszeit 11 Tage 5 Stunden 23 Minuten
• Verbunden 45 m 1 s
• Letzter Verbindungsabbaugrund (201) Kein AP gefunden
• Nummer verbindet 58

Binärdateiname ESP_Easy_mega-20180619_test_ESP8266_4096.bin

Einheit 7

• Betriebszeit 13 Tage 20 Stunden 51 Minuten
• Verbunden 5d23h05m
• Letzter Trennungsgrund (202) Authentifizierungsfehler
• Nummer verbindet sich wieder 2

Vor ungefähr 6 Tagen hatte ich einige Probleme mit einem meiner WLAN-Accesspoints, die ich neu starten musste.

Einheit 6 ist mit Einheit 3 ​​und 7 verbunden, hat jedoch viel mehr Wiederverbindungen.
Diese 3 Einheiten befinden sich direkt nebeneinander, innerhalb eines Meters voneinander, um verschiedene CO2-Sensoren (MH-Z19 A, B und SenseAir S8) zu vergleichen und alle werden von demselben Netzteil (IKEA 3-Port-USB-Ladegerät) gespeist.

Der einzige Unterschied zwischen ihnen besteht darin, dass der mit mehr Reconnects über den Senseair-Sensor verfügt.
Es könnte also sein, dass die Implementierung dieses Sensors die WLAN-Routine stärker belastet (weniger verzögerte Anrufe), was zu WLAN-Instabilität führen könnte.

Könnten Sie eine Liste der verwendeten Plugins geben?
Außerdem habe ich gestern eine Pull-Anfrage gestellt, die eine Menge Timing-Statistiken protokolliert. Vielleicht könnten Sie auf dieser Grundlage einen Build erstellen und ihn einige Minuten lang ausführen, um eine Vorstellung von Plugins zu erhalten, die viel zu viel Zeit benötigen.

Ich verwende immer die offiziellen Builds, da ich nicht in der Lage bin, die Entwicklungsumgebung für diese Geräte vorzubereiten und zu warten.
Das erwähnte Release mega-20180522dev, wie ich oben beschrieben habe, war eine komplett leere Konfiguration, also absolut keine Plugins verwendet, keine Regeln, ich habe sogar den Standard-Controller Nr1 am Ende gelöscht. Nichts konnte den Neustart des Knotens aufgrund einer Ausnahme in Intervallen von etwa 24 - 40 Stunden verhindern.

Ich weiß nicht, ob es ein WLAN-Problem ist - es sieht nicht so aus, ich habe es geschafft, statische IP-Adressen für WLAN festzulegen, aber espeasy holt es immer noch per DHCP und stellt es anders ein.

1104 : WD   : Uptime 0 ConnectFailures 0 FreeMem 21800
1105 : S
W   : State 1.00
1106 : EVENT: x#w=1.00

scandone

state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 2
c
nt 

connected with BJ3, channel 12
dhcp client start...
4350 : WIFI : Connected! AP: BJ3 (E8:DE:27:4F:66:86) Ch: 12 Duration: 3760 ms
4351 : EVENT: WiFi#ChangedAccesspoint
4355 : IP   : Static IP : 192.168.2.184 GW: 192.168.2.1 SN: 192.168.2.0 DNS: 8.8.8.8
4360 : WIFI : Static IP: 0.0.0.0 (ESP5-5) GW: 0.0.0.0 SN: 0.0.0.0   duration: 11 ms
4367 : EVENT: WiFi#Connected
4374 : Webserver: start
4374 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
ip:192.168.2.123,mask:255.255.255.0,gw:192.168.2.1
4400 : WIFI : Static IP: 192.168.2.123 (ESP5-5) GW: 192.168.2.1 SN: 255.255.255.0   duration: 50 ms
4401 : EVENT: WiFi#Connected
4406 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
4500 : MQTT : Intentional reconnect
4501 : LoadFromFile: config.dat index: 28672 datasize: 724

@uzi18 Haben Sie alle Felder für die statische IP-Konfiguration festgelegt?

Wenn ja, fürchte ich, dass es (mir) ein bekanntes Problem ist, bei dem eine vorherige Sitzung in einer Region gespeichert ist, in der wir (noch) keine Daten beim Zurücksetzen auf die Werkseinstellungen löschen.
Dies bedeutet, dass es in diesem Moment keine andere Möglichkeit gibt, als den gesamten Flash zu löschen und mit einer neueren Version von ESPeasy neu zu starten.
Die späteren Versionen setzen einen Wert, um die WLAN-Einstellungen nicht dauerhaft zu machen.

@TD-er Ja, alle Daten ausgefüllt - wie Sie im Protokoll sehen.
Ich habe NEUES Modul geflasht, mit
INFO : Plugins: 71 [Normal] [Testing] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
und es funktioniert so.
Modul wurde nur aus Originaltüte genommen und geflasht, espeasy war noch nie hier.

@TD-er: Zwei Gedanken dazu:

1. Mein nicht ESPEasy-Heizung zum MQTT-Broadcaster funktioniert einwandfrei mit dem neuesten Pubsub-Client. Verbindet sich wieder und so weiter. Vielleicht stört die ESPEasy-Konnektivitätsüberwachung, was bereits von der Kernbibliothek getan wurde. Sollten wir eine Möglichkeit haben, all das zusätzliche Ping-Reconnect-Wifistate-Zeug zu deaktivieren? Nur zum Testen?
2. Kennen Sie die automatische Abschaltung des WLANs? https://blog.creations.de/?p=149

Wäre schön, wenn jemand mit eher instabilem WLAN diesen PR testen könnte: https://github.com/letscontrolit/ESPEasy/pull/1562

@TD-er ist gerade über https://github.com/esp8266/Arduino/pull/4718 gestolpert
befasst sich mit Problemen mit der Wiederverbindung von Lwip. Ist zwischenzeitlich behoben. Vielleicht willst du es überspringen...

Ich verwende immer die neueste GIT-Version vom esp8266.. deshalb sehe ich das Problem 0.0.0.0 wahrscheinlich nicht mehr...

Gestern hat wieder ein Knoten nach dem Neustart des Routers den Kontakt zum Netzwerk verloren.
Regeln funktionierten richtig.
Dies ist mein eigener Wandschalter, es ist schwierig, ihn zum Zurücksetzen zu zerlegen.

Um dies in Zukunft zu erleichtern, habe ich die Regeln geändert:

on S1#Switch do
timerSet,1,5 
if [R1#Relay]=1
gpio,12,0
else
gpio,12,1
endif
endon

on S2#Switch do
if [R2#Relay]=1
gpio,13,0
else
gpio,13,1
endif
endon

On Rules#Timer=1 do
if [S1#Switch]=1.00
 reboot
endif
endon

Jetzt wird das Leben einfacher :))

Ich starte alle 24h neu. Dadurch wird zweimal pro Woche ein Knoten mit einer Firmware von vor 4 Wochen wiederbelebt.
Vielleicht sollte das ein fester Bestandteil sein....

Ist das immer noch ein Thema? Wenn ja, bitte wieder öffnen.

Unser längster Thread auf der Themenliste....