Espeasy: [BUG] [Stabilité WiFi] Exception ESP 3/29 lorsque la couche 2 se déconnecte

On dirait que j'ai le même problème. Parfois, mon esp a perdu la connexion wifi et garde "perdu" du wifi pendant des heures. Je pensais qu'ils devaient redémarrer et se reconnecter au wifi grâce au chien de garde, mais ils ne le font pas. Un démarrage à froid résout le problème.

Cette dernière chose décrite par @wolverinevn est quelque chose que j'ai vu se produire ici aussi.

comme nous en avons discuté dans # 1957, je suis tout à fait sûr que beaucoup de ces étranges problèmes de WiFi / réseau proviennent de cette instabilité de couche 2 ... J'ai vu toutes sortes de comportements étranges avant de changer mon AP à des horaires accrus ...

comme nous en avons discuté dans # 1957, je suis tout à fait sûr que beaucoup de ces étranges problèmes de WiFi / réseau proviennent de cette instabilité de couche 2 ... J'ai vu toutes sortes de comportements étranges avant de changer mon AP à des horaires accrus ...

J'espère que vous trouverez la solution. Un de mes Nodemcu se bloque et disparaît du routeur pendant 5 heures jusqu'à présent sans raison. J'espère qu'il pourra se remettre du chien de garde, mais rien ne se passe. Je dois le redémarrer manuellement maintenant. Très énervé!

@wolverinevn lorsque vous avez à nouveau accès au nœud, allez dans tools => advanced et définissez le "Connection Failure Threshold" sur autre chose que 0 (je suggère quelque chose entre 50 et 100, selon le nombre de tâches que vous avez). Cela ne change en fait pas le problème mais augmente les chances que le nœud redémarre et se reconnecte de manière significative!

L'autre solution de contournement serait si vous pouvez modifier certains paramètres de votre point d'accès, en fonction du type d'AP que vous avez si cela peut être modifié ...

@ clumsy-stefan Devrions-nous définir la valeur par défaut dans ESPeasy à ce niveau également?

Et peut-être devrions-nous également afficher cette valeur dans la page sysinfo et la rendre disponible pour les règles?

@ TD-er le régler à un certain niveau par défaut n'est probablement pas une mauvaise chose s'il n'est pas trop bas (il peut toujours arriver qu'une connexion échoue).

Lors du débogage du problème, j'ai réfléchi à la façon dont cela est fait, actuellement chaque connexion infructueuse augmente le compteur et une connexion réussie le diminue. Je me suis demandé s'il serait plus logique de le remettre à 0 dès qu'une connexion réussie se produirait, mais je suppose que c'est un peu une question idéologique, ce qui a plus de sens.

Le problème avec ce nombre est que si vous avez 10 tâches, chacune avec un nombre de tentatives de 10 et un délai de renvoi de 100 ms, les redémarrages se produisent assez rapidement s'il y a un vrai problème de communication (100 tentatives en 10 secondes environ). .

maintenant, si vous avez par exemple toujours 5 échecs de communication et 1 succès, vous augmenterez continuellement les échecs de connexion. si cela se produit tout le temps, vous redémarrerez le nœud tôt ou tard, même si toutes les données pourraient être livrées.

le principal problème que je vois cependant est que, d'une manière ou d'une autre, le nœud ne se rend pas compte que la connexion sur la couche 2 a effectivement disparu et continue d'envoyer des données (je suppose). en plus de ce que j'ai réalisé ce soir, qu'arrive-t-il au syslog (et aux autres communications comme NTP etc.) s'il n'y a pas de connexion wifi? Est-ce également arrêté? cela pourrait expliquer pourquoi mes nœuds passent soudainement à 100% du processeur lorsque la couche 2 est partie. probablement plus aucune donnée de tâche n'est envoyée, mais il essaie de se débarrasser des paquets syslog UDP et ne peut pas ... juste une supposition cependant ...

désolé, texte long pour deux questions simples ... en bref:
niveau par défaut: oui, je le mettrais au maximum (100) environ par défaut ... si tout va bien, cela ne fait pas de mal sinon, l'unité redevient accessible ...
page sysinfo et règles: je dirais non, pourquoi cela devrait-il être changé dynamiquement? c'est une urgence valeurs ...

@ clumsy-stefan Je l'ai déjà réglé sur 50. Attendons. ;)

@wolverinevn hmm ... 50 devrait arriver assez rapidement en fonction du nombre d'intervalles de tâches et de tentatives (5-15min.) ... si cela n'aide pas, je pense que le nœud n'est en fait pas gelé, mais il peut juste ' t reconnectez-vous au réseau. J'ai eu cela même après un redémarrage de WD. pouvez-vous voir si le nœud essaie de passer en mode AP? voyez-vous l'AP-WLAN du nœud?

page sysinfo et règles: je dirais non, pourquoi cela devrait-il être changé dynamiquement? c'est une urgence valeurs ...

Je voulais être inspecté dans les règles en utilisant une variable système comme %conn_fail% et l'afficher sur la page sysinfo, à côté du nombre de reconnexions wifi.
Après tout, c'est une valeur statistique de performance

Je voulais être inspecté dans les règles en utilisant une variable système comme% conn_fail% et l'afficher sur la page sysinfo, à côté du nombre de reconnexions wifi. Après tout, c'est une valeur statistique de performance

ah, oui, d'accord, ça aurait du sens! c'est aussi un peu lié au numéro de 1993. Avoir un plugin qui envoie régulièrement un certain nombre de variables système / performances au contrôleur (sans gaspiller les tâches limitées disponibles) serait vraiment génial!

@wolverinevn hmm ... 50 devrait arriver assez rapidement en fonction du nombre d'intervalles de tâches et de tentatives (5-15min.) ... si cela n'aide pas, je pense que le nœud n'est en fait pas gelé, mais il peut juste ' t reconnectez-vous au réseau. J'ai eu cela même après un redémarrage de WD. pouvez-vous voir si le nœud essaie de passer en mode AP? voyez-vous l'AP-WLAN du nœud?

J'ai 9 tâches, 3 d'entre elles sont Dummy et MQTT_import. Je pense que les règles sont un peu chargées avec les capteurs de calcul et de lecture, j'ai essayé de limiter mqtt_publish en appelant des règles toutes les quelques minutes. La charge est d'environ 29%.
Si je me souviens bien, la dernière fois qu'il a été gelé ce matin, je ne trouve pas l'AP d'Espeasy (si vous voulez dire qu'AP_WLAN fonctionne en mode AP).
Ma configuration (réseau, emplacement de l'ESP) fonctionnait très bien avec un autre Nodemcu exécutant 2.3 ou 2.4 qui a été publié en mars.

_Le temps est de 7h et 20mins, RSSI est de -71dbm, il y a quelques wifi autour de moi.
Raison de la dernière déconnexion: | (200) Délai d'expiration de la balise
Nombre de reconnexions: | 35_

@wolverinevn le problème avec ce problème est que cela se produit de manière complètement aléatoire. J'ai ~ 30 nœuds en cours d'exécution, certains d'entre eux ont rencontré le problème, certains non, certains redémarrés, certains wnt en mode AP ...

Cela semble vraiment être une combinaison de l'occupation du nœud, de l'occupation de l'air (par exemple, le nombre d'appareils wifi) et de la façon dont votre AP gère réellement certaines conditions (missnig layer 2 acks, etc.) ...

donc je suppose que jusqu'à ce que nous trouvions un moyen au sein de l'application (ESPEasy) de détecter de manière fiable cette condition et d'agir dessus, il n'y a pas de "vraie" solution ....

@wolverinevn PS: vous n'utilisez pas les AP mikrotik par hasard?

@wolverinevn À propos du nombre de reconnexions (dans votre modification)
35 reconnexions en 8 heures environ, c'est beaucoup.
J'ai des nœuds ici en cours d'exécution pendant des jours qui n'ont qu'une poignée de reconnexions.
Le plus stable fonctionne pendant 20 jours 11 heures 46 minutes maintenant et seulement 1 reconnecter.

Connecté | 19d22h33m
- | -
Raison de la dernière déconnexion | (202) Échec de l'authentification
Nombre de reconnexions | 1

@wolverinevn PS: vous n'utilisez pas les AP mikrotik par hasard?

Non. J'utilise un routeur exécutant le firmware Padavan (type ASUS).

@ TD-euh je le savais. J'inspecte la raison, peut-être le bruit du module buck à proximité. Un autre a 0 se reconnecter après 2 heures.

Non. J'utilise un routeur exécutant le firmware Padavan (type ASUS).

Malheureusement je ne connais pas du tout ce FW ... Une chance de modifier les paramètres de la couche 2? Quelque chose comme les délais d'acquittement des images ou similaire? Certains paramètres de "distance"?

@ clumsy-stefan Malheureusement, je ne vois rien de tel.

@ clumpsy-stefan L'unité a été redémarrée 2 fois la nuit dernière avec 50 seuils d'échec définis. La bonne nouvelle est qu'il n'y a plus de gelée. Aujourd'hui, je vais essayer d'améliorer la connexion wifi par quelques changements mineurs dans la configuration matérielle.

3 unités Wemos dans la même pièce, connectées au même AP.
Se reconnecte au cours des 16 dernières heures environ,
Avec règle: sur WiFi # Connecté ....

26 redémarrages WD et 104 reconnexions:

9 redémarrages WD et 32 ​​reconnexions

Redémarrages 2WD et 40 reconnexions

Tous ont 50 seuils de défaillance définis

@Domosapiens & @wolverinevn une autre chose que vous pouvez essayer est d'augmenter le délai d'expiration de la clé de groupe sur votre AP (si vous avez une telle option). Normalement, c'est environ 5 minutes. Vous pouvez essayer d'augmenter à 30min. ou même 1h et voir si ça progresse (tant que ce n'est pas dans un réseau super haute sécurité, ce que je ne suppose pas si vous avez des IoT dedans) ...

@ TD-er

Le plus stable fonctionne pendant 20 jours 11 heures 46 minutes maintenant et seulement 1 reconnecter.

J'ai aussi actuellement des unités qui ont fonctionné pendant plus de 3 jours maintenant et d'autres qui ont redémarré en un jour ...

J'ai vu quelques problèmes avec le rekeeying de la clé de groupe. il semble d'une manière ou d'une autre que dans les versions plus récentes du noyau, il peut arriver que la recréation des clés se termine par un délai d'expiration ... Cependant, l'application devrait agir sur ce point et ne pas entrer dans un mode non réactif à charge élevée ... mais je ne le suis pas sûr où ça échoue ..

@ clumsy-stefan merci pour votre suggestion.
Je vois dans mon routeur dd-wrt un paramètre. "Key Renewal Interval" avec la valeur 3600 (en secondes).
Alors ça devrait être bien?

la recréation se heurte à un délai d'attente

Cela expliquerait seulement une reconnexion horaire à mon humble avis.
Grâce à la fonctionnalité géniale _WiFi # Connected_, nous pouvons le voir.
Aucune idée de la performance des anciennes versions.
Un problème caché depuis longtemps déjà?

après avoir défini mon renouvellement de clé de groupe à partir de 5min. à 1h les unités fonctionnent beaucoup plus stables. Je suppose qu'avec 40 clients connectés à un point d'accès toutes les 5 minutes. une nouvelle clé vient de rendre l'air un peu trop occupé ... après cela, je pourrais même réduire à nouveau le délai d'attente de trame-ack et les unités sont redevenues plus réactives, ainsi que j'ai moins de "délais de connexion" après avoir changé ces paramètres ...

@ TD-er toujours je pense que ce "timeout de clé de groupe" et "assoc fail" doivent ensuite être capturés et gérés par l'application. J'ai le sentiment que l'unité continue d'essayer d'envoyer des messages en file d'attente au contrôleur / serveur tout en essayant de faire une nouvelle clé qui rend l'unité trop lente et que la réinterception échoue ... donc la déconnexion sur la couche 2.

juste une idée approximative cependant, j'essaye toujours de vraiment l'épingler, mais c'est le plus proche que j'ai pu obtenir jusqu'à présent.

@ TD-er jsut maintenant j'ai à nouveau expérimenté un nœud qui entre dans une boucle indéfinie d'essais de reconnexion et qui expire toujours (voir le journal ci-dessous). Il est intéressant de noter qu'il se rend évidemment compte qu'il n'est pas connecté et n'essaye pas d'envoyer des données au contrôleur, ce qui signifie que les «tentatives de connexion infructueuses» n'augmentent plus et n'atteignent donc jamais la limite de connexion échouée.

aussi la charge montre toujours 100%, c'est pourquoi je suppose que ça ne réussit pas à se reconnecter car c'est toujours trop lent pour faire la poignée de main ... c'est comme une queue pour moi ... juste la mémoire diminue lentement (jusqu'à ce que Je suppose que ça plante parce que hors de mémoire) ...

