Espeasy: [BUG] [WiFi-Stabilität] ESP-Ausnahme 3/29, wenn Schicht 2 getrennt wird

Klingt so, als hätte ich das gleiche Problem. Manchmal hat mein Esp die WLAN-Verbindung verloren und hält sich stundenlang vom WLAN fern. Ich denke, sie müssen dank Watchdog neu starten und sich wieder mit WLAN verbinden, aber das tun sie nicht. Ein Kaltstart löst das Problem.

Das letzte, was @wolverinevn beschreibt, habe ich auch hier gesehen.

Wie wir in # 1957 besprochen haben, bin ich mir ziemlich sicher, dass viele dieser seltsamen WLAN- / Netzwerkprobleme auf diese Layer-2-Instabilität zurückzuführen sind.

Wie wir in # 1957 besprochen haben, bin ich mir ziemlich sicher, dass viele dieser seltsamen WLAN- / Netzwerkprobleme auf diese Layer-2-Instabilität zurückzuführen sind.

Ich hoffe, Sie finden die Lösung. Einer meiner Nodemcu hängt und verschwindet bis jetzt ohne Grund für 5 Stunden vom Router. Ich hoffe, es kann sich vom Wachhund erholen, aber es passiert nichts. Ich muss es jetzt manuell neu starten. Sehr genervt!

@wolverinevn Wenn Sie wieder Zugriff auf den Knoten haben, gehen Sie zu tools => advanced und setzen Sie den "Connection Failure Threshold" auf einen anderen

Die andere Problemumgehung wäre, wenn Sie einige Parameter in Ihrem Accesspoint anpassen können, je nachdem, welchen AP-Typ Sie tatsächlich haben, wenn dies optimiert werden kann ...

@ clumsy-stefan Sollten wir den Standard in ESPeasy auch auf diese Stufe setzen?

Und vielleicht sollten wir diesen Wert auch auf der Sysinfo-Seite anzeigen und für Regeln verfügbar machen?

@ TD-er ist es wahrscheinlich keine schlechte Sache, wenn es nicht zu niedrig ist (es kann immer vorkommen, dass eine Verbindung fehlschlägt).

Beim Debuggen des Problems habe ich darüber nachgedacht, wie dies gemacht wird. Derzeit erhöht jede nicht erfolgreiche Verbindung den Zähler und jede immer erfolgreiche Verbindung verringert ihn. Ich dachte darüber nach, ob es logischer wäre, es auf 0 zurückzusetzen, sobald eine erfolgreiche Verbindung zustande gekommen ist, aber ich denke, das ist ein bisschen eine ideologische Frage, was sinnvoller ist.

Das Problem mit dieser Nummer ist, dass bei 10 Aufgaben, von denen jede eine Wiederholungszahl von 10 und eine Wiederholungsverzögerung von 100 ms aufweist, die Neustarts recht schnell erfolgen, wenn ein echtes Kommunikationsproblem vorliegt (100 Wiederholungen innerhalb von etwa 10 Sekunden) .

Wenn Sie zum Beispiel immer 5 Kommunikationsfehler und 1 erfolgreiche haben, werden Sie die Verbindungsfehler kontinuierlich erhöhen. Wenn dies die ganze Zeit passiert, werden Sie den Knoten früher oder später neu starten, obwohl alle Daten geliefert werden könnten.

Das Hauptproblem, das ich jedoch sehe, ist, dass der Knoten irgendwie nicht erkennt, dass die Verbindung auf Schicht 2 tatsächlich unterbrochen ist, und weiterhin Daten sendet (denke ich). Abgesehen davon, was ich heute Abend realisiert habe, was passiert mit Syslog (und anderen Kommunikationsmitteln wie NTP usw.), wenn keine WLAN-Verbindung besteht? Wird das auch gestoppt? Dies könnte erklären, warum meine Knoten plötzlich auf 100% CPU springen, wenn Schicht 2 weg ist. Wahrscheinlich werden keine Aufgabendaten mehr gesendet, aber es versucht, die UDP-Syslog-Pakete loszuwerden und kann nicht ... nur eine Vermutung ...

Entschuldigung, langer Text für zwei einfache Fragen ... kurz:
Standardstufe: Ja, ich würde es auf das Maximum (100) oder so einstellen. Wenn alles in Ordnung ist, schadet es nicht, wenn nicht, wird das Gerät wieder zugänglich.
sysinfo Seite und Regeln: Ich würde nein sagen, warum sollte dies dynamisch geändert werden? Es ist ein Notfall Werte ...

@ clumsy-stefan Ich habe es bereits auf 50 gesetzt. Lass uns warten. ;)

@wolverinevn hmm ... 50 sollte ziemlich schnell passieren, abhängig von der Anzahl der Aufgabenintervalle und Wiederholungsversuche (5-15 Minuten) ... wenn dies nicht hilft, denke ich, dass der Knoten tatsächlich nicht eingefroren ist, aber es kann einfach ' t Stellen Sie die Verbindung zum Netzwerk wieder her. Ich hatte dies auch nach einem WD-Neustart. Können Sie sehen, ob der Knoten versucht, in den AP-Modus zu wechseln? Sehen Sie das AP-WLAN des Knotens?

sysinfo Seite und Regeln: Ich würde nein sagen, warum sollte dies dynamisch geändert werden? Es ist ein Notfall Werte ...

Ich wollte in Regeln mit einer Systemvariablen wie %conn_fail% überprüft und auf der Sysinfo-Seite neben der Anzahl der WLAN-Wiederverbindungen angezeigt werden.
Immerhin handelt es sich um einen Leistungsstatistikwert

Ich wollte in Regeln mit einer Systemvariablen wie% conn_fail% überprüft und auf der Seite sysinfo neben der Anzahl der WLAN-Wiederverbindungen angezeigt werden. Immerhin handelt es sich um einen Leistungsstatistikwert

ah, ja, stimme zu, das würde Sinn machen! Das hängt auch ein bisschen mit der Ausgabe Nr. 1993 zusammen. Ein Plugin, das regelmäßig eine Reihe von System- / Leistungsvariablen an den Controller sendet (ohne die begrenzten verfügbaren Aufgaben zu verschwenden), wäre wirklich großartig!

@wolverinevn hmm ... 50 sollte ziemlich schnell passieren, abhängig von der Anzahl der Aufgabenintervalle und Wiederholungsversuche (5-15 Minuten) ... wenn dies nicht hilft, denke ich, dass der Knoten tatsächlich nicht eingefroren ist, aber es kann einfach ' t Stellen Sie die Verbindung zum Netzwerk wieder her. Ich hatte dies auch nach einem WD-Neustart. Können Sie sehen, ob der Knoten versucht, in den AP-Modus zu wechseln? Sehen Sie das AP-WLAN des Knotens?

Ich habe 9 Aufgaben, 3 davon sind Dummy und MQTT_import. Ich denke, die Regeln sind ein bisschen mit dem Rechnen und Lesen von Sensoren beschäftigt. Ich habe versucht, mqtt_publish zu begrenzen, indem ich alle paar Minuten Regeln aufgerufen habe. Die Last liegt bei 29%.
Wie ich mich erinnere, kann ich den AP von Espeasy beim letzten Einfrieren heute Morgen nicht finden (wenn Sie meinen, dass AP_WLAN im AP-Modus arbeitet).
Mein Setup (Netzwerk, Standort von ESP) funktionierte hervorragend mit einem anderen Nodemcu mit 2.3 oder 2.4, das im März veröffentlicht wurde.

_Uptime ist 7 Stunden und 20 Minuten, RSSI ist -71dbm, es gibt ein paar WiFi um mich herum.
Letzter Trennungsgrund: | (200) Zeitüberschreitung für Leuchtfeuer
Nummer verbindet sich wieder: | 35_

@ Wolverinevn Das Problem mit diesem Problem ist, dass es völlig zufällig passiert. Ich habe ~ 30 Knoten ausgeführt, einige von ihnen hatten das Problem, einige nicht, einige neu gestartet, einige nicht in den AP-Modus ...

Es scheint wirklich eine Kombination zu sein, wie beschäftigt der Knoten ist, wie beschäftigt die Luft ist (z. B. Anzahl der WLAN-Geräte) und wie Ihr AP bestimmte Bedingungen akut handhabt (fehlende Schicht-2-Acks usw.) ...

Ich denke, bis wir innerhalb der Anwendung (ESPEasy) einen Weg finden, diesen Zustand zuverlässig zu erkennen und darauf zu reagieren, gibt es keine "echte" Lösung ...

@wolverinevn PS: Sie verwenden nicht zufällig Mikrotik-APs?

@wolverinevn Über die Anzahl der erneuten Verbindungen (in Ihrer Bearbeitung)
35 Wiederverbindungen in ca. 8 Stunden sind viel.
Ich habe hier Knoten, die tagelang laufen und nur eine Handvoll Wiederverbindungen haben.
Die stabilste läuft jetzt 20 Tage 11 Stunden 46 Minuten und nur 1 Verbindung wieder.

Verbunden | 19d22h33m
- | - -
Letzter Trennungsgrund | (202) Auth fehlgeschlagen
Nummer verbindet sich wieder | 1

@wolverinevn PS: Sie verwenden nicht zufällig Mikrotik-APs?

Ich verwende einen Router, auf dem die Padavan-Firmware (eine Art ASUS) ausgeführt wird.

@ TD-er Ich wusste es. Ich überprüfe den Grund, möglicherweise Geräusche vom Buck-Modul in der Nähe. Ein anderer hat nach 2 Stunden 0 wieder verbunden.

Ich verwende einen Router, auf dem die Padavan-Firmware (eine Art ASUS) ausgeführt wird.

Leider kenne ich diese FW überhaupt nicht ... Gibt es eine Möglichkeit, Layer 2-Parameter zu optimieren? So etwas wie Frame-Ack-Timeouts oder ähnliches? Irgendeine Art von "Entfernungs" -Einstellungen?

@ clumsy-stefan Leider sehe ich so etwas nicht.

@ clumpsy-stefan Das Gerät wurde letzte Nacht zweimal neu gestartet, wobei 50 Fehlerschwellenwerte festgelegt wurden. Gute Nachrichten sind, dass es keine gefrorenen mehr gibt. Heute werde ich versuchen, die WLAN-Verbindung durch einige geringfügige Änderungen im Hardware-Setup zu verbessern.

3 Wemos-Einheiten im selben Raum, die mit demselben AP verbunden sind.
In den letzten 16 Stunden wieder eine Verbindung hergestellt,
Mit Regel: Auf WiFi # Verbunden ....

26 WD-Neustarts und 104 Neuverbindungen:

9 WD-Neustarts und 32 Neuverbindungen

2WD-Neustarts und 40 Neuverbindungen

Alle haben 50 Fehlerschwellenwerte eingestellt

@Domosapiens & @wolverinevn Sie können auch versuchen, das Zeitlimit für Gruppenschlüssel auf Ihrem AP zu erhöhen (sofern Sie eine solche Option haben). Normalerweise sind das ungefähr 5 Minuten. Sie können versuchen, auf 30 Minuten zu erhöhen. oder sogar 1 Stunde und sehen Sie, ob es sich verbessert (solange es sich nicht in einem Super-Hochsicherheitsnetzwerk befindet, was ich nicht annehme, wenn Sie IoTs darin haben) ...

@ TD-er

Die stabilste läuft jetzt 20 Tage 11 Stunden 46 Minuten und nur 1 Verbindung wieder.

Ich habe derzeit auch Einheiten, die seit über 3 Tagen laufen, und andere, die innerhalb eines Tages neu gestartet wurden ...

Ich habe einige Probleme mit der erneuten Eingabe des Gruppenschlüssels festgestellt. Es scheint irgendwie, dass es in neueren Versionen des Kerns vorkommen kann, dass das Rekeying in eine Zeitüberschreitung gerät ... die Anwendung sollte jedoch darauf reagieren und nicht in einen nicht reagierenden Hochlastmodus wechseln ... aber ich bin es nicht sicher, wo es versagt ..

@ ungeschickt-stefan danke für deinen vorschlag.
Ich sehe in meinem dd-wrt Router einen Parameter. "Key Renewal Interval" mit dem Wert 3600 (in Sekunden).
Das sollte also in Ordnung sein?

Beim erneuten Eingeben tritt eine Zeitüberschreitung auf

Das würde nur eine stündliche Wiederverbindung imho erklären.
Dank der großartigen Regelfunktion _WiFi # Connected_ können wir dies sehen.
Keine Ahnung, wie ältere Versionen dies taten.
Ein verstecktes Problem schon lange?

Nach dem Einstellen meines Gruppenschlüssels von 5 Minuten. bis 1h laufen die Einheiten viel stabiler. Ich gehe davon aus, dass 40 Clients, die mit einem AP verbunden sind, alle 5 Minuten arbeiten. Ein Rekey hat die Luft ein bisschen zu beschäftigt. Danach konnte ich sogar das Frame-Ack-Timeout wieder verringern und die Einheiten reagierten wieder schneller. Außerdem bekam ich nach dem Ändern dieser Parameter weniger "Verbindungs-Timeouts".

@ TD-er noch denke ich, dass dieses "Gruppenschlüssel-Timeout" und das "Assoc Fail" danach von der Anwendung erfasst und verarbeitet werden müssen. Ich habe das Gefühl, dass das Gerät weiterhin versucht, Nachrichten in der Warteschlange an den Controller / Server zu senden, während es versucht, einen Neuschlüssel auszuführen, der das Gerät zu langsam macht und das erneute Empfangen fehlschlägt. Daher wird die Verbindung auf Schicht 2 getrennt.

Nur eine grobe Idee, ich versuche immer noch, sie wirklich festzunageln, aber das ist die nächste, die ich bis jetzt bekommen konnte.

@ TD-er jsut jetzt habe ich wieder einen Knoten erlebt, der in eine unbestimmte Schleife von Wiederverbindungsversuchen gerät und immer abläuft (siehe Protokoll unten). Interessant ist, dass es offensichtlich erkennt, dass es nicht verbunden ist und nicht versucht, Daten an den Controller zu senden, was bedeutet, dass die "fehlgeschlagenen Verbindungsversuche" nicht mehr zunehmen und daher niemals das Limit für fehlgeschlagene Verbindungen erreichen.

Auch die Last zeigt immer 100%, deshalb ist es wohl nicht gelungen, die Verbindung wieder herzustellen, da es immer zu langsam ist, um den Handschlag tatsächlich auszuführen. Für mich ist das wie ein Schwanzbiss. Nur der Speicher nimmt langsam ab (bis Ich nehme an, es stürzt ab, weil aus mem) ...

Ich werde mit # 2073 testen und sehen, ob diese Situation erneut auftritt ... sie tritt jedoch sehr selten auf den beiden seriell verbundenen Knoten auf, sodass ich wirklich verfolgen kann, was los ist ...

