Espeasy: [ERROR] [Estabilidad WiFi] ESP Excepción 3/29 cuando la capa 2 se desconecta

Suena como si tuviera el mismo problema. A veces mi esp pierde la conexión wifi y se mantiene “perdido” de wifi durante horas. Pensé que deben reiniciar y volver a conectarse a wifi gracias al perro guardián, pero no lo hacen. Un arranque en frío resuelve el problema.

Lo último descrito por @wolverinevn es algo que también he visto que sucede aquí.

como discutimos en el # 1957, estoy bastante seguro de que muchos de estos extraños problemas de redes / WiFi provienen de esta inestabilidad de capa 2 ... He visto todo tipo de comportamiento extraño antes de cambiar mi AP a algunos tiempos aumentados ...

como discutimos en el # 1957, estoy bastante seguro de que muchos de estos extraños problemas de redes / WiFi provienen de esta inestabilidad de capa 2 ... He visto todo tipo de comportamiento extraño antes de cambiar mi AP a algunos tiempos aumentados ...

Espero que encuentres la solución. Uno de mis Nodemcu se cuelga y desaparece del enrutador durante 5 horas hasta ahora sin motivo. Espero que pueda recuperarse del perro guardián, pero no pasa nada. Tengo que reiniciarlo manualmente ahora. ¡Muy molesto!

@wolverinevn cuando tenga acceso al nodo nuevamente, vaya a herramientas => avanzado y establezca el "Umbral de falla de conexión" en algo diferente a 0 (sugiero algo entre 50 y 100, dependiendo del nr. de tareas que tenga). En realidad, esto no cambia el problema, pero aumenta las posibilidades de que el nodo se reinicie y se vuelva a conectar significativamente.

la otra solución sería si puede modificar algunos parámetros en su punto de acceso, dependiendo realmente del tipo de AP que tenga, si eso se puede modificar ...

@ clumsy-stefan ¿Deberíamos establecer el valor predeterminado en ESPeasy también en este nivel?

¿Y tal vez también deberíamos mostrar este valor en la página sysinfo y hacerlo disponible para las reglas?

@ TD-er establecerlo en algún nivel por defecto probablemente no sea algo malo si no es demasiado bajo (siempre puede suceder que una conexión falle).

Al depurar el problema, pensé en cómo se hace esto, actualmente cada conexión incorrecta aumenta el contador y cada conexión exitosa lo disminuye. Pensé si sería más lógico restablecerlo a 0 tan pronto como sucediera una conexión exitosa, pero supongo que es una cuestión un poco ideológica, lo que tiene más sentido.

El problema con ese número es que, si tiene 10 tareas, cada una de ellas con un recuento de reintentos de 10 y un retraso de reenvío de 100 ms, los reinicios ocurren con bastante rapidez si hay un problema real de comunicaciones (100 reintentos en aproximadamente 10 segundos). .

ahora, si, por ejemplo, siempre fallan 5 comunicaciones y 1 tiene éxito, aumentará continuamente las fallas de conexión. si esto sucede todo el tiempo, reiniciará el nodo tarde o temprano aunque se puedan entregar todos los datos.

Sin embargo, el problema principal que estoy viendo es que de alguna manera el nodo no se da cuenta de que la conexión en la capa 2 en realidad se ha ido y continúa enviando datos (supongo). además de esto de lo que me di cuenta esta noche, ¿qué pasa con syslog (y otras comunicaciones como NTP, etc.) si no hay conexión wifi? ¿Esto también se detuvo? esto podría explicar por qué mis nodos saltan repentinamente al 100% de la CPU cuando la capa 2 se ha ido. probablemente no se envíen más datos de tareas, pero intenta deshacerse de los paquetes de registro del sistema UDP y no puede ... aunque solo una suposición ...

lo siento, texto largo para dos preguntas simples ... en resumen:
nivel predeterminado: sí, lo establecería al máximo (100) o así por defecto ... si todo está bien, no hace daño si no, la unidad vuelve a ser accesible ...
Página y reglas de sysinfo: Yo diría que no, ¿por qué debería cambiarse esto dinámicamente? es un valor de emergencia ...

@ clumsy-stefan Ya lo puse en 50. Esperemos. ;)

@wolverinevn hmm ... 50 debería suceder bastante rápido dependiendo de la cantidad de intervalo de tareas y reintentos que tenga (5-15min.) ... si esto no ayuda, creo que el nodo en realidad no está congelado, pero simplemente puede ' t vuelva a conectarse a la red. También tuve esto incluso después de reiniciar WD. ¿Puedes ver si el nodo intenta pasar al modo AP? ¿Ves el AP-WLAN del nodo?

Página y reglas de sysinfo: Yo diría que no, ¿por qué debería cambiarse esto dinámicamente? es un valor de emergencia ...

Quería ser inspeccionado en reglas usando una variable del sistema como %conn_fail% y mostrarla en la página sysinfo, junto al número de reconexiones wifi.
Después de todo, es un valor de estadísticas de rendimiento.

Quería ser inspeccionado en reglas usando una variable del sistema como% conn_fail% y mostrarlo en la página sysinfo, junto al número de reconexiones wifi. Después de todo, es un valor de estadísticas de rendimiento.

ah, sí, de acuerdo, ¡eso tendría sentido! eso también está un poco relacionado con el número 1993. Tener un complemento que envíe una serie de variables de rendimiento / sistema regularmente al controlador (sin desperdiciar las tareas limitadas disponibles) sería realmente genial.

@wolverinevn hmm ... 50 debería suceder bastante rápido dependiendo de la cantidad de intervalo de tareas y reintentos que tenga (5-15min.) ... si esto no ayuda, creo que el nodo en realidad no está congelado, pero simplemente puede ' t vuelva a conectarse a la red. También tuve esto incluso después de reiniciar WD. ¿Puedes ver si el nodo intenta pasar al modo AP? ¿Ves el AP-WLAN del nodo?

Tengo 9 tareas, 3 de ellas son Dummy y MQTT_import. Creo que las reglas están un poco ocupadas con la computación y la lectura de sensores. Traté de limitar mqtt_publish llamando a las reglas cada pocos minutos. La carga es alrededor del 29%.
Según recuerdo, la última vez que se congeló esta mañana, no puedo encontrar el AP de Espeasy (si te refieres a que AP_WLAN está funcionando en modo AP).
Mi configuración (red, ubicación de ESP) funcionaba a la perfección con otro Nodemcu con 2.3 o 2.4 que se lanzó en marzo.

_El tiempo de actividad es de 7 horas y 20 minutos, RSSI es -71dbm, hay algunos wifi a mi alrededor.
Motivo de la última desconexión: | (200) Tiempo de espera de la baliza
Número de reconexiones: | 35_

@wolverinevn, el problema con este problema es que ocurre completamente al azar. Tengo ~ 30 nodos en ejecución, algunos de ellos enfrentaron el problema, algunos de ellos no, algunos se reiniciaron, algunos pasaron al modo AP ...

Realmente parece ser una combinación de qué tan ocupado está el nodo, qué tan ocupado está el aire (por ejemplo, número de dispositivos wifi) y cómo su AP maneja actualmente ciertas condiciones (missnig layer 2 acks, etc.) ...

así que supongo que hasta que encontremos una manera dentro de la aplicación (ESPEasy) de detectar de manera confiable esta condición y actuar sobre ella, no hay una solución "real" ...

@wolverinevn PD: ¿no estás usando AP de mikrotik por casualidad?

@wolverinevn Acerca del número de reconexiones (en su edición)
35 reconexiones en aproximadamente 8 horas es mucho.
Tengo nodos aquí funcionando durante días que solo tienen un puñado de reconexiones.
El más estable está funcionando durante 20 días, 11 horas y 46 minutos ahora y solo 1 reconexión.

Conectado | 19d22h33m
- | -
Razón de la última desconexión | (202) Error de autenticación
El número se vuelve a conectar | 1

@wolverinevn PD: ¿no estás usando AP de mikrotik por casualidad?

No. Estoy usando un enrutador con firmware Padavan (tipo de ASUS).

@ TD-er lo sabía. Estoy inspeccionando el motivo, puede ser ruido del módulo de reducción cercano. Otro tiene 0 reconexión después de 2 horas.

No. Estoy usando un enrutador con firmware Padavan (tipo de ASUS).

Desafortunadamente, no conozco este FW en absoluto ... ¿Alguna posibilidad de modificar los parámetros de la capa 2? ¿Algo como los tiempos de espera del frame ack o similar? ¿Algún tipo de configuración de "distancia"?

@ clumsy-stefan Desafortunadamente, no veo nada de eso.

@ clumpsy-stefan La unidad se reinició 2 veces anoche con 50 umbrales de falla establecidos. Buenas noticias es que ya no hay congelados. Hoy intentaré mejorar la conexión wifi mediante algunos cambios menores en la configuración del hardware.

3 unidades Wemos en la misma habitación, conectadas al mismo AP.
Se vuelve a conectar en las últimas 16 horas aproximadamente,
Con regla: En WiFi # Conectado ....

26 reinicios de WD y 104 reconexiones:

9 reinicios de WD y 32 reconexiones

2WD reinicia y 40 reconexiones

Todos tienen 50 umbrales de falla establecidos

@Domosapiens & @wolverinevn, una cosa más que puede intentar es aumentar el tiempo de espera de la clave de grupo en su AP (si tiene esa opción). Normalmente eso es alrededor de 5 minutos. Puede intentar aumentar a 30 minutos. o incluso 1h y ver si aumenta (siempre que no esté en una red de seguridad súper alta, que no supongo que tenga IoT) ...

@ TD-er

El más estable está funcionando durante 20 días, 11 horas y 46 minutos ahora y solo 1 reconexión.

También tengo actualmente unidades que funcionaron durante más de 3 días y otras que se reiniciaron en un día ...

Vi algunos problemas con la recuperación de la clave de grupo. de alguna manera parece, que en las versiones más nuevas del núcleo puede suceder que el cambio de clave se ejecute en un tiempo de espera ... sin embargo, la aplicación debería actuar en esto y no entrar en un modo de alta carga que no responde ... pero yo no seguro de dónde está fallando ...

@ clumsy-stefan gracias por tu sugerencia.
Veo en mi enrutador dd-wrt un parámetro. "Intervalo de renovación de claves" con valor 3600 (en segundos).
¿Entonces eso debería estar bien?

reingresar se ejecuta en un tiempo de espera

Eso explicaría solo una reconexión por hora en mi humilde opinión.
Gracias a la gran función de regla _WiFi # Connected_ podemos ver esto.
No tengo idea de cómo se desempeñaron las versiones anteriores en esto.
¿Un problema oculto desde hace mucho tiempo?