Je vais tester avec # 2073 et voir si cette situation se reproduit ... cependant, cela se produit très rarement sur les deux nœuds connectés en série, afin que je puisse vraiment suivre ce qui se passe ...

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

Il est difficile de se connecter avec rssi - 80

La valeur RSSI n'est pas fiable lorsque le nœud ESP n'est pas connecté! le même nœud a moins de -70 lorsqu'il est connecté .... sur les nœuds de sommeil profond, ils affichent même le défaut "non connecté" de +31 lors de l'envoi des valeurs!
et après un redémarrage, il s'exécute sans problème ... (sans le déplacer ...) si vous lisez ci-dessus, c'est un problème de couche 2 qui est reproductible lorsque vous modifiez les paramètres sur l'AP ...

PS: vous pouvez l'essayer vous-même! jsut connect 20-30 nœuds et abaisse le délai de la touche de groupe à 5 min. et la valeur du seuil de réponse de trame à quelque chose comme 7 ... voyez ce qui se passe!

Je pense que ce n'est pas le bon endroit pour les problèmes avec layer2, vous devriez remplir le problème sur le noyau esp8266 ou peut-être mieux sur le projet nonos sdk
Mais s'il te plait ne crie pas ici

cela n'arrive qu'avec ESPeasy et non avec les autres types de firmwares que j'ai essayés. Je suppose que le nœud est trop occupé à un moment donné et ne laisse pas assez de temps au noyau pour faire la recréation (tout a été expliqué plusieurs fois), alors n'hésitez pas à lire les débogages et les explications ...
mais je suis d'accord, vous n'avez pas besoin de répondre en fait ...
PS: @ uzi18 aviez-vous déjà eu 30 nœuds fonctionnant avec succès en même temps?

@ TD-er: dans ESPEasyWifi.ino lignes 650 à 669 la correspondance par défaut de l'instruction switch sort du switch et donc tryConnectWiFi() renvoie true même si WiFi.status() est pas nécessairement WL_CONNECTED mais peut être n'importe quel autre état (seuls 2 faux états de retour sont vérifiés ..).

Chapper ceci et renvoyer true seulement si le WiFi.status() effectivement retourné WL_CONNECTED résout au moins l'un des problèmes de déconnexion / exception de couche 2 auxquels je suis confronté!

Qu'est-ce que tu penses?
Est-ce que je manque quelque chose ou pourquoi tryConnectWiFi() devrait-il revenir alors que WiFi.status() ne l'est pas? WL_CONNECTED`?

@ clumsy-stefan C'est bien de voir que vous êtes toujours en train de creuser le code WiFi.

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

L'idée initiale de cette fonction était de démarrer la séquence de connexion WiFi.
Peut-être que sa fonction a un peu changé à travers tous les changements depuis.
Mais vous êtes peut-être sur quelque chose ici.
Je pense que cela peut être un changement approprié de return true (à la fin de cette fonction) uniquement si le statut renvoie il est connecté.

Pouvez-vous décrire ce qui semble être l'autre problème de couche 2 auquel vous êtes confronté?

Je ne peux pas dire exactement quand l'autre exception se produit, mais au moins il y a une différence si cette fonction ne renvoie que true quand le statut est WL_CONNECTED J'attache le débogage avant et après le changement. .

avant

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

après

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 ... Je viens de me rendre compte qu'après cela, le statut interne ne correspond pas (encore) au statut Arduino ... cela pourrait également entraîner des problèmes, je suppose ...

@ clumsy-stefan cet état est dû au fait que nous ne pouvons pas relayer l'état du wifi Arduino, c'est pourquoi @ TD-er a introduit le statut ESPEasy, mais ok peut-être que nous pouvons essayer de vérifier si chaque état du code est correctement vérifié.

Il se peut que ce statut wifi ait été corrigé dans le noyau 2.5.0, alors peut-être que notre propre statut est devenu obsolète.
Ce serait bien, car cela rend le code WiFi plutôt compliqué et donc sujet aux erreurs.

Éditer:
Je regarde cette erreur que vous avez donnée:
Fatal exception 9(LoadStoreAlignmentCause):
L'un des correctifs les plus récents du noyau 2.5.0 concerne le constructeur de IPAddress , qui devrait résoudre les problèmes lorsque l'alignement de la séquence d'octets donnée n'est pas aligné sur 32 bits.
Peut-être que c'est quelque chose de similaire?

C'est l'une des hypothèses que j'ai, à savoir que le statut ESPEasy n'est pas toujours synchronisé avec le statut Arduino. Surtout les déconnexions temporaires sur la couche 2 (par exemple, les rekeeyings WiFi) ne sont probablement pas vraiment gérées / réalisées.

Une autre chose pourrait être le contraire, que ESPEasy pense qu'il est déconnecté et tente de se reconnecter mais que le noyau est toujours connecté et conduit donc à une exception. mais je ne peux pas encore le prouver ...

à propos de l'alignement, oui, peut être, mais je ne peux pas non plus le clouer actuellement ...

donc la seule chose dont je suis tout à fait sûr actuellement est que le code de retour de tryConnectWiFi() doit correspondre à l'état réel de la connexion ou au moins vérifier WL_CONNECTED ...

@ TD-er je suis un peu plus préoccupé par

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

Pour moi, les deux dernières lignes indiquent que le noyau n'a pas encore mis à jour le statut, même si ESPEasy pense qu'il l'a fait ... donc il pourrait se retrouver dans une condition de course ici ...

après que cela arrive parfois, je commence à voir beaucoup de

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

dont il ne récupère jamais ...

un peu plus tard, il me dit:

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

Aucun indice d'où cela vient ... mais après cela, il commence à essayer de se connecter au contrôleur / serveur qui échoue évidemment jusqu'à ce qu'il manque d'essais (100) et redémarre ...

EDIT: btw, vous pouvez forcer ce comportement si vous coupez le nœud de l'AP manuellement ... parfois il se reconnecte simplement, parfois cela se produit comme décrit ci-dessus ...
EDIT2: parfois il plante avec l'exception 9 ... donc il semble être une sorte de condition de course à quel point il récupère exactement d'une déconnexion! ma faute, j'ai eu un addLog() dans le rappel onDisconenct() ...

c'est plus ou moins toujours la même situation. après l'échec de la poignée de main à 4 voies (rekeeying), il ne récupère plus jamais ... je ne sais pas comment forcer une récupération de cela.

au moins ajouter des delay(100) dans les processConnect() et processDisconnect , donnant ainsi le temps de mettre à jour l'état du WiFi, les satus WiFi se synchronisent à nouveau. Cela permet également aux unités d'entrer dans la situation ci-dessous beaucoup moins souvent!

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() renvoie un true ou false au cas où la connexion serait réussie ou non ... cependant le WiFiConnectRelaxed() ne vérifie jamais cela ...

cette fonction est-elle en quelque sorte antérieure au WiFi basé sur les événements? il semble qu'il n'atteigne jamais les 2 dernières lignes de cette fonction ...

Oui, c'était une sorte de restes d'avant le wifi événementiel.
Je pense que nous devrions vraiment envisager d'examiner à nouveau ce code WiFi, car il n'est pas aussi structuré qu'il devrait l'être.

ok ... je suis toujours en train de déboguer ce qui se passe exactement en raison du délai d'expiration de la prise de contact 4 voies et pourquoi le nœud ne se reconnectera pas à nouveau ... mais je pense que je pique encore un peu dans le noir, mais je trouve de petits bits ici et là qui pourrait s'additionner cependant ....

un autre petit semble être dans WifiCheck() ... là-dedans, la vérification de la connectivité de la couche 2 n'est effectuée que lorsque l'IP n'est plus valide (par exemple, tous les octets sont à 0). Cela pourrait conduire à la situation dans laquelle la couche 2 est dis- (ou re) connexion / établissement de liaison, etc. mais l'IP est toujours valide car elle n'est pas encore expirée (DHCP). C'est probablement la raison pour laquelle le "renouvellement du DCHP a probablement échoué" ne se produit qu'après un long moment, lorsque le bail a effectivement disparu ... mais je vérifie toujours cela ...

il y a aussi wifiCheck() , WiFiConnected() et connectionCheckHandler() qui font tous une sorte de vérification de connexion, et s'appellent les uns les autres ainsi que resetWiFi() sous certaines conditions. . en particulier connectionCheckHandler() ne semble être appelé que lorsque mqtt_reconnect_count > 10 . Alors, que se passe-t-il dans un environnement non MQTT?

PS: Je documente juste mes découvertes ici à la recherche des problèmes de WiFi sous-jacents ... Je suis donc heureux de toute réflexion à ce sujet, mais pas forcément attendu ...

il doit y avoir une sorte de mystérieuse condition de race quelque part. lorsque l'AP initie une réautorisation ou une réintervention, le nœud / noyau n'obtient pas assez de temps processeur pour terminer la poignée de main ou il est interrompu en le faisant, en particulier sur les nœuds avec un signal faible (et donc la poignée de main prend beaucoup plus de temps). . (voir ci-dessous).

ces rekeesings / reauths semblent générer un événement de déconnexion par le noyau, même si le noyau ferait une renégociation automatique ou une reconnexion (si je comprends bien). mais il semble que ce processus de prise de contact soit interrompu par la machine à états ESPEasy lorsqu'une reconnexion manuelle est déclenchée ... ce processus se répète et ne se termine jamais (ou dans certains cas génère des wdt).