105587 : EVENT: WiFi#Disconnected
3105617 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 129 ms
3131325 : WD   : Uptime 52 ConnectFailures 84 FreeMem 12976
3134621 : EVENT: WiFi#Disconnected
3134652 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5141 ms
3141487 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3141488 : WIFI : Connecting clumsy_ap2 attempt #53
3142671 : EVENT: WiFi#Disconnected
3142700 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3153443 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3153444 : WIFI : Connecting clumsy_ap2 attempt #54
3153713 : EVENT: WiFi#Disconnected
3153743 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 157 ms
3161324 : WD   : Uptime 53 ConnectFailures 84 FreeMem 12976
3165518 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3165519 : WIFI : Connecting clumsy_ap2 attempt #55
3178542 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3178543 : WIFI : Connecting clumsy_ap2 attempt #56
3179728 : EVENT: WiFi#Disconnected
3179757 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3189704 : SYS  : 31.00,12808.00,100.00,53.00
3189708 : EVENT: sysinfo#rssi=31.00
3189743 : EVENT: sysinfo#mem=12808.00
3189773 : EVENT: sysinfo#load=100.00
3189804 : EVENT: sysinfo#uptime=53.00
3191297 : WD   : Uptime 53 ConnectFailures 84 FreeMem 12800
3191441 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3191442 : WIFI : Connecting clumsy_ap2 attempt #57
3191576 : EVENT: WiFi#Disconnected
3191606 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 125 ms
3200507 : EVENT: Clock#Time=Tue,10:25
3204458 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3204459 : WIFI : Connecting clumsy_ap2 attempt #58
3217493 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3217493 : WIFI : Connecting clumsy_ap2 attempt #59
3218677 : EVENT: WiFi#Disconnected
3218707 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3221325 : WD   : Uptime 54 ConnectFailures 84 FreeMem 12800
3245444 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3245445 : WIFI : Connecting clumsy_ap2 attempt #61
3249673 : SYS  : -80.00,12632.00,100.00,54.00
3249677 : EVENT: sysinfo#rssi=-80.00
3249709 : EVENT: sysinfo#mem=12632.00
3249741 : EVENT: sysinfo#load=100.00
3249772 : EVENT: sysinfo#uptime=54.00
3250620 : EVENT: WiFi#Disconnected
3250650 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5130 ms
3251307 : WD   : Uptime 54 ConnectFailures 84 FreeMem 12624
3259435 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3259436 : WIFI : Connecting clumsy_ap2 attempt #62
3260490 : EVENT: Clock#Time=Tue,10:26
3260650 : EVENT: WiFi#Disconnected
3260679 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1121 ms
3273521 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3273522 : WIFI : Connecting clumsy_ap2 attempt #63
3273659 : EVENT: WiFi#Disconnected
3273689 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 125 ms
3281281 : WD   : Uptime 55 ConnectFailures 84 FreeMem 12624
3287445 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3287446 : WIFI : Connecting clumsy_ap2 attempt #64

Es ist schwierig, eine Verbindung mit rssi - 80 herzustellen

Der RSSI-Wert ist nicht zuverlässig, wenn der Knoten ESP nicht verbunden ist! Der gleiche Knoten hat weniger als -70, wenn er verbunden ist. Auf Tiefschlafknoten wird beim Senden der Werte sogar die Standardeinstellung "nicht verbunden" von +31 angezeigt.
und nach einem Neustart läuft es ohne Probleme ... (ohne es zu verschieben ...) Wenn Sie oben lesen, handelt es sich um ein Layer-2-Problem, das reproduzierbar ist, wenn Sie Parameter am AP anpassen ...

PS: Du kannst es selbst versuchen! jsut verbinden Sie 20-30 Knoten und senken Sie das Zeitlimit für Gruppenschlüssel auf 5 Minuten. und der Frame-Antwort-Schwellenwert auf ungefähr 7 ... sehen Sie, was passiert!

Ich denke, es ist ein falscher Ort für Probleme mit Layer2. Sie sollten das Problem auf dem esp8266-Kern oder besser auf dem nonos sdk-Projekt ausfüllen
Aber bitte schreien Sie hier nicht

Es passiert nur mit ESPeasy und nicht mit anderen Arten von Firmware, die ich ausprobiert habe. Ich gehe davon aus, dass der Knoten zu einem bestimmten Zeitpunkt zu beschäftigt ist und dem Kern nicht genügend Zeit bleibt, um das Re-Keying durchzuführen (alles wurde mehrmals erklärt). Lesen Sie also die Debugs und Erklärungen ...
aber ich stimme zu, du musst eigentlich nicht antworten ...
PS: @ uzi18 Hatten Sie jemals 30 Knoten gleichzeitig erfolgreich ausgeführt?

@ TD-er: In ESPEasyWifi.ino Zeilen 650 - 669 bricht die Standardübereinstimmung der switch-Anweisung aus dem switch aus und daher gibt tryConnectWiFi() true , obwohl WiFi.status() ist nicht unbedingt WL_CONNECTED , kann aber ein beliebiger anderer Status sein (nur 2 falsche Rückgabezustände werden überprüft ..).

Wenn Sie dies ändern und true nur zurückgeben, wenn WiFi.status() tatsächlich WL_CONNECTED mindestens eines der Probleme mit der Trennung / Ausnahme von Schicht 2 gelöst, mit denen ich konfrontiert bin!

Was denken Sie?
Vermisse ich etwas oder warum sollte tryConnectWiFi() zurückkehren, wenn WiFi.status() nicht ist? WL_CONNECTED`?

@ clumsy-stefan Gut zu sehen, dass Sie sich immer noch mit dem WiFi-Code beschäftigen.

https://github.com/letscontrolit/ESPEasy/blob/5ee18ec556c9c58802af29f5fd78593905ef35c1/src/ESPEasyWifi.ino#L604 -L671

Die ursprüngliche Idee dieser Funktion war es, die WiFi-Verbindungssequenz zu starten.
Vielleicht hat sich seine Funktion während all der Änderungen seitdem etwas geändert.
Aber vielleicht haben Sie hier etwas vor.
Ich denke, es kann eine ordnungsgemäße Änderung von return true (am Ende dieser Funktion) nur sein, wenn der Status zurückgibt, dass es verbunden ist.

Können Sie beschreiben, was das andere Problem der Ebene 2 zu sein scheint, mit dem Sie konfrontiert sind?

Ich kann nicht genau sagen, wann die andere Ausnahme auftritt, aber es gibt zumindest einen Unterschied, wenn diese Funktion nur true zurückgibt, wenn der Status WL_CONNECTED Ich hänge das Debug vor und nach der Änderung an. .

Vor

156874 : EVENT: WiFi#Disconnected Processing time:74 milliSeconds
156876 : WIFI : Disconnected! Reason: '(0) Unknown' Connected for 2 m 32 s
156877 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
157208 : WIFI : Connecting clumsy_ap2 attempt #0
157212 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
scandone
160069 : Fatal exception 9(LoadStoreAlignmentCause):
epc1=0x40105cd4, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000003, depc=0x00000000

Exception (9):
epc1=0x40105cd4 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000003 depc=0x00000000

nach

108304 : EVENT: WiFi#Disconnected Processing time:73 milliSeconds
108307 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2014 ms
108308 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
109217 : WIFI : Connecting clumsy_ap2 attempt #1
109220 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt

connected with clumsy_ap2, channel 9
dhcp client start...
112113 : WIFI : Connected! AP: clumsy_ap2 (4C:5E:0C:39:F6:55) Ch: 9 Duration: 2895 ms
112115 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_CONNECTED
ip:10.0.10.117,mask:255.255.0.0,gw:10.0.0.2
113751 : WIFI : DHCP IP: 10.0.10.117 (wemos-mini-17-17) GW: 10.0.0.2 SN: 255.255.0.0   duration: 1636 ms
113765 : EVENT: WiFi#Connected

Hmm .. Mir ist nur klar, dass der interne Status danach (noch) nicht mit dem Arduino-Status übereinstimmt ... dies könnte auch zu Problemen führen, denke ich ...

@ clumsy-stefan Dieser Status ist, weil wir den Arduino-WLAN-Status nicht weiterleiten können. Deshalb hat @ TD-er den ESPEasy-Status eingeführt, aber ok, vielleicht können wir versuchen, noch einmal zu überprüfen, ob jeder Status im Code ordnungsgemäß überprüft wurde.

Es könnte sein, dass dieser WLAN-Status in Core 2.5.0 behoben wurde, sodass unser eigener Status möglicherweise veraltet ist.
Das wäre schön, da es den WLAN-Code ziemlich kompliziert und damit fehleranfällig macht.

Bearbeiten:
Ich schaue auf diesen Fehler, den Sie gegeben haben:
Fatal exception 9(LoadStoreAlignmentCause):
Eine der neueren Korrekturen in Core 2.5.0 betrifft den Konstruktor von IPAddress , der Probleme beheben sollte, wenn die Ausrichtung der angegebenen Bytesequenz nicht 32-Bit-ausgerichtet ist.
Vielleicht ist das etwas ähnliches?

Das ist eine der Vermutungen, die ich habe, dass der ESPEasy-Status nicht immer mit dem Arduino-Status synchron ist. Insbesondere vorübergehende Unterbrechungen auf Schicht 2 (z. B. WiFi-Rekeeyings) werden wahrscheinlich nicht wirklich gehandhabt / realisiert.

Eine andere Sache könnte das Gegenteil sein: ESPEasy glaubt, dass die Verbindung getrennt ist, und versucht, die Verbindung wiederherzustellen, aber der Kern ist immer noch verbunden und führt daher zu einer Ausnahme. kann das aber noch nicht beweisen ...

über die Ausrichtung kann ja sein, kann das aber auch momentan nicht ...

Ich bin mir also ziemlich sicher, dass der Rückkehrcode von tryConnectWiFi() mit dem tatsächlichen Verbindungsstatus übereinstimmen oder zumindest nach WL_CONNECTED suchen sollte ...

@ TD-er Ich mache mir etwas mehr Sorgen

connected with clumsy_ap2, channel 9
dhcp client start...
112113 : WIFI : Connected! AP: clumsy_ap2 (4C:5E:0C:39:F6:55) Ch: 9 Duration: 2895 ms
112115 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_CONNECTED

Für mich zeigen die letzten beiden Zeilen an, dass der Kern den Status noch nicht aktualisiert hat, obwohl ESPEasy glaubt, dass dies der Fall ist ... so dass es hier in einem Rennzustand enden könnte ...

Danach sehe ich manchmal viel

7989956 : Read settings: ControllerSettings index: 0
7989997 : Read settings: ControllerSettings index: 0
7990130 : Read settings: ControllerSettings index: 0
7990267 : Read settings: ControllerSettings index: 0
7990399 : Read settings: ControllerSettings index: 0
7990531 : Read settings: ControllerSettings index: 0
7990664 : Read settings: ControllerSettings index: 0
7990799 : Read settings: ControllerSettings index: 0
7990938 : Read settings: ControllerSettings index: 0

von dem es sich nie erholt ...

etwas später sagt es mir:

8185850 : ip:169.254.37.119,mask:255.255.0.0,gw:0.0.0.0
Read settings: ControllerSettings index: 0
8185975 : WIFI : DHCP IP: 169.254.37.119 (wemos-mini-18-18) GW: (IP unset) SN: 255.255.0.0
8185990 : EVENT: WiFi#Connected

Keine Ahnung, woher das kommt ... aber danach versucht es, eine Verbindung zum Controller / Server herzustellen, was offensichtlich fehlschlägt, bis die Versuche (100) ausgehen und neu gestartet werden ...

BEARBEITEN: Übrigens können Sie dieses Verhalten erzwingen, wenn Sie den Knoten manuell vom AP entfernen ... manchmal wird die Verbindung einfach wieder hergestellt, manchmal geschieht das, was oben beschrieben wurde ...
EDIT2: Manchmal stürzt es mit Ausnahme 9 ab ... also scheint es eine Art Rennbedingung zu sein, wie genau es sich von einer Unterbrechung erholt! Meine Schuld war ein addLog() im onDisconenct() Rückruf ...

Es ist mehr oder weniger immer die gleiche Situation. Nachdem der 4-Wege-Handshake fehlgeschlagen ist (Rekeeying), erholt er sich nie mehr ... Ich bin mir nicht sicher, wie ich eine Wiederherstellung erzwingen soll.

Wenn Sie mindestens delay(100) in processConnect() und processDisconnect hinzufügen, haben Sie die Kernzeit für die Aktualisierung des WLAN-Status, sodass die WLAN-Sättigungen wieder synchronisiert werden. Dies führt auch dazu, dass die Einheiten viel seltener in die folgende Situation geraten!

900695 : WIFI : DHCP renew probably failed
900697 : Reset WiFi.
900699 : WIFI : Connecting clumsy_ap2 attempt #0
901713 : EVENT: WiFi#Disconnected
901772 : WIFI : Disconnected! Reason: '(8) Assoc leave' Connected for 14 m 56 s
902326 : WD   : Uptime 15 ConnectFailures 44 FreeMem 20248 WiFiStatus 0
907048 : EVENT: WiFi#Disconnected
907106 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 6172 ms
907786 : WIFI : Connecting clumsy_ap2 attempt #1
911821 : EVENT: WiFi#Disconnected
911879 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3860 ms
911894 : WIFI : Connecting clumsy_ap2 attempt #2
912793 : EVENT: Clock#Time=Sat,08:29
919974 : EVENT: WiFi#Disconnected
920033 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 7962 ms
920824 : WIFI : Connecting clumsy_ap2 attempt #3
922083 : EVENT: WiFi#Disconnected
922141 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1125 ms
922805 : WIFI : Connecting clumsy_ap2 attempt #4
923138 : EVENT: WiFi#Disconnected
923196 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 133 ms
925831 : WIFI : Connecting clumsy_ap2 attempt #5
931179 : EVENT: WiFi#Disconnected
931238 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5165 ms
931775 : WIFI : Set WiFi to AP+STA
932701 : EVENT: WiFi#APmodeEnabled
932778 : WIFI : AP Mode ssid will be wemos-mini-17_17 with address 192.168.4.1
932778 : WIFI : Connecting clumsy_ap2 attempt #6
933023 : WD   : Uptime 16 ConnectFailures 44 FreeMem 17856 WiFiStatus 0
934065 : EVENT: WiFi#Disconnected
934122 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1123 ms
935712 : WIFI : Connecting clumsy_ap2 attempt #7
936042 : EVENT: WiFi#Disconnected
936106 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 169 ms
938745 : WIFI : Connecting clumsy_ap2 attempt #8
939079 : EVENT: WiFi#Disconnected
939138 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 131 ms
941778 : WIFI : Connecting clumsy_ap2 attempt #9
947130 : EVENT: WiFi#Disconnected
947189 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5140 ms
947725 : WIFI : Connecting clumsy_ap2 attempt #10
948976 : EVENT: WiFi#Disconnected
949035 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1121 ms
951805 : WIFI : Connecting clumsy_ap2 attempt #11
952140 : EVENT: WiFi#Disconnected
952199 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 134 ms
955778 : WIFI : Connecting clumsy_ap2 attempt #12
956115 : EVENT: WiFi#Disconnected
956174 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 142 ms
959734 : WIFI : Connecting clumsy_ap2 attempt #13
960064 : EVENT: WiFi#Disconnected
960123 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 129 ms

@ TD-er tryConnectWiFi() gibt ein true oder false zurück, falls die Verbindung erfolgreich war oder nicht ... jedoch überprüft das WiFiConnectRelaxed() tatsächlich nie ...

Ist diese Funktion irgendwie von vor ereignisbasiertem WiFi? es scheint, als würde es niemals die letzten 2 Zeilen in dieser Funktion erreichen ...

Ja, es war eine Art Überbleibsel vor dem ereignisbasierten WLAN.
Ich denke, wir sollten wirklich überlegen, uns diesen WiFi-Code noch einmal genauer anzusehen, da er nicht so strukturiert ist, wie er sein sollte.

ok ... Ich debugge immer noch, was genau aufgrund des 4-Wege-Handshake-Timeouts passiert und warum der Knoten die Verbindung nicht wieder herstellt. Aber ich denke, ich stochere immer noch ein bisschen im Dunkeln, finde aber hier und da kleine Teile da könnte sich das aber summieren ....

Eine andere kleine scheint in WifiCheck() ... dort wird die Überprüfung der Layer 2-Konnektivität nur durchgeführt, wenn IP nicht mehr gültig ist (z. B. alle Oktette sind 0). Dies könnte dazu führen, dass Schicht 2 die Verbindung trennt (oder erneut herstellt / Handshaking usw.), die IP jedoch weiterhin gültig ist, da sie noch nicht abgelaufen ist (DHCP). Das ist wahrscheinlich der Grund, warum die "DCHP-Erneuerung wahrscheinlich fehlgeschlagen" erst nach langer Zeit erfolgt, wenn der Mietvertrag tatsächlich abgelaufen ist ... aber ich überprüfe dies immer noch ...

Außerdem gibt es wifiCheck() , WiFiConnected() und connectionCheckHandler() die alle eine Art Verbindungsprüfung durchführen und sich unter bestimmten Bedingungen gegenseitig anrufen sowie resetWiFi() . Insbesondere connectionCheckHandler() scheint nur aufgerufen zu werden, wenn mqtt_reconnect_count > 10 . Was passiert also in einer Nicht-MQTT-Umgebung?

PS: Ich dokumentiere hier nur meine Ergebnisse auf der Suche nach den zugrunde liegenden WiFi-Problemen ... Ich freue mich über alle Gedanken dazu, aber nicht unbedingt erwartet ...

Irgendwo muss es eine mysteriöse Rassenbedingung geben. Wenn der AP eine Reauth oder Rekeeying initiiert, erhält der Knoten / Kern manchmal entweder nicht genügend CPU-Zeit, um den Handshake abzuschließen, oder er wird dabei unterbrochen, insbesondere bei Knoten mit niedrigem Signal (und daher dauert der Handshake viel länger). . (siehe unten).

Diese Neukontrollen / Reauths scheinen ein Trennungsereignis durch den Kern zu erzeugen, obwohl der Kern eine automatische Neuverhandlung oder Neuverbindung durchführen würde (wie ich verstehe). aber dann scheint es, dass dieser Handshake-Prozess von der ESPEasy-Zustandsmaschine unterbrochen wird, wenn eine manuelle Wiederverbindung ausgelöst wird ... dieser Prozess wiederholt sich und endet nie (oder erzeugt in einigen Fällen wdt's).

` 810114 : EVENT: WiFi#Disconnected 810146 : WIFI : Disconnected! Reason: '(16) Group key update timeout' Connected for 13 m 16 s 810977 : WIFI : Connecting clumsy_ap2 attempt #0 811081 : WIFI : Connection lost to: clumsy_ap2 813089 : EVENT: WiFi#Disconnected 813120 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2011 ms 814977 : EVENT: Clock#Time=Thu,08:55 821529 : WD : Uptime 14 ConnectFailures 0 FreeMem 22000 WiFiStatus 0 831976 : WIFI : Connecting clumsy_ap2 attempt #1 832079 : WIFI : Connection lost to: clumsy_ap2 836831 : EVENT: WiFi#Disconnected 836863 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 4753 ms