después de configurar mi renovación de clave de grupo de 5min. a 1h las unidades funcionan mucho más estables. Supongo que con 40 clientes conectados a un AP cada 5 minutos. una reinicialización hizo que el aire estuviera un poco demasiado ocupado ... después de eso, incluso pude reducir el tiempo de espera del frame-ack nuevamente y las unidades volvieron a responder mejor, también obtuve menos "tiempos de espera de conexión" después de cambiar estos parámetros ...

@ TD-er todavía creo que este "tiempo de espera de la clave de grupo" y el "error de asociación" después deben ser capturados y manejados por la aplicación. Tengo la sensación de que la unidad sigue intentando enviar mensajes en cola al controlador / servidor mientras intenta hacer un cambio de clave, lo que hace que la unidad sea demasiado lenta y el mantenimiento falle ... por lo tanto, se desconecta en la capa 2.

Sin embargo, solo es una idea aproximada, todavía estoy tratando de precisarlo, pero eso es lo más cerca que pude estar hasta ahora.

@ TD-er jsut ahora experimenté nuevamente un nodo que entra en un ciclo indefinido de intentos de reconexión y siempre expira (ver registro a continuación). Lo interesante es que, obviamente, se da cuenta de que no está conectado y no intenta enviar datos al controlador, lo que significa que los "intentos fallidos de conexión" ya no aumentan y, por lo tanto, nunca alcanza el límite de conexión fallida.

también la carga se muestra siempre al 100%, por eso supongo que no se logra volver a conectar, ya que siempre es demasiado lento para hacer el apretón de manos ... me parece como una mordedura de cola ... solo la memoria está disminuyendo lentamente (hasta que Supongo que se bloquea porque está fuera de la memoria) ...

Voy a probar con el # 2073 y veré si esta situación ocurre nuevamente ... sin embargo, ocurre muy raramente en los dos nodos conectados en serie, así que realmente puedo rastrear lo que está sucediendo ...

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

Es difícil conectarse con rssi - 80

¡El valor RSSI no es confiable cuando el nodo ESP no está conectado! el mismo nodo tiene menos de -70 cuando está conectado ... en los nodos de sueño profundo, incluso muestran el valor predeterminado "no conectado" de +31 al enviar los valores.
y después de un reinicio se ejecuta sin problemas ... (sin moverlo ...) si lee arriba, es un problema de capa 2 que se puede reproducir cuando modifica los parámetros en el AP ...

PD: ¡puedes probarlo tú mismo! jsut conecte 20-30 nodos y baje el tiempo de espera de la clave de grupo a 5 minutos. y el valor del umbral de respuesta de la trama a algo así como 7 ... ¡mira qué sucede!

Creo que es un lugar incorrecto para problemas con layer2, debería llenar el problema en esp8266 core o tal vez mejor en el proyecto nonos sdk
Pero por favor no grites aquí

solo sucede con ESPeasy y no con otros tipos de firmwares que probé. Supongo que el nodo está demasiado ocupado en algún momento y no deja suficiente tiempo para que el núcleo haga el cambio de clave (todo se explicó varias veces), así que no dude en leer las depuraciones y explicaciones ...
pero estoy de acuerdo, en realidad no es necesario que respondas ...
PD: @ uzi18, ¿alguna vez ha tenido 30 nodos ejecutándose con éxito al mismo tiempo?

@ TD-er: en ESPEasyWifi.ino líneas 650 - 669, la coincidencia predeterminada de la sentencia switch sale del switch y, por lo tanto, tryConnectWiFi() devuelve true aunque WiFi.status() es no necesariamente WL_CONNECTED pero puede ser cualquier otro estado (solo se marcan 2 estados de devolución falsa ..).

Cambiar esto y devolver true solo si WiFi.status() realmente devolvió WL_CONNECTED resuelve al menos uno de los problemas de desconexión / excepción de capa 2 que estoy enfrentando.