` 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

Alors peut-être devrions-nous utiliser les événements wifi uniquement pour surveiller le processus, pas pour agir nous-mêmes?
Changer cela rendra les versions 2.3.0 et peut-être 2.4.0 inutilisables.

Non, je ne ferais pas ça ... Dans ma branche j'ai déjà fait quelques changements (pas si intrusifs) qui semblent rendre ces cas moins fréquents ...

vient de trouver une autre petite chose: dans tryConnectWiFi() le WiFi.status() chèque arrive à la fin après que l'appel WiFi.begin() commence à retourner WL_DISCONNECTED . Selon la documentation, cela signifie "si le module n'est pas configuré en mode station". essayer de savoir pourquoi cela se produit ou si cela aide à mettre explicitement l'esp en mode AP avant d'appeler WiFi.begin()

J'espère donc toujours trouver le "vrai" problème sous-jacent pourquoi ces étals se produisent ... Si tel est le cas (croiser les doigts), je suggérerais de faire un PR avec tous les changements pour que vous (et d'autres) les examiniez ....

Sachez que j'ai également vu beaucoup de situations dans lesquelles l'état de WiFi.status() n'était pas correct.
Alors peut-être que les bibliothèques de base ont maintenant des correctifs et que j'ai très probablement foiré quelque part dans toutes les tentatives pour que le WiFi se comporte de manière stable.
Ce débogage a été très difficile à faire, car je ne peux pas reproduire ces problèmes moi-même et j'ai dû agir sur les rapports d'autres utilisateurs.
Dernièrement, j'ai un module qui se comporte également mal en ce qui concerne le WiFi, c'est donc mon module de test WiFi préféré. Mais cela peut aussi être une indication que le problème s'aggravera lorsque certaines pièces sont tout simplement hors spécifications. Par exemple, une alimentation, ou des condensateurs de découplage manquants, des traces de PCB (trop) minces, moins de blindage, etc.

bien sûr, non pas que j'écarte les problèmes de HW. Mais j'ai ~ 40 nœuds en cours d'exécution, avec tous les types d'alimentation, différentes cartes, marques, etc. et à un moment donné, la plupart d'entre eux font face à des problèmes de connectivité ... en particulier ceux avec une faible couverture wifi ou GPIO en cours d'utilisation.

Et j'ai actuellement un peu de temps pour faire du débogage et je le trouve toujours très intéressant et stimulant;) À présent, je commence même à comprendre comment fonctionne toute la séquence de connexion, vérification, déconnexion, etc.;)

Donc, si cela vous convient, je continuerai à creuser plus profondément ces problèmes de connectivité ... vous êtes le patron cependant ...

Veuillez continuer à creuser :)
Je veux vraiment être libéré de tous ces problèmes de déconnexion qui sont presque impossibles à reproduire.
Ils ont déjà pris beaucoup trop de temps maintenant et ce serait vraiment génial s'ils sont corrigés.

J'obtiens environ 4 à 24 heures de disponibilité suivies de 2 à 10 heures de temps d'arrêt en moyenne.
Pendant les temps d'arrêt, le nœud continue de fonctionner, mais il n'y a pas de connexion wifi.

Le point d'accès (MikroTik) indique:

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 | Information |
----- | ----- |
Construire: ⋄ | 20103 - Mega |
Bibliothèques: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 Prise en charge PUYA |
Version GIT: ⋄ | mega-20190110 |
Plugins: ⋄ | 7 [Normal] [Sonoff POW R1 / R2] |
Temps de construction: ⋄ | 10 janvier 2019 03: 21: 19 |
Nom de fichier binaire: ⋄ | ESP_Easy_mega-20190110_hard_SONOFF_POW_4M.bin |

Ce n'était pas le problème sur l'ancienne version (quand je pouvais encore utiliser le canal 14 et avoir mon réseau SSID caché).

Le canal WiFi est-il fixe ou est-il variable?
J'ai lu sur la page de dépannage de Tasmota et ils conseillent fortement de faire réparer le canal WiFi.
Si le canal 14 n'est pas utilisable, alors quelque chose concernant les paramètres régionaux peut avoir changé quelque part, puisque seuls les canaux 1-11 sont autorisés dans tous les pays.
Les canaux 1, 6 et 11 sont également les seuls canaux utilisables sans interférence d'autres canaux.

seuls les canaux 1-10 fonctionnent, pas 11. Voir ceci: https://github.com/letscontrolit/ESPEasy/issues/1337#issuecomment -394118989

Le canal Wifi est fixe, bien sûr.

N'importe quel canal peut avoir des interférences provenant d'autres canaux, aucun moyen de le contrôler. Bon sang, il peut même y avoir des interférences provenant du même canal.

btw, en ce qui concerne le problème auquel je suis confronté - le voyant d'état du wifi (GPIO13 inversé) est normalement bleu fixe, mais lorsque l'appareil est hors ligne, il va dans le modèle 0,0,0,0,0,1,2,3, 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, ... de luminosité.

IP fixe et DCS, mais les canaux n'ont jamais changé dans le passé.

Von: Gijs Noorlander [mailto: [email protected]]
Gesendet: vendredi, 11 janvier 2019 21:47
Un: letscontrolit / ESPEasy
Cc: Abonné
Betreff: Re: [letscontrolit / ESPEasy] [BUG] [Stabilité WiFi] Exception ESP 3/29 lorsque la couche 2 se déconnecte (# 1987)

Le canal WiFi est-il fixe ou est-il variable?
J'ai lu sur la page de dépannage de Tasmota et ils conseillent fortement de faire réparer le canal WiFi.
Si le canal 14 n'est pas utilisable, alors quelque chose concernant les paramètres régionaux peut avoir changé quelque part, puisque seuls les canaux 1-11 sont autorisés dans tous les pays.
Les canaux 1, 6 et 11 sont également les seuls canaux utilisables sans interférence d'autres canaux.
-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment-453651579 , ou désactivez https://github.com/notifications/unsubscribe-auth/AomgSxPjVKWrp0MSQ90TtbESKxFqaPivGaPVg9PVg https://github.com/notifications/beacon/AomgS_fhHQnmg1AdpX11mVL9yNra8S_kks5vCPgxgaJpZM4YDivP.gif

Les trucs de Mikrotik donnent une grande puissance, mais même les paramètres par défaut pour le wifi ne sont pas corrects.

• Assurez-vous que vous n'avez pas dans les paramètres de sécurité tkip et n'activez que le cryptage aes ccm
• Entrez une mise à jour de groupe de clés comme 30 min ou 1 heure
• dans les canaux ont une largeur de canal de 20Mhz et à ny avis dich la bande B et aller juste pour G / N
• Canal d'extension désactivé
• Seule la désactivation de PMKID (recommandé si vous êtes hystérique à propos de la sécurité) semble rendre l'Esp veeeery malheureux
• Ajoutez votre pays aux paramètres wifi (ou voyez quelle est votre puissance maximale pour l'AP que vous avez et réduisez la puissance de transmission de 3). Cela augmente très souvent les performances du wifi (contre-intuitif, je sais)

Je n'ai généralement pas de déconnexions (sauf quand j'ai eu ce truc PMKID)

De toute façon, il serait intéressant de publier vos paramètres AP :-)

Ce sont de bons conseils. Je connais assez bien les réseaux et encore plus expérimenté dans mikrotik et j'ai tout configuré comme vous le dites sauf la clé de groupe.

La mise à jour de la clé de groupe n'a à voir qu'avec la clé de groupe, pas avec la clé de monodiffusion où se trouve le problème, mais j'ai rétrogradé ce paramètre aux fins de l'expérience.

@ 0ki Cool ne vous savait pas où un expert sur RouterOS!

J'ai conclu qu'il s'agissait clairement d'un bogue dans le logiciel ESPEasy. Vous pouvez voir le comportement problématique sur la droite qui correspond au fait que RouterOS déconnecte le client qui se comporte mal sur la gauche. Le spectre radio est clair comme vous le voyez.

Malheureusement, je n'ai pas le temps de me plonger dans la base de code ESPEasy pour le moment, mais je suis convaincu que cette comparaison entre mauvaise et bonne communication sera utile.
Légende: __red - point d'accès | bleu - espeasy | vert - un autre appareil sur mon réseau iot__

Je crois que ESP_easy, pour une raison quelconque, décide de passer en mode AP après avoir reçu une réponse assoc (trame 380 à gauche) et de ne pas continuer la négociation à quatre. Notez également le changement de macaddress espeasy - le premier octet passe de 80 à 82.

À 0ki

J'ai conclu qu'il s'agissait clairement d'un bogue dans le logiciel ESPEasy.

Moi aussi, mais je n'ai aucune idée de l'endroit où devrait se trouver le bogue.
Il semble que l'état interne d'ESPeasy concernant l'état déconnecté n'est pas synchronisé avec l'état réel.
Il est très bien possible que j'ai fait une erreur en écrivant ce code, ou que ce soit un bogue dans les bibliothèques de base.

Quel fichier entendez-vous spécifiquement par «ce code»? Si vous pointez vers un fichier ou deux, je pourrais y jeter un œil.

Sinon - puisque maintenant vous voyez le moment exact où cela se produit, j'espère que vous pourrez l'examiner de plus près.

Comme je suis également en train de creuser ce problème (depuis environ 2 mois maintenant), je ne suis plus complètement sûr qu'il s'agisse du code ESPEasy lui-même. plus une interaction entre ESPEasy et le noyau / bibliothèque WiFi ... Mes débogages / logs montrent que le "Disconnect" se produit toujours après un échange de clé de groupe / rekeeying. MAIS le rappel n'est appelé qu'après l'expiration du délai de rekeying et par la suite après l'échec de l'authentification ... Donc, à mon avis, ESPEasy ne laisse pas assez de temps CPU au noyau pour faire le rekeeying ... jusqu'à présent, je ne l'ai pas fait Je ne trouve pas de moyen de savoir quand le nœud est dans ce nœud réinterprétant ou en mode réautorisation et donc de pouvoir ajouter suffisamment d'appels delay() pour que la réautorisation réinterprète soit réussie ...

Pour aider à identifier le problème dans le temps - cela fonctionnait bien avec:

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

Et par ok, je veux dire non seulement qu'il n'y avait pas de déconnexion, mais aussi que la connexion à AP caché sur le canal 14 n'était pas un problème.

@ maladroit-stefan, je soutiens pleinement la détection du problème qui cause sa déconnexion en premier lieu, mais honnêtement, il peut y avoir un certain nombre de raisons pour lesquelles une association wifi peut tomber, bien sûr, un échange de clés de groupe ne devrait pas être l'une des leur.

Le problème le plus pressant est le suivant: pourquoi ne peut-il pas se reconnecter après s'être déconnecté. Cela ne peut pas être un problème de synchronisation, car je donne espeasy 5000 ms pour répondre avec le message 2 du 4way HS.

Je pense que le problème est que vous n'obtenez la déconnexion qu'APRÈS l'échec de l'échange de clé ... donc vous n'avez jamais maintenant lorsque l'échange commence réellement, c'est là que vous auriez besoin de donner plus de temps au noyau ...

dans les journaux, vous pouvez voir qu'ESPEasy pense pendant un certain temps qu'il est toujours connecté, même si ce n'est pas le cas (même un ping vers le nœud échoue), mais le nœud essaie toujours d'envoyer des données (et évidemment la connexion échoue alors) ...

le deuxième problème que je suis entièrement d'accord est que, même s'il obtient une déconnexion, pourquoi ne peut-il pas se reconnecter avec une séquence de connexion complètement nouvelle ... Probablement le module ou le noyau est bloqué dans un état étrange?

EDIT: PS: le 4way HS ne tombe pas toujours en panne, (je le fais toutes les 10min.), Il semble donc être une combinaison de l'état / de l'occupation de l'ESPEasy et du moment où le HS se produit ..

Ce que je peux faire, c'est essayer de supprimer complètement le WiFi (éteindre également le modem) et commencer une nouvelle reconnexion complète lorsqu'une déconnexion inattendue se produit.
Je ne sais pas si c'était dans ce fil, mais dans l'un de ces problèmes, quelqu'un a répondu avec un tweet de quelqu'un de Shelly, qui a mentionné qu'il devait redémarrer complètement la pile wifi après la déconnexion.

@ TD-er c'est aussi ce que j'ai mis dans ma dernière version. dans processDisconnect() J'ai ajouté un setWifiMode(WIFI_OFF); pas sûr cependant, si cela suffit ... actuellement il tourne sur certains nœuds de test (depuis environ 1h) ...

@ TD-euh, c'est une bonne idée. pousser une version git et je vais flasher mes trucs!

Je viens de commencer à lire une partie de la base de code il y a 5 minutes, donc cela peut ne pas être pertinent, mais: Assurez-vous également que wifi_connect_attempt est défini sur 0 à ce stade.

hmm ... l'ajout de delay(0) dans backgroundtasks() après chacun des appels de sous-programme semble stabiliser un peu le premier problème (4way-HS). Je ne sais pas si c'est une coïncidence difficile ...
@ TD-er pourrait-il être, que backgroundtasks() bloque l'exécution à un moment donné?

de manière générale: l'ajout de delay(0) dans toutes sortes d'endroits différents où les chronologies montrent de longs temps de traitement semble améliorer beaucoup la gestion du 4way-HS. J'ai plus de chiens de garde SW / HW qui entrent en jeu maintenant que de problèmes de réinterrogation (mais j'en ai encore) ... de manière symptomatique, je dirais donc que c'est vraiment lié au fait que la partie noyau / wifi n'obtient pas assez de cycles pour faire des choses (assez rapides) comme rekeeying et l'AP se lasse alors d'attendre une réponse ...

Ce que je vois aussi, c'est que parfois le client.connect() ou le sendData() peut prendre beaucoup de temps (jusqu'à 2 secondes). Dans certaines documentations, j'ai trouvé que si quelque chose prend plus de delay(0) ms, vous devez appeler

Il y a aussi un autre callback onStationModeAuthModeChanged dans le noyau. Cela vaut probablement la peine d'être examiné, car celui-ci est probablement déclenché avant la déconnexion réelle. mais c'est très peu documenté ... Quelqu'un en a-t-il l'expérience?

EDIT: cela semble être une coïncidence / condition de course avec d'autres choses qui se font au moment où l'AP demande une nouvelle clé ... mais encore une fois juste des observations ...

Je ne sais pas à quelle fréquence ces demandes envoyées par l'AP sont retransmises.
Normalement, le signal de balise de l'AP est envoyé toutes les 102,4 msec. Si certaines tâches prennent plus que cela, l'ESP manque l'une de ces trames de balise. Donc je ne sais pas à quel point c'est grave.
Je sais que les demandes ARP sont parfois manquées, ce qui conduit à des problèmes qu'un commutateur ne sait plus comment acheminer les paquets vers cette adresse MAC et rend ainsi l'ESP inaccessible, alors qu'il peut toujours envoyer des données lui-même.

les cadres de balise manquants ne sont rien. il ne devrait même pas avoir besoin de trames de balise car il devrait de toute façon sonder activement mon réseau caché.

Je ne suis pas un expert en WiFi.
Si j'ai bien compris, l'intervalle de balise est le seul moment - assez garanti - où l'ESP essaie d'écouter le WiFi et entre-temps, il essaiera de dormir autant que possible.

Et comme je l'ai compris, la seule différence entre les réseaux «cachés» et les réseaux «non cachés» est que le SSID n'est pas diffusé. Donc, en fait, il se connecte uniquement sur la base du BSSID (adresse MAC d'AP).
C'est également ce que fait l'ESP lors de la connexion à des réseaux WiFi (non cachés), à la seule différence qu'il effectuera une analyse avant et essaiera de trouver un BSSID qui a un SSID qui correspond à celui donné.
Lors d'une reconnexion automatique, il essaiera d'abord la dernière combinaison de canaux BSSID + connue sans effectuer de balayage. En d'autres termes, cela ne diffère que lors de l'établissement d'une connexion.

Donc à ma connaissance, tant qu'il y a une connexion à un réseau, il écoutera également les trames de balise.

Je ne suis pas un expert en WiFi.
Si j'ai bien compris, l'intervalle de balise est le seul moment - assez garanti - où l'ESP essaie d'écouter le WiFi et entre-temps, il essaiera de dormir autant que possible.

Et comme je l'ai compris, la seule différence entre les réseaux `` cachés '' et les réseaux `` non cachés '' ..........

Oh, cela me rappelle quelque chose qui peut être assez important. Je lance mes ESP dans un SSID caché
À propos, toujours pas de déconnexion ou de redémarrage sur mes nœuds (en essayant des mises à jour de clé de groupe de 5 minutes)

Un de mes nœuds a été redémarré le 5 décembre en raison d'une panne de courant.

C'est de celui-là:

Unité: | 5
- | -
Heure locale: | 15/01/2019 23:27:32
Disponibilité: | 41 jours 12 heures 46 minutes
Charge: | 15,80% (LC = 9135)
Mem gratuit: | 12160 (5360 - sendContentBlocking)
Pile gratuite: | 3552 (1520 - SensorSendTask)
Boot: | Démarrage à froid (0)
Raison de la réinitialisation: | Système externe
Réseau ❔
Wifi: | 802.11N (RSSI -67 dB)
Config IP: | DHCP
IP / sous-réseau: | 192.168.1.89 / 255.255.255.0
GW: | 192.168.1.1
IP du client: | 192.168.1.67
DNS: | 192.168.1.1 / 0.0.0.0
Plage d'adresses IP autorisées: | Tout autorisé
STA MAC: | 5C: CF: 7F: B1: 3F: 12
AP MAC: | 5E: CF: 7F: B1: 3F: 12
SSID: | Lurch4 (34: 31: C4: B1: 8D: C7)
Chaîne: | 11
Connecté: | 20h04m
Raison de la dernière déconnexion: | (202) Échec de l'authentification
Nombre de reconnexions: | 61
Micrologiciel
Construire: ⋄ | 20102 - Méga
Bibliothèques: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 prise en charge PUYA
Version GIT: ⋄ | méga-20181109
Plugins: ⋄ | 46 [Normal]
Construire Md5: | 47f19d99d0c3f083314b45668b1f5c
Contrôle MD5: | passé.
Temps de construction: ⋄ | 9 novembre 2018 03:23:22
Nom de fichier binaire: ⋄ | ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Comme vous pouvez le voir, en moyenne plus d'une déconnexion par jour. Il est connecté à une AVM Fritzbox 1750E

Je pense que les trames de balise ne sont pas si critiques ... Je ne sais toujours pas pourquoi après une déconnexion, la séquence normale WiFi.begin() échoue toujours avec un '(2) Auth expire' .

La seule indication est que la charge du processeur à ce stade indique toujours 100% et indique que le cœur n'a tout simplement pas assez de temps pour établir la liaison ...

Je suppose qu'il y a quelque chose qui ne va pas dans les bibliothèques de base (LWIP ou Arduino ou ESP) et nous devrions réinitialiser le wifi.
Désactivez donc le wifi et recommencez. Peut-être attendez-vous également entre ces étapes pour vous assurer que les tampons sont vidés ou du moins vidés et que les demandes en attente sont activement annulées.

@ TD-er pouvez-vous pousser ce changement, pour que je puisse voir si cela fonctionne?

Le changement discuté dans les 2 derniers articles?
Il n'a pas encore été implémenté, mais je peux essayer ce soir de le coder et de faire un test de build.

Oui, réinitialisation du wifi.

@ TD-er a écrit:

Désactivez donc le wifi et recommencez. Peut-être attendez-vous également entre ces étapes pour vous assurer que les tampons sont vidés ou du moins vidés et que les demandes en attente sont activement annulées.

Je ne suis pas sûr d'avoir un rinçage ... depuis que j'ai supprimé tous les appels client.flush() avant le client.stop() Il semble également que la déconnexion se produit moins souvent. En lisant une documentation, j'ai vu que le vidage supprime tous les tampons d'entrée (tcp), donc théoriquement, il peut arriver que les réponses soient perdues ...

En ajoutant simplement mon 2c, j'ai quelques points d'accès Mikrotik, avec quelques sonoff exécutant espurna et quelques NodeMCU exécutant ESPEasy. J'ai dû ajouter un AP supplémentaire pour les appareils ESP, car pendant une période de trafic élevé sur mon réseau, comme les sauvegardes, je perdrais mes appareils ESP. Je pense que c'était la force du signal WiFi et le trafic. Une fois que l'AP supplémentaire a été ajouté, je ne me souviens plus avoir vu ce problème à nouveau.

Mais mes appareils NodeMCU et ESPEasy ont des déconnexions. Je vais configurer un moniteur ping netdata pour les appareils et voir si je peux comprendre quand, comment et pourquoi cela peut se produire et voir si je donne des informations.

Une autre note, je n'ai pas plus de 40 appareils comme @ maladroit-stefan, seulement environ 5 utilisateurs et leurs appareils mobiles et un appareil intelligent étrange comme la télévision, mais se pourrait-il que l'appareil Mikrotik soit surchargé ou le réseau WiFi RF saturé ?

J'aurais aimé avoir un moyen de voir la quantité de bruit RF. J'ai une application (WiFi Analyzer) qui me montre le nombre de points d'accès et comment ils diffusent les canaux WiFi. J'ai utilisé cet outil pour définir mes canaux WiFi pour différents points d'accès WiFi.

Mais je ne peux pas vraiment dire s'il pourrait y avoir d'autres interférences RF.

En ce qui concerne l'idée d'un périphérique Mikrotik surchargé, j'utilise MikroTik 951UI-2HND pour mon routeur principal et MikroTik RB9412nD hAP lite comme AP ESP.

Je me demande si cette information est utile de quelque manière que ce soit?

@LeeNX merci pour les indices. mes nœuds sont répartis sur 3 AP et le RF est quelque peu équilibré (max. 20 clients par AP environ), de sorte qu'il y ait le moins d'interférences possible (bien sûr il ne peut pas y en avoir ...). Je ne pense donc pas que les MT soient surchargés (je travaille dans une entreprise fournissant une connectivité réseau et WLAN pour des événements professionnels, etc. donc j'ai des tests assez approfondis de l'infrastructure), mais je suis d'accord que le temps d'antenne surchargé pourrait être un problème ... mais même si c'est le cas, un nœud ne peut jamais se reconnecter plus de 250 fois après une déconnexion, puis après le redémarrage, il se reconnecte immédiatement, je pense que cela ne peut pas être un problème de temps d'antenne ... Je ne vois ça sur aucun autre appareil ...
donc je pense toujours que c'est une coïncidence ou une condition de course entre l'état de la puce wifi interne, la quantité de cpu-time que reçoit le noyau wifi et les autres tâches en cours d'exécution sur la partie ESPEasy ...

@ clumsy-stefan Je suis d'accord avec vos idées. Je voulais juste souligner que l'utilisation du petit AP Mikrotik avec plus de 40 nœuds aurait pu être un processeur Mikrotik ou une RAM limitée, mais cela ne semble pas être le problème.

Je me demande si dépeloying un appareil ESP32 et NodeMCU avec rien d'autre que le noyau ESPEasy de base et le laisser fonctionner, afin que nous puissions tester le processeur ESP et aucune autre influence de plugin. Voyez ce que je peux déployer et tester le ping netdata.

Si cela nous donne des informations utiles, je vous ferai un rapport.

Merci les gars!!!

J'ai un nœud ici fonctionnant presque rien (IR RX / TX) et il fonctionne pendant des semaines sans problème.
L'autre nœud qui a une disponibilité de plus de 40 jours exécute Domoticz MQTT et BME280 + MH-Z19 CO2.
Donc, cela dépendra probablement aussi du plugin en cours d'exécution et à quelle fréquence et peut-être aussi si l'intervalle de lecture correspond toujours à l'intervalle de lecture des autres plugins.

J'ai déjà défini des appels de fonction périodiques (10 / sec, 1 / sec et 30sec) avec un décalage initial dans le planificateur afin qu'ils continuent à fonctionner autant que possible dans différents appels de boucle.

Peut-être que je devrais également ajouter un événement piloté par la minuterie d'interruption comme le fait Tasker (ou simplement utiliser Tasker au lieu du planificateur que j'ai écrit) et définir une tâche à un intervalle de 10 ms pour exécuter le délai (0).
La seule chose est que cela peut interrompre d'autres transferts GPIO et ainsi perturber les lectures du capteur.

cela résoudrait probablement le problème 4way-HS, mais je suppose que ce n'est pas le problème de reconnexion ... c'est toujours le plus étrange ... Je viens de voir mon nœud de test échouer à nouveau pendant 12 heures en essayant de se reconnecter pendant> 300 fois à l'AP sans Succès. après le redémarrage (logiciel), il s'est reconnecté instantanément (le redémarrage + reconnexion a pris environ 5 secondes) ...

Je viens de trouver ce problème qui semble assez lié à ce que nous voyons ici:
https://github.com/esp8266/Arduino/issues/5527

semble similaire, oui ... mais appeler le wifi OFF ne semble pas le changer (essayé), actuellement j'essaye avec WiFi.setOutputPower(0) avant d'appeler WiFi.begin() comme suggéré ici
https://github.com/esp8266/Arduino/issues/2235
et ici
https://github.com/esp8266/Arduino/issues/2186#issuecomment -233853152
attend toujours que cela arrive maintenant difficile ...

c'est similaire mais ce n'est pas pareil. En fait, dans notre cas, le redémarrage de l'AP résout le problème, dans le problème publié par Gijs, le redémarrage de l'AP ne résout pas le problème.

@ giig1967g le redémarrage de l'AP ne résout pas le problème pour moi! seul le redémarrage du nœud le permet de se reconnecter (dans mon environnement cependant) ...

@ giig1967g Dans le numéro mentionné par @ clumsy-stefan, ce redémarrage de l'AP est également mentionné: https://github.com/esp8266/Arduino/issues/2235#issuecomment -248851270

Il semble donc que nous ayons plusieurs problèmes à portée de main.

@ maladroit-stefan
Ah ok. Et dans mon cas uniquement avec Mikrotik ... :(
@ TD-er
peut-être devriez-vous demander quelle marque / modèle AP ils utilisent ...

@ giig1967g Certains nœuds étaient également inaccessibles, mais l'intervalle de ces événements était bien supérieur à 10 jours, il est donc un peu difficile de dire si cela est lié à l'un de ces problèmes.
Environ la moitié de mes nœuds sont maintenant connectés à un Mikrotik et l'autre moitié est connectée à la Fritzbox 1750E

@ giig1967g Je n'ai aussi que des MT ... et cela semble arriver plus souvent aux nœuds avec un signal plus faible et aux nœuds avec GPIO en cours d'utilisation (en particulier PCF) ...

J'aurais aimé avoir un moyen de voir la quantité de bruit RF. J'ai une application (WiFi Analyzer) qui me montre le nombre de points d'accès et comment ils diffusent les canaux WiFi. J'ai utilisé cet outil pour définir mes canaux WiFi pour différents points d'accès WiFi.

Mais je ne peux pas vraiment dire s'il pourrait y avoir d'autres interférences RF.

Vous pouvez faire /interface wireless registration-table print interval=1 sur votre mikrotik pour voir le snr.

malheureusement, le WiFi.setOutputPower(0) n'a pas aidé non plus ... après près de 6 heures de bon fonctionnement (sans aucune modification de l'infrastructure wifi, tout à coup, il se retrouve à nouveau dans l'impasse (voir la sortie série ci-dessous) dont il ne se remet jamais, sauf si par hasard un SW ou HW WDT entre en action ...

cela ne semble se produire qu'après un «délai de mise à jour de la clé de groupe» ou un «échec de la prise de contact 4 voies». si je lance le nœud de l'AP manuellement, il obtient également un "auth expire" mais peut se reconnecter instantanément ...

sortie série (pas la charge ne passe alors à 100%) ...

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

juste une petite remarque: ajouter wifi_set_phy_mode(PHY_MODE_11G); et forcer le nœud en mode 802.11g semble être au moins une solution de contournement. Je n'ai redémarré aucune des unités depuis quelques heures et aussi une ou deux fois une unité récupérée du problème de temporisation de clé de groupe ci-dessus ...
probablement lié à

• ESP8266 SoftAP prend uniquement en charge 802.11b / g.

ce qui est noté dans la documentation ...

Je mettrai à jour plus tard / demain s'il reste stable ...

Comme cela a déjà été noté (à quelques reprises) par quelqu'un d'autre, la sensibilité devrait également être augmentée en passant à 802.11G.
Mon objectif est (était?) Que la plupart des AP ont des problèmes lors du basculement entre N, G et B.
Avez-vous des clients mixtes? (G et N) actif sur le même AP?

J'utilise différents modes sur tous les Mikrotik. B / G / N / AC mélangé, également les deux bandes 2 / 5GHz, y compris les AP virtuels définis ... Différents clients se connectent avec différents modes sur le même AP, sans problèmes (sauf l'esp8266).

bonne nouvelle (du moins pour moi) ... mes nœuds ont fonctionné pendant les 12 dernières heures sans déconnexion / redémarrage / gel!

forcer le nœud en 802.11g semble fonctionner sans problème avec les AP MikroTik. au moins, c'est une solution de contournement simple (tant que vous n'avez pas besoin de la vitesse supplémentaire de 802.11n).

si quelqu'un veut se tester, il suffit d'ajouter ESPEasyWifi.ino autour de la ligne 644 dans la fonction tryConnectWiFi() la ligne suivante (après setupStaticIPconfig(); ):
WiFi.setPhyMode(WIFI_PHY_MODE_11G);

Je ne peux que deviner que les problèmes se posent parce que le mode SoftAP ne prend pas en charge 802.11n et que le nœud est connecté en mode N, le noyau devient "confus" d'une manière ou d'une autre ... mais je suppose que c'est un problème à soulever avec les personnes du noyau. ..

Pour ESPEasy, cela pourrait être rendu configurable je suppose (@ TD-er?) Afin de pouvoir choisir sur la page de configuration dans quel mode l'ESP doit fonctionner (B / G / N) ...

Oui, je vais ajouter une option de sélection dans les paramètres avancés.
J'ai oublié qui l'a demandé en premier, mais je vais le rechercher et le créditer aussi dans le commit;)

parfait!! Je n'ai pas besoin du crédit, j'en ai juste besoin pour fonctionner;) alors n'hésitez pas à le lui dédier !! 😄

Lors du débogage, j'ai trouvé d'autres petites choses que je suggérerais de changer (comme appeler delay() sans condition après les appels de plugin, quelques {} supplémentaires et quelques ajouts à la sortie de journalisation. Devrais-je faire un PR pour ces ASPIT ou voudriez-vous le garder tel quel (je pense que ce ne sont pas des changements vitaux, juste quelques améliorations mineures probabaly)?

Veuillez faire un PR.
Cela aiderait au moins la discussion et garderait une trace de vos conclusions.
L'ajout de commentaires à ce que vous avez vérifié serait également utile

Pour référence # 2012
Tous les crédits au dev. équipe!

Ce correctif inclut-il également l'idée WiFi.setOutputPower (0)?

Je fais une expérience depuis 7 jours maintenant.
nœud mega-20180224 - zéro redémarrage
nœud mega-20190110 - 35 redémarrages; 9 d'entre eux aujourd'hui.

J'ai laissé la ligne pertinente dans le code mais je l'ai commentée. Vous devrez donc supprimer le // (à propos de la ligne 644) dans ESPEasyWiFi.ino et le recompiler!

@oki désolé, je viens de voir que j'ai mal lu votre question ... Non, cela n'est pas inclus car je ne voyais aucune différence lors de la mise sous tension à 0 avant de se reconnecter ... J'ai donc rejeté celle-là à nouveau!

Je fais une expérience depuis 7 jours maintenant.
nœud mega-20180224 - zéro redémarrage
nœud mega-20190110 - 35 redémarrages; 9 d'entre eux aujourd'hui.

C'est effectivement comparer:

• core 2.3.0 sans wifi basé sur les événements
• core 2.4.2 avec wifi basé sur les événements.

bonne nouvelle (du moins pour moi) ... mes nœuds ont fonctionné pendant les 12 dernières heures sans déconnexion / redémarrage / gel!

forcer le nœud en 802.11g semble fonctionner sans problème avec les AP MikroTik. au moins, c'est une solution de contournement simple (tant que vous n'avez pas besoin de la vitesse supplémentaire de 802.11n).

Je l'ai fait dans l'autre sens pour les tests.
J'ai réglé mon Mikrotik sur N-Mode uniquement et bien ... tous les ESP fonctionnent depuis> 12h sans un seul redémarrage.

approche bonne et valable aussi! Malheureusement, je ne peux pas faire cela, car je fais un certain nombre de clients sans capacité N ...

Désactivez simplement le mode B et activez uniquement G / N. Vous êtes mieux sans le mode B. Sauf si vous avez d'anciens téléphones ou (généralement) des scanners de codes-barres wifi datant de 10 ans qui ne prennent en charge que le mode et les tarifs B.

La sensibilité supplémentaire de l'antenne en mode B ne jouera pas non plus de rôle significatif dans la portée. Le mode B consomme juste du temps d'antenne. Il n'y a littéralement aucun inconvénient à ne pas utiliser le mode B et aucun inconvénient à utiliser le mode N sur G également. Le mode N a une plage encore meilleure que B et G.

@ jimmys01 vous avez raison, le mode B n'est probablement plus utilisé nulle part ... mais je ne peux pas aller pour seulement N cependant ... donc ce serait à tester ce qui se passe en mode G / N si les nœuds restent stables et sont capables de se reconnecter en cas d'expiration du délai HS 4 voies.

g / n est instable pour moi.

Cela signifie-t-il que l'esp8266 rencontre des problèmes à chaque fois qu'il passe d'un mode (B / G / N)?

Cela signifie-t-il que l'esp8266 rencontre des problèmes à chaque fois qu'il passe d'un mode (B / G / N)?

Très probable.
J'ai vu beaucoup de problèmes avec certains appareils (pas ceux ESP) prenant uniquement en charge le mode G.
Si vous les utilisez en combinaison avec N appareils, ils peuvent sembler inaccessibles.
Le HomeWizard et certaines caméras WiFi sont connus.

Avec cette nouvelle version mega-20190121 l'ESP semble être plus stable, je n'ai pas eu de problèmes de crash / Wlan jusqu'à présent.
Mais maintenant je ne peux plus éteindre l'OLED (framedPlugin). Lorsque j'envoie OLEDFRAMEDCMD, il éteint l'affichage pendant un très court instant et se rallume.
J'ai fait un test dos à dos avec une ancienne version (à partir de 2018), l'affichage réagit comme prévu.

Je viens d'essayer mega-20190121 et la stabilité WiFi est la même. Il plante environ une heure après le démarrage.

@ TD-er, quand pensez-vous que vous pourriez pousser une version avec le changement discuté afin que je puisse le tester?

mise à jour rapide: depuis le réglage du correctif de mode sur 802.11g, je n'ai plus de gel, de redémarrage, etc. même si les AP fonctionnent en mode mixte g / n ... donc je voterais également pour un patch qui rend le mode wifi configurable sur l'esp!

J'espère aussi un patch bientôt 😉

Je viens d'ajouter un commit pour sélectionner le B / G uniquement.
Cela ne fonctionne pas encore bien sur ESP32, j'ai donc désactivé l'option de le sélectionner pour ESP32.
J'ai également ajouté une option de repli pour pouvoir se connecter à nouveau si l'AP n'autorise pas B / G uniquement.

@ TD-euh je veux dire ce changement:

Je suppose qu'il y a quelque chose qui ne va pas dans les bibliothèques de base (LWIP ou Arduino ou ESP) et nous devrions réinitialiser le wifi.
Désactivez donc le wifi et recommencez. Peut-être attendez-vous également entre ces étapes pour vous assurer que les tampons sont vidés ou du moins vidés et que les demandes en attente sont activement annulées.

Le changement discuté dans les 2 derniers articles?
Il n'a pas encore été implémenté, mais je peux essayer ce soir de le coder et de faire un test de build.

@oki J'ai essayé les deux variantes, définissant la puissance de sortie sur 0 et déconnectant / reconnectant activement lorsque le problème se produit. les deux versions n'ont pas aidé à réinitialiser / se reconnecter à l'AP ... (dans mon environnement) ... mre détails ci-dessus ...
la seule chose qui le rendait stable était d'utiliser le N-Mode.

J'en suis bien conscient. En espérant un patch prochainement, pour que je puisse continuer mon débogage.

@ 0ki Je peux faire un testbuild pour vous en utilisant ce dernier commit.
Ou souhaitez-vous également tester avec la désactivation du WiFi?

Et si oui, quelles options souhaitez-vous / avez-vous besoin? WiFi désactivé / activé et redémarrer tous les services?
Cette dernière partie (redémarrer les services) est également une chose à examiner attentivement, car je ne suis pas tout à fait sûr que tous les services utilisant une socket sont correctement redémarrés.
Cela peut également causer des problèmes lorsque la connexion WiFi est recréée.

Éteindre automatiquement (puis rallumer) l'émetteur wifi lorsqu'une déconnexion est détectée.

Je vois que vous avez ajouté du code. Quelle version puis-je tirer pour tester cela?

Pas sûr, je vais faire une nouvelle version pour les tests.
Cela se fera en +/- 30 minutes.

construire un test
Il est basé sur ce que j'ai fusionné plus tôt dans la journée et sur le PR # 2235 qui présente les changements pour la connexion en mode B / G.
Il semble y avoir des problèmes avec certains plugins dans ce PR, c'est donc la raison pour laquelle il n'a pas encore été fusionné.

Merci! Flashé la version de test.

J'ai maintenant les paramètres suivants:
Connection Failure Threshold: 0 Force WiFi B/G: NO Restart WiFi on lost conn.: YES

Pensez-vous que je devrais tester quelque chose différemment étant donné que j'ai PLATFORMIO_ESP12E?
Autrement dit, je ne sais pas si b / g va fonctionner sur esp12e et quel était exactement le seuil d'échec de connexion.

Ce seuil est juste un compteur pour lancer un redémarrage si un nombre de tentatives de connexion infructueuses dépasse cette valeur.
0 est la valeur par défaut et signifie qu'il n'effectuera pas de redémarrage.

Je suppose que le régler sur 50 ou 100 vous aidera à le redémarrer lorsqu'il se trouve dans un endroit difficile à atteindre et qu'il entre dans une boucle de reconnexion.

Même avec ce paramètre, il peut toujours afficher les redémarrages du chien de garde HW, comme un certain nombre de mes nœuds l'ont déjà montré.
Il peut être simplement plus difficile de reproduire ceux avec le mode B / G actif.

construire un test
Il est basé sur ce que j'ai fusionné plus tôt dans la journée et sur le PR # 2235 qui présente les changements pour la connexion en mode B / G.
Il semble y avoir des problèmes avec certains plugins dans ce PR, c'est donc la raison pour laquelle il n'a pas encore été fusionné.

Merci pour la version de test.
Mon ESP12F précédemment le plus instable est maintenant actif depuis 59 heures sans redémarrage :)

EDIT: Les paramètres sont:
Forcer WiFi B / G: OUI
Redémarrez le WiFi en cas de perte de connexion: OUI

Je pense que je vais diviser ce commit (B / G WiFi) en un PR séparé, afin qu'il puisse être fusionné avant de réparer le reste du PR dans lequel il attend maintenant d'être fusionné.

Bonne idée!

Mes paramètres précédents RestartWifi = YES n'ont rien fait d'utile.

Maintenant je suis passé à

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

et cela fait deux jours sans redémarrage ni même une seule déconnexion. Incroyable. Je ne pense pas que je vais même m'éloigner de cette version de test.

Après env. 100 heures, le module a finalement effectué une réinitialisation. :(

Raison de la réinitialisation: chien de garde matériel

Cependant, cela peut également être causé par la configuration difficile (12 capteurs 1 fil et un serveur FHEM).

Vous pouvez également essayer d'ajouter ce correctif: https://github.com/letscontrolit/ESPEasy/pull/2235/commits/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf2
Peut-être que cela aidera également à améliorer la stabilité.
Il est inclus dans cette version de test

Vous pouvez également essayer d'ajouter ce patch: 9a05eaf
Peut-être que cela aidera également à améliorer la stabilité.
Il est inclus dans cette version de test

Merci!
Installé sur deux unités configurées complètement différentes et donnera des commentaires.

eu une exécution sur l'un de mes nœuds de test, y compris
https://github.com/letscontrolit/ESPEasy/commit/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf, malheureusement, il n'a fallu que 2 heures environ avant de rencontrer à nouveau le problème de temporisation de clé de groupe et de ne pas récupérer ou de se reconnecter à l'AP. Avec "redémarrer le wifi en cas de connexion perdue" activé et ne pas le forcer à B / G .... donc N semble toujours être un problème.
Donc, pour moi, le mode B / G est toujours la seule option de travail stable.

Pouvons-nous envisager d'abandonner complètement le support N? Avons-nous besoin des avantages fournis par N pour un appareil aussi simple?

@ 0ki avec la "nouvelle" option pour forcer le mode B / G que @ TD-er a intégré, c'est en gros la suppression de N au niveau du logiciel, vous ne pouvez pas le supprimer des bibliothèques de base, je suppose ...

Lorsque vous déplacez cela dans les paramètres principaux, je recommande que cette option soit activée par défaut.

Nous pourrions le rendre dynamique.
Si aucune connexion n'est possible, réessayez avec l'option N activée.

Il y a beaucoup de configurations qui ont N-seulement vérifié dans AP. Donc, dans ces environnements, vous ne pouvez pas revenir en arrière si vous désactivez le support N sur l'ESPeasy.

Vous pouvez également essayer d'ajouter ce patch: 9a05eaf
Peut-être que cela aidera également à améliorer la stabilité.
Il est inclus dans cette version de test

Merci!
Installé sur deux unités configurées complètement différentes et donnera des commentaires.

Jusqu'à présent, un module a redémarré après 2 jours, l'autre après 5 jours.
Les deux ont montré "Hardware Watchdog" comme raison de réinitialisation.
Les deux modules sont réglés sur «Forcer WiFi B / G: Oui» et «Redémarrer WiFi en cas de connexion perdue: Oui».
L'AP est un Mikrotik réglé sur B / G uniquement (temps de disponibilité 49 jours).
Distance entre AP et modules env. 2 à 3 m.

Je me demandais pourquoi ma suggestion de le rendre dynamique (pour revenir à N à partir du réglage B / G uniquement) a reçu 2 "votes".
Veuillez expliquer pourquoi ce n'est pas une bonne suggestion.

Je me demandais pourquoi ma suggestion de le rendre dynamique (pour revenir à N à partir du réglage B / G uniquement) a reçu 2 "votes".
Veuillez expliquer pourquoi ce n'est pas une bonne suggestion.

À mon avis, si quelqu'un active cette option, il recherchait déjà désespérément plus de stabilité et sait ce que cela signifie pour ses paramètres AP.
Je préfère une solution statique parce que lorsque je sélectionne l'option B / G uniquement, je ne veux absolument jamais être dans une situation où je pense qu'elle utilise B / G mais encore une fois pas.
Cependant, comme mes nœuds redémarrent de toute façon (bien que beaucoup moins fréquents), j'aimerais avoir une vraie solution pour le problème lié au nouveau noyau.

Je comprends cela, mais vous devez également comprendre le problème lorsque les utilisateurs ne savent pas ce que fait un paramètre et se retrouvent avec des nœuds inaccessibles.
Il devrait donc avoir un grand seuil avant de revenir au support N.
Par exemple, la solution de secours pour les plugins corrompus est:
Après 10 redémarrages infructueux, il désactivera 1 plugin ou contrôleur pour voir si le redémarrage peut réussir.

Quelque chose de similaire peut également être appliqué à la connexion wifi.
Après X tentatives de reconnexion infructueuses, il permettra de se connecter avec 802.11N autorisé
La qualité de réception est meilleure pour les réseaux en mode G, donc si vous mettez X à quelque chose comme 10, il est très peu probable qu'il se connecte avec N au lieu de G. Surtout si vous réinitialisez ce compteur à chaque fois que vous le tentez en mode N.

Hmm les dernières semaines de moins de temps pour ESPeasy ont apparemment obscurci ma mémoire de ce que je prévoyais de mettre en œuvre ou de ce qui a été implémenté.

Je viens de regarder le code pour cela et j'ai trouvé:

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

Donc, apparemment, il a déjà été implémenté pour n'autoriser N que lorsque wifi_connect_attempt est> 10.
Ce compteur est remis à 0 dès qu'il y a une tentative réussie de connexion au wifi.

Est-ce une solution acceptable?

Hmm les dernières semaines de moins de temps pour ESPeasy ont apparemment obscurci ma mémoire de ce que je prévoyais de mettre en œuvre ou de ce qui a été implémenté.

Je viens de regarder le code pour cela et j'ai trouvé:

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

Donc, apparemment, il a déjà été implémenté pour n'autoriser N que lorsque wifi_connect_attempt est> 10.
Ce compteur est remis à 0 dès qu'il y a une tentative réussie de connexion au wifi.

Est-ce une solution acceptable?

Eh bien .. je dirais oui (en espérant que le bogue dans la 2.5.0 sera bientôt trouvé).

Commentaires sur le réglage B / G uniquement.
Je viens d'installer le test fw sur une unité qui a redémarré toutes les 20 minutes au plus tard. Avant, il était connecté à N avec -72dBi. Cela aurait dû être un signal suffisant pour ne pas se déconnecter. J'utilise des AP de qualité entreprise avec des capacités de réception de -105 dBi. Encore une fois, il ne devrait jamais abandonner la chaîne.

Après quelques heures avec le test FW et il n'y a pas eu de réinitialisation jusqu'à présent.
Je vais le faire fonctionner et faire rapport.

PS: Je reconnais que c'est lié à N d'une manière ou d'une autre.
PSS: J'utilise 20 nœuds ESP-07 qui ont été mis à niveau vers 4M. Prend beaucoup de temps mais rembourse lorsque le re-clignotement est nécessaire

J'ai plus de 120 nœuds tous fonctionnant sur GN (mega-20190202) sans aucun problème. Ils rapportent tous être connectés à N

@ jimmys01 Combien de nœuds se connectent au même AP?
Et quelle est la marque de cet AP? (Mikrotik?)

Presque tous se connectent à un point d'accès différent (un par chambre d'hôtel). Ils ont un interrupteur (capteur PIR), un capteur de température et d'humidité HTU et des LED IR.
La marque AP est Mikrotik.
Les paramètres sont les suivants:
Le pays est défini
Canal de contrôle: 20Mhz
Bande: GN
Canal d'extension: désactivé
Type d'authentification: WPA2 PSK uniquement
Cryptage: aes ccm uniquement
Chiffrement de groupe: aes ccm
Mise à jour de la clé Groyp: 00:01:00

Commentaires sur le réglage B / G uniquement.
Je viens d'installer le test fw sur une unité qui a redémarré toutes les 20 minutes au plus tard. Avant, il était connecté à N avec -72dBi. Cela aurait dû être un signal suffisant pour ne pas se déconnecter. J'utilise des AP de qualité entreprise avec des capacités de réception de -105 dBi. Encore une fois, il ne devrait jamais abandonner la chaîne.

Après quelques heures avec le test FW et il n'y a pas eu de réinitialisation jusqu'à présent.
Je vais le faire fonctionner et faire rapport.

PS: Je reconnais que c'est lié à N d'une manière ou d'une autre.
PSS: J'utilise 20 nœuds ESP-07 qui ont été mis à niveau vers 4M. Prend beaucoup de temps mais rembourse lorsque le re-clignotement est nécessaire

Malheureusement, l'unité continue de se réinitialiser après un temps aléatoire. Tout dans les 1 à 4 heures.
B / G seul FW ne résout pas mes problèmes

Je me demandais pourquoi ma suggestion de le rendre dynamique (pour revenir à N à partir du réglage B / G uniquement) a reçu 2 "votes".
Veuillez expliquer pourquoi ce n'est pas une bonne suggestion.

Disons que le wifi lui-même tombe en panne pendant une heure en raison de circonstances externes / environnementales. Mon ou mes nœuds basculent sur N et redeviennent très instables (mon application est sensible aux redémarrages - le wifi ne doit pas être là 100% du temps, mais le nœud lui-même devrait être opérationnel tout le temps)

Je voudrais une configuration pour mes nœuds qui évite l'instabilité et ne jamais se connecter à N le fait pour moi en ce moment.

Lorsque vous déplacez cela dans les paramètres principaux, je recommande que cette option soit activée par défaut.

Comme solution, nous pourrions avoir cela expédié en mode de repli (B / G-then-N) par défaut en étant commutable en B / G uniquement ou B / G / N.

En ce qui concerne la solution actuelle pour 2.5.0, veuillez essayer ceci:

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

J'ai plus de 120 nœuds tous fonctionnant sur GN (mega-20190202) sans aucun problème. Ils rapportent tous être connectés à N

Comment mettre à jour plus de 120 nœuds dans un délai acceptable?
"..aucun problème que ce soit ..." avez-vous vérifié la disponibilité de chaque nœud et de quoi s'agit-il?
Sont tous les mêmes depuis le dernier redémarrage prévu?

Les temps de disponibilité comptent les jours et tous ont 0 reconnexion. Des mois maintenant, je n'ai jamais eu de problèmes avec la connectivité, sauf lorsque j'ai désactivé PMKID sur les points d'accès. Probablement le noyau le plus récent est devenu plus sélectif sur les paramètres wifi ou je ne sais pas quoi. Nous prévoyons dans le mois prochain de déployer 80 esp8266 supplémentaires. Au fait, si @ TD-er vous voulez un accès pour avoir un aperçu de la configuration particulière, je suis heureux de vous le donner. Je veux vraiment qu'ESPEasy se développe, cela nous a beaucoup aidés.

Edit: @ chunter1 Je les

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

@ jimmys01 J'ai récemment acheté un Mikrotik moi-même, pour pouvoir tester des choses.

Et juste un avis sur les versions de base 2.5.0.
Dans les versions nocturnes à venir, les versions 2.5.0 ne sont pas incluses, car il y a un bogue dans le noyau 2.5.0 qui empêche le serveur Web de répondre et laisse le nœud planter.
Dès que cela sera corrigé, il y aura à nouveau des versions de base 2.5.0.
Dans la dernière version nocturne, il y a un core 2.6.0 alpha inclus, qui est essentiellement le dernier code du github de la bibliothèque principale afin que vous puissiez le voir par vous-même.

Vous avez le 2.6.0 avec B / G ne fonctionnant que depuis 4 jours sur deux modules et le premier a redémarré.
La raison de la réinitialisation était le "chien de garde matériel" habituel.
Ce que j'observe puisque le seul mode "B / G" est actif, c'est un temps d'exécution de 3..5 jours avant qu'une réinitialisation se produise.

Peut-être aussi comparer le nombre de déconnexions wifi, puisque ces déconnexions semblent être liées aux plantages.

Les deux modules se trouvent dans la cave, à seulement 2..3 mètres du Mikrotik AP.
Je viens de vérifier le deuxième module exécutant la même version FW et il affiche 0 reconnexion et 4d02h de disponibilité (pas de redémarrage depuis le clignotement).
Je crois vivement que l'autre module, qui a fait la réinitialisation. avait également 0 reconnexion avant sa réinitialisation.

Concernant les tâches configurées sur les deux modules de test:
Le module qui a réinitialisé a 12 capteurs DS18B20 configurés qui envoient leur valeur toutes les 120 s à un serveur FHEM.
Le module qui n'a pas été réinitialisé jusqu'à présent n'a que deux gpios configurés qui envoient également leur valeur toutes les 120 secondes au même serveur FHEM.

Donc, AP (Mikrotik) est le même, la distance (2..3 mm) est la même, le serveur FHEM est le même - juste le module avec les 12 capteurs de température se réinitialise définitivement plus fréquemment que celui avec les 2 gpios.

sur mes nœuds, cela se produit principalement lorsque fhem est trop lent pour répondre ou n'est pas accessible car j'ai défini une nouvelle tentative maximale de 100, puis les nœuds redémarrent (ce qui montre également un redémarrage manuel).

sur mes nœuds, cela se produit principalement lorsque fhem est trop lent pour répondre ou n'est pas accessible car j'ai défini une nouvelle tentative maximale de 100, puis les nœuds redémarrent (ce qui montre également un redémarrage manuel).

Pourquoi vos nœuds devraient-ils redémarrer lorsque les tentatives sont supérieures à 100?
(J'ai mis les tentatives à 0 pour les tests)

outils -> avancé -> seuil d'échec de connexion

pour vous assurer que si le wifi sur les modules s'étouffe pour une raison quelconque, il redémarre après un certain temps ...

Ahh avec "retries" vous voulez dire le "Connection Failure Threshold:" et non le "Max retries:" dans les paramètres du contrôleur de FHEM.
J'ai défini le seuil d'échec de connexion sur 0.

BTW: pour la première fois, j'ai eu un nœud qui est resté bloqué dans le problème de délai d'expiration 4WHS même si "seul B / G" était actif ... je n'avais jamais eu cela auparavant (auto-compilé, noyau 2.5.0) .... Je continuerai à regarder ça, si c'était juste une coïncidence ...

Veuillez noter qu'il y aura très bientôt un noyau 2.5.1 qui rétablira le SDK utilisé en SDK2.2.1, car il y a beaucoup de problèmes avec SDK3.0.0
Cela peut également changer la façon dont les nœuds réagissent sur le wifi et ce sera peut-être à nouveau comparable au noyau 2.4.2.
Je ne sais pas quels correctifs du noyau 2.5.0 sont inclus, ce qui peut résoudre certains autres problèmes auxquels nous sommes confrontés.

@ chunter1 À propos des nœuds que vous avez.
Il semble que celui qui a redémarré envoyait beaucoup plus de messages au contrôleur, donc statistiquement parlant, il a alors plus de chances d'essayer d'envoyer quelque chose qui se bloque quelque part dans le processus.

@ clumsy-stefan Pouvez-vous tester le code actuel sur Github? (ou la dernière version)

J'ai apporté quelques modifications à la manière d'effectuer des activités liées au réseau.

Voulez-vous dire celui-ci?

ESP_Easy_mega-20190227_test_core_260_sdk3_alpha_ESP8266_4M.bin

À peu près n'importe quelle version de la nuit dernière.
J'ai également ajouté une version "normale" pour le noyau 2.6.0 en utilisant SDK2.
Core 2.6.0 SDK2 fonctionne maintenant sur plusieurs nœuds et n'a eu qu'un chien de garde HW sur l'un d'entre eux qui est exceptionnellement faible en ressources (exécutant beaucoup de plugins à mémoire élevée) et aussi celui avec la mémoire flash probablement épuisée (devrait jeter celui-là car il a eu des milliers de mises à jour du firmware)

@ TD-er j'ai compilé et installé à partir de git il y a environ 6 heures sur 2 nœuds de test .. mais comme j'ai toujours un accès Internet très limité, je ne peux probablement faire rapport que dans 24 heures, donc ...

J'ai testé le dernier firmware avec le "mode Force B / G" avec le routeur Mikrotik et jusqu'à présent, il semble fonctionner de manière stable. Fera rapport.

@ TD-er Une question: quelle est la règle pour le retour en mode N lorsque "Forcer le mode B / G" est défini?

@ giig1967g
S'il n'a pas réussi à se connecter plus de 10 fois au point d'accès avec _B / G uniquement_, il reviendra au mode BGN par défaut.

Cela laisse donc la possibilité qu'il se connecte en mode N si l'AP était hors ligne pendant un certain temps.
Si cela semble être un vrai problème, je peux essayer de le configurer pour qu'il ne le fasse que toutes les 10 tentatives, mais je dois ensuite m'assurer qu'il essaiera également cela lorsque le ssid de secours sera essayé.

Salut @ TD-er
Je pense que le repli est une mauvaise idée.
Regardez ce scénario: mon appareil est forcé de passer en mode B / G et fonctionne avec mon Mikrotik.
Pour une raison quelconque, mon Mikrotik passe hors ligne (mise à jour, redémarrage, peu importe).
À chaque fois que le mikrotik remonte, l'ESP se connectera alors en mode N et j'ai perdu la stabilité de l'appareil.

En d'autres termes, si je règle le mode Force B / G et que la connexion échoue, il devrait devenir un AP (192.168.4.1), mais ne devrait pas revenir en mode N. La possibilité de repli crée une fausse attente pour l'utilisateur.

Ne vous méprenez pas, le repli était bon pour tester la validité du changement, mais maintenant qu'il a prouvé qu'il résolvait le problème (du moins le mien jusqu'à présent), le repli devrait être supprimé.

Je suis d'accord avec le commentaire @ chunter1 : https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment -462295204

Que pensez-vous du scénario suivant alors.
Dès qu'il est possible de se connecter aux AP donnés en utilisant uniquement B / G, un drapeau supplémentaire sera défini pour ne plus fournir de repli.
Si certains de ces paramètres (B / G uniquement ou d'autres paramètres AP) changent, le repli sera à nouveau activé jusqu'à ce qu'il réussisse à se connecter au point d'accès donné.

Éditer:
Avec le repli, je veux dire ces paramètres supplémentaires, pas le "SSID de secours"

En d'autres termes, le repli ne reste actif que jusqu'à la première connexion réussie au point d'accès, puis il est supprimé. Dans ce cas, il serait utile de voir dans la page système le mode wifi.
C'est une solution possible même si je préfère toujours éviter les replis vers N si je règle Force B / G.
Je comprends la possibilité que l'utilisateur fasse des erreurs, mais l'utilisateur pourrait alors taper le SSID incorrect et ne pas avoir accès à l'unité dans tous les cas ...

Autre question: dans la mise en œuvre actuelle, dans quel scénario l'unité deviendra-t-elle un PA?
Parce qu'il me semble que l'appareil essaiera B / G 10 fois puis essaiera N mais finira-t-il par abandonner et devenir un AP?

Non, le mode AP reste actif tout en essayant de se connecter aux points d'accès donnés.
Peut-être devrions-nous également ajouter une vérification facultative de la disponibilité et n'autoriser le démarrage du mode AP que dans les 10 premières minutes du démarrage du nœud.
Juste pour plus de sécurité et aussi pour exclure la possibilité que le mode AP puisse avoir un effet sur l'ESP ne pouvant pas atteindre les réseaux wifi donnés.

Et nous devons rester concentrés sur la partie «facile» du projet.
Cela signifie des valeurs par défaut appropriées et aucune quantité écrasante de paramètres proposés, mais donnez la possibilité à l'expert de tout faire.
Cela signifie également qu'il devrait y avoir une solution de secours appropriée pour l'utilisateur le moins expérimenté.
Surtout pour les paramètres B / G uniquement. Je suppose que plus de 90% des personnes qui commencent avec ESPeasy ne sont pas conscientes des différences entre 802.11B / G / N Donc, si elles rencontrent des problèmes, qui peuvent être très bien gérés en utilisant une solution de secours, cela peut les amener à rechercher d'autres projets .
Je comprends également pourquoi ce repli ne devrait pas donner une fausse impression de «stabilité», alors je comprends vraiment pourquoi la mise en œuvre actuelle peut être améliorée. Mais si le "succès de la première tentative de connexion => désactiver le repli" est rendu automatique, il est également parfait pour l'utilisateur plus expérimenté. (qui fait aussi des erreurs stupides, comme je le sais par expérience;))

Je suis d'accord qu'il devrait être plus clair quel paramètre de connexion est activement utilisé.

compris.
Donc, le prosal est:
L'unité Boots.
L'indicateur N-fallback est défini sur true.
Si FORCE B / G est défini, il essaie 10 fois de se connecter au point d'accès wifi en B / G.
S'il peut se connecter, il définit le flack N-fallback sur false.
S'il ne peut pas se connecter, il essaie en mode N.

Veuillez également considérer ce scénario avec le jeu Force B / G: panne de courant.
L'ESP et le routeur Wifi sont hors tension.
Ensuite, le courant revient et l'ESP est plus rapide que le routeur wifi.
Dans ce cas, il se peut qu'après 10 fois, le point d'accès wifi n'écoute toujours pas.
Ainsi, l'appareil essaiera le mode N et finira par réussir.
L'utilisateur (expérimenté) ne saura pas que la connexion était en mode N et pense qu'elle est en mode B / G avec un manque de stabilité.

Je ne veux pas insister, mais vraiment ces problèmes de matériel et de gel durent depuis 1 an. Maintenant que vous avez trouvé une solution de travail avec l'aide de la communauté, je vous conseille vivement de vous assurer qu'elle reste appliquée. Les risques pour un utilisateur inexpérimenté de paramétrer le "mode Force B / G" sont moindres que lui en définissant le mauvais SSID avec les mêmes résultats: pas d'accès au point d'accès.

SUGGESTION:
Afin de vous assurer que l'utilisateur le moins expérimenté ne se trompe pas, pourquoi n'ajoutez-vous pas un bouton pour "Test B / G mode". S'il réussit, il active le "mode FORCE B / G", sinon il reste désactivé.

Dans ce cas, les utilisateurs moins expérimentés sauront ce qu'ils font et les utilisateurs plus expérimentés seront sûrs que lorsque le mode ForceB / G est défini, il ne peut pas revenir à N.

Qu'est-ce que tu penses?

Vous pourriez

Non seulement s'il démarre, mais l'option de secours sera alors désactivée dans les paramètres et enregistrée.

D'accord. Ensuite, une vérification manuelle est encore plus appropriée qu'une vérification automatique. Tu ne penses pas?

Oui, je vais d'abord ajouter une simple coche pour désactiver les remplacements.
Mais plus tard, il devrait être rendu plus dynamique dans ce domaine pour nous aider également, les "experts" à faire moins d'erreurs :)

D'accord

La version 2019_02_16 fonctionnait maintenant pendant 9 jours sans redémarrage (forcé à B / G). Hier, il a recommencé à redémarrer. Le chien de garde matériel l'a forcé à deux reprises.
Après un certain temps, l'unité n'était plus accessible. La commutation du routeur WLAN n'a pas aidé (essayé 3 fois, jusqu'à 30 minutes). Le redémarrage de l'ESP en commutant le fusible d'alimentation n'a pas non plus aidé.
J'ai dû fermer à nouveau le wlan et me connecter à l'ESP via 192.168.4.1 directement pour y accéder

Je n'ai absolument aucune idée de ce qui s'est passé

@kischde Quel type de point d'
Hier soir, j'ai vécu quelque chose de similaire moi-même en expérimentant l'installation d'un nouvel AP.
J'essayais d'installer un AP MikroTik et tout fonctionnait bien jusqu'à ce que l'ESP ait besoin de se reconnecter.
Grâce à l'interface Web du MikroTik, j'ai pu voir que le nœud était connecté au WiFi, mais il n'a pas reçu d'adresse IP.
Même lorsque j'ai essayé de le connecter au point d'accès de mon téléphone, je pouvais redémarrer l'ESP, mais il a répété ce comportement.
Ce n'est que lorsque j'ai défini la configuration AP principale sur un autre AP qu'il a commencé à se connecter comme il se doit.

Notez que le nœud n'a pas été redémarré pour y parvenir.

Une chose qui est "incorrecte" sur cet AP, par rapport à un autre MikroTik que j'ai, c'est qu'il a le paramètre "Distance" réglé sur "à l'intérieur".
Je vais effectuer plus de tests pour voir quelle est la différence ici, mais comme indiqué précédemment, il semble y avoir un paramètre de délai d'attente pour une réponse sur un paquet.
Et je peux imaginer que l'ESP prend un certain temps pour répondre aux requêtes DHCP, ce qui peut être tout simplement trop court pour ce paramètre.

J'utilise un AP Swisscom (fournisseur de télécommunications suisse AP), mais j'ai eu tous les mêmes problèmes écrits ici à différents endroits, comme les gars avec le MikroTik. Donc, il a peut-être le même chipset, mais je ne peux pas changer grand-chose dans les paramètres, par exemple ces paramètres étendus.
Avant de remettre sous tension, j'ai également essayé de me connecter à mon téléphone mobile, comme vous l'avez fait, avec le même comportement que vous.
J'utilise une adresse IP fixe, pas de DHCP
Je suis maintenant passé au 2019_03_05 réel, je vais voir ce qui se passe ...

Avez-vous récemment modifié les paramètres Wi-Fi?
Par exemple, point d'accès avec adresse MAC AA: AA: AA: AA: AA sur la position 1 du SSID, un autre AP avec l'adresse MAC BB: BB: BB: BB: BB: BB
J'ai l'impression qu'il reste des paramètres à un endroit de l'ESP où nous ne les stockons pas.

J'essaierai également de voir dans la documentation NonOS comment ceux-ci peuvent être effacés efficacement lorsque nous modifions les paramètres WiFi.
Toujours dans mes tests, il semble vraiment utile d'avoir plus de 2 SSID à utiliser.
Je vais également essayer d'ajouter plus de champ pour cela, ou peut-être même permettre de stocker un fichier crypté dans SPIFFS pour avoir une quantité presque illimitée d'AP WiFi stockée.

Avez-vous récemment modifié les paramètres Wi-Fi?

Non, comme je n'ai qu'un seul AP, ce n'était pas IMO nécessaire

D'ACCORD. Bon à savoir.
Comme je ne sais pas encore ce qui en est la cause, j'essaie d'éliminer le plus d'inconnues possible.
Donc, la seule chose que vous deviez faire pour que cela fonctionne à nouveau est d'ajouter à nouveau le paramètre pour le wifi.

Non, encore moins
J'ai forcé de me connecter directement à l'esp via 192.168.4.1 (désactivé l'AP)
Ensuite, j'ai tout vérifié, mais je n'ai trouvé aucune chose anormale ... Alors je lui donne un essai et redémarre mon AP, puis réinitialise l'ESP et il fonctionne à nouveau. Donc, IMO, j'ai juste dû forcer à faire une connexion WLAN "normale / autre".
BTW je l'ai également vu connecté à l'AP, mais aussi aucune adresse IP attribuée, mais c'est statique

Hmm, j'ai un peu joué avec, avec 5 nœuds connectés au MikroTik avec lequel je joue.

Dès que j'ai défini "Hw. Fragmentation Threshold" ("dépliez" simplement l'option), les nœuds ESP ne sont plus capables de recevoir aucune adresse IP.
La valeur par défaut de ce paramètre est 256. Si je la mets à 1600 (convient à un MTU complet), tous les nœuds recevront une adresse IP et continueront à fonctionner.

Ceci est affiché dans l'interface utilisateur de MikroTik lorsque les nœuds sont capables de communiquer:

Et ce lorsqu'ils ne peuvent pas envoyer / recevoir de données (mais sont connectés à la couche WiFi)

@ TD-er avez-vous vu qu'il y avait une option dans le nouveau noyau esp8266 appelée LWIP_FEATURES qui, je pense, activera le réassemblage IP ... Probablement ce n'est pas défini dans votre build?

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

également la prise en charge de la fragmentation IP est définie avec ceci:
https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L756 -L763

Hmm, je ne sais pas quelles sont les valeurs par défaut.
Les nombres indiqués sur la première ligne de la documentation Doxygen sont-ils les valeurs par défaut?

Je ne sais pas ... Je sais juste que dans l'IDE Arduino dans le fichier de définition des plates-formes, vous pouvez sélectionner si vous voulez qu'il soit inclus et défini ou non.

J'ai toujours pensé que les parties LWIP étaient incluses en tant que bibliothèques pré-compilées dans la distribution principale.
Il est donc assez difficile de s'assurer que LWIP est reconstruit en utilisant les bons indicateurs.

oui, mais cela dépend de celui que vous liez (à partir de boards.txt):

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

Ils utilisent donc ces indicateurs:

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

| Étiquette | build.lwip_lib | build.lwip_flags |
| --- | --- | --- |
| v2 Mémoire inférieure | -llwip2-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 Bande passante supérieure | -llwip2-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 Mémoire inférieure (sans fonctionnalités) | -llwip2-536 | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 Bande passante supérieure (sans fonctionnalités) | -llwip2-1460 | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 Mémoire inférieure IPv6 | -llwip6-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v2 Bande passante IPv6 supérieure | -llwip6-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v1.4 Bande passante supérieure | -llwip_gcc | -DLWIP_OPEN_SRC |
| v1.4 Compiler à partir des sources | -llwip_src | -DLWIP_OPEN_SRC |

Donc toutes les versions v2 ont LWIP_FEATURES=1 exception de celles étiquetées comme "sans fonctionnalités"

oui, mais si vous regardez les instructions -l , vous devez utiliser les bibliothèques avec -feat à la fin (contrairement à l'étiquette, un peu contre-intuitif) ...