Vielleicht sollten wir die WLAN-Ereignisse nur verwenden, um den Prozess zu überwachen, und nicht selbst Maßnahmen ergreifen?
Wenn Sie dies ändern, werden die Builds 2.3.0 und 2.4.0 möglicherweise unbrauchbar.

Nein, das würde ich nicht tun ... In meiner Branche habe ich bereits einige (nicht so aufdringliche) Änderungen vorgenommen, die dazu führen, dass diese Fälle seltener auftreten ...

Ich habe gerade eine andere kleine Sache gefunden: In tryConnectWiFi() endet der WiFi.status() Scheck am Ende, nachdem der WiFi.begin() -Anruf beginnt, WL_DISCONNECTED . Laut Dokumentation bedeutet dies "wenn das Modul nicht im Stationsmodus konfiguriert ist". versuchen herauszufinden, warum dies passiert oder ob es tatsächlich hilft, den esp explizit in den AP-Modus zu versetzen, bevor Sie WiFi.begin() aufrufen

Daher hoffe ich immer noch, das "echte" Grundproblem zu finden, warum diese Stände auftreten ... Wenn ja (Daumen drücken), würde ich vorschlagen, dass ich eine PR mit allen Änderungen mache, die Sie (und andere) überprüfen können ...

Bitte beachten Sie, dass ich auch viele Situationen gesehen habe, in denen der Status von WiFi.status() nicht korrekt war.
Vielleicht haben die Kernbibliotheken jetzt Korrekturen und sehr wahrscheinlich habe ich auch irgendwo bei all den Versuchen, das WLAN stabil zu halten, etwas durcheinander gebracht.
Dieses Debuggen war sehr schwierig, da ich diese Probleme nicht selbst reproduzieren kann und auf Berichte anderer Benutzer reagieren musste.
In letzter Zeit habe ich ein Modul, das sich auch in Bezug auf WiFi schlecht verhält. Das ist also mein Lieblings-WiFi-Testmodul. Es kann aber auch ein Hinweis darauf sein, dass sich das Problem verschlimmert, wenn einige Teile nur knapp außerhalb der Spezifikation liegen. Zum Beispiel Stromversorgung oder fehlende Entkopplungskondensatoren, (zu) dünne Leiterplattenspuren, weniger Abschirmung usw.

Sicher, nicht, dass ich HW-Probleme ausschließe. Aber ich habe ~ 40 Knoten mit allen Arten von Netzteilen, verschiedenen Boards, Marken usw. und irgendwann haben die meisten Konnektivitätsprobleme ... insbesondere solche mit schwacher WLAN-Abdeckung oder vielen GPIOs werden verwendet.

Und ich habe momentan etwas Zeit zum Debuggen und finde es immer noch sehr interessant und herausfordernd;) Inzwischen verstehe ich sogar, wie die gesamte Abfolge von Verbinden, Überprüfen, Trennen usw. funktioniert;)

Wenn es für Sie in Ordnung ist, werde ich mich eingehender mit diesen Konnektivitätsproblemen befassen. Sie sind jedoch der Boss.

Bitte weiter graben :)
Ich möchte wirklich von all den Verbindungsproblemen befreit werden, die so gut wie unmöglich zu reproduzieren sind.
Sie haben jetzt schon viel zu lange gedauert und es wäre wirklich toll, wenn sie repariert würden.

Ich habe ungefähr 4-24 Stunden Betriebszeit, gefolgt von durchschnittlich 2-10 Stunden Ausfallzeit.
Während der Ausfallzeit arbeitet der Knoten weiter, es besteht jedoch keine WLAN-Verbindung.

Der Accesspoint (MikroTik) zeigt:

18:16:15 wireless,info 80:xx:xx:xx:xx:xx<strong i="8">@iotnet</strong>: connected, signal strength -62 
18:16:20 wireless,info 80:xx:xx:xx:xx:xx<strong i="9">@iotnet</strong>: disconnected, unicast key exchange timeout 
18:17:31 wireless,info 80:xx:xx:xx:xx:xx<strong i="10">@iotnet</strong>: connected, signal strength -60 
18:17:36 wireless,info 80:xx:xx:xx:xx:xx<strong i="11">@iotnet</strong>: disconnected, unicast key exchange timeout 

ESP Easy | Informationen |
----- | ----- |
Build: ⋄ | 20103 - Mega |
Bibliotheken: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 PUYA-Unterstützung |
GIT-Version: ⋄ | mega-20190110 |
Plugins: ⋄ | 7 [Normal] [Sonoff POW R1 / R2] |
Bauzeit: ⋄ | 10. Januar 2019 03: 21: 19 |
Binärer Dateiname: ⋄ | ESP_Easy_mega-20190110_hard_SONOFF_POW_4M.bin |

Dies war bei der älteren Version nicht das Problem (als ich noch Kanal 14 verwenden und mein Hidden-SSID-Netzwerk haben konnte).

Haben Sie den WiFi-Kanal repariert oder ist er variabel?
Ich habe auf der Fehlersuchseite von Tasmota gelesen und sie raten dringend dazu, den WiFi-Kanal reparieren zu lassen.
Wenn Kanal 14 nicht verwendet werden kann, hat sich möglicherweise irgendwo etwas an den regionalen Einstellungen geändert, da in allen Ländern nur Kanal 1-11 zulässig ist.
Auch Kanal 1, 6 und 11 sind tatsächlich die einzigen Kanäle, die ohne Störung durch andere Kanäle verwendet werden können.

Nur die Kanäle 1-10 funktionieren, nicht 11. Siehe dies: https://github.com/letscontrolit/ESPEasy/issues/1337#issuecomment -394118989

Wifi-Kanal ist natürlich fest.

Jeder Kanal kann Störungen durch andere Kanäle aufweisen und kann nicht gesteuert werden. Zur Hölle, es kann sogar Störungen durch denselben Kanal geben.

Übrigens, in Bezug auf das Problem, mit dem ich konfrontiert bin - die LED mit WLAN-Status (inverser GPIO13) ist normalerweise durchgehend blau, aber wenn das Gerät offline ist, weist es das Muster 0,0,0,0,0,1,2,3 auf. 4,5,6,7,8,9,0,0,0,0,0,0,0,0,1,2,3,4,5,6,7,8,9,0,0, 0,0,0, ... der Helligkeit.

IP und DCS wurden behoben, aber die Kanäle haben sich in der Vergangenheit nie geändert.

Von: Gijs Noorlander [mailto: [email protected]]
Gesendet: Freitag, 11. Januar 2019 21:47
An: Let'scontrolit / ESPEasy
Cc: Abonniert
Betreff: Re: [Let'scontrolit / ESPEasy] [BUG] [WiFi-Stabilität] ESP-Ausnahme 3/29, wenn Schicht 2 getrennt wird (# 1987)

Haben Sie den WiFi-Kanal repariert oder ist er variabel?
Ich habe auf der Fehlersuchseite von Tasmota gelesen und sie raten dringend dazu, den WiFi-Kanal reparieren zu lassen.
Wenn Kanal 14 nicht verwendet werden kann, hat sich möglicherweise irgendwo etwas an den regionalen Einstellungen geändert, da in allen Ländern nur Kanal 1-11 zulässig ist.
Auch Kanal 1, 6 und 11 sind tatsächlich die einzigen Kanäle, die ohne Störung durch andere Kanäle verwendet werden können.
- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie auf diese E - Mail direkt, sehen sie auf GitHub https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment-453651579 oder stumm https://github.com/notifications/unsubscribe-auth/AomgSxPjVKWrp0MSQTtbESKxFqaPVt90ks5vCPgxgaJpZM4YDivP den Faden. https://github.com/notifications/beacon/AomgS_fhHQnmg1AdpX11mVL9yNra8S_kks5vCPgxgaJpZM4YDivP.gif

Mikrotik-Sachen bieten große Leistung, aber selbst die Standardeinstellungen für WLAN sind nicht richtig.

• Stellen Sie sicher, dass Sie nicht in den Sicherheitseinstellungen tkip haben und aktivieren Sie nur aes ccm Verschlüsselung
• Geben Sie eine Schlüsselgruppe ein. Aktualisieren Sie beispielsweise 30 Minuten oder 1 Stunde
• in Kanälen haben Kanalbreite 20Mhz und meiner Meinung nach das B-Band dich und gehen nur für G / N.
• Erweiterungskanal deaktiviert
• Nur das Deaktivieren von PMKID (empfohlen, wenn Sie hinsichtlich der Sicherheit hysterisch sind) scheint die Esp-Veeeery unglücklich zu machen
• Fügen Sie Ihr Land zu den WLAN-Einstellungen hinzu (oder sehen Sie, wie hoch Ihre maximale Leistung für den AP ist, den Sie haben, und senken Sie die Sendeleistung um 3). Dies steigert sehr oft die WLAN-Leistung (kontraintuitiv, ich weiß)

Ich habe im Allgemeinen keine Verbindungsabbrüche (außer wenn ich dieses PMKID-Ding hatte)

Es wäre sowieso aufschlussreich, deine AP-Einstellungen zu posten :-)

Das sind gute Tipps. Ich bin mit Netzwerken ziemlich gut vertraut und noch erfahrener in der Mikrotik. Ich habe alle so konfiguriert, wie Sie sagen, mit Ausnahme des Gruppenschlüssels.

Die Aktualisierung des Gruppenschlüssels hat nur mit dem Gruppenschlüssel zu tun, nicht mit dem Unicast-Schlüssel, in dem auch das Problem liegt, aber ich habe diese Einstellung für die Zwecke des Experiments herabgestuft.

@ 0ki Cool wusste nicht, wo ein Experte für RouterOS!

Ich bin zu dem Schluss gekommen, dass es sich eindeutig um einen Fehler in der ESPEasy-Software handelt. Sie können das problematische Verhalten auf der rechten Seite sehen, das mit RouterOS übereinstimmt, das den sich schlecht verhaltenden Client auf der linken Seite trennt. Das Funkspektrum ist klar, wie Sie sehen.

Leider habe ich momentan keine Zeit, mich mit der ESPEasy-Codebasis zu befassen, aber ich vertraue darauf, dass dieser Vergleich von schlechter und guter Kommunikation von Nutzen sein wird.
Legende: __red - Zugangspunkt | blau - espeasy | grün - ein anderes Gerät in meinem iot-Netzwerk__

Ich glaube, dass ESP_easy aus irgendeinem Grund beschließt, nach Erhalt der Assoc-Antwort (Frame 380 links) in den AP-Modus zu wechseln und den Vier-Wege-Handshake nicht fortzusetzen. Beachten Sie auch die Änderung der Macadresse - das erste Oktett ändert sich von 80 auf 82.