¿Qué piensas?
¿Me estoy perdiendo algo o por qué debería tryConnectWiFi() regresar cuando WiFi.status() no lo es? WL_CONNECTED`?

@ clumsy-stefan Es bueno ver que todavía estás investigando el código WiFi.

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

La idea inicial de esta función era iniciar la secuencia de conexión WiFi.
Quizás su función haya cambiado un poco a lo largo de todos los cambios desde entonces.
Pero puede que haya algo aquí.
Creo que puede ser un cambio adecuado a return true (al final de esa función) solo si el estado devuelve que está conectado.

¿Puede describir cuál parece ser el otro problema de la capa 2 al que se enfrenta?

No puedo decir exactamente cuándo ocurre la otra excepción, pero al menos hay una diferencia si esta función solo devuelve true cuando el estado es WL_CONNECTED Adjunto la depuración antes y después del cambio. .

antes de

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

despué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 ... Me acabo de dar cuenta de que después de esto, el estado interno no coincide (todavía) con el estado de Arduino ... esto también podría provocar problemas, supongo ...

@ clumsy-stefan, este estado se debe a que no podemos transmitir el estado del wifi de Arduino, por eso @ TD-er introdujo el estado ESPEasy, pero bueno, tal vez podamos intentar verificar si todos los estados en el código están verificados correctamente.

Podría ser que este estado de wifi se haya solucionado en el núcleo 2.5.0, por lo que tal vez nuestro propio estado se haya vuelto obsoleto.
Eso sería bueno, ya que hace que el código WiFi sea bastante complicado y, por lo tanto, propenso a errores.

Editar:
Estoy viendo este error que diste:
Fatal exception 9(LoadStoreAlignmentCause):
Una de las correcciones más recientes en el núcleo 2.5.0 es sobre el constructor de IPAddress , que debería solucionar problemas cuando la alineación de la secuencia de bytes dada no está alineada a 32 bits.
¿Quizás esto sea algo similar?

Esa es una de las conjeturas que tengo, que el estado de ESPEasy no siempre está sincronizado con el estado de Arduino. Especialmente las desconexiones temporales en la capa 2 (por ejemplo, cambios de clave de WiFi) probablemente no se manejen / realicen realmente.

Otra cosa podría ser lo contrario, que ESPEasy piensa que está desconectado e intenta volver a conectarse, pero el núcleo sigue conectado y, por lo tanto, genera una excepción. pero aún no puedo probar eso ...

sobre la alineación, sí, puede ser, pero tampoco puedo clavar esto actualmente ...

así que lo único que estoy bastante seguro actualmente es que el código de retorno de tryConnectWiFi() debe coincidir con el estado de conexión real o al menos verificar WL_CONNECTED ...

@ TD-er estoy algo más preocupado por

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

Para mí, las dos últimas líneas indican que el núcleo aún no actualizó el estado, aunque ESPEasy cree que sí ... así que podría terminar en alguna condición de carrera aquí ...

después de que esto suceda, a veces empiezo a ver muchos

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

de la que nunca se recupera ...

un poco después me dice:

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

No tengo idea de dónde viene esto ... pero después de esto comienza a intentar conectarse al controlador / servidor que obviamente falla hasta que se queda sin intentos (100) y se reinicia ...

EDITAR: por cierto, puede forzar este comportamiento si expulsa el nodo del AP manualmente ... a veces simplemente se vuelve a conectar, a veces sucede lo que se describe anteriormente ...
EDIT2: a veces se bloquea con la Excepción 9 ... ¡así que parece ser una especie de condición de carrera cómo se recupera exactamente de una desconexión! mi culpa, tuve una addLog() en la devolución onDisconenct() llamada

es más o menos siempre la misma situación. después de que falla el apretón de manos de 4 vías (reanudación), ya no se recupera ... no estoy seguro de cómo forzar una recuperación de esto ...

al menos agregando algo de delay(100) en processConnect() y processDisconnect lo que le da tiempo al núcleo para actualizar el estado de WiFi y hace que los satuses de WiFi vuelvan a sincronizarse. ¡Esto también hace que las unidades entren en la siguiente situación con mucha menos frecuencia!

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() devuelve un true o false en caso de que la conexión haya sido satisfactoria o no ... sin embargo, el WiFiConnectRelaxed() realidad nunca comprueba esto ...

¿Es esta función de alguna manera anterior al WiFi basado en eventos? parece que nunca llega a las últimas 2 líneas en esa función ...

Sí, fue una especie de sobrante de antes del wifi basado en eventos.
Creo que deberíamos considerar echarle un vistazo a ese código WiFi de nuevo, ya que no está tan estructurado como debería.

ok ... todavía estoy depurando lo que sucede exactamente debido al tiempo de espera del protocolo de enlace de 4 vías y por qué el nodo no se vuelve a conectar ... allí que podría sumar sin embargo ...

otro pequeño parece estar en WifiCheck() ... allí, la verificación de la conectividad de la capa 2 solo se realiza cuando la IP ya no es válida (por ejemplo, todos los octetos son 0). Esto podría llevar a la situación en que la capa 2 se desconecta (o vuelve a) conectarse / apretón de manos, etc. pero la IP sigue siendo válida porque aún no ha caducado (DHCP). Esa es probablemente la causa por la que la "renovación de DCHP probablemente falló" solo ocurre después de mucho tiempo, cuando el contrato de arrendamiento en realidad se ha agotado ...

también hay wifiCheck() , WiFiConnected() y connectionCheckHandler() que realizan algún tipo de verificación de conexión y se llaman entre sí, así como resetWiFi() bajo ciertas condiciones. .especialmente connectionCheckHandler() parece ser llamado solo cuando mqtt_reconnect_count > 10 . Entonces, ¿qué sucede en un entorno no MQTT?

PD: Solo estoy documentando mis hallazgos aquí en busca de los problemas subyacentes de WiFi ... Así que estoy feliz por cualquier pensamiento al respecto, pero no necesariamente lo esperaba ...

tiene que haber algún tipo de condición racial misteriosa en alguna parte. cuando el AP inicia una reautorización o restablecimiento, a veces el nodo / núcleo no tiene suficiente tiempo de CPU para completar el protocolo de enlace o se interrumpe mientras lo hace, especialmente en nodos con baja señal (y, por lo tanto, el protocolo de enlace tarda mucho más). . (vea abajo).

estas renovaciones / reaautorizaciones parecen generar un evento de desconexión por parte del núcleo, aunque el núcleo haría una renegociación o reconexión automática (según tengo entendido). pero luego parece que este proceso de apretón de manos es interrumpido por la máquina de estado ESPEasy cuando se activa una reconexión manual ... este proceso se repite y nunca termina (o en algunos casos genera 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

Entonces, ¿quizás deberíamos usar los eventos wifi solo para monitorear el proceso, no para tomar medidas nosotros mismos?
Sin embargo, cambiar esto hará que las compilaciones 2.3.0 y quizás 2.4.0 sean inutilizables.

No, no haría eso ... En mi rama ya hice un par de cambios (no tan intrusivos) que parecen hacer que estos casos ocurran con menos frecuencia ...

Acabo de encontrar otra pequeña cosa: en tryConnectWiFi() el cheque WiFi.status() llega al final después de que la llamada WiFi.begin() comience a regresar WL_DISCONNECTED . Según la documentación, esto significa "si el módulo no está configurado en modo de estación". tratando de averiguar por qué sucede esto o en realidad si ayuda poner el esp explícitamente en modo AP antes de llamar a WiFi.begin()

Así que todavía espero encontrar el problema subyacente "real" de por qué ocurren estos puestos ... Si es así (dedos cruzados), sugeriría que haga un PR con todos los cambios para que usted (y otros) los revisen ...

Por favor, sepa que también he visto muchas situaciones en las que el estado de WiFi.status() no era correcto.
Entonces, tal vez las bibliotecas centrales ahora tengan correcciones y es muy probable que también me equivoqué en algún lugar en todos los intentos para que el WiFi se comporte estable.
Esa depuración fue muy difícil de hacer, ya que no puedo reproducir estos problemas por mí mismo y tuve que actuar sobre los informes de otros usuarios.
Últimamente tengo un módulo que también se está comportando mal con respecto a WiFi, así que ese es mi módulo de prueba de WiFi favorito. Pero también puede ser una indicación de que el problema empeorará cuando algunas piezas estén cerca de estar fuera de especificaciones. Por ejemplo, fuente de alimentación o condensadores de desacoplamiento faltantes, trazas de PCB (demasiado) delgadas, menos blindaje, etc.

seguro, no es que esté descartando problemas de HW. Pero tengo ~ 40 nodos en funcionamiento, con diferentes tipos de fuentes de alimentación, diferentes placas, marcas, etc., y en algún momento la mayoría de ellos enfrentan problemas de conectividad ... especialmente los que tienen poca cobertura wifi o muchos GPIO está en uso ..

Y actualmente tengo un poco de tiempo para hacer algunas depuraciones y todavía lo encuentro muy interesante y desafiante;) A estas alturas incluso empiezo a comprender cómo funciona toda la secuencia de conexión, verificación, desconexión, etc.

Entonces, si está bien para usted, seguiré profundizando en estos problemas de conectividad ... aunque usted es el jefe ...

Continúe excavando :)
Realmente quiero liberarme de todos esos problemas de desconexión que son casi imposibles de reproducir.
Ya han tardado demasiado y sería genial si se arreglaran.

Estoy obteniendo entre 4 y 24 horas de tiempo de actividad seguidas de 2 a 10 horas de tiempo de inactividad en promedio.
Durante el tiempo de inactividad, el nodo sigue funcionando, pero no hay conexión wifi.

El punto de acceso (MikroTik) muestra:

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 | Informacion |
----- | ----- |
Construir: ⋄ | 20103 - Mega |
Bibliotecas: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 Soporte PUYA |
Versión GIT: ⋄ | mega-20190110 |
Complementos: ⋄ | 7 [Normal] [Sonoff POW R1 / R2] |
Tiempo de construcción: ⋄ | 10 de enero de 2019 03: 21: 19 |
Nombre de archivo binario: ⋄ | ESP_Easy_mega-20190110_hard_SONOFF_POW_4M.bin |

Este no era el problema en la versión anterior (cuando todavía podía usar el canal 14 y tener mi red hidden-ssid).

¿Tienes el canal WiFi fijo o es variable?
He estado leyendo en la página de resolución de problemas de Tasmota y me recomiendan encarecidamente que arreglen el canal WiFi.
Si el canal 14 no se puede usar, entonces algo relacionado con la configuración regional puede haber cambiado en alguna parte, ya que solo los canales 1-11 están permitidos en todos los países.
Además, los canales 1, 6 y 11 son en realidad los únicos canales que se pueden utilizar sin interferencia de otros canales.

solo funcionan los canales 1-10, no 11. Vea esto: https://github.com/letscontrolit/ESPEasy/issues/1337#issuecomment -394118989

El canal wifi es fijo, por supuesto.

Cualquier canal puede tener interferencias de otros canales, no hay forma de controlarlo. Demonios, incluso puede haber interferencias del mismo canal.

Por cierto, con respecto al problema al que me enfrento: el LED de estado de wifi (GPIO13 invertido) normalmente es azul sólido, pero cuando el dispositivo está fuera de línea, sigue el patrón 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 brillo.

IP fija y DCS, pero los canales nunca cambiaron en el pasado.

Von: Gijs Noorlander [mailto: [email protected]]
Gesendet: Freitag, 11 de enero de 2019 21:47
An: letscontrolit / ESPEasy
Cc: suscrito
Betreff: Re: [letscontrolit / ESPEasy] [BUG] [Estabilidad WiFi] ESP Excepción 3/29 cuando la capa 2 se desconecta (# 1987)

¿Tienes el canal WiFi fijo o es variable?
He estado leyendo en la página de resolución de problemas de Tasmota y me recomiendan encarecidamente que arreglen el canal WiFi.
Si el canal 14 no se puede usar, entonces algo relacionado con la configuración regional puede haber cambiado en alguna parte, ya que solo los canales 1-11 están permitidos en todos los países.
Además, los canales 1, 6 y 11 son en realidad los únicos canales que se pueden utilizar sin interferencia de otros canales.
-
Recibes esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment-453651579 , o silencie https://github.com/notifications/unsubscribe-auth/AomgSxPjVKWrp0MSQTtbESKxFqaPVt90DivPZCPg . https://github.com/notifications/beacon/AomgS_fhHQnmg1AdpX11mVL9yNra8S_kks5vCPgxgaJpZM4YDivP.gif

Las cosas de Mikrotik brindan un gran poder, pero incluso la configuración predeterminada para wifi no es correcta.

• Asegúrese de no tener en la configuración de seguridad tkip y habilite solo el cifrado aes ccm
• Ingrese una actualización de grupo de claves como 30 min o 1 hora
• en los canales tienen un ancho de canal de 20Mhz y en mi opinión, la banda B y van solo para G / N
• Canal de extensión deshabilitado
• Solo deshabilitar PMKID (recomendado si está histérico por la seguridad) parece hacer que el Esp se sienta muuuuuy infeliz
• Agregue su país a la configuración de wifi (o vea cuál es su potencia máxima para el AP que tiene y reduzca la potencia de transmisión en 3). Esto muy a menudo aumenta el rendimiento de wifi (contra intuitivo, lo sé)

Generalmente no tengo desconexiones (excepto cuando tuve esto PMKID)

De todos modos, sería interesante publicar la configuración de su AP de todos modos :-)

Son buenos consejos. Sin embargo, estoy bastante versado en redes e incluso más experimentado en mikrotik y he configurado todo como dices, excepto la clave de grupo.

La actualización de la clave de grupo solo tiene que ver con la clave de grupo, no con la clave de unidifusión donde se encuentra el problema también, pero he degradado esa configuración para los fines del experimento.

¡@ 0ki Cool no sabía que eras un experto en RouterOS!

Llegué a la conclusión de que claramente se trata de un error en el software ESPEasy. Puede ver el comportamiento problemático a la derecha que coincide con RouterOS desconectando al cliente que se comporta mal a la izquierda. El espectro de radio es claro como ve.

Desafortunadamente, no tengo tiempo para profundizar en el código base de ESPEasy en este momento, pero confío en que esta comparación de comunicación mala vs buena será útil.
Leyenda: __red - punto de acceso | azul - espeasy | verde: otro dispositivo en mi red iot__

Creo que ESP_easy, por alguna razón, decide cambiar al modo AP después de recibir la respuesta asociada (cuadro 380 a la izquierda) y no continuar con el protocolo de enlace de cuatro vías. Observe también el cambio de macaddress espeasy: el primer octeto cambia de 80 a 82.

@ 0ki

Llegué a la conclusión de que claramente se trata de un error en el software ESPEasy.

Yo también, pero no tengo ni idea de dónde debería estar el error.
Parece que el estado interno de ESPeasy con respecto al estado desconectado no está sincronizado con el estado real.
Es muy posible que haya cometido algún error al escribir ese código, o es un error en las bibliotecas centrales.

¿A qué archivo se refiere específicamente con "ese código"? Si señala uno o dos archivos, podría echarle un vistazo.

De lo contrario, dado que ahora ve el momento exacto en que sucede, espero que pueda verlo más de cerca.

Como también estoy investigando este problema (durante aproximadamente 2 meses) ya no estoy completamente seguro de si es el código ESPEasy en sí. más una interacción entre ESPEasy y el núcleo / biblioteca de WiFi ... Mis depuraciones / registros muestran que la "Desconexión" siempre ocurre después de un intercambio / mantenimiento de claves de grupo. PERO la devolución de llamada solo se llama después del tiempo de espera de cambio de clave y, posteriormente, después de que la autenticación falló ... Por lo que actualmente mi conjetura es que ESPEasy no deja suficiente tiempo de CPU al núcleo para realmente hacer el mantenimiento ... hasta ahora no lo hice Sin embargo, no encuentro una manera de averiguar cuándo el nodo está en este nodo de recuperación o en el modo de reautorización y, por lo tanto, puede agregar suficientes llamadas delay() para que la reautorización sea satisfactoria ...

Para ayudar a identificar el problema en el tiempo, estaba funcionando bien con:

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

Y con ok me refiero a que no solo no hubo desconexión, sino también que conectarse a un AP oculto en el canal 14 no fue un problema.

@ clumsy-stefan, apoyo completamente detectar el problema que hace que se desconecte en primer lugar, pero honestamente, puede haber varias razones por las que una asociación wifi puede caer, por supuesto, un intercambio de claves grupales no debería ser uno de los ellos.

El problema más urgente es: ¿por qué no puede volver a conectarse después de desconectarse? No puede ser un problema de tiempo, ya que estoy dando especialmente 5000ms para responder con el mensaje 2 del HS de 4 vías.

Creo que el problema es que solo obtienes la desconexión DESPUÉS de que falla el intercambio de claves ... por lo que nunca ahora cuando el intercambio realmente comienza, ahí es donde deberías darle más tiempo al núcleo ...

en los registros se puede ver que ESPEasy piensa durante bastante tiempo que todavía está conectado, incluso si no lo está (incluso falla un ping al nodo), pero el nodo aún intenta enviar datos (y obviamente la conexión falla entonces) ...

El segundo problema en el que estoy completamente de acuerdo es que, incluso si se desconecta, ¿por qué no puede volver a conectarse con una secuencia de conexión completamente nueva ... probablemente el módulo o núcleo está atascado en algún estado extraño?

EDITAR: PD: el HS de 4 vías no siempre falla (lo hago cada 10 minutos), por lo que parece ser una combinación del estado / ocupación del ESPEasy y el momento en que ocurre el HS.

Lo que puedo hacer es intentar desconectar completamente el WiFi (también apague el módem) e iniciar una nueva conexión completa cuando se produzca una desconexión inesperada.
No estoy seguro si estaba en este hilo, pero en uno de estos problemas, alguien respondió con un tweet de alguien en Shelly, quien mencionó que tenían que reiniciar la pila wifi por completo después de desconectarse.

@ TD-er eso es también lo que puse en mi última versión. dentro de processDisconnect() agregué un setWifiMode(WIFI_OFF); aunque no estoy seguro, si eso es suficiente ... actualmente se está ejecutando en algunos nodos de prueba (desde aproximadamente 1h) ...

@ TD-er esa es una buena idea. ¡Presiona un lanzamiento de git y mostraré mis cosas!

Acabo de comenzar a leer parte del código base hace 5 minutos, por lo que esto puede ser irrelevante, pero: asegúrese también de que wifi_connect_attempt esté configurado en 0 en ese momento.

hmm ... agregar algo de delay(0) en backgroundtasks() después de cada una de las llamadas de subrutina, parece estabilizar aún más el primer problema un poco (4way-HS). No estoy seguro si es una coincidencia difícil ...
@ TD-er ¿podría ser que backgroundtasks() esté bloqueando la ejecución en algún momento?

En términos generales: agregar delay(0) en todo tipo de lugares diferentes donde las estadísticas de tiempo muestran tiempos de procesamiento largos parece mejorar mucho el manejo de 4way-HS. Tengo más perros guardianes de SW / HW activando ahora que problemas de recuperación (pero todavía tengo algunos) ... sintomáticamente, así que diría que está realmente relacionado con la parte central / wifi que no recibe suficientes ciclos para hacer (bastante rápido) cosas como volver a guardar y el AP luego se cansa de esperar una respuesta ...

Lo que también veo es que a veces el client.connect() o el sendData() puede llevar bastante tiempo (hasta 2 segundos). En alguna documentación, encontré que si algo toma más de 50 ms, debe llamar a delay(0) entre medias ... pero no puede dividir estas llamadas ya que las realiza la biblioteca ...

También hay otra devolución onStationModeAuthModeChanged llamada

EDITAR: parece ser una condición de coincidencia / carrera con algunas otras cosas que se están haciendo en el momento en que AP solicita una nueva clave ... pero nuevamente solo observaciones ...

No sé con qué frecuencia se retransmiten estas solicitudes enviadas por AP.
Normalmente, la señal de baliza del AP se envía cada 102,4 ms. Si algunas tareas requieren más que eso, el ESP pierde uno de esos marcos de baliza. Entonces no estoy seguro de cuán malo es esto.
Sé que las solicitudes ARP a veces se pierden, lo que conduce a problemas de que un conmutador ya no sabe cómo enrutar paquetes a esa dirección MAC y, por lo tanto, hace que el ESP sea inaccesible, mientras que aún puede enviar datos por sí mismo.

la falta de marcos de baliza no es nada. ni siquiera debería necesitar marcos de baliza, ya que debería estar investigando activamente mi red oculta de todos modos.

No soy un experto en WiFi.
Según lo entendí, el intervalo de baliza es el único momento, en cierto modo garantizado, que el ESP está tratando de escuchar el WiFi y entre ellos intentará dormir lo más posible.

Y según lo entendí, la única diferencia entre las redes "ocultas" y las redes "no ocultas" es que el SSID no se está transmitiendo. Entonces, de hecho, se está conectando solo en función de BSSID (dirección MAC de AP).
Eso es también lo que hace el ESP cuando se conecta a redes WiFi (no ocultas), con la única diferencia de que realizará un escaneo antes e intentará encontrar un BSSID que tenga un SSID que coincida con el dado.
Al realizar una reconexión automática, probará primero la última combinación conocida de BSSID + canal sin realizar un escaneo. En otras palabras, solo difiere al hacer una conexión.

Entonces, que yo sepa, siempre que haya una conexión a una red, también escuchará las tramas de baliza.

No soy un experto en WiFi.
Según lo entendí, el intervalo de baliza es el único momento, en cierto modo garantizado, que el ESP está tratando de escuchar el WiFi y entre ellos intentará dormir lo más posible.

Y según lo entendí, la única diferencia entre redes 'ocultas' y redes 'no ocultas' ..........

Oh, eso me recuerda algo que puede ser muy importante. Ejecuto mis ESP en un SSID oculto
Por cierto, todavía no hay desconexiones ni reinicios en mis nodos (probando actualizaciones de claves de grupo de 5 minutos)

Uno de mis nodos se reinició el 5 de diciembre debido a un corte de energía.

Esto es de ese:

Unidad: | 5
- | -
Hora local: | 2019-01-15 23:27:32
Tiempo de actividad: | 41 días 12 horas 46 minutos
Carga: | 15,80% (LC = 9135)
Mem libre: | 12160 (5360 - enviar bloqueo de contenido)
Pila libre: | 3552 (1520 - SensorSendTask)
Arranque: | Arranque en frío (0)
Razón de reinicio: | Sistema externo
Red ❔
Wifi: | 802.11N (RSSI -67 dB)
Configuración de IP: | DHCP
IP / subred: | 192.168.1.89 / 255.255.255.0
GW: | 192.168.1.1
IP del cliente: | 192.168.1.67
DNS: | 192.168.1.1 / 0.0.0.0
Rango de IP permitido: | Todo permitido
STA MAC: | 5C: CF: 7F: B1: 3F: 12
AP MAC: | 5E: CF: 7F: B1: 3F: 12
SSID: | Estacada4 (34: 31: C4: B1: 8D: C7)
Canal: | 11
Conectado: | 20h04m
Motivo de la última desconexión: | (202) Error de autenticación
Número de reconexiones: | 61
Firmware
Construir: ⋄ | 20102 - Mega
Bibliotecas: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 Soporte PUYA
Versión GIT: ⋄ | mega-20181109
Complementos: ⋄ | 46 [Normal]
Construir Md5: | 47f19d99d0c3f083314b45668b1f5c
Comprobación de MD5: | pasado.
Tiempo de construcción: ⋄ | 9 de noviembre de 2018 03:23:22
Nombre de archivo binario: ⋄ | ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Como puede ver, en promedio más de una desconexión al día. Está conectado a un AVM Fritzbox 1750E

Creo que los marcos de baliza no son tan críticos ... todavía no tengo claro por qué, después de una desconexión, la secuencia normal WiFi.begin() siempre falla con un '(2) Auth expire' .

La única indicación es que la carga de la CPU en este punto siempre muestra el 100% y sugiere que el núcleo simplemente no tiene suficiente tiempo para hacer el apretón de manos ...

Supongo que hay algo mal en las bibliotecas centrales (LWIP o Arduino o ESP) y deberíamos restablecer el wifi.
Por lo tanto, apague el wifi y comience de nuevo. Quizás también espere entre esos pasos para asegurarse de que los búferes se vacíen o al menos se vacíen y las solicitudes pendientes se cancelen activamente.

@ TD-er, ¿puedes impulsar este cambio para que pueda ver si funciona?

¿El cambio discutido en las últimas 2 publicaciones?
Aún no se ha implementado, pero puedo intentar esta noche codificarlo y hacer una compilación de prueba.

Sí, restableciendo el wifi.

@ TD-er escribió:

Por lo tanto, apague el wifi y comience de nuevo. Quizás también espere entre esos pasos para asegurarse de que los búferes se vacíen o al menos se vacíen y las solicitudes pendientes se cancelen activamente.

No estoy seguro sobre el vaciado ... ya que eliminé todas las llamadas client.flush() antes de client.stop() También parecía que la desconexión ocurre con menos frecuencia. Mientras leía algo de documentación, vi que el flush elimina todos los búferes de entrada (tcp), por lo que, en teoría, podría suceder que las respuestas se pierdan ...

Solo agregando mi 2c, tengo algunos AP Mikrotik, con algunos sonoffs ejecutando espurna y algunos NodeMCU ejecutando ESPEasy. Tuve que agregar un AP adicional para los dispositivos ESP, porque durante un período de alto tráfico en mi red, como las copias de seguridad, perdería mis dispositivos ESP. Creo que esto se debió a la intensidad de la señal WiFi y al tráfico. Una vez que se agregó el AP adicional, no recuerdo haber vuelto a ver este problema.

Pero mis dispositivos NodeMCU y ESPEasy tienen algunas desconexiones. Voy a configurar un monitor de ping de netdata a los dispositivos y veré si puedo averiguar cuándo, cómo y por qué podría estar sucediendo esto y ver si les devuelvo información.

Otra nota, no tengo más de 40 dispositivos como @ clumsy-stefan, solo unos 5 usuarios y sus dispositivos móviles y algún que otro dispositivo inteligente como la televisión, pero ¿podría ser que el dispositivo Mikrotik esté sobrecargado o la red WiFi RF saturada? ?

Ojalá tuviera una forma de ver la cantidad de ruido de RF. Tengo una aplicación (WiFi Analyzer) que me muestra la cantidad de AP y cómo se propagan los canales WiFi. Utilicé esta herramienta para configurar mis canales WiFi para diferentes puntos de acceso WiFi.

Pero realmente no puedo decir si podría haber otras interferencias de RF.

En cuanto a la idea de un dispositivo Mikrotik sobrecargado, estoy usando MikroTik 951UI-2HND para mi enrutador principal y MikroTik RB9412nD hAP lite como mi AP ESP.

Me pregunto si esa información es útil de alguna manera.

@LeeNX gracias por las sugerencias. mis nodos se distribuyen en 3 AP y la RF está algo equilibrada (máx. 20 clientes por AP aproximadamente), por lo que hay la menor interferencia posible (por supuesto, no puede haber ninguna ...). Así que no creo que los MT estén sobrecargados (trabajo en una empresa que proporciona conectividad de red troncal y WLAN para eventos profesionales, etc., así que tengo algunas pruebas en profundidad del infraestructor), pero estoy de acuerdo en que el tiempo de aire sobrecargado podría ser un problema ... sin embargo, incluso si es así, un nodo nunca puede volver a conectarse por> 250 veces después de una desconexión y luego, después de reiniciarlo, se vuelve a conectar inmediatamente, creo que no puede ser un problema de tiempo aire ... No veo eso en cualquier otro dispositivo ...
así que sigo pensando que es una coincidencia o una condición de carrera entre el estado del chip wifi interno, la cantidad de tiempo de CPU que obtiene el núcleo wifi y qué otras tareas se están ejecutando en la parte ESPEasy ...

@ clumsy-stefan Estoy de acuerdo con sus ideas. Solo quería señalar que usar el pequeño Mikrotik AP con más de 40 nodos, podría haber sido una CPU Mikrotik o RAM limitada, pero ese no parece ser el problema.

Me pregunto si instalar un dispositivo ESP32 y NodeMCU con nada más que el núcleo base ESPEasy y dejar que se ejecute, para que podamos probar la CPU ESP y ninguna otra influencia del complemento. Vea lo que puedo implementar y haga una prueba de ping de netdata.

Si esto nos da alguna información útil, se lo informaré.

¡¡¡Gracias chicos!!!

Tengo un nodo aquí que se ejecuta casi sin nada (IR RX / TX) y está funcionando durante semanas sin problemas.
El otro nodo que tiene un tiempo de actividad de más de 40 días está ejecutando Domoticz MQTT y BME280 + MH-Z19 CO2.
Por lo tanto, probablemente también dependerá de qué complemento se esté ejecutando y con qué frecuencia, y tal vez también si el intervalo de lectura siempre coincide con el intervalo de lectura de otros complementos.

Ya configuré algunas llamadas de función periódicas (10 / seg, 1 / seg y 30 seg) con un desplazamiento inicial en el programador para que sigan ejecutándose tanto como sea posible en diferentes llamadas de bucle.

Tal vez también debería agregar algún evento impulsado por temporizador de interrupción como lo hace Tasker (o simplemente usar tasker en lugar del programador que escribí) y establecer una tarea en un intervalo de 10 mseg para ejecutar delay (0).
Lo único es que puede interrumpir otras transferencias GPIO y, por lo tanto, perturbar las lecturas del sensor.

eso probablemente resolvería el problema de 4way-HS, pero supongo que no es el problema de reconexión ... ese sigue siendo el más extraño ... Acabo de tener mi nodo de prueba fallando nuevamente durante 12 horas tratando de reconectar por> 300 veces al AP sin éxito. después de (soft-) reiniciarlo, se reconectó instantáneamente (reiniciar + reconectar tomó unos 5 segundos más o menos) ...

Encontré este problema que parece bastante relacionado con lo que estamos viendo aquí:
https://github.com/esp8266/Arduino/issues/5527

parece similar, sí ... pero llamar a wifi OFF no parece cambiarlo (lo intenté), actualmente estoy probando con WiFi.setOutputPower(0) antes de llamar a WiFi.begin() como se sugiere aquí
https://github.com/esp8266/Arduino/issues/2235
y aquí
https://github.com/esp8266/Arduino/issues/2186#issuecomment -233853152
todavía esperando que suceda ahora difícil ...

es similar pero no es lo mismo. De hecho, en nuestro caso, reiniciar el AP resuelve el problema, en el problema publicado por Gijs, reiniciar el AP no resuelve el problema.

@ giig1967g ¡ reiniciar el AP no me lo resuelve! solo reiniciar el nodo hace que se vuelva a conectar (aunque en mi entorno) ...

@ giig1967g En el problema mencionado por @ clumsy-stefan, este reinicio del AP también se menciona: https://github.com/esp8266/Arduino/issues/2235#issuecomment -248851270

Así que parece que tenemos varios problemas aquí.

@ torpe-stefan
Ah, vale. Y en mi caso solo con Mikrotik ... :(
@ TD-er
tal vez debería preguntar qué marca / modelo AP están usando ...

@ giig1967g También tuve algunos nodos aquí inaccesibles, pero el intervalo de esos eventos fue mucho más de 10 días, por lo que es un poco difícil decir si está relacionado con uno de estos problemas.
Aproximadamente la mitad de mis nodos ahora están conectados a un Mikrotik y la otra mitad está conectada a Fritzbox 1750E

@ giig1967g También solo tengo MT ... y parece suceder con más frecuencia en los nodos con señal más débil y nodos con GPIO en uso (específicamente PCF) ...

Ojalá tuviera una forma de ver la cantidad de ruido de RF. Tengo una aplicación (WiFi Analyzer) que me muestra la cantidad de AP y cómo se propagan los canales WiFi. Utilicé esta herramienta para configurar mis canales WiFi para diferentes puntos de acceso WiFi.

Pero realmente no puedo decir si podría haber otras interferencias de RF.

Puedes hacer /interface wireless registration-table print interval=1 en tu mikrotik para ver el snr.

Desafortunadamente, el WiFi.setOutputPower(0) tampoco ayudó ... después de casi 6 horas funcionando sin problemas (sin ningún cambio en la infraestructura wifi, de repente vuelve a estar en un punto muerto (ver la salida en serie a continuación) del cual nunca se recupera, excepto si por coincidencia se activa un SW o HW WDT ...

esto sólo parece suceder después de un "tiempo de espera de actualización de clave de grupo" o un "error de enlace de 4 vías". si saco el nodo del AP manualmente, también obtiene un "vencimiento de autenticación", pero puede volver a conectarse instantáneamente ...

salida serial (entonces la carga no llega al 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

solo un comentario rápido: agregar wifi_set_phy_mode(PHY_MODE_11G); y forzar el nodo en el modo 802.11g parece ser al menos una solución. No he reiniciado ninguna de las unidades desde hace un par de horas y también una o dos veces una unidad se recuperó del problema de tiempo de espera de la clave de grupo anterior ...
probablemente relacionado con

• ESP8266 SoftAP solo admite 802.11b / g.

que se indica en los documentos ...

Actualizaré más tarde / mañana si se mantiene estable ...

Como ya ha señalado (algunas veces) otra persona, la sensibilidad también debe aumentarse cambiando a 802.11G.
Mi objetivo en contra es (¿era?) Que la mayoría de los AP tienen problemas al cambiar entre N, G y B.
¿Tiene clientes mixtos? (G y N) activos en el mismo AP?

Utilizo diferentes modos en todos los Mikrotik. B / G / N / AC mixto, también ambas bandas 2 / 5GHz incluyendo AP virtuales definidos ... Diferentes clientes se conectan con diferentes modos en el mismo AP, sin problemas (excepto el esp8266) ..

buenas noticias (al menos para mí) ... ¡mis nodos se ejecutaron durante las últimas 12 horas sin desconexiones / reinicios / congelamientos!

forzar el nodo en 802.11g parece funcionar sin problemas junto con los AP de MikroTik. al menos esta es una solución simple (siempre que no necesite la velocidad adicional de 802.11n).

si alguien quiere probarse a sí mismo, simplemente agregue ESPEasyWifi.ino alrededor de la línea 644 en la función tryConnectWiFi() la siguiente línea (después de setupStaticIPconfig(); ):
WiFi.setPhyMode(WIFI_PHY_MODE_11G);

Solo puedo suponer que los problemas surgen porque el modo SoftAP no es compatible con 802.11ny el nodo está conectado en modo N, el núcleo se "confunde" de alguna manera ... pero supongo que este es un problema para plantear a la gente del núcleo. ..

Para ESPEasy, esto podría hacerse configurable, supongo (@ TD-er?) De modo que se pueda elegir en la página de configuración en qué modo debe ejecutarse el ESP (B / G / N) ...

Sí, agregaré una opción de selección en la configuración avanzada.
Olvidé quién lo preguntó primero, pero lo buscaré y lo acreditaré también en el compromiso;)

¡¡Perfecto!! No necesito el crédito, solo lo necesito para que funcione;) ¡así que siéntete libre de dedicárselo a él! 😄

Mientras depuraba encontré algunas otras cosas pequeñas que sugeriría cambiar (como llamar a delay() incondicionalmente después de las llamadas al complemento, algunos {} adicionales y algunas adiciones a la salida de registro. ¿Debo hacer un PR para estos ASPIT o le gustaría mantenerlo como está (creo que estos no son cambios vitales, solo algunas mejoras menores, probablemente)?

Por favor haga un PR.
Al menos ayudaría a la discusión y realizaría un seguimiento de sus hallazgos.
También sería útil agregar comentarios a lo que ha verificado

Para referencia # 2012
Todos los créditos al dev. ¡equipo!

¿Este parche también incluye la idea WiFi.setOutputPower (0)?

He estado realizando un experimento durante 7 días.
Nodo mega-20180224 - cero reinicios
nodo mega-20190110 - 35 reinicios; 9 de ellos hoy.

Dejé la línea relevante en el código pero la comenté. Por lo tanto, tendría que eliminar // (sobre la línea 644) en ESPEasyWiFi.ino y volver a compilarlo.

@oki lo siento, acabo de ver que leí tu pregunta incorrectamente ... No, esto no está incluido, ya que no pude ver ninguna diferencia al establecer la energía en 0 antes de reconectar ... ¡Así que descarté esa otra vez!

He estado realizando un experimento durante 7 días.
Nodo mega-20180224 - cero reinicios
nodo mega-20190110 - 35 reinicios; 9 de ellos hoy.

Eso es comparar efectivamente:

• core 2.3.0 sin wifi basado en eventos
• core 2.4.2 con wifi basado en eventos.

buenas noticias (al menos para mí) ... ¡mis nodos se ejecutaron durante las últimas 12 horas sin desconexiones / reinicios / congelamientos!

forzar el nodo en 802.11g parece funcionar sin problemas junto con los AP de MikroTik. al menos esta es una solución simple (siempre que no necesite la velocidad adicional de 802.11n).

Lo hice al revés para probar.
Configuré mi Mikrotik solo en modo N y bueno ... todos los ESP se están ejecutando desde> 12 h sin un solo reinicio.

enfoque bueno y válido también! Desafortunadamente, no puedo hacer esto, ya que tengo una cantidad de clientes sin capacidad N ...

Simplemente desactive el modo B y active solo G / N. Estás mejor sin el modo B. A menos que tenga teléfonos antiguos o (normalmente) lectores de códigos de barras wifi de hace 10 años que solo admiten el modo B y las tarifas.

La sensibilidad adicional de la antena en el modo B tampoco jugará un papel significativo en el alcance. El modo B solo consume tiempo aire. Literalmente, no hay inconveniente en no usar el modo B y tampoco hay inconveniente en usar el modo N sobre G. El modo N tiene un rango aún mejor que B y G también.

@ jimmys01 tienes razón, es probable que el modo B ya no se use en ningún lado ... pero no puedo ir solo por N ... por lo tanto,

g / n es inestable para mí.

¿Significa esto que el esp8266 tiene problemas cada vez que cambia entre un modo (B / G / N)?

¿Significa esto que el esp8266 tiene problemas cada vez que cambia entre un modo (B / G / N)?

Muy probable.
He visto muchos problemas con algunos dispositivos (no los ESP) que solo admiten el modo G.
Si los usa combinados con dispositivos N, pueden parecer inalcanzables.
Son notorios el HomeWizard y algunas cámaras WiFi.

Con esta nueva versión mega-20190121 el ESP parece ser más estable, no tuve los problemas de crash / Wlan hasta ahora.
Pero ahora ya no puedo apagar el OLED (framedPlugin). Cuando envío OLEDFRAMEDCMD, apagado apaga la pantalla por un momento muy corto y luego se enciende nuevamente.
Hice una prueba consecutiva con una versión anterior (de 2018), la pantalla reacciona como se esperaba.

Acabo de probar mega-20190121 y la estabilidad de WiFi es la misma. Se bloquea en aproximadamente una hora desde su inicio.

@ TD-er, ¿cuándo crees que podrías lanzar una versión con el cambio discutido para que pueda probarlo?

actualización rápida: desde que configuré el modo de corrección en 802.11g, ¡ya no tengo congelaciones, reinicios, etc.! a pesar de que los AP funcionan en modo mixto g / n ... ¡así que también votaría por un parche que haga configurable el modo wifi en el esp!

Espero un parche pronto también 😉

Acabo de agregar una confirmación para seleccionar solo B / G.
Todavía no funciona bien en ESP32, así que desactivé la opción de seleccionarlo para ESP32.
También agregué una opción de respaldo para poder conectarse nuevamente si el AP no permite solo B / G.

@ TD-er me refiero a este cambio:

Supongo que hay algo mal en las bibliotecas centrales (LWIP o Arduino o ESP) y deberíamos restablecer el wifi.
Por lo tanto, apague el wifi y comience de nuevo. Quizás también espere entre esos pasos para asegurarse de que los búferes se vacíen o al menos se vacíen y las solicitudes pendientes se cancelen activamente.

¿El cambio discutido en las últimas 2 publicaciones?
Aún no se ha implementado, pero puedo intentar esta noche codificarlo y hacer una compilación de prueba.

@oki Probé ambas variantes, estableciendo la potencia de salida en 0 y desconectando / reconectando activamente cuando ocurre el problema. ambas versiones no ayudaron a restablecer / reconectar al AP ... (en mi entorno) ... más detalles arriba ...
lo único que lo hizo estable fue usar N-Mode.

Soy muy consciente de eso. Espero un parche pronto, para poder continuar con la depuración.

@ 0ki Puedo hacer una construcción de prueba para ti usando esta última confirmación.
¿O también quieres probar con la desactivación de WiFi?

Y si es así, ¿qué opciones quieres / necesitas? ¿WiFi apagado / encendido y reiniciar todos los servicios?
Esa última parte (reiniciar los servicios) también es algo a tener en cuenta, ya que no estoy completamente seguro de que todos los servicios que usan un socket se reinicien correctamente.
Eso también puede causar algunos problemas, supongo, cuando se recrea la conexión WiFi.

Apagar automáticamente (y luego encender) el transmisor wifi cuando se detecta una desconexión.

Veo que ha agregado un código. ¿Qué versión puedo sacar para probar esto?

No estoy seguro, haré una nueva compilación para probar.
Se hará en +/- 30 minutos.

prueba de construcción
Se basa en lo que fusioné hoy y PR # 2235 que tiene los cambios para conectarse en modo B / G.
Parece haber problemas con algunos complementos en ese PR, por lo que esa es la razón por la que aún no se ha fusionado.

¡Gracias! Flasheó la construcción de prueba.

Ahora tengo la siguiente configuración:
Connection Failure Threshold: 0 Force WiFi B/G: NO Restart WiFi on lost conn.: YES

¿Crees que debería probar algo diferente considerando que tengo PLATFORMIO_ESP12E?
Es decir, olvidé si b / g va a funcionar en esp12e y qué umbral de falla de conexión era exactamente.

Ese umbral es solo un contador para iniciar un reinicio si una cantidad de intentos de conexión fallidos excede ese valor.
0 es el valor predeterminado y significa que no se reiniciará.

Supongo que establecerlo en 50 o 100 te ayudará a reiniciarlo cuando esté en un lugar de difícil acceso y entre en un bucle de reconexión.

Incluso con esta configuración, todavía puede mostrar reinicios del perro guardián de HW, como ya lo mostraron varios de mis nodos.
Puede que sea más difícil reproducir aquellos con el modo B / G activo.

prueba de construcción
Se basa en lo que fusioné hoy y PR # 2235 que tiene los cambios para conectarse en modo B / G.
Parece haber problemas con algunos complementos en ese PR, por lo que esa es la razón por la que aún no se ha fusionado.

Gracias por la construcción de prueba.
Mi ESP12F anteriormente más inestable ahora está activo desde 59 horas sin reiniciar :)

EDITAR: Las configuraciones son:
Forzar WiFi B / G: SÍ
Reinicie WiFi en conexión perdida: SÍ

Creo que dividiré ese compromiso (B / G WiFi) en un PR separado, para que pueda fusionarse antes de que arregle el resto del PR en el que ahora está esperando ser combinado.

¡Buena idea!

Mi configuración anterior RestartWifi = YES no hizo nada útil.

Ahora cambié a

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

y han pasado dos días sin reiniciar o incluso una sola desconexión. Asombroso. No creo que ni siquiera me aleje de este lanzamiento de prueba.

Después de aprox. 100 horas, el módulo finalmente hizo un reinicio. :(

Razón de reinicio: Watchdog de hardware

Sin embargo, esto también puede deberse a la configuración desafiante (12 sensores de 1 cable y un servidor FHEM).

También puede intentar agregar este parche: https://github.com/letscontrolit/ESPEasy/pull/2235/commits/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf2
Quizás eso también ayude a mejorar la estabilidad.
Está incluido en esta versión de prueba.

También puede intentar agregar este parche: 9a05eaf
Quizás eso también ayude a mejorar la estabilidad.
Está incluido en esta versión de prueba.

¡Gracias!
Lo instalé en dos unidades configuradas completamente diferentes y dará su opinión.

corrí en uno de mis nodos de prueba, incluido
https://github.com/letscontrolit/ESPEasy/commit/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf desafortunadamente solo tomó alrededor de 2 horas hasta que volviera a encontrarse con el problema de tiempo de espera de clave de grupo y no recuperarse o volver a conectarse al AP. Con "reiniciar wifi en conexión perdida" habilitado y sin forzarlo a B / G ... entonces N todavía parece ser un problema
Entonces, para mí, el modo B / G sigue siendo la única opción de trabajo estable.

¿Podríamos pensar en eliminar el soporte de N por completo? ¿Necesitamos los beneficios que proporciona N para un dispositivo tan simple?

@ 0ki con la opción "nueva" para forzar el modo B / G que @ TD-er incorporó, básicamente está eliminando N a nivel de software, no puede eliminarlo de las librerías principales, supongo ...

Al mover esto a la configuración principal, recomiendo que esta opción se envíe ENCENDIDA de manera predeterminada.

Podríamos hacerlo dinámico.
Si no es posible la conexión, vuelva a intentarlo con la opción N activada.

Hay muchas configuraciones que tienen solo N verificado en el AP. Entonces, en esos entornos, no puede retroceder si está deshabilitando el soporte N en el ESPeasy.

También puede intentar agregar este parche: 9a05eaf
Quizás eso también ayude a mejorar la estabilidad.
Está incluido en esta versión de prueba.

¡Gracias!
Lo instalé en dos unidades configuradas completamente diferentes y dará su opinión.

Hasta ahora, un módulo se reinicia después de 2 días, el otro después de 5 días.
Ambos mostraron "Hardware Watchdog" como motivo de reinicio.
Ambos módulos están configurados para "Forzar WiFi B / G: Sí" y "Reiniciar WiFi en conexión perdida: Sí".
El AP es un Mikrotik configurado solo en B / G (tiempo de actividad 49 días).
Distancia entre AP y módulos aprox. 2 ... 3 m.

Me preguntaba por qué mi sugerencia de hacerlo dinámico (para volver a N desde la configuración solo B / G) ha recibido 2 "votos" con el pulgar hacia abajo.
Explique por qué no es una buena sugerencia.

Me preguntaba por qué mi sugerencia de hacerlo dinámico (para volver a N desde la configuración solo B / G) ha recibido 2 "votos" con el pulgar hacia abajo.
Explique por qué no es una buena sugerencia.

En mi opinión, si alguien activa esta opción, ya está buscando desesperadamente más estabilidad y sabe lo que esto significa para su configuración de AP.
Prefiero una solución estática porque cuando selecciono la opción B / G only, absolutamente nunca quiero estar en una situación en la que creo que está usando B / G pero nuevamente no lo hace.
Sin embargo, dado que mis nodos se están reiniciando de todos modos (aunque con mucha menos frecuencia), me encantaría tener una solución real para el problema relacionado con el núcleo más nuevo.

Lo entiendo, pero también debe comprender el problema cuando los usuarios no saben lo que hace una configuración y terminan con nodos inalcanzables.
Por lo tanto, debería tener un gran umbral antes de volver al soporte N.
Por ejemplo, la alternativa para los complementos dañados es:
Después de 10 reinicios fallidos, se desactivará 1 complemento o controlador para ver si el reinicio puede ser exitoso.

También se puede aplicar algo similar a la conexión wifi.
Después de X intentos fallidos de reconexión, permitirá conectarse con 802.11N permitido
La calidad de recepción es mejor para las redes en modo G, por lo que si coloca X en algo como 10, es muy poco probable que se conecte con N en lugar de G. Especialmente si restablece este contador cada vez que lo intenta en modo N.

Hmm, las últimas semanas de menos tiempo para ESPeasy aparentemente ofuscaron mi memoria de lo que planeaba implementar o lo que se había implementado.

Solo miré el código para esto y encontré:

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

Entonces, aparentemente, ya se ha implementado para permitir N solo cuando wifi_connect_attempt es> 10.
Este contador se restablece a 0 tan pronto como hay un intento exitoso de conectarse a wifi.

¿Es esta una solución aceptable?

Hmm, las últimas semanas de menos tiempo para ESPeasy aparentemente ofuscaron mi memoria de lo que planeaba implementar o lo que se había implementado.

Solo miré el código para esto y encontré:

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

Entonces, aparentemente, ya se ha implementado para permitir N solo cuando wifi_connect_attempt es> 10.
Este contador se restablece a 0 tan pronto como hay un intento exitoso de conectarse a wifi.

¿Es esta una solución aceptable?

Bueno ... yo diría que sí (esperando que el error en la 2.5.0 se encuentre pronto).

Comentarios sobre el ajuste B / G solamente.
Acabo de instalar el fw de prueba en una unidad que se reinicia cada 20 minutos a más tardar. Antes se conectaba a N con -72dBi. Esa debería haber sido una señal lo suficientemente buena como para no desconectarse. Estoy operando AP de grado empresarial con capacidades de recepción de -105dBi. Así que, de nuevo, nunca debería abandonar el canal.

Después de unas horas con el FW de prueba y no hubo reinicio hasta ahora.
Lo mantendré funcionando e informaré.

PD: Estoy de acuerdo en que está relacionado con N de alguna manera.
PSS: Estoy ejecutando 20 nodos ESP-07 que se actualizaron a 4M. Consume mucho tiempo pero se amortiza cuando se necesita volver a flashear.

Tengo más de 120 nodos que se ejecutan en GN (mega-20190202) sin ningún problema. Todos informan estar conectados a N

@ jimmys01 ¿Cuántos nodos se están conectando al mismo AP?
¿Y cuál es la marca de ese AP? (¿Mikrotik?)

Casi todos se conectan a un AP diferente (uno por habitación de hotel). Disponen de interruptor (sensor PIR), sensor de temperatura y humedad HTU, y leds IR.
La marca AP es Mikrotik.
Los ajustes son los siguientes:
El país está configurado
Canal de control: 20 Mhz
Banda: GN
Canal de extensión: deshabilitado
Tipo de autenticación: solo WPA2 PSK
Cifrado: solo aes ccm
Cifrado de grupo: aes ccm
Actualización de Groyp Key: 00:01:00

Comentarios sobre el ajuste B / G solamente.
Acabo de instalar el fw de prueba en una unidad que se reinicia cada 20 minutos a más tardar. Antes se conectaba a N con -72dBi. Esa debería haber sido una señal lo suficientemente buena como para no desconectarse. Estoy operando AP de grado empresarial con capacidades de recepción de -105dBi. Así que, de nuevo, nunca debería abandonar el canal.

Después de unas horas con el FW de prueba y no hubo reinicio hasta ahora.
Lo mantendré funcionando e informaré.

PD: Estoy de acuerdo en que está relacionado con N de alguna manera.
PSS: Estoy ejecutando 20 nodos ESP-07 que se actualizaron a 4M. Consume mucho tiempo pero se amortiza cuando se necesita volver a flashear.

Desafortunadamente, la unidad continúa reiniciándose después de un tiempo aleatorio. Cualquier cosa dentro de 1-4 horas.
B / G only FW no resuelve mis problemas

Me preguntaba por qué mi sugerencia de hacerlo dinámico (para volver a N desde la configuración solo B / G) ha recibido 2 "votos" con el pulgar hacia abajo.
Explique por qué no es una buena sugerencia.

Digamos que el wifi en sí se cae durante una hora debido a circunstancias externas o ambientales. Mi (s) nodo (s) cambian a N y se vuelven altamente inestables nuevamente (mi aplicación es sensible a los reinicios; wifi no tiene que estar allí el 100% del tiempo, pero el nodo en sí debería estar operativo todo el tiempo).

Querría una configuración para mis nodos que evite la inestabilidad y nunca conectarme a N lo hace por mí en este momento.

Al mover esto a la configuración principal, recomiendo que esta opción se envíe ENCENDIDA de manera predeterminada.

Como solución, podríamos enviar esto en modo alternativo (B / G-then-N) de forma predeterminada con la posibilidad de conmutar solo a B / G o B / G / N.

En cuanto a la solución real para 2.5.0, intente esto:

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

Tengo más de 120 nodos que se ejecutan en GN (mega-20190202) sin ningún problema. Todos informan estar conectados a N

¿Cómo se actualizan más de 120 nodos en un plazo aceptable?
"... sin problemas en absoluto ..." ¿Verificó el tiempo de actividad de cada nodo y cuál es?
¿Son todos iguales desde el último reinicio previsto?

Los tiempos de actividad cuentan los días y todos tienen 0 reconexiones. Hace meses que nunca tuve problemas con la conectividad, excepto cuando desactivé PMKID en los AP. Probablemente el núcleo más nuevo se volvió más exigente con la configuración de wifi o no sé qué ... También ejecuto todos aquellos con fuentes de alimentación de 2A. Planeamos implementar en el próximo mes 80 esp8266 más. Por cierto, si @ TD-er quieres un acceso para echar un vistazo a la configuración en particular, estoy feliz de dártelo. Realmente quiero que ESPEasy prospere, nos ha ayudado mucho.

Editar: @ chunter1 los actualizo usando scripts por lotes

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

@ jimmys01 Recientemente compré un Mikrotik yo mismo, para poder probar cosas.

Y solo un aviso sobre las compilaciones principales 2.5.0.
En las próximas compilaciones nocturnas, las compilaciones 2.5.0 no están incluidas, ya que hay un error en el núcleo 2.5.0 que hace que el servidor web deje de responder y deje que el nodo se bloquee.
Tan pronto como se solucione, habrá compilaciones centrales 2.5.0 nuevamente.
En la última compilación nocturna, se incluye un núcleo alfa 2.6.0, que es esencialmente el código más reciente del github de la biblioteca principal para que pueda verlo usted mismo.

Obtuve el 2.6.0 con B / G solo ejecutándose desde 4 días en dos módulos y el primero se reinició.
El motivo del reinicio fue el habitual "perro guardián de hardware".
Lo que observo, dado que el modo "B / G" solo está activo, es un tiempo de ejecución de 3-5 días antes de que se produzca un reinicio.

Quizás también compare la cantidad de desconexiones de wifi, ya que esas desconexiones parecen estar relacionadas con los bloqueos.

Ambos módulos se encuentran en el sótano, a solo 2..3 m de distancia del Mikrotik AP.
Acabo de comprobar el segundo módulo que ejecuta la misma versión de FW y muestra 0 reconexiones y 4d02h de tiempo de actividad (sin reiniciar desde que parpadeó).
Creo que el otro módulo, que hizo el reinicio. también tuvo 0 reconexiones antes de reiniciar.

Respecto a las tareas configuradas en los dos módulos de prueba:
El módulo que se reinició tiene 12 sensores DS18B20 configurados que envían su valor cada 120 segundos a un servidor FHEM.
El módulo que no se reinició hasta ahora solo tiene dos gpios configurados que también envían su valor cada 120 segundos al mismo servidor FHEM.

Entonces, AP (Mikrotik) es el mismo, la distancia (2..3 mm) es el mismo, el servidor FHEM es el mismo - solo el módulo con los 12 sensores de temperatura definitivamente se reinicia con más frecuencia que el que tiene los 2 gpios.

en mis nodos, esto sucede principalmente cuando fhem es demasiado lento para responder o no es accesible porque definí un reintento máximo de 100 y luego los nodos se reinician (que también muestra un reinicio manual).

en mis nodos, esto sucede principalmente cuando fhem es demasiado lento para responder o no es accesible porque definí un reintento máximo de 100 y luego los nodos se reinician (que también muestra un reinicio manual).

¿Por qué deberían reiniciarse sus nodos cuando los reintentos superan los 100?
(He configurado los reintentos en 0 para la prueba)

herramientas -> avanzado -> umbral de falla de conexión

para asegurarse de que si el wifi en los módulos se ahoga por alguna razón, se reinicia después de un tiempo ...

Ahh con "reintentos" te refieres al "Umbral de falla de conexión:" no al "Máximo de reintentos:" en la configuración del controlador de FHEM.
Establecí el umbral de falla de conexión en 0.

Por cierto: por primera vez tuve un nodo que se atascó en el problema de tiempo de espera de 4WHS a pesar de que "solo B / G" estaba activo ... nunca antes había tenido eso hasta ahora (autocompilado, núcleo 2.5.0) ... Seguiré viendo esto, si esto fue solo una coincidencia ...

Tenga en cuenta que muy pronto habrá un núcleo 2.5.1 que revertirá el SDK usado a SDK2.2.1, ya que hay muchos problemas con SDK3.0.0
Esto también puede cambiar la forma en que los nodos reaccionan en wifi y tal vez sea comparable al núcleo 2.4.2 nuevamente.
No estoy seguro de las correcciones incluidas en el núcleo 2.5.0 que pueden solucionar algunos otros problemas que enfrentamos.

@ chunter1 Acerca de los nodos que tienes.
Parece que el que se reinició estaba enviando muchos más mensajes al controlador, por lo que estadísticamente hablando, tiene una mayor probabilidad de intentar enviar algo que se detiene en algún lugar del proceso.

@ clumsy-stefan ¿Puedes probar el código actual en Github? (o la última versión)

He realizado algunos cambios en cómo realizar la actividad relacionada con la red.

¿Te refieres a este?

ESP_Easy_mega-20190227_test_core_260_sdk3_alpha_ESP8266_4M.bin

Casi cualquier construcción de anoche.
También agregué una versión "normal" para el núcleo 2.6.0 usando SDK2.
Core 2.6.0 SDK2 ahora se está ejecutando en varios nodos y solo ha tenido un perro guardián de HW en uno de ellos que tiene recursos excepcionalmente bajos (ejecutando muchos complementos de memoria alta) y también el que tiene la memoria flash probablemente desgastada (debería deseche ese ya que ha tenido miles de actualizaciones de firmware)

@ TD-er compilé e instalé desde git hace aproximadamente 6 horas en 2 nodos de prueba ... pero como todavía tengo un acceso a Internet muy limitado, probablemente solo pueda informar en 24 horas, así que ...

He estado probando el último firmware con "modo Force B / G" con el enrutador Mikrotik y hasta ahora parece funcionar de manera estable. Informaré de vuelta.

@ TD-er Una pregunta: ¿Cuál es la regla para el retroceso al modo N cuando se establece "Forzar modo B / G"?

@ giig1967g
Si no pudo conectarse más de 10 veces al AP con _B / G only_, volverá al modo BGN predeterminado.

Así que esto deja la posibilidad de que se conecte en modo N si el AP estuvo fuera de línea por algún tiempo.
Si esto parece ser un problema real, puedo intentar configurarlo para que solo lo haga cada décimo intento, pero luego debo asegurarme de que también lo intentará cuando se intente el ssid alternativo.

Hola @ TD-er
Creo que la alternativa es una mala idea.
Mire este escenario: tengo mi unidad forzada al modo B / G funcionando felizmente con mi Mikrotik.
Por alguna razón, mi Mikrotik se desconecta (actualizar, reiniciar, lo que sea).
Siempre que el mikrotik vuelva a aparecer, el ESP se conectará en modo N y pierdo la estabilidad de la unidad.

En otras palabras, si configuro el modo Force B / G y la conexión falla, entonces debería convertirse en un AP (192.168.4.1), pero no debería volver al modo N. La posibilidad de reserva crea una falsa expectativa para el usuario.

No me malinterpretes, el respaldo fue bueno para probar la validez del cambio, pero ahora que se ha demostrado que resuelve el problema (al menos el mío hasta ahora), el respaldo debería eliminarse.

Estoy de acuerdo con el comentario de @ chunter1 : https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment -462295204

Entonces, ¿qué piensas sobre el próximo escenario?
Tan pronto como sea posible conectarse a los AP dados usando solo B / G, se establecerá una bandera adicional para no proporcionar más respaldo.
Si algunas de estas configuraciones (solo B / G u otras configuraciones de AP) cambian, la alternativa se habilitará nuevamente hasta que se conecte con éxito al AP dado.

Editar:
Con respaldo me refiero a esas configuraciones adicionales, no al "SSID de respaldo"

En otras palabras, el respaldo permanece activo solo hasta la primera conexión exitosa al AP, luego se elimina. En este caso, sería útil ver en la página del sistema el modo wifi.
Es una posible solución incluso si todavía prefiero evitar retrocesos a N si configuro Force B / G.
Entiendo la posibilidad de que el usuario cometa errores, pero luego el usuario podría escribir el SSID incorrectamente y no tener acceso a la unidad en cualquier caso ...

Otra pregunta: en la implementación actual, ¿en qué escenario la unidad se convertirá en AP?
Porque me parece que la unidad probará B / G 10 veces y luego N, pero ¿eventualmente se rendirá y se convertirá en AP?

No, el modo AP permanece activo mientras aún se prueba para conectarse a los AP dados.
Tal vez también deberíamos agregar una verificación opcional para el tiempo de actividad y solo permitir iniciar el modo AP en los primeros 10 minutos en que se inicia el nodo.
Solo para mayor seguridad y también para excluir la posibilidad de que el modo AP pueda tener un efecto en el ESP que no pueda alcanzar las redes wifi dadas.

Y debemos centrarnos en la parte "fácil" del proyecto.
Esto significa valores predeterminados adecuados y ninguna cantidad abrumadora de configuraciones ofrecidas, pero déle la opción al experto para que lo haga todo.
Esto también significa que debe haber una alternativa adecuada para el usuario menos experimentado.
Especialmente para configuraciones solo B / G. Supongo que más del 90 por ciento de las personas que comienzan con ESPeasy no son conscientes de las diferencias entre 802.11B / G / N. Por lo tanto, si experimentan problemas, que se pueden manejar muy bien mediante el uso de una alternativa, es posible que busquen otros proyectos. .
También entiendo por qué esta alternativa no debería dar una falsa sensación de "estabilidad", así que realmente entiendo por qué la implementación actual tiene margen de mejora. Pero si el "primer intento de conexión exitoso => ​​desactivar el respaldo" se hace automático, entonces también es perfecto para el usuario más experimentado. (que también comete errores estúpidos, según sé por experiencia;))

Estoy de acuerdo en que debería quedar más claro qué configuración de conexión se usa activamente.

entendido.
Entonces, el prosal es:
La unidad Boots.
El indicador N-fallback se establece en verdadero.
Si se establece FORCE B / G, intenta 10 veces conectarse al AP wifi en B / G.
Si puede conectarse, establece el flack N-fallback en falso.
Si no puede conectarse, lo intenta en modo N.

Tenga en cuenta también este escenario con Force B / G configurado: corte de energía.
El ESP y el enrutador Wifi están apagados.
Luego, vuelve la energía y el ESP funciona más rápido que el enrutador wifi.
En este caso, podría suceder que después de 10 veces el AP wifi no siga escuchando.
Entonces, la unidad probará el modo N y eventualmente tendrá éxito.
El usuario (experimentado) no sabrá que la conexión estaba en modo N y piensa que está en modo B / G con falta de estabilidad.

No quiero insistir, pero realmente estos problemas de HW y congelación han estado ocurriendo desde hace 1 año. Ahora que con la ayuda de la comunidad encontró una solución que funciona, le recomiendo encarecidamente que se asegure de que se siga aplicando. El riesgo de que un usuario inexperto establezca el "modo Forzar B / G" es menor que el de establecer el SSID incorrecto con los mismos resultados: sin acceso al punto de acceso.

SUGERENCIA:
Para asegurarse de que el usuario con menos experiencia no cometa errores, ¿por qué no agrega un botón a "Probar modo B / G"? Si tiene éxito, habilita el "modo FORCE B / G", si no, permanece deshabilitado.

En este caso, los usuarios menos experimentados sabrán lo que están haciendo y los usuarios más experimentados estarán seguros de que cuando se configura el modo ForceB / G no puede volver a N.

¿Qué piensas?

Tú podrías

No solo si arranca, sino que la opción de reserva se desactivará en la configuración y se guardará.

Okay. Entonces, una verificación manual es aún más apropiada en lugar de una verificación automática. ¿No crees?

Sí, primero agregaré una marca de verificación simple para deshabilitar las anulaciones.
Pero luego debería ser más dinámico en esto para ayudar también a nosotros, los "expertos" a cometer menos errores :)

Okay

La versión 2019_02_16 ahora se ejecutó durante 9 días sin reiniciar (forzado a B / G). Ayer comenzó a reiniciarse nuevamente. El perro guardián del hardware forzó esto dos veces.
Después de un tiempo, la unidad ya no estaba disponible. El cambio del enrutador WLAN no ayudó (lo intenté 3 veces, hasta 30 minutos). Reiniciar el ESP mediante la conmutación del fusible de potencia tampoco ayudó.
Tuve que apagar wlan nuevamente y luego conectarme al ESP a través de 192.168.4.1 directamente para obtener acceso a él

No tengo ni idea de lo que paso

@kischde ¿Qué tipo de punto de acceso estás usando?
Anoche experimenté algo similar mientras experimentaba con la instalación de un nuevo AP.
Estaba intentando instalar un MikroTik AP y todo funcionaba bien hasta que el ESP tuvo que volver a conectarse.
A través de la interfaz web del MikroTik, pude ver que el nodo estaba conectado al WiFi, pero no recibió una dirección IP.
Incluso cuando intenté conectarlo al punto de acceso de mi teléfono, pude reiniciar el ESP, pero repitió este comportamiento.
Solo cuando configuré la configuración de AP principal en otro AP, comenzó a conectarse como debería.

Tenga en cuenta que el nodo no se reinició para lograr esto.

Una cosa que está configurada como "incorrecta" en ese AP, en comparación con otro MikroTik que tengo, es que tiene la configuración de "Distancia" configurada en "adentro".
Realizaré más pruebas para ver cuál es la diferencia aquí, pero como se discutió antes, parece ser una configuración de tiempo de espera para una respuesta en un paquete.
Y puedo imaginar que el ESP tarda algún tiempo en responder a las solicitudes de DHCP, que pueden ser demasiado cortas para esta configuración.

Estoy usando un AP de Swisscom (AP del proveedor de telecomunicaciones suizo), pero tenía todos los mismos problemas escritos aquí en diferentes lugares, como los chicos con MikroTik. Así que quizás tenga el mismo chipset, pero no puedo cambiar mucho en la configuración, por ejemplo, esas configuraciones extendidas.
Antes de volver a encender también intenté conectarme con mi teléfono móvil, como lo hiciste tú, con el mismo comportamiento que tú.
Utilizo IP fija, sin DHCP
Cambié ahora al 2019_03_05 real, veré qué sucede ...

¿Cambiaste recientemente la configuración de WiFi?
Por ejemplo, punto de acceso con dirección MAC AA: AA: AA: AA: AA en la posición 1 del otro AP del SSID con dirección MAC BB: BB: BB: BB: BB: BB
Tengo la sensación de que quedan algunos ajustes en algún lugar del ESP donde no los almacenamos.

También intentaré ver en los documentos de NonOS cómo se pueden borrar de manera efectiva cuando cambiamos la configuración de WiFi.
También en mis pruebas, parece ser realmente útil tener más de 2 SSID para usar.
También intentaré agregar más campos para esto, o tal vez incluso permitir almacenar algún archivo cifrado en SPIFFS para tener una cantidad casi ilimitada de puntos de acceso WiFi almacenados.

¿Cambiaste recientemente la configuración de WiFi?

No, como solo tengo un AP, esto no era necesario en mi opinión

OKAY. Bueno saber.
Como aún no sé qué está causando esto, estoy tratando de eliminar tantas incógnitas como sea posible.
Entonces, lo único que debe hacer para que funcione nuevamente es agregar la configuración para wifi nuevamente.

No menos
Me obligué a conectarme directamente al esp a través de 192.168.4.1 (desactivé el AP)
Luego revisé todo, pero no encontré nada anormal ... Así que lo intento y reinicio mi AP, luego reinicio el ESP y se ejecuta nuevamente. Entonces, en mi opinión, solo tuve que forzar a hacer una conexión WLAN "normal / otra".
Por cierto, también lo vi conectado al AP, pero tampoco una dirección IP asignada, sin embargo, es estático

Hmm, he estado jugando un poco con él, con 5 nodos conectados al MikroTik con el que estoy jugando.

Tan pronto como configuro "Hw. Fragmentation Threshold" (simplemente 'despliegue' la opción), los nodos ESP ya no son capaces de recibir ninguna dirección IP.
El valor predeterminado de esta configuración es 256. Si lo configuro en 1600 (se ajustará a una MTU completa), todos los nodos recibirán una dirección IP y continuarán funcionando.

Esto se muestra en la interfaz de usuario de MikroTik cuando los nodos pueden comunicarse:

Y esto cuando no pueden enviar / recibir ningún dato (pero están conectados a la capa WiFi)

@ TD-er, ¿viste que hay una opción en el nuevo núcleo esp8266 llamada LWIP_FEATURES que creo que activará el reensamblaje de IP ... Probablemente eso no está definido en tu compilación?

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

también el soporte para la fragmentación de IP se establece con esto:
https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L756 -L763

Hmm, no estoy seguro de cuáles son los valores predeterminados.
¿Son los números que aparecen en la primera línea de la documentación de Doxygen los valores predeterminados?

No lo sé ... solo sé, que en el IDE de Arduino en el archivo de definición de plataformas puedes seleccionar si lo quieres incluido y definido o no.

Siempre pensé que las partes de LWIP se incluían como bibliotecas precompiladas en la distribución principal.
Entonces, es bastante difícil asegurarse de que LWIP se reconstruya usando las banderas correctas.

sí, pero depende de con cuál se vincule (de boards.txt):

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

Entonces están usando estas banderas:

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

| Etiqueta | build.lwip_lib | build.lwip_flags |
| --- | --- | --- |
| v2 Memoria inferior | -llwip2-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 Mayor ancho de banda | -llwip2-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| Memoria inferior v2 (sin funciones) | -llwip2-536 | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 Mayor ancho de banda (sin funciones) | -llwip2-1460 | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| Memoria inferior IPv6 v2 | -llwip6-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v2 IPv6 mayor ancho de banda | -llwip6-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v1.4 Mayor ancho de banda | -llwip_gcc | -DLWIP_OPEN_SRC |
| v1.4 Compilar desde la fuente | -llwip_src | -DLWIP_OPEN_SRC |

Por lo tanto, todas las versiones v2 tienen LWIP_FEATURES=1 excepto las etiquetadas como "sin funciones"

sí, pero si observa las declaraciones -l , debe usar las bibliotecas con -feat al final (al contrario de la etiqueta, un poco contraintuitivo) ...