@ 0ki

Ich bin zu dem Schluss gekommen, dass es sich eindeutig um einen Fehler in der ESPEasy-Software handelt.

Ich auch, aber ich habe keine Ahnung, wo der Fehler sein sollte.
Es scheint, dass der interne Status von ESPeasy bezüglich des getrennten Status nicht mit dem wahren Status synchron ist.
Es ist sehr gut möglich, dass ich beim Schreiben dieses Codes einen Fehler gemacht habe, oder es ist ein Fehler in den Kernbibliotheken.

Welche Datei meinen Sie konkret mit "diesem Code"? Wenn Sie auf ein oder zwei Dateien zeigen, könnte ich sie mir ansehen.

Ansonsten - da Sie jetzt genau den Moment sehen, in dem es passiert, hoffe ich, dass Sie es sich genauer ansehen können.

Da ich mich auch mit diesem Problem beschäftige (seit ungefähr 2 Monaten), bin ich mir nicht mehr ganz sicher, ob es sich um den ESPEasy-Code selbst handelt. eher eine Interaktion zwischen ESPEasy und dem WiFi-Kern / der WiFi-Bibliothek ... Meine Debugs / Protokolle zeigen, dass das "Trennen" immer nach einem Gruppenschlüsselaustausch / Rekeeying erfolgt. ABER der Rückruf wird erst nach dem Zeitlimit für die erneute Eingabe und anschließend nach dem Fehlschlagen der Authentifizierung aufgerufen. Ich vermute derzeit, dass ESPEasy dem Kern nicht genügend CPU-Zeit überlässt, um die erneute Eingabe tatsächlich durchzuführen. Bisher habe ich dies nicht getan Es wird jedoch kein Weg gefunden, um herauszufinden, wann sich der Knoten in diesem Rekeeying-Knoten oder im Reauth-Modus befindet und daher in der Lage ist, genügend delay() -Aufrufe hinzuzufügen, damit die Rekeeying-Reauth erfolgreich ist ...

Um das Problem zeitlich genau zu bestimmen, funktionierte es einwandfrei mit:

Build   20100 - Mega (core 2_3_0)
GIT version mega-20180224
Plugins 48 [Normal]
Build Md5   719b94a4d6bc257b86916e4989eed3a0
Md5 check   passed.
Build time  Feb 24 2018 03:03:12

Und mit ok meine ich, dass es nicht nur keine Unterbrechung gab, sondern auch, dass die Verbindung zu einem versteckten AP auf Kanal 14 kein Problem war.

@ clumsy-stefan, ich unterstütze es voll und ganz, das Problem zu lösen, das dazu führt, dass die Verbindung zunächst getrennt wird, aber ehrlich gesagt kann es eine Reihe von Gründen geben, warum ein WLAN-Verband fallen kann. Natürlich sollte ein Gruppenschlüsselaustausch nicht einer der Gründe sein Sie.

Das dringlichere Problem ist, warum es nach dem Trennen der Verbindung nicht wieder verbunden werden kann. Es kann kein Timing-Problem sein, da ich espeasy satte 5000 ms gebe, um mit Nachricht 2 des 4way HS zu antworten.

Ich denke, das Problem ist, dass Sie die Trennung erst erhalten, nachdem der Schlüsselaustausch fehlgeschlagen ist. Wenn Sie also nie jetzt anfangen, wenn der Austausch tatsächlich beginnt, müssten Sie dem Kern mehr Zeit geben ...

In den Protokollen können Sie sehen, dass ESPEasy für einige Zeit denkt, dass es immer noch verbunden ist, auch wenn dies nicht der Fall ist (selbst ein Ping an den Knoten schlägt fehl), aber der Knoten versucht immer noch, Daten zu senden (und die Verbindung schlägt dann offensichtlich fehl) ...

Das zweite Problem, dem ich vollkommen zustimme, ist, selbst wenn es getrennt wird, warum kann es nicht wieder mit einer völlig neuen Verbindungssequenz verbunden werden ... wahrscheinlich steckt das Modul oder der Kern in einem seltsamen Zustand fest?

EDIT: PS: Das 4-Wege-HS fällt nicht immer aus (ich mache es alle 10 Minuten), daher scheint es eine Kombination aus dem Zustand / der Besetztheit des ESPEasy und der Zeit zu sein, zu der das HS passiert.

Was ich tun kann, ist zu versuchen, WiFi vollständig zu löschen (Modem ebenfalls auszuschalten) und eine vollständige Neuverbindung zu starten, wenn eine unerwartete Trennung auftritt.
Ich bin mir nicht sicher, ob es in diesem Thread war, aber in einem dieser Probleme antwortete jemand mit einem Tweet von jemandem bei Shelly, der erwähnte, dass er den WLAN-Stack nach dem Trennen der Verbindung vollständig neu starten müsse.

@ TD-er das habe ich auch in meine neueste Version eingefügt. Innerhalb von processDisconnect() ich ein setWifiMode(WIFI_OFF); hinzugefügt. Ich bin mir jedoch nicht sicher, ob das ausreicht. Derzeit läuft es auf einigen Testknoten (seit ca. 1 Stunde).

@ TD-er das ist eine coole Idee. Drücken Sie eine Git-Veröffentlichung und ich werde meine Sachen flashen!

Ich habe gerade vor 5 Minuten angefangen, einen Teil der Codebasis zu lesen, daher ist dies möglicherweise irrelevant, aber: Stellen Sie außerdem sicher, dass wifi_connect_attempt zu diesem Zeitpunkt auf 0 gesetzt ist.

hmm ... das Hinzufügen von delay(0) in backgroundtasks() nach jedem Unterprogrammaufruf scheint das erste Problem ein wenig weiter zu stabilisieren (4way-HS). Ich bin mir nicht sicher, ob es ein schwieriger Zufall ist ...
@ TD-er könnte es sein, dass backgroundtasks() irgendwann die Ausführung blockiert?

Im Allgemeinen: Das Hinzufügen von delay(0) an verschiedenen Stellen, an denen die Zeitstatistiken lange Verarbeitungszeiten anzeigen, scheint das 4way-HS-Handling erheblich zu verbessern. Ich habe jetzt mehr SW / HW-Wachhunde als Probleme beim erneuten Empfangen (aber immer noch einige) ... symptomatisch, also würde ich sagen, dass es wirklich damit zusammenhängt, dass der Kern- / WLAN-Teil nicht genügend Zyklen erhält, um tatsächlich (ziemlich schnelle) Dinge wie das erneute Empfangen zu erledigen und der AP wird es leid, auf eine Antwort zu warten ...

Was ich auch sehe, ist, dass manchmal das client.connect() oder das sendData() ziemlich viel Zeit in Anspruch nehmen kann (bis zu 2 Sekunden). In einigen Dokumentationen habe ich festgestellt, dass Sie, wenn etwas länger als 50 ms dauert, delay(0) dazwischen aufrufen sollten ... aber Sie können diese Aufrufe nicht aufteilen, da sie von der Bibliothek ausgeführt werden ...

Es gibt auch einen weiteren Rückruf onStationModeAuthModeChanged im Kern. Wahrscheinlich lohnt es sich, einen Blick darauf zu werfen, da dieser wahrscheinlich ausgelöst wird, bevor die eigentliche Trennung erfolgt. aber es ist sehr wenig dokumentiert ... Hat jemand Erfahrung damit?

EDIT: Es scheint eine Zufalls- / Rennbedingung zu sein, bei der einige andere Dinge zu dem Zeitpunkt erledigt werden, als der AP eine erneute Eingabe anfordert ... aber auch hier nur Beobachtungen ...

Ich weiß nicht, wie oft diese vom AP gesendeten Anfragen erneut übertragen werden.
Normalerweise wird das Beacon-Signal vom AP alle 102,4 ms gesendet. Wenn einige Aufgaben mehr als das erfordern, fehlt dem ESP einer dieser Beacon-Frames. Ich bin mir also nicht sicher, wie schlimm das ist.
Ich weiß, dass ARP-Anforderungen manchmal übersehen werden, was zu Problemen führt, dass ein Switch nicht mehr weiß, wie Pakete an diese MAC-Adresse weitergeleitet werden sollen, und somit das ESP nicht erreichbar macht, während es weiterhin Daten selbst senden kann.

fehlende Beacon-Frames sind nichts. Es sollte nicht einmal Beacon-Frames benötigen, da es sowieso aktiv nach meinem versteckten Netzwerk suchen sollte.

Ich bin kein Experte für WiFi.
So wie ich es verstanden habe, ist das Beacon-Intervall der einzige - etwas garantierte - Moment, in dem das ESP versucht, auf das WLAN zu hören, und dazwischen wird es versuchen, so viel wie möglich zu schlafen.

Und wie ich es verstanden habe, besteht der einzige Unterschied zwischen "versteckten" Netzwerken und "nicht versteckten" Netzwerken darin, dass die SSID nicht gesendet wird. Tatsächlich wird die Verbindung also nur basierend auf der BSSID (MAC-Adresse des AP) hergestellt.
Dies ist auch das, was der ESP tut, wenn er eine Verbindung zu (nicht versteckten) WiFi-Netzwerken herstellt, mit dem einzigen Unterschied, dass er zuvor einen Scan durchführt und versucht, eine BSSID zu finden, deren SSID mit der angegebenen übereinstimmt.
Wenn Sie eine automatische Wiederverbindung durchführen, wird zuerst die letzte bekannte BSSID + -Kanalkombination versucht, ohne einen Scan durchzuführen. Mit anderen Worten, es unterscheidet sich nur beim Herstellen einer Verbindung.

Meines Wissens werden also, solange eine Verbindung zu einem Netzwerk besteht, auch die Beacon-Frames abgehört.

Ich bin kein Experte für WiFi.
So wie ich es verstanden habe, ist das Beacon-Intervall der einzige - etwas garantierte - Moment, in dem das ESP versucht, auf das WLAN zu hören, und dazwischen wird es versuchen, so viel wie möglich zu schlafen.

Und wie ich es verstanden habe, der einzige Unterschied zwischen "versteckten" Netzwerken und "nicht versteckten" Netzwerken ..........

Oh, das erinnert mich an etwas, das ziemlich wichtig sein kann. Ich führe meine ESPs in einer versteckten SSID aus
Übrigens immer noch keine Unterbrechungen oder Neustarts auf meinen Knoten (versuchen 5 Minuten Gruppenschlüssel-Updates)

Einer meiner Knoten wurde am 5. Dezember aufgrund eines Stromausfalls neu gestartet.

Dies ist von diesem:

Einheit: | 5
- | - -
Ortszeit: | 2019-01-15 23:27:32
Betriebszeit: | 41 Tage 12 Stunden 46 Minuten
Laden: | 15,80% (LC = 9135)
Free Mem: | 12160 (5360 - sendContentBlocking)
Freier Stapel: | 3552 (1520 - SensorSendTask)
Booten: | Kaltstart (0)
Grund zurücksetzen: | Externes System
Netzwerk ❔
Wifi: | 802.11N (RSSI -67 dB)
IP-Konfiguration: | DHCP
IP / Subnetz: | 192.168.1.89 / 255.255.255.0
GW: | 192.168.1.1
Client-IP: | 192.168.1.67
DNS: | 192.168.1.1 / 0.0.0.0
Zulässiger IP-Bereich: | Alles erlaubt
STA MAC: | 5C: CF: 7F: B1: 3F: 12
AP MAC: | 5E: CF: 7F: B1: 3F: 12
SSID: | Lurch4 (34: 31: C4: B1: 8D: C7)
Kanal: | 11
Verbunden: | 20h04m
Letzter Trennungsgrund: | (202) Auth fehlgeschlagen
Nummer verbindet sich wieder: | 61
Firmware
Build: ⋄ | 20102 - Mega
Bibliotheken: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 PUYA-Unterstützung
GIT-Version: ⋄ | Mega-20181109
Plugins: ⋄ | 46 [Normal]
Build Md5: | 47f19d99d0c3f083314b45668b1f5c
Md5 prüfen: | bestanden.
Bauzeit: ⋄ | 9. November 2018 03:23:22
Binärer Dateiname: ⋄ | ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Wie Sie sehen können, wird durchschnittlich mehr als eine Verbindung pro Tag getrennt. Es ist an eine AVM Fritzbox 1750E angeschlossen

Ich denke, die Beacon-Frames sind nicht so kritisch ... Ich bin mir immer noch nicht sicher, warum nach einer Trennung die normale WiFi.begin() -Sequenz immer mit einem '(2) Auth expire' fehlschlägt.

Der einzige Hinweis ist, dass die CPU-Auslastung zu diesem Zeitpunkt immer 100% anzeigt und darauf hindeutet, dass der Kern einfach nicht genug Zeit für den Handshake hat ...

Ich vermute, dass in den Kernbibliotheken (LWIP oder Arduino oder ESP) etwas nicht stimmt und wir das WLAN zurücksetzen sollten.
Schalten Sie also das WLAN aus und beginnen Sie von vorne. Warten Sie möglicherweise auch zwischen diesen Schritten, um sicherzustellen, dass die Puffer geleert oder zumindest geleert werden und ausstehende Anforderungen aktiv abgebrochen werden.

@ TD-er kannst du diese Änderung vorantreiben, damit ich sehen kann, ob sie funktioniert?

Die Änderung in den letzten 2 Beiträgen diskutiert?
Es wurde noch nicht implementiert, aber ich kann heute Abend versuchen, es zu codieren und einen Testbuild zu erstellen.

Ja, das WiFi zurücksetzen.

@ TD-er schrieb:

Schalten Sie also das WLAN aus und beginnen Sie von vorne. Warten Sie möglicherweise auch zwischen diesen Schritten, um sicherzustellen, dass die Puffer geleert oder zumindest geleert werden und ausstehende Anforderungen aktiv abgebrochen werden.

Ich bin mir nicht sicher, ob ich spülen soll ... da ich alle client.flush() -Anrufe vor dem client.stop() Es schien auch, dass die Trennung weniger häufig vorkommt. Beim Lesen einer Dokumentation habe ich festgestellt, dass der Flush alle (TCP-) Eingabepuffer emittiert. Theoretisch kann es also vorkommen, dass Antworten verloren gehen ...

Wenn ich nur meine 2c hinzufüge, habe ich ein paar Mikrotik-APs, mit ein paar Sonoffs, auf denen espurna läuft, und ein paar NodeMCUs, auf denen ESPEasy läuft. Ich musste einen zusätzlichen AP für die ESP-Geräte hinzufügen, da ich während eines Zeitraums mit hohem Datenverkehr in meinem Netzwerk, wie z. B. Backups, meine ESP-Geräte verlieren würde. Ich denke, das war WiFi-Signalstärke und Verkehr. Nachdem der zusätzliche AP hinzugefügt wurde, kann ich mich nicht mehr daran erinnern, dieses Problem erneut gesehen zu haben.

Meine NodeMCUs und ESPEasy-Geräte weisen jedoch einige Verbindungsabbrüche auf. Ich werde einen NetData-Ping-Monitor für Geräte einrichten und prüfen, ob ich herausfinden kann, wann, wie und warum dies geschehen kann, und prüfen, ob ich einige Informationen zurückgebe.

Ein weiterer Hinweis: Ich habe nicht mehr als 40 Geräte wie @ clumsy-stefan, nur etwa 5 Benutzer und deren mobile Geräte und das eine oder andere intelligente Gerät wie TV. Könnte es aber sein, dass entweder das Mikrotik-Gerät überlastet oder das WLAN-RF-Netzwerk gesättigt ist ?

Ich wünschte, ich hätte eine Möglichkeit, die Menge des HF-Rauschens zu sehen. Ich habe eine App (WiFi Analyzer), die mir die Anzahl der APs und deren Verteilung auf die WiFi-Kanäle anzeigt. Ich habe dieses Tool verwendet, um meine WiFi-Kanäle für verschiedene WiFi-APs einzustellen.

Kann aber nicht wirklich sagen, ob es andere HF-Störungen geben könnte.

Für die Idee eines überlasteten Mikrotik-Geräts verwende ich MikroTik 951UI-2HND für meinen Hauptrouter und MikroTik RB9412nD hAP lite als meinen ESP-AP.

Ich frage mich, ob diese Informationen in irgendeiner Weise nützlich sind.

@LeeNX danke für die Hinweise. Meine Knoten sind auf 3 APs verteilt und die RF ist etwas ausgeglichen (max. 20 Clients pro AP oder so), so dass es so wenig Interferenzen wie möglich gibt (natürlich kann es keine geben ...). Ich glaube also nicht, dass die MTs überlastet sind (ich arbeite in einem Unternehmen, das Netzwerk-Backbone-Konnektivität und WLAN für professionelle Veranstaltungen usw. bereitstellt, daher habe ich einige eingehende Tests des Infrastrukturers), aber ich stimme zu, dass überlastete Sendezeit möglich ist ein Problem sein ... aber selbst wenn dies der Fall ist, kann ein Knoten nach einer Unterbrechung> 250 Mal keine Verbindung mehr herstellen und nach einem Neustart wird die Verbindung sofort wieder hergestellt. Ich denke, es kann kein Problem mit der Sendezeit sein. Ich sehe das auf keinem anderen Gerät ...
Ich denke also immer noch, dass es ein Zufall oder eine Rennbedingung zwischen dem Zustand des internen WLAN-Chips, der CPU-Zeit, die der WLAN-Kern erhält, und den anderen Aufgaben, die auf dem ESPEasy-Teil ausgeführt werden, ist.

@ plumsy-stefan Ich stimme deinen Einsichten zu. Ich wollte nur darauf hinweisen, dass die Verwendung des kleinen Mikrotik-AP mit mehr als 40 Knoten eine Mikrotik-CPU oder RAM-begrenzt sein könnte, aber das scheint nicht das Problem zu sein.

Ich frage mich, ob ich ein ESP32- und NodeMCU-Gerät mit nichts anderem als dem Basis-ESPEasy-Kern dpeloying und das laufen lassen soll, damit wir die ESP-CPU und keinen anderen Plugin-Einfluss testen können. Sehen Sie, was ich bereitstellen und NetData-Ping-Test.

Wenn dies uns nützliche Informationen gibt, werde ich zurückmelden.

Danke Leute!!!

Ich habe hier einen Knoten, der so gut wie nichts läuft (IR RX / TX) und der wochenlang ohne Probleme läuft.
Auf dem anderen Knoten mit einer Betriebszeit von über 40 Tagen werden Domoticz MQTT und BME280 + MH-Z19 CO2 ausgeführt.
Es wird also wahrscheinlich auch davon abhängen, welches Plugin wie oft ausgeführt wird und vielleicht auch, ob das Leseintervall immer mit dem Leseintervall anderer Plugins übereinstimmt.

Ich habe bereits einige periodische Funktionsaufrufe (10 / s, 1 / s und 30 s) mit einem anfänglichen Versatz im Scheduler festgelegt, damit sie in verschiedenen Schleifenaufrufen so weit wie möglich ausgeführt werden.

Vielleicht sollte ich auch ein Interrupt-Timer-gesteuertes Ereignis hinzufügen, wie es Tasker tut (oder einfach Tasker anstelle des von mir geschriebenen Schedulers verwenden) und eine Task im Intervall von 10 ms einstellen, um die Verzögerung (0) auszuführen.
Das einzige ist, dass es andere GPIO-Übertragungen unterbrechen und somit die Sensorwerte stören kann.

Das würde wahrscheinlich das 4way-HS-Problem lösen, aber ich denke nicht das Problem der erneuten Verbindung ... das ist immer noch das seltsamste ... Ich hatte gerade 12 Stunden lang einen erneuten Ausfall meines Testknotens, als ich versuchte, die Verbindung für> 300 Mal ohne AP wiederherzustellen Erfolg. Nach dem (Soft-) Neustart wurde die Verbindung sofort wieder hergestellt (Neustart + Wiederverbindung dauerte ungefähr 5 Sekunden) ...

Ich habe gerade dieses Problem gefunden, das ziemlich verwandt mit dem ist, was wir hier sehen:
https://github.com/esp8266/Arduino/issues/5527

sieht ähnlich aus, ja ... aber das Aufrufen von Wifi OFF scheint es nicht zu ändern (habe das versucht). Derzeit versuche ich es mit WiFi.setOutputPower(0) bevor ich WiFi.begin() anrufe, wie hier vorgeschlagen
https://github.com/esp8266/Arduino/issues/2235
und hier
https://github.com/esp8266/Arduino/issues/2186#issuecomment -233853152
Ich warte immer noch darauf, dass es jetzt hart wird ...

es ist ähnlich, aber es ist nicht dasselbe. In unserem Fall löst ein Neustart des AP das Problem. In dem von Gijs veröffentlichten Problem löst ein Neustart des AP das Problem nicht.

@ giig1967g Neustart des AP löst es nicht für mich! Nur ein Neustart des Knotens führt zu einer erneuten Verbindung (allerdings in meiner Umgebung) ...

@ giig1967g In dem von @ clumsy-stefan erwähnten Problem wird dieser Neustart des AP auch erwähnt: https://github.com/esp8266/Arduino/issues/2235#issuecomment -248851270

Es scheint also, dass wir hier einige Probleme haben.

@ ungeschickt-stefan
Ah ok. Und in meinem Fall nur mit Mikrotik ... :(
@ TD-er
Vielleicht sollten Sie sich fragen, welche AP-Marke / welches AP-Modell sie verwenden ...

@ giig1967g Ich hatte auch einige Knoten hier, die nicht erreichbar waren, aber das Intervall dieser Ereignisse betrug viel mehr als 10 Tage, so dass es ein bisschen schwer zu sagen ist, ob es mit einem dieser Probleme zusammenhängt.
Etwa die Hälfte meiner Knoten ist jetzt mit einer Mikrotik verbunden und die andere Hälfte ist mit der Fritzbox 1750E verbunden

@ giig1967g Ich habe auch nur PCFs) zu passieren ...

Ich wünschte, ich hätte eine Möglichkeit, die Menge des HF-Rauschens zu sehen. Ich habe eine App (WiFi Analyzer), die mir die Anzahl der APs und deren Verteilung auf die WiFi-Kanäle anzeigt. Ich habe dieses Tool verwendet, um meine WiFi-Kanäle für verschiedene WiFi-APs einzustellen.

Kann aber nicht wirklich sagen, ob es andere HF-Störungen geben könnte.

Sie können /interface wireless registration-table print interval=1 auf Ihrer Mikrotik ausführen, um den Snr zu sehen.

Leider hat das WiFi.setOutputPower(0) auch nicht geholfen ... nach fast 6 Stunden reibungslosem Betrieb (ohne Änderungen an der WLAN-Infrastruktur gerät es plötzlich wieder in einen Deadlock (siehe serielle Ausgabe unten), von dem es sich nie wieder erholt. außer wenn zufällig ein SW oder HW WDT einsetzt ...

Dies scheint nur nach einem "Timeout für die Aktualisierung des Gruppenschlüssels" oder einem "4-Wege-Handshake fehlgeschlagen" zu geschehen. Wenn ich den Knoten manuell vom AP trete, wird auch ein "Auth Expire" angezeigt, der jedoch sofort wieder verbunden werden kann ...

serieller Ausgang (obwohl die Last dann auf 100% geht) ...

20457441 : WIFI : Disconnected! Reason: '(16) Group key update timeout' Connected for 2h19m
20457593 : WIFI : Connecting clumsy_ap2 attempt #0
20458607 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20459707 : EVENT: WiFi#Disconnected
20459763 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2012 ms
20470762 : SYS  : 31.00,20048.00,66.70,341.00
20470766 : EVENT: sysinfo#rssi=31.00
20470824 : EVENT: sysinfo#mem=20048.00
20470882 : EVENT: sysinfo#load=66.70
20470940 : EVENT: sysinfo#uptime=341.00
20472658 : EVENT: Clock#Time=Thu,14:22
20473264 : WD   : Uptime 341 ConnectFailures 22 FreeMem 20040 WiFiStatus 0
20477609 : WIFI : Connecting clumsy_ap2 attempt #1
20478135 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20482577 : EVENT: WiFi#Disconnected
20482635 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 4771 ms
20503270 : WD   : Uptime 342 ConnectFailures 22 FreeMem 18440 WiFiStatus 0
20505709 : WIFI : Connecting clumsy_ap2 attempt #2
20506235 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20509784 : EVENT: WiFi#Disconnected
20509845 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3879 ms
20530897 : SYS  : 31.00,16248.00,100.00,342.00
20530902 : EVENT: sysinfo#rssi=31.00
20530963 : EVENT: sysinfo#mem=16248.00
20531025 : EVENT: sysinfo#load=100.00
20531087 : EVENT: sysinfo#uptime=342.00
20532688 : EVENT: Clock#Time=Thu,14:23
20533158 : WD   : Uptime 342 ConnectFailures 22 FreeMem 16240 WiFiStatus 0
20533716 : WIFI : Connecting clumsy_ap2 attempt #3
20534242 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20537788 : EVENT: WiFi#Disconnected
20537851 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3865 ms

Nur eine kurze Bemerkung: Das Hinzufügen von wifi_set_phy_mode(PHY_MODE_11G); und das Erzwingen des Knotens in den 802.11g-Modus scheint zumindest eine Problemumgehung zu sein. Ich habe seit ein paar Stunden keinen Neustart einer der Einheiten mehr und auch ein- oder zweimal eine Einheit, die nach dem oben genannten Problem mit dem Gruppenschlüssel-Timeout wiederhergestellt wurde ...
wahrscheinlich verwandt mit

• ESP8266 SoftAP unterstützt nur 802.11b / g.

was in den Dokumenten vermerkt ist ...

Ich werde später / morgen aktualisieren, wenn es stabil bleibt ...

Wie bereits (einige Male) von einer anderen Person erwähnt, sollte die Empfindlichkeit auch durch Umschalten auf 802.11G erhöht werden.
Mein Ziel dagegen ist (war?), Dass die meisten AP Probleme beim Umschalten zwischen N, G und B haben.
Haben Sie gemischte Kunden? (G und N) auf demselben AP aktiv?

Ich benutze bei allen Mikrotik verschiedene Modi. B / G / N / AC gemischt, auch beide Bänder 2 / 5GHz einschließlich definierter virtueller APs ... Verschiedene Clients stellen ohne Probleme eine Verbindung mit verschiedenen Modi auf demselben AP her (außer dem esp8266).

Gute Nachrichten (zumindest für mich) ... meine Knoten liefen die letzten 12 Stunden ohne Unterbrechungen / Neustarts / Einfrieren!

Das Erzwingen des Knotens in 802.11g scheint reibungslos mit den MikroTik-APs zusammenzuarbeiten. Zumindest ist dies eine einfache Problemumgehung (solange Sie nicht die zusätzliche Geschwindigkeit von 802.11n benötigen).

Wenn jemand sich selbst testen möchte, fügen Sie einfach ESPEasyWifi.ino um Zeile 644 in Funktion tryConnectWiFi() die folgende Zeile ein (nach setupStaticIPconfig(); ):
WiFi.setPhyMode(WIFI_PHY_MODE_11G);

Ich kann nur vermuten, dass die Probleme auftreten, weil der SoftAP-Modus 802.11n nicht unterstützt und der Knoten im N-Modus verbunden ist. Der Kern wird irgendwie "verwirrt" ... aber ich denke, dies ist ein Problem, das bei den Core-Leuten auftreten muss. ..

Für ESPEasy könnte dies konfigurierbar gemacht werden (@ TD-er?), So dass auf der Konfigurationsseite ausgewählt werden kann, in welchem ​​Modus das ESP ausgeführt werden soll (B / G / N) ...

Ja, ich werde eine Auswahloption in den erweiterten Einstellungen hinzufügen.
Ich habe vergessen, wer es zuerst gefragt hat, werde es aber nachschlagen und ihm auch das Commit gutschreiben;)

perfekt!! Ich brauche den Kredit nicht, ich brauche ihn nur, um zu funktionieren;) also zögern Sie nicht, ihn ihm zu widmen !! 😄

Während des Debuggens habe ich einige andere kleine Dinge gefunden, die ich ändern möchte (wie das bedingungslose Aufrufen von delay() nach Plugin-Aufrufen, einige zusätzliche {} und einige Ergänzungen zur Protokollierungsausgabe. Sollte ich eine PR für machen diese ASPIT oder möchten Sie es so lassen, wie es ist (ich denke, dies sind keine wesentlichen Änderungen, nur einige geringfügige Verbesserungen wahrscheinlich)?

Bitte machen Sie eine PR.
Es würde zumindest die Diskussion unterstützen und Ihre Ergebnisse verfolgen.
Es wäre auch hilfreich, Kommentare zu dem hinzuzufügen, was Sie überprüft haben

Als Referenz # 2012
Alle Credits an den Entwickler. Mannschaft!

Enthält dieser Patch auch die Idee WiFi.setOutputPower (0)?

Ich habe jetzt seit 7 Tagen ein Experiment durchgeführt.
Mega-20180224-Knoten - Null Neustart
Mega-20190110-Knoten - 35 Neustarts; 9 von ihnen heute.

Ich habe die entsprechende Zeile im Code belassen, sie aber auskommentiert. Sie müssten also das // (ungefähr in Zeile 644) in ESPEasyWiFi.ino entfernen und neu kompilieren!

@oki Entschuldigung, ich habe gerade gesehen, dass ich Ihre Frage falsch gelesen habe ... Nein, dies ist nicht enthalten, da ich keinen Unterschied

Ich habe jetzt seit 7 Tagen ein Experiment durchgeführt.
Mega-20180224-Knoten - Null Neustart
Mega-20190110-Knoten - 35 Neustarts; 9 von ihnen heute.

Das ist effektiv zu vergleichen:

• Kern 2.3.0 ohne ereignisbasiertes WLAN
• Kern 2.4.2 mit ereignisbasiertem WLAN.

Gute Nachrichten (zumindest für mich) ... meine Knoten liefen die letzten 12 Stunden ohne Unterbrechungen / Neustarts / Einfrieren!

Das Erzwingen des Knotens in 802.11g scheint reibungslos mit den MikroTik-APs zusammenzuarbeiten. Zumindest ist dies eine einfache Problemumgehung (solange Sie nicht die zusätzliche Geschwindigkeit von 802.11n benötigen).

Ich habe es zum Testen umgekehrt gemacht.
Ich habe meine Mikrotik nur auf N-Mode eingestellt und nun ... alle ESPs laufen seit> 12h ohne einen einzigen Neustart.

guter und gültiger Ansatz auch! Leider kann ich das nicht tun, da ich eine Anzahl von Clients ohne N-Fähigkeit mache ...

Deaktivieren Sie einfach den B-Modus und aktivieren Sie nur G / N. Ohne den B-Modus sind Sie besser dran. Es sei denn, Sie haben alte Telefone oder (normalerweise) WLAN-Barcode-Scanner aus 10 Jahren, die nur den B-Modus und die Tarife unterstützen.

Die zusätzliche Empfindlichkeit der Antenne im B-Modus wird auch in der Reichweite keine wesentliche Rolle spielen. Der B-Modus verschlingt nur die Sendezeit. Es gibt buchstäblich keinen Nachteil, wenn der B-Modus nicht verwendet wird, und keinen Nachteil, wenn der N-Modus auch über G verwendet wird. Der N-Modus hat eine noch bessere Reichweite als B und G.

@ jimmys01 du hast recht, der B-Modus wird wahrscheinlich nirgendwo mehr verwendet ... aber ich kann nicht nur N wählen ... daher wäre es an der Zeit zu testen, was im G / N-Modus passiert, wenn die Knoten stabil bleiben und können im Falle eines 4-Wege-HS-Timeouts wieder eine Verbindung herstellen.

g / n ist für mich instabil.

Bedeutet dies, dass der esp8266 bei jedem Übergang zwischen einem Modus (B / G / N) in Schwierigkeiten gerät?

Bedeutet dies, dass der esp8266 bei jedem Übergang zwischen einem Modus (B / G / N) in Schwierigkeiten gerät?

Sehr wahrscheinlich.
Ich habe viele Probleme mit einigen Geräten (nicht ESP-Geräten) gesehen, die nur den G-Modus unterstützen.
Wenn Sie sie gemischt mit N Geräten verwenden, können sie als nicht erreichbar erscheinen.
Bekannt sind der HomeWizard und einige WiFi-Kameras.

Mit dieser neuen Version mega-20190121 scheint das ESP stabiler zu sein, ich hatte bis jetzt keine Crash / Wlan-Probleme.
Aber jetzt kann ich die OLED (framedPlugin) nicht mehr ausschalten. Wenn ich OLEDFRAMEDCMD sende, schaltet es die Anzeige für einen sehr kurzen Moment aus und dann wieder ein.
Ich habe einen Back-to-Back-Test mit einer alten Version (ab 2018) durchgeführt. Das Display reagiert wie erwartet.

Gerade Mega-20190121 ausprobiert und WiFi-Stabilität ist die gleiche. Es stürzt innerhalb von etwa einer Stunde nach dem Start ab.

@ TD-er, wann denkst du, könntest du eine Version mit der besprochenen Änderung pushen, damit ich sie testen kann?

Schnelles Update: Seit dem Einstellen des Modus-Fixes auf 802.11g habe ich keine Einfrierungen, Neustarts usw. mehr! Obwohl die APs im gemischten G / N-Modus arbeiten ... würde ich auch für einen Patch stimmen, der den WLAN-Modus auf der Esp konfigurierbar macht!

Hoffe auch bald auf einen Patch 😉

Ich habe gerade ein Commit hinzugefügt, um nur das B / G auszuwählen.
Es funktioniert noch nicht gut auf ESP32, daher habe ich die Option deaktiviert, es für ESP32 auszuwählen.
Ich habe auch eine Fallback-Option hinzugefügt, um wieder eine Verbindung herstellen zu können, wenn der AP nicht nur B / G zulässt.

@ TD-er Ich meine diese Änderung:

Ich vermute, dass in den Kernbibliotheken (LWIP oder Arduino oder ESP) etwas nicht stimmt und wir das WLAN zurücksetzen sollten.
Schalten Sie also das WLAN aus und beginnen Sie von vorne. Warten Sie möglicherweise auch zwischen diesen Schritten, um sicherzustellen, dass die Puffer geleert oder zumindest geleert werden und ausstehende Anforderungen aktiv abgebrochen werden.

Die Änderung in den letzten 2 Beiträgen diskutiert?
Es wurde noch nicht implementiert, aber ich kann heute Abend versuchen, es zu codieren und einen Testbuild zu erstellen.

@oki Ich habe beide Varianten ausprobiert, die Ausgangsleistung auf 0 gesetzt und die Verbindung aktiv getrennt / wieder hergestellt, wenn das Problem auftritt. Beide Versionen haben nicht geholfen, den AP zurückzusetzen / wieder herzustellen ... (in meiner Umgebung) ... mehr Details oben ...
Das einzige, was es stabil machte, war die Verwendung des N-Modus.

Das ist mir klar. Ich hoffe bald auf einen Patch, damit ich mein Debuggen fortsetzen kann.

@ 0ki Mit diesem neuesten Commit kann ich ein Testbuild für Sie erstellen.
Oder möchten Sie auch mit der Deaktivierung von WiFi testen?

Und wenn ja, welche Optionen möchten / benötigen Sie? WiFi aus / ein und alle Dienste neu starten?
Dieser letzte Teil (Neustart von Diensten) ist auch eine Sache, die Sie sich genauer ansehen sollten, da ich nicht ganz sicher bin, ob alle Dienste, die einen Socket verwenden, ordnungsgemäß neu gestartet werden.
Das kann auch einige Probleme verursachen, wenn die WiFi-Verbindung wiederhergestellt wird.

Automatisches vollständiges Aus- und Einschalten des WLAN-Senders, wenn eine Unterbrechung festgestellt wird.

Ich sehe, dass Sie Code hinzugefügt haben. Welche Version kann ich ziehen, um dies zu testen?

Ich bin mir nicht sicher, ob ich einen neuen Build zum Testen erstellen werde.
Es wird in +/- 30 Minuten erledigt sein.

Test Build
Es basiert auf dem, was ich heute zuvor zusammengeführt habe, und PR # 2235, das die Änderungen für die Verbindung im B / G-Modus enthält.
Es scheint Probleme mit einigen Plugins in dieser PR zu geben, daher wurde sie noch nicht zusammengeführt.

Vielen Dank! Der Testbuild hat geflasht.

Ich habe jetzt folgende Einstellungen:
Connection Failure Threshold: 0 Force WiFi B/G: NO Restart WiFi on lost conn.: YES

Glaubst du, ich sollte etwas anders testen, wenn ich PLATFORMIO_ESP12E habe?
Das heißt, ich weiß nicht, ob b / g auf esp12e funktionieren wird und welcher Schwellenwert für Verbindungsfehler genau war.

Dieser Schwellenwert ist nur ein Zähler, um einen Neustart einzuleiten, wenn mehrere erfolglose Verbindungsversuche diesen Wert überschreiten.
0 ist die Standardeinstellung und bedeutet, dass kein Neustart durchgeführt wird.

Ich denke, wenn Sie es auf 50 oder 100 einstellen, können Sie es neu starten, wenn es an einem schwer erreichbaren Ort ist und sich in einer Wiederverbindungsschleife befindet.

Selbst mit dieser Einstellung werden möglicherweise immer noch HW-Watchdog-Neustarts angezeigt, wie einige meiner Knoten bereits gezeigt haben.
Es kann nur schwieriger sein, solche mit aktivem B / G-Modus zu reproduzieren.

Test Build
Es basiert auf dem, was ich heute zuvor zusammengeführt habe, und PR # 2235, das die Änderungen für die Verbindung im B / G-Modus enthält.
Es scheint Probleme mit einigen Plugins in dieser PR zu geben, daher wurde sie noch nicht zusammengeführt.

Danke für den Test Build.
Mein bisher instabilster ESP12F ist jetzt seit 59 Stunden ohne Neustart aktiv :)

EDIT: Einstellungen sind:
WiFi erzwingen B / G: JA
Starten Sie WiFi bei verlorener Verbindung neu: JA

Ich denke, ich werde dieses Commit (B / G WiFi) auf einen separaten PR aufteilen, damit es zusammengeführt werden kann, bevor ich den Rest des PR repariere, in dem es jetzt darauf wartet, zusammengeführt zu werden.

Gute Idee!

Meine vorherigen Einstellungen RestartWifi = YES haben nichts Nützliches bewirkt.

Jetzt wechselte ich zu

Connection Failure Threshold: 0
Force WiFi B/G: YES
Restart WiFi on lost conn.: NO

und es ist zwei Tage ohne Neustart oder auch nur eine einzige Trennung gewesen. Tolle. Ich glaube nicht, dass ich mich überhaupt von dieser Testversion entfernen werde.

Nach ca. 100 Stunden hat das Modul endlich einen Reset durchgeführt. :(

Grund zurücksetzen: Hardware Watchdog

Dies kann jedoch auch durch die herausfordernde Konfiguration (12 x 1-Draht-Sensoren und ein FHEM-Server) verursacht werden.

Sie können auch versuchen, diesen Patch hinzuzufügen: https://github.com/letscontrolit/ESPEasy/pull/2235/commits/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf2
Vielleicht hilft das auch, die Stabilität zu verbessern.
Es ist in diesem Testbuild enthalten

Sie können auch versuchen, diesen Patch hinzuzufügen: 9a05eaf
Vielleicht hilft das auch, die Stabilität zu verbessern.
Es ist in diesem Testbuild enthalten

Vielen Dank!
Installiert es auf zwei völlig unterschiedlich konfigurierten Einheiten und gibt Feedback.

hatte einen Lauf auf einem meiner Testknoten einschließlich
https://github.com/letscontrolit/ESPEasy/commit/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf Leider dauerte es nur etwa 2 Stunden, bis das Problem mit dem Zeitlimit für Gruppenschlüssel erneut auftrat und keine Wiederherstellung oder Wiederherstellung der Verbindung zum AP erfolgte. Wenn "WLAN bei Verbindungsverlust neu starten" aktiviert ist und es nicht auf B / G erzwungen wird, scheint N immer noch ein Problem zu sein.
Für mich ist der B / G-Modus immer noch die einzige stabile Arbeitsoption.

Könnten wir versuchen, die N-Unterstützung insgesamt fallen zu lassen? Benötigen wir die Vorteile von N für ein so einfaches Gerät?

@ 0ki mit der "neuen" Option, um den von @ TD-er eingebauten B / G-Modus zu erzwingen, lässt N auf Software-Ebene fallen. Sie können es nicht aus den Kernbibliotheken entfernen, nehme ich an ...

Wenn Sie dies in die Haupteinstellungen verschieben, empfehle ich, dass diese Option standardmäßig aktiviert ist.

Wir könnten es dynamisch machen.
Wenn keine Verbindung möglich ist, versuchen Sie es erneut mit aktivierter Option N.

Es gibt viele Setups, bei denen nur N im AP eingecheckt ist. In diesen Umgebungen können Sie nicht zurückkehren, wenn Sie die N-Unterstützung auf dem ESPeasy deaktivieren.

Sie können auch versuchen, diesen Patch hinzuzufügen: 9a05eaf
Vielleicht hilft das auch, die Stabilität zu verbessern.
Es ist in diesem Testbuild enthalten

Vielen Dank!
Installiert es auf zwei völlig unterschiedlich konfigurierten Einheiten und gibt Feedback.

Bisher wurde ein Modul nach 2 Tagen neu gestartet, das andere nach 5 Tagen.
Beide zeigten "Hardware Watchdog" als Rücksetzgrund.
Beide Module sind auf "WiFi B / G erzwingen: Ja" und "WiFi bei verlorener Verbindung neu starten: Ja" eingestellt.
Der AP ist ein Mikrotik, der nur auf B / G eingestellt ist (Betriebszeit 49 Tage).
Abstand zwischen AP und Modulen ca. 2 ... 3 m.

Ich habe mich gefragt, warum mein Vorschlag, es dynamisch zu gestalten (von der Einstellung B / G nur zu N zurückzukehren), 2 Daumen nach unten "Stimmen" erhalten hat.
Bitte erläutern Sie, warum dies kein guter Vorschlag ist.

Ich habe mich gefragt, warum mein Vorschlag, es dynamisch zu gestalten (von der Einstellung B / G nur zu N zurückzukehren), 2 Daumen nach unten "Stimmen" erhalten hat.
Bitte erläutern Sie, warum dies kein guter Vorschlag ist.

Wenn jemand diese Option aktiviert, hat er meiner Meinung nach bereits verzweifelt nach mehr Stabilität gesucht und weiß, was dies für seine AP-Einstellungen bedeutet.
Ich bevorzuge eine statische Lösung, weil ich, wenn ich die Option Nur B / G auswähle, absolut nie in einer Situation sein möchte, in der ich denke, dass B / G verwendet wird, dies aber nicht tut.
Da meine Knoten ohnehin neu starten (obwohl viel seltener), hätte ich gerne eine echte Lösung für das Problem mit dem neueren Kern.

Ich verstehe das, aber Sie müssen das Problem auch verstehen, wenn Benutzer nicht wissen, was eine Einstellung bewirkt, und am Ende nicht erreichbare Knoten haben.
Es sollte also einen großen Schwellenwert haben, bevor Sie wieder zur N-Unterstützung wechseln.
Der Fallback für beschädigte Plugins lautet beispielsweise:
Nach 10 erfolglosen Neustarts wird 1 Plugin oder Controller deaktiviert, um festzustellen, ob der Neustart erfolgreich war.

Ähnliches kann auch auf die WLAN-Verbindung angewendet werden.
Nach X erfolglosen Wiederverbindungsversuchen kann eine Verbindung mit 802.11N hergestellt werden
Die Empfangsqualität ist für G-Modus-Netzwerke besser. Wenn Sie also X auf etwa 10 setzen, ist es sehr unwahrscheinlich, dass eine Verbindung mit N anstelle von G hergestellt wird. Insbesondere, wenn Sie diesen Zähler jedes Mal zurücksetzen, wenn Sie ihn im N-Modus versuchen.

Hmm, die letzten Wochen mit weniger Zeit für ESPeasy haben anscheinend meine Erinnerung an das, was ich implementieren wollte oder was implementiert wurde, verschleiert.

Ich habe mir gerade den Code dafür angesehen und festgestellt:

void setConnectionSpeed() {
  #ifdef ESP8266
  if (!Settings.ForceWiFi_bg_mode() || wifi_connect_attempt > 10) {
    WiFi.setPhyMode(WIFI_PHY_MODE_11N);
  } else {
    WiFi.setPhyMode(WIFI_PHY_MODE_11G);
  }
  #endif

Anscheinend wurde es bereits implementiert, um N nur zuzulassen, wenn wifi_connect_attempt > 10 ist.
Dieser Zähler wird auf 0 zurückgesetzt, sobald erfolgreich versucht wurde, eine Verbindung zu WLAN herzustellen.

Ist das eine akzeptable Lösung?

Hmm, die letzten Wochen mit weniger Zeit für ESPeasy haben anscheinend meine Erinnerung an das, was ich implementieren wollte oder was implementiert wurde, verschleiert.

Ich habe mir gerade den Code dafür angesehen und festgestellt:

void setConnectionSpeed() {
  #ifdef ESP8266
  if (!Settings.ForceWiFi_bg_mode() || wifi_connect_attempt > 10) {
    WiFi.setPhyMode(WIFI_PHY_MODE_11N);
  } else {
    WiFi.setPhyMode(WIFI_PHY_MODE_11G);
  }
  #endif

Anscheinend wurde es bereits implementiert, um N nur zuzulassen, wenn wifi_connect_attempt > 10 ist.
Dieser Zähler wird auf 0 zurückgesetzt, sobald erfolgreich versucht wurde, eine Verbindung zu WLAN herzustellen.

Ist das eine akzeptable Lösung?

Nun ... ich würde ja sagen (in der Hoffnung, dass der Fehler in 2.5.0 bald gefunden wird).

Feedback nur zur Einstellung B / G.
Ich habe gerade den Test fw auf einem Gerät installiert, das spätestens alle 20 Minuten neu gestartet wurde. Vorher war es mit -72dBi mit N verbunden. Das hätte ein ausreichend gutes Signal sein müssen, um die Verbindung nicht zu trennen. Ich betreibe APs für Unternehmen mit -105dBi-Empfangsfunktionen. Also sollte es den Kanal niemals fallen lassen.

Nach ein paar Stunden mit dem Test FW gab es bisher keinen Reset.
Ich werde es am Laufen halten und zurückmelden.

PS: Ich stimme zu, dass es irgendwie mit N zusammenhängt.
PSS: Ich verwende 20 x ESP-07-Knoten, die auf 4M aktualisiert wurden. Zeitaufwändig, aber eine Rückzahlung, wenn ein erneutes Flashen erforderlich ist.

Ich habe mehr als 120 Knoten, die alle auf GN (Mega-20190202) laufen, ohne irgendwelche Probleme. Sie alle melden, mit N verbunden zu sein

@ jimmys01 Wie viele Knoten verbinden sich mit demselben AP?
Und was ist die Marke dieses AP? (Mikrotik?)

Fast alle von ihnen sind mit einem anderen AP verbunden (einer pro Hotelzimmer). Sie haben einen Schalter (PIR-Sensor), einen HTU-Temperatur- und Feuchtigkeitssensor und IR-LEDs.
Die Marke AP ist Mikrotik.
Die Einstellungen sind wie folgt:
Land ist eingestellt
Steuerkanal: 20 MHz
Band: GN
Nebenstellenkanal: Deaktiviert
Authentifizierungstyp: Nur WPA2 PSK
Verschlüsselung: nur aes ccm
Gruppenverschlüsselung: aes ccm
Groyp Key Update: 00:01:00

Feedback nur zur Einstellung B / G.
Ich habe gerade den Test fw auf einem Gerät installiert, das spätestens alle 20 Minuten neu gestartet wurde. Vorher war es mit -72dBi mit N verbunden. Das hätte ein ausreichend gutes Signal sein müssen, um die Verbindung nicht zu trennen. Ich betreibe APs für Unternehmen mit -105dBi-Empfangsfunktionen. Also sollte es den Kanal niemals fallen lassen.

Nach ein paar Stunden mit dem Test FW gab es bisher keinen Reset.
Ich werde es am Laufen halten und zurückmelden.

PS: Ich stimme zu, dass es irgendwie mit N zusammenhängt.
PSS: Ich verwende 20 x ESP-07-Knoten, die auf 4M aktualisiert wurden. Zeitaufwändig, aber eine Rückzahlung, wenn ein erneutes Flashen erforderlich ist.

Leider wird das Gerät nach einer zufälligen Zeit weiter zurückgesetzt. Alles innerhalb von 1-4 Stunden.
Nur B / G FW löst meine Probleme nicht

Ich habe mich gefragt, warum mein Vorschlag, es dynamisch zu gestalten (von der Einstellung B / G nur zu N zurückzukehren), 2 Daumen nach unten "Stimmen" erhalten hat.
Bitte erläutern Sie, warum dies kein guter Vorschlag ist.

Nehmen wir an, das WLAN selbst fällt aufgrund äußerer / umweltbedingter Umstände eine Stunde lang aus. Meine Knoten wechseln zu N und werden wieder sehr instabil (meine Anwendung reagiert empfindlich auf Neustarts - WLAN muss nicht immer 100% vorhanden sein, aber der Knoten selbst sollte immer betriebsbereit sein).

Ich möchte eine Konfiguration für meine Knoten, die Instabilität vermeidet und niemals eine Verbindung zu N herstellt.

Wenn Sie dies in die Haupteinstellungen verschieben, empfehle ich, dass diese Option standardmäßig aktiviert ist.

Als Lösung könnten wir dies standardmäßig in den Fallback-Modus (B / G-dann-N) versetzen, indem wir nur auf B / G oder B / G / N umschalten können.

Versuchen Sie Folgendes für die eigentliche Lösung für 2.5.0:

#include "esp_wifi.h"
esp_wifi_set_ps(WIFI_PS_NONE);

Ich habe mehr als 120 Knoten, die alle auf GN (Mega-20190202) laufen, ohne irgendwelche Probleme. Sie alle melden, mit N verbunden zu sein

Wie aktualisiere ich mehr als 120 Knoten innerhalb eines akzeptablen Zeitrahmens?
"..keine Probleme überhaupt ..." haben Sie die Betriebszeit jedes Knotens überprüft und was ist das?
Sind alle seit dem letzten geplanten Neustart gleich?

Die Betriebszeiten zählen Tage und alle haben 0 Wiederverbindungen. Seit Monaten hatte ich keine Probleme mit der Konnektivität, außer wenn ich PMKID auf den APs deaktiviert habe. Wahrscheinlich wurde der neuere Kern wählerischer in Bezug auf die WLAN-Einstellungen, oder ich weiß nicht, was. Ich verwende auch alle mit 2A-Netzteilen. Wir planen, im nächsten Monat 80 weitere esp8266 bereitzustellen. Übrigens, wenn Sie @ TD-er möchten, dass ein Zugriff auf das jeweilige Setup erfolgt, gebe ich es Ihnen gerne weiter. Ich möchte wirklich, dass ESPEasy aufflammt, es hat uns sehr geholfen.

Edit: @ chunter1 Ich aktualisiere sie mit Batch-Skripten

curl -# -o /dev/null --form update=@ESP_Easy.bin --max-time 40 --connect-timeout 20 --retry 1 http://x.x.x.x/update

@ jimmys01 Ich habe kürzlich selbst eine Mikrotik gekauft, um Sachen testen zu können.

Und nur ein Hinweis zu Core 2.5.0 Builds.
In den kommenden nächtlichen Builds sind die Builds 2.5.0 nicht enthalten, da es einen Fehler in Core 2.5.0 gibt, der dazu führt, dass der Webserver nicht mehr reagiert und den Knoten abstürzen lässt.
Sobald dies behoben ist, wird es wieder Core 2.5.0 Builds geben.
Im letzten nächtlichen Build ist ein Core 2.6.0 Alpha enthalten, bei dem es sich im Wesentlichen um den neuesten Code aus dem Github der Core Library handelt, damit Sie sich selbst davon überzeugen können.

Habe die 2.6.0 mit B / G nur seit 4 Tagen auf zwei Modulen laufen lassen und das erste hat einen Neustart durchgeführt.
Grund für das Zurücksetzen war der übliche "Hardware-Watchdog".
Was ich beobachte, da der "B / G" -Modus nur aktiv ist, ist eine Laufzeit von 3..5 Tagen, bevor ein Reset erfolgt.

Vergleichen Sie vielleicht auch die Anzahl der WLAN-Trennungen, da diese Trennungen mit den Abstürzen in Zusammenhang zu stehen scheinen.

Beide Module befinden sich im Keller, nur 2..3m vom Mikrotik AP entfernt.
Ich habe gerade das zweite Modul überprüft, auf dem dieselbe FW-Version ausgeführt wird, und es zeigt 0 Wiederverbindungen und 4d02h Betriebszeit an (kein Neustart seit dem Flashen).
Ich glaube sehr, dass das andere Modul, das den Reset durchgeführt hat. hatte auch 0 Wiederverbindungen, bevor es zurückgesetzt wurde.

Zu den auf den beiden Testmodulen konfigurierten Aufgaben:
Das Modul, das zurückgesetzt wurde, verfügt über 12 konfigurierte DS18B20-Sensoren, die ihren Wert alle 120 Sekunden an einen FHEM-Server senden.
Für das Modul, das bisher nicht zurückgesetzt wurde, sind nur zwei GPIs konfiguriert, die ebenfalls alle 120 Sekunden ihren Wert an denselben FHEM-Server senden.

AP (Mikrotik) ist also gleich, Abstand (2..3mm) ist gleich, FHEM-Server ist gleich - nur das Modul mit den 12 Temperatursensoren wird definitiv häufiger zurückgesetzt als das mit den 2 gpios.

Auf meinen Knoten geschieht dies hauptsächlich, wenn fhem zu langsam ist, um zu reagieren, oder nicht erreichbar ist, weil ich einen maximalen Wiederholungsversuch von 100 definiert habe und dann die Knoten neu gestartet werden (was dann auch einen manuellen Neustart anzeigt).

Auf meinen Knoten geschieht dies hauptsächlich, wenn fhem zu langsam ist, um zu reagieren, oder nicht erreichbar ist, weil ich einen maximalen Wiederholungsversuch von 100 definiert habe und dann die Knoten neu gestartet werden (was dann auch einen manuellen Neustart anzeigt).

Warum sollten Ihre Knoten neu gestartet werden, wenn die Wiederholungsversuche über 100 liegen?
(Ich habe Wiederholungsversuche zum Testen auf 0 gesetzt.)

Tools -> Erweitert -> Verbindungsfehlerschwelle

um sicherzustellen, dass das WLAN der Module nach einiger Zeit neu gestartet wird, wenn es aus irgendeinem Grund erstickt ...

Ahh mit "Wiederholungsversuchen" meinen Sie den "Verbindungsfehlerschwellenwert": nicht die "Max. Wiederholungsversuche:" in den Controller-Einstellungen von FHEM.
Ich habe den Verbindungsfehlerschwellenwert auf 0 gesetzt.

Übrigens: Zum ersten Mal hatte ich einen Knoten, der im 4WHS-Timeout-Problem stecken blieb, obwohl "nur B / G" aktiv war ... hatte das bis jetzt noch nie (selbst kompiliert, 2.5.0 Core) .... Ich werde das weiter beobachten, wenn das nur ein Zufall war ...

Bitte beachten Sie, dass es sehr bald einen Core 2.5.1 geben wird, der das verwendete SDK auf SDK2.2.1 zurücksetzt, da es viele Probleme mit SDK3.0.0 gibt
Dies kann auch die Reaktion der Knoten auf WLAN ändern und ist möglicherweise wieder mit Core 2.4.2 vergleichbar.
Wir sind uns nicht sicher, welche Korrekturen in Core 2.5.0 enthalten sind, die möglicherweise einige andere Probleme beheben, mit denen wir konfrontiert sind.

@ chunter1 Über die Knoten, die Sie haben.
Es scheint, als hätte derjenige, der neu gestartet wurde, viel mehr Nachrichten an den Controller gesendet. Statistisch gesehen besteht also eine höhere Wahrscheinlichkeit, dass er versucht, etwas zu senden, das irgendwo im Prozess ins Stocken gerät.

@ clumsy-stefan Kannst du den aktuellen Code auf Github testen? (oder der neueste Build)

Ich habe einige Änderungen an der Durchführung netzwerkbezogener Aktivitäten vorgenommen.

Meinst du das?

ESP_Easy_mega-20190227_test_core_260_sdk3_alpha_ESP8266_4M.bin

Fast jeder Build der letzten Nacht.
Ich habe auch eine "normale" Version für Core 2.6.0 mit SDK2 hinzugefügt.
Core 2.6.0 SDK2 läuft jetzt auf mehreren Knoten und hatte nur einen HW-Watchdog auf einem von ihnen, der außergewöhnlich wenig Ressourcen hat (mit vielen Plugins mit hohem Speicher) und auch auf dem mit dem wahrscheinlich abgenutzten Flash-Speicher (sollte) werfen Sie das weg, da es Tausende von Firmware-Updates hatte)

@ TD-er Ich habe vor ungefähr 6 Stunden von Git auf 2 Testknoten kompiliert und installiert. Da ich aber immer noch einen sehr eingeschränkten Internetzugang habe, kann ich wahrscheinlich nur innerhalb von 24 Stunden zurückmelden, also ...

Ich habe die neueste Firmware mit "Force B / G-Modus" mit Mikrotik-Router getestet und bisher scheint sie stabil zu funktionieren. Werde zurückmelden.

@ TD-er Eine Frage: Was ist die Regel für den Fallback in den N-Modus, wenn "Force B / G-Modus" eingestellt ist?

@ giig1967g
Wenn die Verbindung zum AP über 10 Mal nur mit _B / G_ nicht hergestellt werden konnte, wird der Standard-BGN-Modus wiederhergestellt.

Dies lässt die Möglichkeit offen, dass eine Verbindung im N-Modus hergestellt wird, wenn der AP einige Zeit offline war.
Wenn dies ein echtes Problem zu sein scheint, kann ich versuchen, es so einzustellen, dass es nur bei jedem 10. Versuch ausgeführt wird, aber dann muss ich sicherstellen, dass es dies auch versucht, wenn die Fallback-SSID versucht wird.

Hi @ TD-er
Ich denke, dass der Fallback eine schlechte Idee ist.
Schauen Sie sich dieses Szenario an: Ich habe mein Gerät in den B / G-Modus gezwungen, der mit meiner Mikrotik zufrieden ist.
Aus irgendeinem Grund geht meine Mikrotik offline (Update, Neustart, was auch immer).
Immer wenn die Mikrotik wieder hochfährt, wird das ESP im N-Modus verbunden und ich habe die Stabilität des Geräts verloren.

Mit anderen Worten, wenn ich den Force B / G-Modus einstelle und die Verbindung fehlschlägt, sollte dies ein AP (192.168.4.1) werden, aber nicht auf den N-Modus zurückgreifen. Die Fallback-Möglichkeit erzeugt eine falsche Erwartung an den Benutzer.

Verstehen Sie mich nicht falsch, der Fallback war gut, um die Gültigkeit der Änderung zu testen, aber jetzt, da sich herausgestellt hat, dass das Problem gelöst ist (zumindest meiner bisher), sollte der Fallback entfernt werden.

Ich stimme dem Kommentar von @ chunter1 zu: https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment -462295204

Was denkst du dann über das nächste Szenario?
Sobald es möglich ist, nur mit B / G eine Verbindung zu den angegebenen APs herzustellen, wird ein zusätzliches Flag gesetzt, um keinen Fallback mehr zu ermöglichen.
Wenn sich einige dieser Einstellungen (nur B / G oder andere AP-Einstellungen) ändern, wird der Fallback wieder aktiviert, bis die Verbindung zum angegebenen AP erfolgreich hergestellt wurde.

Bearbeiten:
Mit Fallback meine ich diese zusätzlichen Einstellungen, nicht die "Fallback-SSID"

Mit anderen Worten, der Fallback bleibt nur bis zur ersten erfolgreichen Verbindung zum AP aktiv und wird dann entfernt. In diesem Fall wäre es hilfreich, auf der Syspage den WLAN-Modus zu sehen.
Dies ist eine mögliche Lösung, auch wenn ich es immer noch vorziehe, Fallbacks auf N zu vermeiden, wenn ich Force B / G einstelle.
Ich verstehe die Möglichkeit des Benutzers, Fehler zu machen, aber dann könnte der Benutzer die SSID falsch eingeben und auf keinen Fall Zugriff auf das Gerät erhalten ...

Noch eine Frage: In welchem ​​Szenario wird die Einheit in der aktuellen Implementierung zu einem AP?
Weil es mir so scheint, als würde das Gerät 10 Mal B / G und dann N versuchen, aber wird es irgendwann aufgeben und ein AP werden?

Nein, der AP-Modus bleibt aktiv, während noch getestet wird, um eine Verbindung zu den angegebenen APs herzustellen.
Vielleicht sollten wir auch eine optionale Überprüfung der Verfügbarkeit hinzufügen und den AP-Modus nur in den ersten 10 Minuten starten, in denen der Knoten gestartet wird.
Nur zur zusätzlichen Sicherheit und um die Möglichkeit auszuschließen, kann der AP-Modus Auswirkungen darauf haben, dass der ESP die angegebenen WLAN-Netzwerke nicht erreichen kann.

Und wir sollten uns weiterhin auf den "einfachen" Teil des Projekts konzentrieren.
Dies bedeutet korrekte Standardeinstellungen und keine überwältigende Anzahl angebotener Einstellungen, bietet dem Experten jedoch die Möglichkeit, alles zu tun.
Dies bedeutet auch, dass es für den weniger erfahrenen Benutzer einen angemessenen Rückfall geben sollte.
Speziell für B / G nur Einstellungen. Ich denke, 90+ Prozent der Leute, die mit ESPeasy beginnen, sind sich der Unterschiede zwischen 802.11B / G / N nicht bewusst. Wenn sie also Probleme haben, die mit einem Fallback sehr gut gelöst werden können, kann dies dazu führen, dass sie nach anderen Projekten suchen .
Ich verstehe auch, warum dieser Fallback kein falsches Gefühl von "Stabilität" vermitteln sollte, daher verstehe ich wirklich, warum die aktuelle Implementierung Raum für Verbesserungen bietet. Wenn der "Erfolg beim ersten Verbindungsversuch => Fallback deaktivieren" automatisch erfolgt, ist er auch perfekt für erfahrene Benutzer. (wer macht auch dumme Fehler, wie ich aus Erfahrung weiß;))

Ich bin damit einverstanden, dass klarer gemacht wird, welche Verbindungseinstellung aktiv verwendet wird.

verstanden.
Der Prosal ist also:
Die Einheit bootet.
Das N-Fallback-Flag wird auf true gesetzt.
Wenn FORCE B / G eingestellt ist, wird 10 Mal versucht, eine Verbindung zum WLAN-AP in B / G herzustellen.
Wenn es eine Verbindung herstellen kann, setzt es das N-Fallback-Flack auf false.
Wenn es keine Verbindung herstellen kann, versucht es es im N-Modus.

Bitte beachten Sie auch dieses Szenario mit eingestelltem Force B / G: Stromausfall.
ESP und Wifi-Router sind ausgeschaltet.
Dann kehrt die Stromversorgung zurück und ESP ist schneller als der WLAN-Router.
In diesem Fall kann es vorkommen, dass der WLAN-AP nach 10 Mal nicht mehr zuhört.
Das Gerät wird also den N-Modus ausprobieren und schließlich erfolgreich sein.
(Erfahrene) Benutzer werden nicht wissen, dass sich die Verbindung im N-Modus befand, und denken, dass sie sich im B / G-Modus mit mangelnder Stabilität befindet.

Ich möchte nicht darauf bestehen, aber wirklich, diese HW- und Freeze-Probleme gibt es seit 1 Jahr. Nachdem Sie mit Hilfe der Community eine funktionierende Lösung gefunden haben, empfehle ich dringend, sicherzustellen, dass diese weiterhin angewendet wird. Das Risiko für einen unerfahrenen Benutzer, den "Force B / G-Modus" einzustellen, ist geringer als für ihn, die falsche SSID mit den gleichen Ergebnissen einzustellen: kein Zugriff auf den Zugriffspunkt.

VORSCHLAG:
Um sicherzustellen, dass der weniger erfahrene Benutzer keine Fehler macht, fügen Sie dem "Test B / G-Modus" eine Schaltfläche hinzu. Wenn dies erfolgreich ist, wird der "FORCE B / G-Modus" aktiviert, andernfalls bleibt er deaktiviert.

In diesem Fall wissen weniger erfahrene Benutzer, was sie tun, und erfahrene Benutzer sind sich sicher, dass der ForceB / G-Modus beim Einstellen des ForceB / G-Modus nicht auf N zurückgreifen kann.

Was denken Sie?

Du könntest

Nicht nur beim Booten, sondern auch die Fallback-Option wird in den Einstellungen deaktiviert und gespeichert.

in Ordnung. Dann ist eine manuelle Überprüfung noch angemessener als eine automatische Überprüfung. Denkst du nicht?

Ja, ich werde zuerst ein einfaches Häkchen hinzufügen, um Überschreibungen zu deaktivieren.
Aber später sollte es dynamischer gemacht werden, um uns, den "Experten", auch dabei zu helfen, weniger Fehler zu machen :)

in Ordnung

Die Version 2019_02_16 wurde nun 9 Tage lang ohne Neustart ausgeführt (auf B / G gezwungen). Gestern wurde es wieder neu gestartet. Der Hardware-Watchdog hat dies zweimal erzwungen.
Nach einer Weile war das Gerät nicht mehr erreichbar. Das Umschalten des WLAN-Routers hat nicht geholfen (dreimal versucht, bis zu 30 Minuten). Ein Neustart des ESP durch Ausschalten der Sicherung half ebenfalls nicht.
Ich musste wlan wieder herunterfahren und dann über 192.168.4.1 direkt eine Verbindung zum ESP herstellen, um Zugriff darauf zu erhalten

Ich habe absolut keine Ahnung, was passiert ist

@kischde Welche Art von Zugangspunkt verwenden Sie?
Letzte Nacht habe ich selbst etwas Ähnliches erlebt, als ich mit der Installation eines neuen AP experimentiert habe.
Ich habe versucht, einen MikroTik-AP zu installieren, und alles funktionierte einwandfrei, bis das ESP erneut eine Verbindung herstellen musste.
Über die Weboberfläche des MikroTik konnte ich sehen, dass der Knoten mit dem WLAN verbunden war, aber keine IP-Adresse erhielt.
Selbst als ich versuchte, es mit dem Hotspot meines Telefons zu verbinden, konnte ich das ESP neu starten, aber es wiederholte dieses Verhalten.
Erst als ich die Haupt-AP-Konfiguration auf einen anderen AP eingestellt habe, wurde die Verbindung wie gewünscht hergestellt.

Beachten Sie, dass der Knoten nicht neu gestartet wurde, um dies zu erreichen.

Eine Sache, die auf diesem AP im Vergleich zu einem anderen MikroTik, den ich habe, auf "falsch" eingestellt ist, ist, dass die Einstellung "Entfernung" auf "drinnen" eingestellt ist.
Ich werde weitere Tests durchführen, um festzustellen, was hier der Unterschied ist, aber wie bereits erwähnt, scheint es sich um eine Zeitüberschreitungseinstellung für eine Antwort auf ein Paket zu handeln.
Und ich kann mir vorstellen, dass das ESP einige Zeit braucht, um auf DHCP-Anfragen zu antworten, die für diese Einstellung möglicherweise zu kurz sind.

Ich benutze einen Swisscom AP (Schweizer Telekommunikationsanbieter AP), aber ich hatte alle die gleichen Probleme hier an den verschiedenen Stellen geschrieben wie die Jungs mit der MikroTik. Es hat also vielleicht den gleichen Chipsatz, aber ich kann nicht viel an der Einstellung ändern, zum Beispiel an diesen erweiterten Einstellungen.
Vor dem erneuten Einschalten habe ich auch versucht, wie Sie eine Verbindung zu meinem Mobiltelefon herzustellen, und zwar mit demselben Verhalten wie Sie.
Ich benutze feste IP, kein DHCP
Ich habe jetzt auf den aktuellen 2019_03_05 umgestellt, werde sehen was passiert ...

Haben Sie kürzlich die WLAN-Einstellungen geändert?
Zum Beispiel Zugangspunkt mit MAC-Adresse AA: AA: AA: AA: AA auf Position 1 des anderen AP der SSID mit MAC-Adresse BB: BB: BB: BB: BB: BB
Ich habe das Gefühl, dass an einigen Stellen im ESP noch einige Einstellungen vorhanden sind, in denen wir sie nicht speichern.

Ich werde auch versuchen, in den NonOS-Dokumenten zu sehen, wie diese effektiv gelöscht werden können, wenn wir die WLAN-Einstellungen ändern.
Auch in meinen Tests scheint es sehr nützlich zu sein, mehr als 2 SSIDs zu verwenden.
Ich werde auch versuchen, mehr Felder dafür hinzuzufügen oder vielleicht sogar zu erlauben, eine verschlüsselte Datei in SPIFFS zu speichern, um eine nahezu unbegrenzte Anzahl von WiFi-APs zu speichern.

Haben Sie kürzlich die WLAN-Einstellungen geändert?

Nein, da ich nur einen AP habe, war dies IMO nicht notwendig

IN ORDNUNG. Gut zu wissen.
Da ich noch nicht weiß, was dies verursacht, versuche ich, so viele Unbekannte wie möglich zu beseitigen.
Das einzige, was Sie tun müssen, damit es wieder funktioniert, ist, die Einstellung für WLAN erneut hinzuzufügen.

Nein, noch weniger
Ich musste mich über 192.168.4.1 direkt mit dem esp verbinden (deaktivierte den AP)
Dann habe ich alles überprüft, aber keine anormalen Dinge gefunden ... Also versuche ich es und stelle meinen AP neu zusammen, dann setze ich das ESP zurück und es läuft erneut. Also IMO musste ich nur zwingen, eine "normale / andere" WLAN-Verbindung herzustellen.
Übrigens habe ich auch gesehen, dass es am AP verbunden ist, aber auch keine IP-Adresse zugewiesen, aber es ist statisch

Hmm, ich habe ein bisschen damit gespielt, mit 5 Knoten, die mit der MikroTik verbunden sind, mit der ich spiele.

Sobald ich "Hw. Fragmentation Threshold" eingestellt habe (einfach die Option "entfalten"), können die ESP-Knoten keine IP-Adresse mehr empfangen.
Der Standardwert dieser Einstellung ist 256. Wenn ich sie auf 1600 setze (passt zu einer vollständigen MTU), erhalten alle Knoten eine IP-Adresse und arbeiten weiter.

Dies wird in der MikroTik-Benutzeroberfläche angezeigt, wenn die Knoten kommunizieren können:

Und dies, wenn sie keine Daten senden / empfangen können (aber mit der WiFi-Schicht verbunden sind)

@ TD-er hast du gesehen, dass es im neuen esp8266-Kern eine Option namens LWIP_FEATURES die meiner Meinung nach die IP-Neuzusammenstellung aktiviert ... Wahrscheinlich ist das in deinem Build nicht definiert?

siehe hier: https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L748 -L754

Außerdem wird die Unterstützung für die IP-Fragmentierung wie folgt festgelegt:
https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L756 -L763

Hmm, ich bin mir nicht sicher, wie die Standardeinstellungen lauten.
Sind die in der ersten Zeile der Doxygen-Dokumentation angegebenen Zahlen die Standardeinstellungen?

Ich weiß nicht ... Ich weiß nur, dass Sie in der Arduino IDE in der plattforms-Definitionsdatei auswählen können, ob sie aufgenommen und definiert werden soll oder nicht.

Ich habe immer gedacht, dass die LWIP-Teile als vorkompilierte Bibliotheken in der Kerndistribution enthalten sind.
Daher ist es ziemlich schwierig sicherzustellen, dass LWIP mit den richtigen Flags neu erstellt wird.

ja, aber es kommt darauf an, gegen welches du verlinkst (von board.txt):

-llwip2-1460-feat
-llwip2-536-feat
-llwip2-536
-llwip2-1460
-llwip2

Also benutzen sie diese Flags:

https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/boards.txt#L357 -L387

| Label | build.lwip_lib | build.lwip_flags |
| --- | --- | --- |
| v2 Unterer Speicher | -llwip2-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 Höhere Bandbreite | -llwip2-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 Unterer Speicher (keine Funktionen) | -llwip2-536 | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 Höhere Bandbreite (keine Funktionen) | -llwip2-1460 | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 IPv6 unterer Speicher | -llwip6-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v2 IPv6 Höhere Bandbreite | -llwip6-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
v1.4 Höhere Bandbreite -llwip_gcc | -DLWIP_OPEN_SRC |
| v1.4 Aus Quelle kompilieren | -llwip_src | -DLWIP_OPEN_SRC |

Alle v2-Versionen haben also LWIP_FEATURES=1 Ausnahme derjenigen, die als "keine Funktionen" gekennzeichnet sind.

Ja, aber wenn Sie sich die -l -Anweisungen ansehen, müssen Sie die Bibliotheken am Ende mit -feat (im Gegensatz zum Label etwas konterintuitiv) ...