Realmente no puedo hablar de esto desde un nivel de programación, pero me parece que por lo que he estado viendo es que, con la excepción de la dirección IP estática, cuando se configura una unidad "nueva", el wifi parece funcionar. multa. No he visto ningún problema de conexión con instalaciones "nuevas" con los últimos firmwares. Las páginas web se cargan rápido y todo parece rápido y receptivo. Es cuando intenta actualizar es cuando la mayoría de estos problemas parecen estar sucediendo. Parece que hay un problema de corrupción al actualizar a un firmware más nuevo.

También me doy cuenta de que parece que muchos firmwares compilados por el usuario tienen problemas de wifi. Solo por leer todas estas publicaciones de problemas, tengo esa impresión. Aunque podría estar completamente equivocado sobre eso. No estoy tratando de decir eso como un hecho, sino solo como una posibilidad.

No puedo hablar con MQTT porque no lo uso.

Solo mis 2 centavos valen ...

Budman1758 en 23 abr. 2018

Si se está inclinando hacia la opción 3, lo apoyo plenamente. Odiaría vernos descartar las mejoras que nos ha brindado su WiFi basado en eventos. ¿Core 2_4_x podría ser más fácil de revertir / subir?

Grovkillen en 23 abr. 2018

👍1

Desde la perspectiva de un usuario:
Seguiría adelante y usaría el nuevo Core 2.4.1 lo antes posible.
Los usuarios siempre pueden utilizar versiones anteriores.

DittelHome en 23 abr. 2018

❤1 👍1

No lo olvides, el núcleo 2.4.x soluciona algunos problemas:
El parpadeo de PWM es historia (# 1156 se corrigió con el núcleo 2.4.0)
Seriales con paquetes grandes también son fijos ...
En algún momento tenemos que hacer la transición al nuevo núcleo. Volver a 2.3.0 significa solo posponer el problema. Al final tenemos que hacer el trabajo de todos modos. Mis ESP son definitivamente mejores con 2.4.0

DittelHome en 23 abr. 2018

👍2

Como lo veo, el núcleo 2_4_x sucederá, pero tal vez no sea necesario a partir de ahora. Tomamos una mala decisión cuando seguimos adelante con la actualización del núcleo y el enfoque basado en eventos wifi al mismo tiempo. Deberíamos haberlos hecho uno tras otro. Cuando, al mismo tiempo, tuvimos una actualización en la configuración global, el problema se volvió excepcionalmente difícil de identificar. Apoyo firmemente la idea de volver a 2_3_0 durante la corrección de la estabilidad wifi + corrección de la corrupción de la configuración.

Después de eso, es de esperar que podamos lanzar la v2.1.0 y luego concentrarnos en lograr que el núcleo 2_4_x sea estable para la v2.2.0

Grovkillen en 23 abr. 2018

👍2

Después de borrar la configuración y cargar la versión de 22.04. Hasta ahora todo está funcionando. Al menos por ahora :) Solo la memoria libre no es suficiente, incluso en NORMAL. Veremos cómo sigue.

melwinek en 23 abr. 2018

Tengo que estar de acuerdo con @ Budman1758 y @melwinek : también descubrí que a partir de una unidad limpia no hay ningún problema con Wifi, IP estática y configuraciones.
El problema principal es el hecho de que para actualizar ahora necesito limpiar manualmente todas las unidades, actualizarlas y reconstruir su configuración.

giig1967g en 23 abr. 2018

👍2

Supongo que no debemos olvidar que oficialmente todavía estamos en el proceso de pasar de un R120 estable a un 2.1.0 estable y que la configuración no se convertirá entre estas dos versiones, por lo que debe comenzar desde cero de todos modos. Lo que hicimos con la actualización del núcleo 2_4_x fue crear un "punto de ruptura" una vez más. Si podemos vivir con eso, entonces no es un problema. Estoy de acuerdo en que una instalación limpia es realmente estable (al menos en NORMAL, que pruebo con más frecuencia). Y NORMAL es la única parte que realmente estará en el lanzamiento, la prueba y el desarrollo solo están en el lanzamiento nocturno de desarrollo de todos modos.

Grovkillen en 23 abr. 2018

Lo que quiero decir es: si el firmware desarrollado actual funciona y es estable en una configuración limpia, significa que no tiene nada de malo. No volvería a la 2.3 o al wifi antiguo.

giig1967g en 23 abr. 2018

👍1

Sí, te escucho y estoy un poco de acuerdo. Lo único es que creamos otro punto de ruptura que supongo que está bien, ya que todavía es beta.

Grovkillen en 23 abr. 2018

👍1

Aunque es un paso atrás que no me gusta, me temo que sería realmente mejor volver al núcleo 2_3_0 por ahora, ya que creo que pueden ocurrir algunos problemas extraños debido a la falta de memoria libre en 2_4_0.

ghtester en 23 abr. 2018

@ giig1967g Estoy de acuerdo contigo en eso. Sin embargo, creo que hay algunos problemas de corrupción. Podría ser lo que arruina el wifi en lugar de tener muchos problemas inherentes.

Budman1758 en 23 abr. 2018

Todavía hay opciones para llevar el uso de la memoria a un punto aceptable.
Creo que puedo obtener de 3 a 4 kB más de memoria en una noche de programación. (aunque es necesario cambiar todos los archivos de complementos)
Y la importación de MQTT también es algo que realmente es un problema que debería resolverse pronto.
Y el complemento Switch tiene demasiadas funciones que debería dividirse.

Lo pensaré hoy, lo que deberíamos hacer, así que agregue más sugerencias / argumentos :)

TD-er en 23 abr. 2018

👍1

@ TD-er Tienes razón con SWITCH.
La mayoría de la gente usa solo ENCENDIDO / APAGADO para interruptor / relé.
Y en este complemento hay un servo, un atenuador y probablemente algo.
Eso podría estar separado.

melwinek en 23 abr. 2018

También está manejando cosas muy específicas para MQTT y / o Domoticz. Eso no debería ser parte del complemento.

TD-er en 23 abr. 2018

@ TD-er En muchos casos, me ayudaría a compilarme, después de eliminar complementos innecesarios, en muchos casos solo necesito SWITCH, FHEM Controller, DHT.
Pero después de estas aventuras con escenarios, tengo miedo de compilarme. Especialmente después de su publicación: https://github.com/letscontrolit/ESPEasy/issues/1292

melwinek en 23 abr. 2018

¿Echaste un vistazo, cómo se realiza wifi en otros proyectos (por ejemplo, tasmota)?

Sobre la memoria: te lo dije: sonríe:
Creo que hay demasiadas funciones en el núcleo que rara vez se usan; la decisión, si se implementa una solicitud de función central, debería ser mucho más estricta, ahora es un poco como la Navidad para todos ...
Quizás una votación con un límite determinado ayudaría.

Si es posible, el núcleo debe limpiarse primero de las características que se usan con poca frecuencia (o transformarse en un complemento) y luego optimizarse. Además, uno podría pensar en interfaces adicionales para complementos, para permitir intercambiar más funcionalidades fuera del núcleo.

M0ebiu5 en 23 abr. 2018

@ M0ebiu5 De acuerdo.
Lo que debería suceder es que las nuevas funciones se desarrollarán en una rama separada, luego recopile algunas de ellas y las fusione en una rama candidata a la versión y las pruebe.
Luego, libere y combine las funciones utilizadas con la rama maestra (o rama de desarrollo, o como se le llame).

Y una cosa que aprendí es a preguntar dos veces sobre qué se observa, qué se debe observar y qué versión se usa. Eso hará las cosas mucho más claras y dará lugar a menos errores.
Parte de eso debe hacerse en el código mismo para hacer algún tipo de huella para poder ver (y registrar) qué software se usa.

Además, los complementos deberían ser solo complementos para conectar un sensor a algunos valores de salida.
Quizás los complementos que generan resultados (como pantallas) no deberían usarse igual que los de entrada.
Entonces obtenemos algo como:

Sensor para leer un dispositivo y generar medidas
Salida (¿mostrar?) A los valores actuales. Esto también puede ser algo diferente a una pantalla, por ejemplo, JSON o una imagen.
Controlador para interactuar con el mundo exterior (entrada y salida)
Reglas para procesar datos y eventos.
Notificaciones para convertir eventos en otra cosa. En realidad, suena como un controlador más elaborado.
Comandos para realizar una configuración básica o cambios / actualizaciones temporales (no persistentes) y realizar algunas acciones (por ejemplo, reiniciar)
Página web para configurarlos todos.

Pero tal rediseño requerirá bastante esfuerzo.

TD-er en 23 abr. 2018

@ TD-er, tienes razón, pero haría los cambios en pequeños pasos, porque la mayoría de las piezas funcionan de forma estable y los grandes cambios podrían poner en riesgo esta estabilidad.

Las nuevas interfaces con el núcleo son una forma posible. No influirán en el comportamiento actual y solo los utilizarán complementos nuevos o muy modificados. Llevará más tiempo transformarse en una arquitectura limpia, pero con un riesgo menor y el esfuerzo también se extenderá a lo largo del tiempo.

M0ebiu5 en 23 abr. 2018

Estoy de acuerdo en que estos cambios deben hacerse a gusto.
Es más una visión del rediseño para el futuro.

TD-er en 23 abr. 2018

Sin embargo, el nodo de 22.04 ha perdido la conexión.
Restablecer el enrutador no ayuda.
El restablecimiento del ESP ayudará, pero estoy muy lejos.
Entonces, la mejor versión en mis nodos es mega-20180410.
¿Quizás porque está en el núcleo 2.3?
¿Quizás, sin embargo, una buena solución sería volver a 2.3 por algún tiempo?

melwinek en 24 abr. 2018

No, anoche vi el problema (en el código y sucediendo en mis propias unidades).
Mis nodos no se volvieron a conectar cuando recibieron un error de 'tiempo de espera de baliza', que es una razón bastante común para desconectarse. Es un error lógico en el código, pero ya era pasada la 1:30 am y no quería arreglarlo en ese momento. Sin duda, habría pasado el tiempo de construcción nocturno para arreglarlo, así que eso ya no importaba;)

TD-er en 24 abr. 2018

👍2

relacionado: # 1064

s0170071 en 25 abr. 2018

Acabo de flashear 6 dispositivos con la versión actual ESP_Easy_mega-20180425_test_ESP8266_4096.bin.

Creo que con esta versión hemos llegado a un punto bajo absoluto.
No se pudo acceder a todos los dispositivos en la red después de unas horas.

micropet en 25 abr. 2018

Es por eso que, de una forma u otra, volveré a una versión wifi que funcione.

Quizás también deberíamos eliminar la compilación de hoy, solo para evitar que otros carguen lo mismo.

TD-er en 25 abr. 2018

Sugeriría construir ahora una nueva versión 04.25 en el núcleo 2.3.0 y reemplazar la actual :)

melwinek en 25 abr. 2018

No tengo control sobre el servidor de compilación.
y 2 versiones con el mismo número de compilación nunca es una buena idea.

Sé que @Grovkillen puede eliminar la compilación de hoy.

TD-er en 25 abr. 2018

¿Crees que debería eliminarlo @ TD-er? Mañana se construirá uno nuevo.

Grovkillen en 25 abr. 2018

Al parecer, es incluso peor en comparación con la construcción de ayer.
Así que sí, quítalo.

TD-er en 25 abr. 2018

Hecho

Grovkillen en 25 abr. 2018

Y platformio.ini también se cambia.
Entonces, pase lo que pase, la construcción de mañana no será tan mala como la de hoy.

TD-er en 25 abr. 2018

Siento pánico por aquí. No se preocupe, todavía hay esperanza.
Primero, tomemos una: cerveza: o: cervezas: Ahora,
gracias @ TD-er por avanzar tan inquieto a pesar de sus preocupaciones, gracias @Grovkillen por apoyarlo. Gracias a todos los demás también. Y gracias a todos por discutir nuevas ideas tan abiertamente.

Dicho esto, déjame decirte esto:

Según mi experiencia, no hay nada de malo con las versiones centrales más nuevas, excepto la 2.4.1, que tiene una pérdida de memoria excelente (y una solución).
Las versiones anteriores de la rama maestra hasta el momento en que se tomó la decisión de abandonar 2.0 funcionaron bastante estable con esas versiones principales. Y rápido.
Realmente deberíamos (¡énfasis en realmente!) Enfocarnos en la estabilidad. Sin características nuevas por un tiempo (a menos que mejore la estabilidad) menos ESP32 y menos búsqueda de memoria, menos aceleración, menos todo menos estabilidad. Hagamos como si planeamos volar a la luna. De verdad. Esa cosa necesita funcionar. Necesita tolerar fallas de un solo bit, reinicios, fluctuaciones de energía y estrés de temperatura.
Me refiero a la programación tolerante a fallas. Hecho. Puede ser divertido si lo enfocas en tu mente.

Que sigue ? Si fuera un desarrollador principal, optaría por esa configuración basada en json. Lo antes posible. Parece la raíz actual del mal, como lo fue hace un tiempo el servidor web que consume mucha memoria.

s0170071 en 25 abr. 2018

Siento pánico por aquí. No se preocupe, todavía hay esperanza.
Primero, tengamos un 🍺 o 🍻 Ahora,
gracias @ TD-er por avanzar tan inquieto a pesar de sus preocupaciones, gracias @Grovkillen por apoyarlo. Gracias a todos los demás también. Y gracias a todos por discutir nuevas ideas tan abiertamente.

100% de acuerdo !!!

No sé si este error ya se conoce:
Después de uno o dos días, parece que el servidor web ya no funciona. La publicación MQTT sigue funcionando.
Estoy usando la versión normal del 22/04.

DittelHome en 25 abr. 2018

@ TD-er personalmente votaré por algo nuevo como 2.4.1 para probar.

uzi18 en 25 abr. 2018

1+

micropet en 25 abr. 2018

1+

susisstrolch en 25 abr. 2018

Siento pánico por aquí. No se preocupe, todavía hay esperanza.

No es pánico, es pura frustración;)
La cosa es que realmente pruebo cosas aquí y en minutos (al menos se siente así) las compilaciones fallan incluso peor que antes.
Estoy acostumbrado a programar contra cajas negras, y también rev. diseñar esas cajas negras.
Pero esto se siente como la retroalimentación que creo que ver en los registros es completamente diferente a la realidad.
Ahora está claro que hubo varios problemas en las últimas semanas, debido a errores en las bibliotecas centrales, configuraciones corruptas y algunos cambios que hice parecían estar relacionados con algunos errores en el firmware AP.

Y mi opinión personal sobre el software es que debería ser sólido como una roca y la velocidad ocupa el segundo lugar.
Pero las últimas semanas el aumento de velocidad está bien, pero la estabilidad empeoraba día a día, sin importar lo que intenté.

Así que ahora ha llegado el momento de hacer un alto enérgico y centrarse primero en la estabilidad. Podrías llamar a eso 'pánico', pero en realidad es una especie de retroceso para concentrarte realmente en lo que está sucediendo.
Ahora sé mucho más sobre wifi que hace un mes, por lo que debería poder hacer un paquete bien diseñado. Pero eso lleva tiempo y realmente quiero llegar a un punto de estabilidad y tener un momento de tranquilidad en mi cabeza para que funcione como debería.
Y luego todavía hay mucho espacio para hacer las cosas aún más rápido, porque he visto que ik se conecta aún más rápido :)
Pero eso es para la próxima versión.

Sobre el resto de cuestiones principales:

uso de memoria
Importación / exportación JSON de configuraciones
Rediseño de importación MQTT
algunos complementos como P001-switch deberían cambiarse.
Lo que queda.

TD-er en 25 abr. 2018

❤1

para mí (y probablemente solo para mí) pasar a 2.4.1 o incluso a GIT Core no mejoró, fue todo lo contrario. Probé alrededor de 20 combinaciones diferentes de versión core, mage-commits y versiones lwIP. Regresar a 2.3.0, especialmente a lwIP 1.4, fue la única forma de hacerlo funcionar de manera estable. Pero de nuevo, solo mi visión de esto en mi entorno específico ...

Y sí, muchas gracias @ TD-er y

clumsy-stefan en 25 abr. 2018

👍1

Gracias a todos, @ TD-er resumimos bastante bien el camino a seguir.

Sobre el resto de cuestiones principales:
• uso de memoria
• Importación / exportación JSON de configuraciones
• Rediseño de importación MQTT
• Deben cambiarse algunos complementos como P001-switch.
• Lo que queda.

Y volveremos a la versión 2.3.0 para el lanzamiento de mañana y lo probaremos por un tiempo.

Grovkillen en 25 abr. 2018

La mayoría de las imágenes de mi autoconstrucción se basan en core rev. 491c9b8b (2.4.1 + x).
Lo único que veo son reinicios aleatorios con mi dispositivo Sonof de 4 canales. Desafortunadamente, es parte del control de mi estanque, por lo que no hay posibilidad de conectar una interfaz en serie para un mejor monitoreo, Syslog es bastante inutilizable, porque la información relevante se escupe antes de que WIFI esté funcionando.

Es bastante útil, siempre que utilice la biblioteca lwIP 'v2 Higher Bandwith'.
De lo contrario, verá problemas con la fragmentación de MTU con paquetes> 512Bytes (fuera de servicio, con información de ventana incorrecta).

Las ESPEasy Revs de trabajo (mis repositorios) son

cometer 3576619181926b3adff5a1a133390eb71e808ae9
Fusionar: 9038bd2 d083a58
Autor: Susis Strolch
Fecha: viernes 13 de abril 17:07:30 2018 +0200

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

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

y
cometer daf39a064d3633fe1eccfa33576fafbccd7611a7
Fusionar: 2a96218 806a275
Autor: Susis Strolch
Fecha: lun 9 de abril 09:15:52 2018 +0200

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

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

Cualquier ESPEasy después del viernes 13 de abril muestra resultados horribles (hablar no funciona), incluso cuando se borra todo el flash antes de flashear el binario (a través de Arduino IDE).

Entonces, sugiero ir con 2.4.1 (o posterior) y pulir ESPEasy (WIFI y config).
El núcleo en sí parece estar bien hasta ahora.

susisstrolch en 25 abr. 2018

jajaja @ Viernes 13, un día desafortunado de hecho ..
Entonces, ¿qué es "pulir ESPEasy (WIFI y config)". ?
¿Una rama diferente ..?
Polonia también conocido como polaco o pulido como en buff & shine, ja

Oxyandy en 26 abr. 2018

😄1 👎1

@susisstrolch ¿Cómo puedo detectar errores como este?
"Problemas con la fragmentación de MTU con paquetes> 512Bytes (fuera de servicio, con información de ventana incorrecta)".

Oxyandy en 26 abr. 2018

Simplemente envíe una solicitud preparada para un servidor web espeasy, con un encabezado adicional con un mínimo de 512 caracteres

uzi18 en 26 abr. 2018

👍1

@Oxyandy : ejecutando tcpdump en mi servidor FHEM y analizando con WireShark, encontré que los últimos 512 bytes de una respuesta JSON de ~ 700 bytes se enviaron primero, seguidos del encabezado HTTP.
Y esos dos paquetes donde simplemente faltaba la información de la ventana TCP.
Puede enviar más detalles a pedido ...
pulir como en buff & shine

susisstrolch en 26 abr. 2018

👍1

Para mí, la versión de 22.04.2018 con Core 2.4.1 funciona bastante bien.
sysinfo

micropet en 26 abr. 2018

¿Podrías comprobar también mi trabajo de ayer, pero luego me basé en 2.4.1?
https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability

En 2.3.0 todavía tenía problemas con la IP estática.
Aún no probé el modo AP con la página de configuración.

TD-er en 26 abr. 2018

Acabo de mostrar un wemos con tu versión
[wifi] Intento de simplificar el wifi basado en eventos).

Vesion corre .....

¿Qué debería hacer ahora?

micropet en 26 abr. 2018

Mierda, de mi última prueba (22.04.1018) 4 de 8 dispositivos colgaron después de aproximadamente 7 horas.

micropet en 26 abr. 2018

¿Supongo que no hay registro? :(
¿Los nodos se bloquearon (se bloquearon) o simplemente no se volvieron a conectar?
¿Responden al ping y, por lo tanto, solo el servidor web está desactivado o demasiado ocupado (la reconexión de MQTT requiere muchos recursos)?

TD-er en 26 abr. 2018

Mientras tanto, cuelga 5 dispositivos.
No tengo un registro. No se puede acceder al servidor web. Ping tampoco funciona.

simplemente están muertos.

micropet en 26 abr. 2018

Realmente deberías intentar registrarlo. Podría darnos algunos consejos útiles.

Grovkillen en 26 abr. 2018

Registro la versión de Gijs. Ha estado funcionando durante 55 minutos. :)

micropet en 26 abr. 2018

¡Oh, puedo vencer eso! Tengo 12 dispositivos que se ejecutan entre 45 y 263Min en la versión de Gijs (con esp core de GIT) 😀 y todavía todos están contentos ...

clumsy-stefan en 26 abr. 2018

Sí, los tiempos han cambiado.
En el pasado, mis dispositivos funcionaban durante semanas.

Hoy soy feliz cuando trabajan unas horas. :)

micropet en 26 abr. 2018

😄1

Uno de mis dispositivos en casa todavía está ejecutando la compilación que hice en 20171231 y está pasando a 60 días de tiempo de actividad hoy.

Entonces sé lo que quieres decir :(

TD-er en 26 abr. 2018

Entonces, tomemos la versión 2017123, luego podemos enfocarnos en otras cosas. :)

micropet en 26 abr. 2018

👍1

micropet en 26 abr. 2018

Oye, ¿por qué no tomar esa versión de 60 días, etiquetarla con 2.0 y escribir algunas viñetas sobre problemas conocidos (no faltan características)?

s0170071 en 26 abr. 2018

👍2

@ s0170071 ¿realmente necesitamos un 75% de producto funcional y muchos problemas resueltos después del lanzamiento?

uzi18 en 26 abr. 2018

Quizás no hay necesidad de volver tan lejos ... Esto es del último reinicio manual:

Tiempo de actividad: 21 días 3 horas 32 minutos
Carga: 32% (LC = 6281)
Memoria libre: 14328 (13392 - parseTemplate3)

ghtester en 26 abr. 2018

6 dispositivos han estado funcionando durante 5 horas, un nuevo récord.

micropet en 26 abr. 2018

Eso es más de 30 horas ya;)

TD-er en 26 abr. 2018

Ahora tengo casi todos (12+) dispositivos ejecutándose en los cambios de @ TD-er desde tonigt. Todos los Wemos D1 Mini con una variedad de sensores y relés conectados (todos diferentes). La mayoría de ellos tienen ahora más de 10 horas de actividad. Voy a mostrar los últimos también ahora.
Tuve dos o tres reinicios espontáneos de uno o dos dispositivos, pero esto también podría deberse a complementos o sensores defectuosos (también uso algunos complementos de desarrollo e incluso cambié la configuración para admitir 24 tareas y usar esp GIT core, algunos incluso sin borrar el config primero). ¡Pero siempre volvían a subir y se conectaban a la red con éxito!

Entonces, para mí, esta es la versión más estable que tuve hasta ahora. similar a lo que tenía antes del núcleo 2.4.0.

Por lo tanto, votaría para fusionar los cambios de @ TD-er de esta noche, probarlo y seguir adelante ... Pero eso es solo MHO ...

¡¡Y gracias a @ TD-er por la rápida corrección de errores (prueba) !! ¡Para mí funcionó!

clumsy-stefan en 26 abr. 2018

👍1

También reinicié un dispositivo, pero se reconectó de inmediato.
Todos los dispositivos son Wemos D1 mini.

He ejecutado la versión de prueba aquí con 71 complementos.
En los dispositivos hay casi solo BME280, Pir, MH-Z19 y un sensor de polvo y algunos Leds.

El servidor web reacciona muy rápido.
Por el momento estoy muy satisfecho con esta versión y Core 2.4.1.

micropet en 26 abr. 2018

Tal vez ya se sepa (si es así, ignórelo)
He instalado un ESP pro mini con ESP_Easy_mega-20180422_normal_ESP8266_4096.bin (core 2.4.0).
¡Está funcionando desde hace 3 días!
La GUI ya no es accesible, solo después del arranque en frío. (testeto con otro esp)
El ping está bien, la publicación mqtt también funciona, el conmutador GPIO sobre http también funciona.
El "único" problema, la interfaz gráfica de usuario no es accesible.
En otras palabras, el ESP funciona a ciegas, todo está bien, solo la GUI no responde.
Después de escribir la ip en el navegador, obtenga:

ily: sans-serif; tamaño de fuente: 12pt; margen: 0px; relleno: 0px; tamaño de caja: caja de borde; } h1 {tamaño de fuente: 16pt; color: # 07D; margen: 8px 0; font-weig190; color: # 07D; } .button {margin: 4px; relleno: 4px 16px; color de fondo: # 07D; color: #FFF; decoración de texto: ninguna; radio del borde: 4px; borde: 190 190 ativo; cursor: puntero; tamaño de fuente: 12pt; -webkit-user-select: ninguno; -moz-user-select: ninguno; -ms-u

He habilitado el registro con mi segundo dispositivo después del reinicio en frío, después de que el dispositivo deje de responder, informará el registro aquí, si lo desea.

DittelHome en 26 abr. 2018

¿También podría registrar el uso de la memoria? Solo para ver si hay alguna fuga de memoria en 2.4.1 según lo informado por algunos.

TD-er en 26 abr. 2018

Sí, exactamente lo mismo que tengo con la versión del 22.04.2018.
El dispositivo está funcionando pero no se puede acceder al servidor web.

micropet en 26 abr. 2018

Intentaré registrarlo.
Parece constante.

Mem libre: | 9792 (9008 - enviar bloqueo de contenido)

micropet en 26 abr. 2018

¿Te refieres a sysheap?

unbenannt

micropet en 26 abr. 2018

@ uzi18 no puedes tener ambos, vanguardia y estabilidad. La versión de 60 días es estable, ¿verdad?

s0170071 en 26 abr. 2018

@ TD-er Si deja la ventana Reglas abierta durante unos minutos, todas las reglas desaparecerán.

micropet en 26 abr. 2018

¿Eso es con 2.3.0?

TD-er en 26 abr. 2018

Tengo 2.4.1

micropet en 26 abr. 2018

Hola,
Estoy probando 20180426. Funciona pero es muy lento en comparación con 20180424.
Para mí, el núcleo 2.4.0 funcionaba perfectamente bien y estable.
Con la nueva versión, MQTT tardó más de 1 minuto en conectarse, mientras que la versión anterior fue la mitad del tiempo.
¿Tengo suerte con el núcleo 2.4.0? ¿O es solo una cuestión de configuración?

giig1967g en 26 abr. 2018

Encuentro la versión de @ TD-er de ayer con Core 2.4.1 extremadamente rápida.

Después de conectar la tensión, solo se necesitan unos segundos para acceder a la interfaz web.
Los mensajes MQTT llegan de inmediato.

micropet en 26 abr. 2018

solo para los interesados. Estoy rastreando CPU, memoria y RSSI. Adjunto un gráfico de todas las unidades. Puede ver claramente el uso de la memoria, cuando realicé la actualización al núcleo 2.4.x. Sin embargo, la memoria parece ser estable (por ejemplo, sin fugas) ...
Los dispositivos 1-11 y 16 están "en uso" con sensores, etc. los otros son simplemente D1 sin nada adjunto.

clumsy-stefan en 26 abr. 2018

Hola @micropet : ¿cómo puedo usar la versión de ayer con el núcleo 2.4.1?

Estoy empezando a pensar que tal vez Wemos sea más estable que SONOS.
Yo también uso Wemos

giig1967g en 26 abr. 2018

Con:
https://github.com/TD-er/ESPEasy/commits/bugfix/wifi_stability
y en platformio:
[core_2_4_1]
plataforma = [email protected]

micropet en 26 abr. 2018

@micropet y @ TD-er: Acabo de compilar la rama de estabilidad wifi con el núcleo 2.4.1.
GUAU. Increíble rápido.
Lo dejará funcionando durante los próximos 3 días e informará. Contiene reglas bastante complejas ...
Por el momento: 7 segundos para conectarse a MQTT en comparación con 60 con la versión 2.3.0 20180426.

Veo algunas reconexiones en MQTT Import.

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

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

giig1967g en 26 abr. 2018

@ giig1967g ¿ Alguna posibilidad de que puedas hacer un archivo bin para que yo pueda descargar? Versión 4meg? Todavía estoy aprendiendo el proceso de compilación ...

Budman1758 en 26 abr. 2018

firmware.zip

micropet en 26 abr. 2018

👍1

@ giig1967g, como dije, extremadamente rápido y también parece estable.

Ahora tuve una reconexión en 7 horas.

micropet en 26 abr. 2018

@ giig1967g La ejecución de IP estática todavía tiene algunos problemas con mi nuevo código.
Especialmente cuando se ejecuta con MQTT.
DHCP parece estar funcionando bien.

Mañana va a ser un día muy ajetreado para mí, ya que es "Día del Rey" y la familia real estará en Groningen. También me invitan a estar allí para -quizás- contarle al rey sobre nuestros problemas aquí.
Así que me iré a la cama ahora y mi sugerencia es no fusionar el código hoy con la rama principal. Mañana continuaremos con el desarrollo y haremos el mejor código de conexión wifi posible :)

TD-er en 26 abr. 2018

ok, encontré un problema tanto en 20180426 (2.3.0) como en WifistabilityBranch (2.4.1).
Si apago el enrutador y luego lo vuelvo a encender, la unidad no se vuelve a conectar a Wifi a pesar de que escribe en serie "Wifi # Connected". La unidad funciona (en serie y las reglas están bien) pero no hay conexión WiFi, por lo que no hay interfaz web.

giig1967g en 26 abr. 2018

@ TD-he, hagámoslo. Saludos al Rey, tal vez tenga otra idea. :)
Y buenas noches.

micropet en 26 abr. 2018

@ TD-er: buena suerte con sus problemas de la vida real ...

giig1967g en 26 abr. 2018

👍2

Algunos aquí, si desconecto WIFI durante 0,2 segundos:

29113846: ACT: timerSet, 1,60
29115651: MQTT: Conexión perdida
29115652: EVENTO: MQTT # desconectado
29115689: MQTT: No se pudo conectar al intermediario
29115690: EVENTO: WiFi # desconectado
29115706: WIFI: ¡Desconectado! Razón: '(1) No especificado' Conectado durante 8h04m <-------- !!
29116189: MQTT: No se pudo conectar al intermediario
29116939: MQTT: No se pudo conectar al intermediario
29117860: WD: Tiempo de actividad 485 ConnectFailures 6 FreeMem 16416
29117881: MQTT: No se pudo conectar al intermediario
29117938: MQTT: No se pudo conectar al intermediario
29119189: MQTT: No se pudo conectar al intermediario
29120689: MQTT: No se pudo conectar al intermediario
29120736: DS: Temperatura: 19,94 (28-ff-b8-ea-b4-16-3-ed)
29120738: EVENTO: DS18b20 # Temperatura = 19.94
29122440: MQTT: No se pudo conectar al intermediario
29124440: MQTT: No se pudo conectar al intermediario
29126441: MQTT: No se pudo conectar al intermediario
29128442: MQTT: No se pudo conectar al intermediario

micropet en 26 abr. 2018

@ giig1967g
Puede buscar la función para iniciar / detener el servidor web y agregar return; en la primera línea de esa función.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585

Supongo que hay algún problema al llamar a la función 'gotIP' cuando se usa una IP estática.
Esa es también la razón de la inestabilidad al ejecutar MQTT + IP estática.

TD-er en 26 abr. 2018

Pero eso es probablemente para @ TD-er un poquito. :)

micropet en 26 abr. 2018

Hm, no estoy mirando a través.
Creo que será mejor que lo hagas mañana.
Además, trabajo aquí con DHCP.

micropet en 26 abr. 2018

Me parece que la estabilidad con mi hardware siempre es 'mejor' (no perfecta) con las compilaciones de núcleo 2.3.0

probado 2.4.0 y 2.41 - son peores ...

0403 mega normal: parece que funciona y versiones anteriores.
Cualquiera que todavía tenga problemas como yo puede probar 0403 por favor ..
@susisstrolch & @ uzi18 - gracias a ambos por sus respuestas ... Tengo una mejor idea de cómo puedo ver las comunicaciones ahora - el adaptador Wireshark y USB wifi 2.4g funcionará, tengo suficiente
Gracias

Oxyandy en 26 abr. 2018

El mío está funcionando casi 17 horas ahora. Conexión única

Grovkillen en 27 abr. 2018

actualizar desde mis unidades (nombre | tiempo de actividad en minutos | último disco. motivo | wifi conectado en ms):
wemos_mini_01_sysinfo | 1220 | 200 | 6462869
wemos_mini_02_sysinfo | 1223 | 1 | 19359544
wemos_mini_03_sysinfo | 657 | 1 | 1018597
wemos_mini_04_sysinfo | 1078 | 201 | 439668
wemos_mini_05_sysinfo | 650 | 6 | 9194816
wemos_mini_06_sysinfo | 927 | 1 | 955432
wemos_mini_07_sysinfo | 1142 | 1 | 14078412
wemos_mini_08_sysinfo | 730 | 1 | 7848454
wemos_mini_09_sysinfo | 1005 | 1 | 5536489
wemos_mini_10_sysinfo | 550 | 201 | 465734
wemos_mini_11_sysinfo | 662 | 4 | 15658520
wemos_mini_12_sysinfo | 1211 | 1 | 17915701
wemos_mini_13_sysinfo | 1211 | 1 | 17896590
wemos_mini_14_sysinfo | 1210 | 1 | 17882406
wemos_mini_15_sysinfo | 753 | 1 | 58904600
wemos_mini_16_sysinfo | 1197 | 1 | 17210855

un reinicio de la unidad 10 (también podría estar relacionado con complementos). todas las unidades con controlador DHCP y FHEM, así como actualizaciones de estado JSON regulares (llamadas a través de HTTPMOD desde fhem).
servidor web en todos ellos todavía en ejecución y muy receptivo. Sin embargo, nunca usé static-ip o setup-page.

entonces para mí esta parece ser una versión bastante estable.

como estoy casi desconectado los próximos 4 días, veré cuántos siguen vivos la semana que viene 😃

¡Oh, y saludos al rey! espero que a él también le guste IoT 😀

clumsy-stefan en 27 abr. 2018

@ torpe-stefan esta versión? https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability
y que nucleo
¿Ha intentado reiniciar el enrutador?

melwinek en 27 abr. 2018

@melwinek git commit: d582cab938f041f622f2d4d8016b3d4bada55580 from esp8266 master branch (por lo que el último compromiso en la rama master del desarrollo del núcleo).

clumsy-stefan en 27 abr. 2018

@ torpe-stefan core 2.3.0, 2.4.0 o 2.4.1?

melwinek en 27 abr. 2018

última confirmación de GIT! (así que Issume es el núcleo 2.4.1+)

clumsy-stefan en 27 abr. 2018

No puedo encontrar este compromiso.
La última es: https://github.com/letscontrolit/ESPEasy/commit/d780f1a07fdcd4eec394a0677866c2a9778eb696
¿Puede proporcionar un enlace?

melwinek en 27 abr. 2018

@ clumsy-stefan, entiendo, escribiste git hasta la médula.
¿Qué compromiso de ESPEasy compila?

melwinek en 27 abr. 2018

ESPEasy commit f9be283 desde https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability branch
esp8266 comete d582cab desde https://github.com/esp8266/Arduino

clumsy-stefan en 27 abr. 2018

@ TD-er:

@ giig1967g
Puede buscar la función para iniciar / detener el servidor web y agregar un retorno; en la primera línea de esa función.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585
Supongo que hay algún problema al llamar a la función 'gotIP' cuando se usa una IP estática.
Esa es también la razón de la inestabilidad al ejecutar MQTT + IP estática.

Hola, el problema no es el servidor web, es la unidad que parece estar conectada a Wifi pero no lo está. No se puede hacer ping, no se puede enviar MQTT, etc.

giig1967g en 27 abr. 2018

El último github funciona perfectamente aquí en el núcleo 2.4.1. No hay problemas de conexión, no hay fugas de miembros

ghost en 27 abr. 2018

@mvdbro ¿Utiliza un dispositivo esp32 o esp8266?

weisskopfjens en 27 abr. 2018

Utilizo ESP8266 y ESP32. Ambos funcionan bien.

Nota al margen:
Siempre usando IP estática
Usando solo los complementos que necesito (mantiene la RAM en un mínimo seguro. Creo que el conjunto predeterminado tiene muchos complementos cargados)

ghost en 27 abr. 2018

👍1

¡Estupendo! :sonrisa:
También pruebo el núcleo 2.4.1 en mi esp8266.
Estático y DHCP está funcionando.
dnsserver y el portal cautivo funciona.
ntp funciona!

weisskopfjens en 27 abr. 2018

@Feuerreiter : ¿intentó apagar y encender el enrutador para ver si la unidad se vuelve a conectar?
En mi caso, el registro dice que se volvió a conectar pero no lo hizo.

giig1967g en 27 abr. 2018

@ giig1967g Lo probaría más tarde en casa. Hice la prueba en mi coche con mi teléfono móvil como punto de acceso. ;-)

weisskopfjens en 27 abr. 2018

@mvdbro

Creo que el conjunto predeterminado tiene muchos complementos cargados

Estoy de acuerdo. Debería haber alguna preselección en los complementos, o tal vez una mejor verificación de todos ellos para no usar más memoria de la absolutamente necesaria cuando no se usan.
Y hay mucha memoria que ganar al mirar de cerca las grandes estructuras que contienen información sobre los complementos disponibles.

TD-er en 27 abr. 2018

[PlatformIO] Core actualizado a 2.4.1
1+

Creo que es una buena decisión.
No tengo problemas desde ayer por la tarde.

micropet en 27 abr. 2018

Como publiqué en otro hilo:
Para aquellos que necesitan un poco de ayuda en la construcción, acabo de crear una versión del parche que escribí hace 2 días, pero ahora con el núcleo 2.4.1:
TD-er_wifi_stability_core-2.4.1

TD-er en 27 abr. 2018

La memoria se mantiene bastante constante.
Se hunde un poco en los primeros 15 minutos.
(No se ven aquí)
19:05:33 ESP-206 / SYSHEAP 11536
19:08:34 ESP-206 / SYSHEAP 11536
19:11:36 ESP-206 / SYSHEAP 11536
19:14:37 ESP-206 / SYSHEAP 11536
19:17:40 ESP-206 / SYSHEAP 11536
19:20:42 ESP-206 / SYSHEAP 11536
19:23:45 ESP-206 / SYSHEAP 11536
19:26:47 ESP-206 / SYSHEAP 11536
19:29:50 ESP-206 / SYSHEAP 11536
19:32:52 ESP-206 / SYSHEAP 11536
19:35:54 ESP-206 / SYSHEAP 11536
19:38:57 ESP-206 / SYSHEAP 11536
19:41:59 ESP-206 / SYSHEAP 11536
19:45:01 ESP-206 / SYSHEAP 11536
19:48:04 ESP-206 / SYSHEAP 11536
19:51:06 ESP-206 / SYSHEAP 11536
19:54:09 ESP-206 / SYSHEAP 11536
19:57:11 ESP-206 / SYSHEAP 11536
20:00:13 ESP-206 / SYSHEAP 11536
20:03:16 ESP-206 / SYSHEAP 11536
20:06:17 ESP-206 / SYSHEAP 11536
20:09:29 ESP-206 / SYSHEAP 11656
20:12:19 ESP-206 / SYSHEAP 11592
20:15:21 ESP-206 / SYSHEAP 11592
20:18:23 ESP-206 / SYSHEAP 11592
20:21:24 ESP-206 / SYSHEAP 11592
20:24:25 ESP-206 / SYSHEAP 13192
20:27:27 ESP-206 / SYSHEAP 11592
20:30:30 ESP-206 / SYSHEAP 11592
20:33:31 ESP-206 / SYSHEAP 11592
20:36:34 ESP-206 / SYSHEAP 11592
20:39:36 ESP-206 / SYSHEAP 11592
20:42:39 ESP-206 / SYSHEAP 11592
20:45:40 ESP-206 / SYSHEAP 11592
20:48:43 ESP-206 / SYSHEAP 11592
20:51:45 ESP-206 / SYSHEAP 11592
20:54:48 ESP-206 / SYSHEAP 11592
20:57:50 ESP-206 / SYSHEAP 11592
21:00:52 ESP-206 / SYSHEAP 11592
21:03:54 ESP-206 / SYSHEAP 11592
21:06:56 ESP-206 / SYSHEAP 11424
21:09:58 ESP-206 / SYSHEAP 13024
21:13:01 ESP-206 / SYSHEAP 11424
21:16:03 ESP-206 / SYSHEAP 13024
21:19:06 ESP-206 / SYSHEAP 11424
21:22:08 ESP-206 / SYSHEAP 11448
21:25:10 ESP-206 / SYSHEAP 11424
21:28:13 ESP-206 / SYSHEAP 11424
21:31:15 ESP-206 / SYSHEAP 11424
21:34:18 ESP-206 / SYSHEAP 11424
21:37:20 ESP-206 / SYSHEAP 11424
21:40:22 ESP-206 / SYSHEAP 11424
21:43:24 ESP-206 / SYSHEAP 11424
21:46:27 ESP-206 / SYSHEAP 11424
21:49:28 ESP-206 / SYSHEAP 13024
21:52:31 ESP-206 / SYSHEAP 11424
21:55:33 ESP-206 / SYSHEAP 11424
21:58:36 ESP-206 / SYSHEAP 11424
22:01:38 ESP-206 / SYSHEAP 11424

micropet en 27 abr. 2018

Mientras tanto, 8 dispositivos han estado funcionando desde ayer al mediodía.
Ninguno de ellos se atascó.

No se pudo acceder a uno durante unos 15 minutos; de repente, volvió a estar en la red.
En general, un resultado agradable.

micropet en 27 abr. 2018

Muy bueno escuchar.
Esperemos que @Oxyandy también pueda compartir resultados positivos similares con la última versión que compartí.
Sus nodos fueron los más críticos al usar 2.4.x

TD-er en 27 abr. 2018

@ TD-er Morning, finalmente encontré esta publicación después de ponerme al día
0403 usando 2.4.1 fue genial toda la noche ..
Ahora parpadeando desde su último rar normal 1024 8266
se conecta al primer intento, actualiza el tiempo de inmediato, no hay errores de wifi (hasta ahora) y permanece conectado (hasta ahora),
El servidor web responde cada vez.
Necesita un poco más de tiempo para realizar pruebas, pero se ve bien

Oxyandy en 27 abr. 2018

Eso es bueno escuchar :)

Echaré un vistazo al problema de NTP informado por enviaré este código al repositorio de ESPeasy.
Esperemos lo mejor.

Sería genial si pudiéramos dejar el wifi como es y continuar con el resto.

TD-er en 27 abr. 2018

❤1 👍1

Con la esperanza de que pueda ajustar algunas cosas sobre las que proporciono comentarios, una vez que las cosas se muestren como estables nuevamente.
Voy a probar algunas pruebas específicas con su fuente wifi_stability_core-2.4.1 de Github
Y tal vez solucione mis problemas de larga data, si la fuente no ha cambiado radicalmente

Oxyandy en 27 abr. 2018

Si tiene algunas correcciones, compártalas.

TD-er en 28 abr. 2018

@ giig1967g Tengo que hacer las pruebas. Las desconexiones muy breves no suponen ningún problema. AP apagado e inmediatamente encendido. Mi mcunode se conecta si AP está de vuelta. Mi PC ya se ha conectado a otro AP.

weisskopfjens en 28 abr. 2018

También acaba de comenzar a probar con D1-Mini y BME280

ESPEasy: comete 2abec2b0bb74018ea76203886f683761796091a2
Fusionar: 16d3a9f 29f89b6
Autor: Susis Strolch [email protected]
Fecha: Sáb 28 de abril 10:26:14 2018 +0200

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

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

Núcleo: cometer 41a64707f149d01ace37c903f448d5e3f1cee5d8
Autor: Marcel Stör [email protected]
Fecha: jueves 26 de abril 01:46:17 2018 +0200

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

Personalizado.h:
`#warning" ** Uso de la configuración del archivo Custom.h * "

si está definido (ESP8266)

// habilita la actualización de Arduino OTA.
// Nota: Esto agrega alrededor de 10 kb al tamaño del firmware y 1 kb de RAM adicional.
// #define FEATURE_ARDUINO_OTA

// habilita el modo mDNS (agrega aproximadamente 6kb de ram y algunos bytes de IRAM)
// #define FEATURE_MDNS

terminara si

undef PLUGIN_BUILD_NORMAL

undef PLUGIN_BUILD_TESTING

undef PLUGIN_BUILD_DEV

definir PLUGIN_BUILD_CUSTOM

undef BUILD_UPLOADER

si está definido (BUILD_UPLOADER)

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

demás

// definir nuestros propios complementos
#define USES_P001 // Cambiar
#define USES_P002 // ADC
#define USES_P004 // Dallas
#define USES_P005 // DHT
#define USES_P013 // HCSR04
#define USES_P026 // SysInfo
#define USES_P028 // BME280
#define USES_P033 // Dummy

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

terminara si

undef BUILD_GIT

definir BUILD_GIT "2abec2b" `

susisstrolch en 28 abr. 2018

Parece que hay algunos problemas con NTP:
'
INIT: Versión de arranque: 2abec2b (ESP82xx Core 41a64707)

80: INIT: arranque en caliente n. ° 2

81: FS: Montaje ...

106: FS: Montaje exitoso, se utilizaron 76053 bytes de 957314

115: CRC: No se encontró la suma de comprobación de la memoria del programa. Verifique la salida de crc2.py

144: CRC: SecuritySettings CRC ... OK

227: INIT: RAM libre

227: INIT: I2C

227: INIT: SPI no habilitado

232: INFORMACIÓN: Complementos: 8 (ESP82xx Core 41a64707)

233: EVENTO: Sistema # Wake

241: WIFI: Establecer WiFi en STA
242: WIFI: Intento de conexión de SusiconStrolch # 0
355: EVENTO: Sistema # Arranque
364: WD: Tiempo de actividad 0 ConnectFailures 0 FreeMem 31504
3987: BMx280: BME280 detectado
5575: BME280: punto de rocío 8.03C
5576: BME280: Dirección: 0x76
5576: BME280: Temperatura: 18,49
5576: BME280: Humedad: 50,75
5576: BME280: Presión barométrica: 1010.58
5583: EVENTO: BMx280 # Temperatura = 18.49
5592: EVENTO: BMx280 # Humedad = 50,75
5597: EVENTO: BMx280 # Presión = 1010.58
5853: Zona horaria actual: Hora de inicio de DST: 2018-03-25 02:00:00 compensación: 120 min Hora de inicio de STD: 2018-10-28 03:00:00 compensación: 60 min
5853: EVENTO: No de tiempo inicializado
5862: EVENTO: Reloj # Hora = Sábado, 10:52
5866: ACT: taskvalueset 12,1,0
5872: ACT: taskvalueset 12,2, -58
5877: ACT: taskvalueset 12,3,29912
5883: ACT: taskvalueset 12,4,39164
5888: WIFI: ¡Conectado! AP: SusiconStrolch (38: 10: D5: B2: 22: 1E) Canal: 13 Duración: 3783 ms
5888: EVENTO: WiFi # ChangedAccesspoint
5894: WIFI: DHCP IP: 192.168.254.71 (D1pro-01-11) GW: 192.168.254.1 SN: 255.255.255.0 duración: 17 ms
5913: Zona horaria actual: Hora de inicio de DST: 2036-03-30 02:00:00 Desplazamiento: 120 min Hora de inicio de STD: 2036-10-26 03:00:00 Desplazamiento: 60 min
5914: EVENTO: Tiempo # configurado
5921: EVENTO: WiFi # conectado
5928: servidor web: iniciar
5935: EVENTO: Reloj # Hora = Jue, 07: 28
'
5853: Zona horaria actual: Hora de inicio del horario de verano: 2018-03-25 02:00:00
5913: Zona horaria actual: Hora de inicio de DST: 2036-03-30 02:00:00 Desplazamiento: 120 min Hora de inicio de STD:

susisstrolch en 28 abr. 2018

Ese es un código de error -1 conocido y aún se convierte en error de tiempo.

s0170071 en 28 abr. 2018

Hmm, todavía me pregunto cómo la llamada a NTP puede resultar en un -1.

@susisstrolch
¿Qué versión es esa? ESPeasy usó el valor BUILD_GIT para determinar qué se debe parchear en los archivos de configuración y tal vez también en otros archivos. Es una especie de versión interna que se utiliza para determinar los parches necesarios. (Si alguna)
cuando cambia ese valor, puede resultar en cosas extrañas.

TD-er en 28 abr. 2018

Supongo que está relacionado con UDP. No veo ninguno de mis otros dispositivos. Y viceversa.

susisstrolch en 28 abr. 2018

@susisstrolch ¿ Eso es con IP estática o con DHCP?

TD-er en 28 abr. 2018

El parcheo @ TD-er basado en BUILD_GIT es una mala idea, porque cambia en bifurcaciones, ramas y confirmaciones locales.
Debería haber algún tipo / variable diferente, puede ser BUILD_FEATURE, que controle dicho comportamiento.

susisstrolch en 28 abr. 2018

Como casi nunca reinicio mi AP, pasó desapercibido que una reconexión falla con la última fuente de github (20180428). Intenté obtener un estado interno para ver qué está pasando:

Después del arranque:
llamar a Wifi.status (): 3 significa WL_CONNECTED
variable wifiStatus: 3 significa ESPEASY_WIFI_SERVICES_INITIALIZED

Después de reiniciar AP
llamar a Wifi.status (): 3 significa WL_CONNECTED
variable wifiStatus: 0 significa ESPEASY_WIFI_DISCONNECTED

esto no cambia con el tiempo y el ESP nunca se vuelve a conectar

Me pregunto por qué la llamada Wifi.status () al núcleo todavía informa un estado 3 (WL_CONNECTED)
¿Se debe a que el wifi basado en eventos interfiere con el estado del núcleo interno?

El comportamiento es el mismo en el núcleo 2_3_0 y 2_4_1

ghost en 28 abr. 2018

Eso es con DHCP

susisstrolch en 28 abr. 2018

Y esperaría después del reinicio normal:

llamar a Wifi.status (): 3 significa WL_CONNECTED
variable wifiStatus: 1 significa ESPEASY_WIFI_CONNECTED

en vez de:
llamar a Wifi.status (): 3 significa WL_CONNECTED
variable wifiStatus: 3 significa ESPEASY_WIFI_SERVICES_INITIALIZED

ghost en 28 abr. 2018

Hmm, esa es una buena pregunta @mvdbro
Quizás el estado WL_CONNECTED nunca se actualice porque no está llamando a la función para actualizar ese estado.
Solo desde la memoria, diría que la función se llama en la biblioteca central cuando se maneja el evento "got IP".
Examinaré esa área del código de la biblioteca central.
Gracias por notarlo.

@susisstrolch Está bien, también intentaré con DHCP aquí.
Mis unidades de prueba pueden verse entre sí a través de la comunicación interna ESPeasy UDP, pero actualmente se ejecutan en IP estática, ya que eso dio la mayoría de los problemas últimamente.

TD-er en 28 abr. 2018

@ TD-er espera: comprobará si se trata de un problema central relacionado.

susisstrolch en 28 abr. 2018

@mvdbro
Aquí está el código:
https://github.com/esp8266/Arduino/blob/836c7da8cc1ad11a66e0be1f30d35a92b5317bcc/libraries/ESP8266WiFi/src/ESP8266WiFiSTA.cpp#L497 -L513

De hecho, siempre que el estado interno no se establezca en 'tengo IP', no devolverá WL_CONNECTED.

Acerca de la diferencia en los nombres de las variables entre la enumeración / define en ESPeasy y la biblioteca principal.
Los estados de la biblioteca principal no reflejan realmente el estado real, ya que puede estar conectado y no tener una IP.

TD-er en 28 abr. 2018

Puede que sea mejor mantener este hilo solo para problemas de conexión / reconexión Wifi para que esto pueda solucionarse en primer lugar.

ghost en 28 abr. 2018

Supongo que estos son los códigos efectivos utilizados:

Códigos Wifi.status ():
WL_IDLE_STATUS 0
WL_NO_SSID_AVAIL 1
WL_SCAN_COMPLETED 2
WL_CONNECTED 3
WL_CONNECT_FAILED 4
WL_CONNECTION_LOST 5
WL_DISCONNECTED 6

wifiCódigos de estado:
ESPEASY_WIFI_DISCONNECTED 0
ESPEASY_WIFI_CONNECTED 1
ESPEASY_WIFI_GOT_IP 2
ESPEASY_WIFI_SERVICES_INITIALIZED 3

ghost en 28 abr. 2018

Supongo que puede estar relacionado con el problema de conexión / reconexión wifi.
Con IP estática, simplemente no hay ningún evento para "got IP", por lo que su manejo actual puede estar incompleto, lo que está causando algunos de estos problemas.

TD-er en 28 abr. 2018

Entonces, después de reiniciar AP
llamar a Wifi.status (): 3 significa WL_CONNECTED
Esto no es correcto.

Si Wifi.status () no funciona como se esperaba, esto sería un error grave en el núcleo de arduino. ¿No debería informarse esto en su rastreador de problemas de github?

ghost en 28 abr. 2018

@susisstrolch Acabo de experimentar lo mismo. Se actualizó un dispositivo configurado en buen estado y listo. No descubrí otras unidades.

Solución: verifique la entrada del puerto UDP. (65500) La mía acababa de desaparecer. Otro reinicio y estaba funcionando.
¡Realmente deberíamos optar por la configuración basada en JSON!

s0170071 en 28 abr. 2018

@mvdbro Acabo de encontrar esto, vea la parte superior de la página 39:
https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf
Así que ahora probaré para ver si tenemos que configurar la IP (nuevamente) después de procesar el evento de conexión.

TD-er en 28 abr. 2018

¿Alguien puede probar el código en este PR: https://github.com/letscontrolit/ESPEasy/pull/1328

TD-er en 28 abr. 2018

@ s0170071 - confirmado - se modificó la configuración del puerto UDP.

susisstrolch en 28 abr. 2018

@ TD-er sobre # 1328:

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

Como puede ver, DHCP se inicia incluso cuando se establece en IP estática ...

Y aquí está mi JSON

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

susisstrolch en 28 abr. 2018

99: CRC: No se encontró la suma de comprobación de la memoria del programa. Verifique la salida de crc2.py
130: CRC: SecuritySettings CRC ... OK
211: INIT: RAM libre
211: INIT: I2C
211: INIT: SPI no habilitado
1042: INFO: Complementos: 71 [Normal] [Prueba] (ESP82xx Core 2_4_1)
1042: EVENTO: Sistema # Wake
1089: WIFI: configurar WiFi en STA
1091: WIFI: Intento de conexión SMC # 0
1103: EVENTO: Sistema # Arranque
1111: ACT: Publicar ESP-201 / IP, 0.0.0.0
1124: ACT: timerSet, 1,60
1152: WD: Tiempo de actividad 0 Fallos de conexión 0 FreeMem 20160
1183: DS: Temperatura: 20,37 (28-ff-b8-ea-b4-16-3-ed)
1184: EVENTO: DS18b20 # Temperatura = 20,37
4887: WIFI: ¡Conectado! AP: SMC (78: 8A: 20: D1: 9B: D9) Canal: 1 Duración: 3795 ms
4888: EVENTO: WiFi # ChangedAccesspoint
4910: IP: IP estática: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4911: WIFI: IP estática: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 duración: 25 ms
5009: Zona horaria actual: Hora de inicio de DST: 2018-03-25 02:00:00 compensación: 120 min Hora de inicio de STD: 2018-10-28 03:00:00 compensación: 60 min
5010: EVENTO: No de tiempo inicializado
5027: EVENTO: WiFi # Conectado
5044: servidor web: iniciar
5127: MQTT: reconexión intencional
5182: MQTT: Conectado al intermediario con ID de cliente: ESPClient_5C: CF: 7F: 0B: 68: 52
5184: Suscrito a: ESP-201 / #
5185: EVENTO: MQTT # Conectado
5846: EVENTO: Reloj # Hora = Sábado, 16:19

micropet en 28 abr. 2018

@susisstrolch Es extraño iniciar DHCP, ya que escribí un parche para él recientemente.
¿Quizás algo ha cambiado en 2.4.1?

¿Qué hiciste para obtener la información adicional de depuración?

TD-er en 28 abr. 2018

Simplemente configuré el nivel de depuración en "Depurar más" ...

susisstrolch en 28 abr. 2018

@susisstrolch También parece tener otra salida de depuración generada por la biblioteca central.
No veo eso en mi registro en el puerto serie.

Editar:
Lo encontré, Serial.setDebugOutput se llama desde Setup (). Así que un simple reinicio fue suficiente :)

TD-er en 28 abr. 2018

Aquí hay una interacción de SYSHEAP y Uptime.

sysheap

micropet en 28 abr. 2018

Tengo curiosidad por saber cómo se verá ese gráfico de sysheap después de uno o dos días.

TD-er en 28 abr. 2018

Si no falla lo veremos. :)

micropet en 28 abr. 2018

Todos los gráficos se ven diferentes: este es el dispositivo con su último cambio y una IP estática.

esp-201 sysheap

micropet en 28 abr. 2018

¿Qué versión era la tabla anterior?

TD-er en 28 abr. 2018

El primer gráfico, la versión especial tuya de anoche. Con DHCP

micropet en 29 abr. 2018

Interesante.
También agregaré algunos registros de sysheap a mis nodos.

TD-er en 29 abr. 2018

Me conecto con openHAB. También es genial con Grafana.

micropet en 29 abr. 2018

¿Debo mostrar tus confirmaciones actuales? Entonces mi gráfico se pierde en el ESP-201.

micropet en 29 abr. 2018

Supongo que las pruebas de estabilidad wifi son más importantes en este momento.

TD-er en 29 abr. 2018

Ok, lo haré.

micropet en 29 abr. 2018

OK, está en línea.

INIT: Versión de arranque: (ESP82xx Core 2_4_1)
92: INIT: arranque en caliente n. ° 2
94: FS: Montaje ...
118: FS: Montaje exitoso, se utilizaron 76806 bytes de 957314
131: CRC: No se encontró la suma de comprobación de la memoria del programa. Verifique la salida de crc2.py
162: CRC: SecuritySettings CRC ... OK
243: INIT: RAM libre
243: INIT: I2C
243: INIT: SPI no habilitado
1073: INFO: Complementos: 71 [Normal] [Prueba] (ESP82xx Core 2_4_1)
1073: EVENTO: Sistema # Wake
1120: WIFI: establezca WiFi en STA
1152: WIFI: Intento de conexión de SMC # 0
1153: IP: IP estática: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
1155: WIFI: el estado de la estación SDK difiere del estado de Arduino. Estado de SDK: 1 Estado de Arduino: 6
1172: EVENTO: Núm. De sistema de arranque
1178: ACT: NeoPixelAll, 0,0,0,0
1189: ACT: Publicar ESP-201 / IP, 192.168.0.201
1201: ACT: timerSet, 1,60
1226: WD: Tiempo de actividad 0 Fallos de conexión 0 FreeMem 20088
1257: DS: Temperatura: 20.25 (28-ff-b8-ea-b4-16-3-ed)
1259: EVENTO: DS18b20 # Temperatura = 20.25
4952: WIFI: ¡Conectado! AP: SMC (78: 8A: 20: D1: 9B: D9) Canal: 1 Duración: 3798 ms
4953: EVENTO: WiFi # Punto de acceso cambiado
4974: IP: IP estática: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4975: WIFI: el estado de la estación SDK difiere del estado de Arduino. Estado de SDK: 5 Estado de Arduino: 3
4980: WIFI: IP estática: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 duración: 24 ms
5102: Zona horaria actual: Hora de inicio de DST: 2018-03-25 02:00:00 compensación: 120 min Hora de inicio de STD: 2018-10-28 03:00:00 compensación: 60 min
5103: EVENTO: No de tiempo inicializado
5123: EVENTO: WiFi # Conectado
5140: servidor web: iniciar
5141: WIFI: el estado de la estación SDK difiere del estado de Arduino. Estado de SDK: 5 Estado de Arduino: 3
5223: MQTT: reconexión intencional
5261: MQTT: conectado al intermediario con ID de cliente: ESPClient_5C: CF: 7F: 0B: 68: 52
5264: Suscrito a: ESP-201 / #
5265: EVENTO: MQTT # conectado
5912: EVENTO: Reloj # Hora = Sol, 00: 14
31226: WD: Tiempo de actividad 1 ConnectFailures 0 FreeMem 15968

micropet en 29 abr. 2018

También amplié la información en la página sysinfo.
Se agregó un contador de reconexión y se utilizó la configuración Static / DHCP (y la versión SDK)

También se incluye una verificación de reconexión forzada, que se volverá a conectar cuando no esté conectada por un tiempo.

TD-er en 29 abr. 2018

¿Debo interrumpir WIFI durante 0,2 segundos?

micropet en 29 abr. 2018

Por favor, intente bloquearlo :)

TD-er en 29 abr. 2018

OK

micropet en 29 abr. 2018

244302: ACT: Publicar ESP-201 / IP, 192.168.0.201
244318: ACT: Publicar ESP-201 / MAC, 5C: CF: 7F: 0B: 68: 52
244331: ACT: Publicar ESP-201 / Hora, 00: 18: 18
244343: ACT: Publicar ESP-201 / Uptime, 4
244355: ACT: Publicar ESP-201 / RSSI, -62
244367: ACT: Publicar ESP-201 / SSID, SMC
244379: ACT: Publicar ESP-201 / BSSID, 78: 8A: 20: D1: 9B: D9
244391: ACT: Publicar ESP-201 / CH, 1
244406: ACT: Publicar ESP-201 / SYSHEAP, 12616
244422: ACT: timerSet, 1,60
255542: EVENTO: WiFi # desconectado
255560: WIFI: ¡Desconectado! Razón: '(1) No especificado' Conectado durante 4 m 10 s
255560: WIFI: el estado de la estación SDK difiere del estado de Arduino. Estado de SDK: 5 Estado de Arduino: 3
255571: MQTT: conexión perdida
255572: EVENTO: MQTT # desconectado
255610: MQTT: No se pudo conectar al intermediario
256110: MQTT: No se pudo conectar al intermediario
256860: MQTT: No se pudo conectar al intermediario
257860: MQTT: No se pudo conectar al intermediario
259110: MQTT: No se pudo conectar al intermediario
260610: MQTT: no se pudo conectar al intermediario
262360: MQTT: no se pudo conectar al intermediario
264360: MQTT: No se pudo conectar al intermediario
266360: MQTT: no se pudo conectar al intermediario
268360: MQTT: no se pudo conectar al intermediario
270360: MQTT: no se pudo conectar al intermediario
271226: WD: Tiempo de actividad 5 ConnectFailures 22 FreeMem 17224
271247: MQTT: No se pudo conectar al intermediario
272360: MQTT: no se pudo conectar al intermediario
274360: MQTT: No se pudo conectar al intermediario
276360: MQTT: No se pudo conectar al intermediario
278360: MQTT: No se pudo conectar al intermediario
280360: MQTT: no se pudo conectar al intermediario
282360: MQTT: No se pudo conectar al intermediario
284360: MQTT: no se pudo conectar al intermediario
286291: EVENTO: Reloj # Hora = Sol, 00: 19
286359: MQTT: No se pudo conectar al intermediario
288360: MQTT: no se pudo conectar al intermediario
290360: MQTT: no se pudo conectar al intermediario

micropet en 29 abr. 2018

Solo para esta comprobación, ¿podría dejarlo en este estado durante 4 minutos?
Reduciré el intervalo de ticker para esta verificación (actualmente es de 240 segundos)

TD-er en 29 abr. 2018

Ok, lo hago.

micropet en 29 abr. 2018

240 segundos son muy largos

micropet en 29 abr. 2018

Sí, lo sé, lo cambiaré.
Acabo de tomar la idea de este número: https://github.com/esp8266/Arduino/issues/4445

TD-er en 29 abr. 2018

nada....

432148: MQTT: No se pudo conectar al intermediario
434148: MQTT: No se pudo conectar al intermediario
436148: MQTT: No se pudo conectar al intermediario
438147: MQTT: No se pudo conectar al intermediario
440148: MQTT: No se pudo conectar al intermediario
442147: MQTT: No se pudo conectar al intermediario
444148: MQTT: No se pudo conectar al intermediario
446148: MQTT: No se pudo conectar al intermediario
448148: MQTT: No se pudo conectar al intermediario
450147: MQTT: No se pudo conectar al intermediario
451222: WD: Tiempo de actividad 8 ConnectFailures 446 FreeMem 17384
451243: MQTT: No se pudo conectar al intermediario
452148: MQTT: No se pudo conectar al intermediario
453907: EVENTO: Reloj # Hora = Sol, 00: 29
454148: MQTT: No se pudo conectar al intermediario
456148: MQTT: No se pudo conectar al intermediario
458148: MQTT: No se pudo conectar al intermediario

micropet en 29 abr. 2018

Me voy a dormir, nos vemos mañana.

micropet en 29 abr. 2018

Acabo de encontrar otro problema, posiblemente relacionado con UDP:
en una nueva unidad de restablecimiento de fábrica, use los comandos seriales
wifikey
wifissid
ahorrar

reinicie, luego vaya a la configuración avanzada y verifique ssdp. Reiniciar.
Entra en un ciclo de arranque y luego:

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

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


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

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

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

s0170071 en 29 abr. 2018

Buenos dias a todos.
Para mí, la reconexión aún no funciona.

INIT: Versión de arranque: (ESP82xx Core 2_4_1)
92: INIT: arranque en caliente n. ° 8
94: FS: Montaje ...
118: FS: Montaje exitoso, se utilizaron 76806 bytes de 957314
131: CRC: No se encontró la suma de comprobación de la memoria del programa. Verifique la salida de crc2.py
162: CRC: SecuritySettings CRC ... OK
243: INIT: RAM libre
243: INIT: I2C
243: INIT: SPI no habilitado
1073: INFO: Complementos: 71 [Normal] [Prueba] (ESP82xx Core 2_4_1)
1074: EVENTO: Sistema # Wake
1121: WIFI: establezca WiFi en STA
1153: WIFI: Intento de conexión SMC # 0
1154: IP: IP estática: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
1155: WIFI: el estado de la estación SDK difiere del estado de Arduino. Estado de SDK: 1 Estado de Arduino: 6
1173: EVENTO: Núm. De sistema de arranque
1179: ACT: NeoPixelAll, 0,0,0,0
1190: ACT: Publicar ESP-201 / IP, 192.168.0.201
1201: ACT: timerSet, 1,60
1226: WD: Tiempo de actividad 0 Fallos de conexión 0 FreeMem 20072
1258: DS: Temperatura: 19,75 (28-ff-b8-ea-b4-16-3-ed)
1259: EVENTO: DS18b20 # Temperatura = 19,75
4925: WIFI: ¡Conectado! AP: SMC (78: 8A: 20: D1: 9B: D9) Canal: 1 Duración: 3770 ms
4926: EVENTO: WiFi # ChangedAccesspoint
4947: IP: IP estática: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4947: WIFI: el estado de la estación SDK difiere del estado de Arduino. Estado de SDK: 5 Estado de Arduino: 3
4953: WIFI: IP estática: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 duración: 23 ms
5066: Zona horaria actual: Hora de inicio de DST: 2018-03-25 02:00:00 compensación: 120 min Hora de inicio de STD: 2018-10-28 03:00:00 compensación: 60 min
5066: EVENTO: No de tiempo inicializado
5087: EVENTO: WiFi # Conectado
5104: servidor web: iniciar
5104: WIFI: el estado de la estación SDK difiere del estado de Arduino. Estado de SDK: 5 Estado de Arduino: 3
5186: MQTT: reconexión intencional
5222: MQTT: conectado al intermediario con ID de cliente: ESPClient_5C: CF: 7F: 0B: 68: 52
5225: Suscrito a: ESP-201 / #
5226: EVENTO: MQTT # conectado
5906: EVENTO: Reloj # Hora = Sol, 10: 01
31227: WD: Tiempo de actividad 1 ConnectFailures 0 FreeMem 16336
47905: EVENTO: Reloj # Hora = Sol, 10: 02
61229: WD: Tiempo de actividad 1 ConnectFailures 0 FreeMem 16336
61926: DS: Temperatura: 19,75 (28-ff-b8-ea-b4-16-3-ed)
61928: EVENTO: DS18b20 # Temperatura = 19,75
61972: EVENTO: Reglas # Temporizador = 1
61983: ACT: Publicar ESP-201 / IP, 192.168.0.201
61999: ACT: Publicar ESP-201 / MAC, 5C: CF: 7F: 0B: 68: 52
62015: ACT: Publicar ESP-201 / Hora, 10: 02: 14
62030: ACT: Publicar ESP-201 / Tiempo de actividad, 1
62044: ACT: Publicar ESP-201 / RSSI, -62
62060: ACT: Publicar ESP-201 / SSID, SMC
62076: ACT: Publicar ESP-201 / BSSID, 78: 8A: 20: D1: 9B: D9
62091: ACT: Publicar ESP-201 / CH, 1
62107: ACT: Publicar ESP-201 / SYSHEAP, 13536
62120: ACT: timerSet, 1,60
67292: EVENTO: WiFi # desconectado
67310: WIFI: ¡Desconectado! Razón: '(1) No especificado' Conectado durante 1 m 2 s
67310: WIFI: el estado de la estación SDK difiere del estado de Arduino. Estado de SDK: 5 Estado de Arduino: 3
67316: MQTT: Conexión perdida
67317: EVENTO: MQTT # desconectado
67357: MQTT: No se pudo conectar al intermediario
67856: MQTT: No se pudo conectar al intermediario
68606: MQTT: No se pudo conectar al intermediario
69607: MQTT: No se pudo conectar al intermediario
70857: MQTT: No se pudo conectar al intermediario
72357: MQTT: No se pudo conectar al intermediario
74107: MQTT: No se pudo conectar al intermediario
76106: MQTT: No se pudo conectar al intermediario
78107: MQTT: No se pudo conectar al intermediario
80107: MQTT: No se pudo conectar al intermediario
82106: MQTT: No se pudo conectar al intermediario
84106: MQTT: No se pudo conectar al intermediario
86107: MQTT: No se pudo conectar al intermediario
88106: MQTT: No se pudo conectar al intermediario
90107: MQTT: No se pudo conectar al intermediario
91228: WD: Tiempo de actividad 2 ConnectFailures 30 FreeMem 17368
91250: MQTT: No se pudo conectar al intermediario
92107: MQTT: No se pudo conectar al intermediario
94107: MQTT: No se pudo conectar al intermediario
96106: MQTT: No se pudo conectar al intermediario
98107: MQTT: No se pudo conectar al intermediario
100107: MQTT: No se pudo conectar al intermediario
102107: MQTT: No se pudo conectar al intermediario
104106: MQTT: No se pudo conectar al intermediario
106107: MQTT: No se pudo conectar al intermediario
107905: EVENTO: Reloj # Hora = Sol, 10: 03
108107: MQTT: No se pudo conectar al intermediario
110107: MQTT: No se pudo conectar al intermediario
112107: MQTT: No se pudo conectar al intermediario
114107: MQTT: No se pudo conectar al intermediario
116107: MQTT: No se pudo conectar al intermediario
118107: MQTT: No se pudo conectar al intermediario
120107: MQTT: No se pudo conectar al intermediario
121228: WD: Tiempo de actividad 2 ConnectFailures 62 FreeMem 17368
121249: MQTT: No se pudo conectar al intermediario
121926: DS: Temperatura: 19,75 (28-ff-b8-ea-b4-16-3-ed)
121927: EVENTO: DS18b20 # Temperatura = 19,75
122107: MQTT: No se pudo conectar al intermediario
122905: EVENTO: Reglas # Temporizador = 1
122915: ACT: Publicar ESP-201 / IP, 0.0.0.0
122927: ACT: Publicar ESP-201 / MAC, 5C: CF: 7F: 0B: 68: 52
122939: ACT: Publicar ESP-201 / Hora, 10: 03: 15
122950: ACT: Publicar ESP-201 / Uptime, 2
122961: ACT: Publicar ESP-201 / RSSI, 0
122972: ACT: Publicar ESP-201 / SSID, -
122983: ACT: Publicar ESP-201 / BSSID, 00: 00: 00: 00: 00: 00
122994: ACT: Publicar ESP-201 / CH, 0
123005: ACT: Publicar ESP-201 / SYSHEAP, 16992
123015: ACT: timerSet, 1,60
124107: MQTT: No se pudo conectar al intermediario
126106: MQTT: No se pudo conectar al intermediario
128107: MQTT: No se pudo conectar al intermediario
130107: MQTT: No se pudo conectar al intermediario
132107: MQTT: No se pudo conectar al intermediario
134107: MQTT: No se pudo conectar al intermediario
136107: MQTT: No se pudo conectar al intermediario
138107: MQTT: No se pudo conectar al intermediario
140107: MQTT: No se pudo conectar al intermediario
142107: MQTT: No se pudo conectar al intermediario
144107: MQTT: No se pudo conectar al intermediario
146107: MQTT: No se pudo conectar al intermediario
148107: MQTT: No se pudo conectar al intermediario
150107: MQTT: No se pudo conectar al intermediario
151228: WD: Tiempo de actividad 3 ConnectFailures 94 FreeMem 17368
151249: MQTT: No se pudo conectar al intermediario
152107: MQTT: No se pudo conectar al intermediario
154107: MQTT: No se pudo conectar al intermediario
156107: MQTT: No se pudo conectar al intermediario
158107: MQTT: No se pudo conectar al intermediario
160107: MQTT: No se pudo conectar al intermediario
162107: MQTT: No se pudo conectar al intermediario
164107: MQTT: No se pudo conectar al intermediario
166107: MQTT: No se pudo conectar al intermediario
167905: EVENTO: Reloj # Hora = Sol, 10: 04
168107: MQTT: No se pudo conectar al intermediario
170107: MQTT: No se pudo conectar al intermediario
172107: MQTT: No se pudo conectar al intermediario
174106: MQTT: No se pudo conectar al intermediario
176106: MQTT: No se pudo conectar al intermediario
178107: MQTT: No se pudo conectar al intermediario
180107: MQTT: No se pudo conectar al intermediario
181228: WD: Tiempo de actividad 3 ConnectFailures 126 FreeMem 17368
181250: MQTT: No se pudo conectar al intermediario
181926: DS: Temperatura: 19,75 (28-ff-b8-ea-b4-16-3-ed)
181927: EVENTO: DS18b20 # Temperatura = 19,75
182107: MQTT: No se pudo conectar al intermediario
183905: EVENTO: Reglas # Temporizador = 1
183915: ACT: Publicar ESP-201 / IP, 0.0.0.0
183927: ACT: Publicar ESP-201 / MAC, 5C: CF: 7F: 0B: 68: 52
183938: ACT: Publicar ESP-201 / Hora, 10: 04: 16
183950: ACT: Publicar ESP-201 / Uptime, 3
183961: ACT: Publicar ESP-201 / RSSI, 0
183972: ACT: Publicar ESP-201 / SSID, -
183983: ACT: Publicar ESP-201 / BSSID, 00: 00: 00: 00: 00: 00
183994: ACT: Publicar ESP-201 / CH, 0
184005: ACT: Publicar ESP-201 / SYSHEAP, 16992
184015: ACT: timerSet, 1,60
184107: MQTT: No se pudo conectar al intermediario
186106: MQTT: No se pudo conectar al intermediario
188107: MQTT: No se pudo conectar al intermediario
190106: MQTT: No se pudo conectar al intermediario
192107: MQTT: No se pudo conectar al intermediario
194106: MQTT: No se pudo conectar al intermediario
196106: MQTT: No se pudo conectar al intermediario
198106: MQTT: No se pudo conectar al intermediario
200106: MQTT: No se pudo conectar al intermediario
202106: MQTT: No se pudo conectar al intermediario
204106: MQTT: No se pudo conectar al intermediario
206106: MQTT: No se pudo conectar al intermediario
208106: MQTT: No se pudo conectar al intermediario
210106: MQTT: No se pudo conectar al intermediario
211228: WD: Tiempo de actividad 4 ConnectFailures 158 FreeMem 17368
211249: MQTT: No se pudo conectar al intermediario
212106: MQTT: No se pudo conectar al intermediario
214106: MQTT: No se pudo conectar al intermediario
216106: MQTT: No se pudo conectar al intermediario
218106: MQTT: No se pudo conectar al intermediario
220106: MQTT: No se pudo conectar al intermediario
222106: MQTT: No se pudo conectar al intermediario
224106: MQTT: No se pudo conectar al intermediario
226106: MQTT: No se pudo conectar al intermediario
227905: EVENTO: Reloj # Hora = Sol, 10: 05
228107: MQTT: No se pudo conectar al intermediario
230107: MQTT: No se pudo conectar al intermediario
232107: MQTT: No se pudo conectar al intermediario
234107: MQTT: No se pudo conectar al intermediario
236106: MQTT: No se pudo conectar al intermediario
238106: MQTT: No se pudo conectar al intermediario
240106: MQTT: No se pudo conectar al intermediario
241228: WD: Tiempo de actividad 4 ConnectFailures 190 FreeMem 17368
241249: MQTT: No se pudo conectar al intermediario
241925: DS: Temperatura: 19,75 (28-ff-b8-ea-b4-16-3-ed)
241927: EVENTO: DS18b20 # Temperatura = 19,75
242107: MQTT: No se pudo conectar al intermediario
244106: MQTT: No se pudo conectar al intermediario
244908: EVENTO: Reglas # Temporizador = 1
244918: ACT: Publicar ESP-201 / IP, 0.0.0.0
244930: ACT: Publicar ESP-201 / MAC, 5C: CF: 7F: 0B: 68: 52
244942: ACT: Publicar ESP-201 / Hora, 10: 05: 17
244953: ACT: Publicar ESP-201 / Uptime, 4
244964: ACT: Publicar ESP-201 / RSSI, 0
244975: ACT: Publicar ESP-201 / SSID, -
244986: ACT: Publicar ESP-201 / BSSID, 00: 00: 00: 00: 00: 00
244997: ACT: Publicar ESP-201 / CH, 0
245008: ACT: Publicar ESP-201 / SYSHEAP, 16992
245018: ACT: timerSet, 1,60
246107: MQTT: No se pudo conectar al intermediario
248106: MQTT: No se pudo conectar al intermediario
250106: MQTT: No se pudo conectar al intermediario
252106: MQTT: No se pudo conectar al intermediario
254106: MQTT: No se pudo conectar al intermediario
256106: MQTT: no se pudo conectar al intermediario
258106: MQTT: No se pudo conectar al intermediario
260106: MQTT: No se pudo conectar al intermediario
262106: MQTT: No se pudo conectar al intermediario
264106: MQTT: No se pudo conectar al intermediario
266107: MQTT: No se pudo conectar al intermediario

micropet en 29 abr. 2018

ESP32 - últimos cambios (28-04-2018) MQTT deja de funcionar, NTP deja de funcionar
(IP estática)

flexiti en 29 abr. 2018

@flexiti
MQTT pierde la conexión cada segundo si no se suscribe y simplemente intenta publicar.

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

Intente ingresar algo en la línea de suscripción incluso si no lo usa. Trabajó para mi.

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

s0170071 en 29 abr. 2018

@ TD-er
este hilo se está sobrecargando un poco y parece que hay varios problemas de estabilidad / wifi. Sugiero mover todos los problemas a un problema de github separado y etiquetarlos con una palabra clave, por ejemplo
[WIFICORE] ssdp
[WIFICORE] MQTT subscription needed
[WIFICORE] Unit not found - port setting vanished
[WIFICORE] ticker interval

s0170071 en 29 abr. 2018

Solo para informar, recién actualizado de mega-20180428 a mega-20180429.

En mega-20180428, el wifi era estable en general, pero no se volvía a conectar después de una desconexión.
en mega-20180429, el wifi es muy inestable y no puedo hacer ping sin obtener muchos tiempos de espera de lectura.

Estoy usando un sonoff básico, autocompilando los lanzamientos con #define PLUGIN_SET_SONOFF_BASIC para hacer que el contenedor sea lo suficientemente pequeño para OTA.
No estoy seguro de si ayuda, mientras tanto, volviendo a mega-20180428.

louis-lau en 29 abr. 2018

@ louis-lau ¿Podrías volver a probar con el último compromiso + combinación que acabo de hacer?

TD-er en 29 abr. 2018

Esta es la última confirmación
screenshot

louis-lau en 29 abr. 2018

@ louis-lau ¿Y el registro del propio nodo?
Si intenta volver a conectarse a un intermediario MQTT, la respuesta es más lenta y actualmente hay un controlador de reconexión en segundo plano para volver a conectarse cuando hay muchos fallos de reconexión MQTT.
Ah, y a veces, después de un intento de flash, es mejor hacer un reinicio del nodo (no reiniciar la configuración, como presionar el botón de reinicio). A veces, queda algo de configuración aún presente en el nodo después de flashear, lo que puede dar lugar a resultados extraños.

TD-er en 29 abr. 2018

@ louis-lau un sonoff básico?
yo también amo 0429, 0428 fue terrible
¿Puedo saber más sobre su configuración "general", por favor?
Y como autocompilado, ¿está compilado con 2.4.1 Core?
Acabo de probar 0429 flash nuevo en un nodo en blanco y funciona perfectamente.
Mi intento anterior con 0429 fue una actualización de un nodo de conjunto estático preconfigurado. perfecto tambien
Mis tablas tienen fecha de 5-5-2017

Oxyandy en 29 abr. 2018

@Oxyandy
2.4.2 núcleo ????

TD-er en 29 abr. 2018

Esto es todo lo que tengo que parece relevante:

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

@Oxyandy Intentaré un restablecimiento de fábrica. No hice ningún cambio antes de compilar, excepto el indicador del complemento básico de sonoff y la configuración de red en Custom.h.

louis-lau en 29 abr. 2018

Tienes razón, funciona bien con la configuración de fábrica 😄.

Intentaré restaurar, ver si se rompe de nuevo.

louis-lau en 29 abr. 2018

¿Parece un reinicio?

En el registro web obtendrás un poco más de líneas, ya que ese tiene un búfer de 15 líneas.
También en la página sysinfo puede obtener más información.

Es posible que los registros grabados en el servidor syslog no estén completos, ya que ese no recibe datos cuando se desconecta el wifi.

TD-er en 29 abr. 2018

Muy bien, comenzó a suceder de nuevo cuando habilité el controlador mqtt.
Y se detuvo cuando lo desactivé.

Intentaré obtener un registro mejor, es un poco difícil cuando no puedes conectarte a él la mitad del tiempo.
¿Qué nivel de registro? ¿depurar?

louis-lau en 29 abr. 2018

Las conexiones MQTT también se muestran en el nivel de información.
La información muestra error + info.
De esa manera, no llenará el búfer de registro del weblog demasiado rápido para mostrarlo.

TD-er en 29 abr. 2018

Bien, cuando detengo el servidor mqtt también funciona normalmente, solo cuando el servidor se está ejecutando se agota el tiempo de espera de la conexión.

Esto es todo lo que pude obtener del registro:
screenshot

louis-lau en 29 abr. 2018

¿Qué tipo de controlador MQTT es este? Domoticz? OpenHAB?

¿O estás intentando hacer importMQTT?

También hay un botón de copia en la página web que muestra el registro.
Esa página se actualiza cada N segundos, lo que le permite pegar el texto entre actualizaciones en un editor de texto.
No es perfecto, lo sé, pero es mejor que nada :)

Editar:
Por favor, también eche un vistazo a las reglas, si están completas.
Todavía hay un problema al guardar las reglas. Este ahorro puede no ser el conjunto de reglas completo ingresado.

TD-er en 29 abr. 2018

Usando el último githib (07bfec42347d13ad49dda907654a36bf747df3bc), Wifi se conecta sin problemas en todos mis nodos. Ahora también se vuelve a conectar correctamente después de reiniciar el AP. Usando el núcleo 2.4.1.

ghost en 29 abr. 2018

Jeje, una vez que está realmente cargado, tengo muy poco tiempo, así que solo tomé una captura de pantalla. Estoy usando el controlador openhab mqtt, el servidor es mosquitto.

EDITAR: no estoy usando reglas en este momento. Solo para asegurarme de que ese no sea el problema.

louis-lau en 29 abr. 2018

Aquí igual. Intenta suscribirte a cualquier tema. Eso solucionó mi problema.

-------- Ursprüngliche Nachricht --------
Von: Louis Laureys [email protected]
Gesendet: 29 de abril de 2018 16:23:54 MESZ
An: letscontrolit / ESPEasy [email protected]
CC: s0170071 [email protected] , mencione menció[email protected]
Betreff: Re: [letscontrolit / ESPEasy] Problemas con la conexión Wi-Fi, que nunca termina la historia, ¿volver a la conexión Wi-Fi no basada en eventos? (# 1302)

Jeje, una vez que está realmente cargado, tengo muy poco tiempo, así que solo tomé una captura de pantalla. Estoy usando el controlador openhab mqtt, el servidor es mosquitto.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/letscontrolit/ESPEasy/issues/1302#issuecomment -385255207

s0170071 en 29 abr. 2018

@ s0170071 ¿Dónde se debe realizar esta suscripción?
Si eso está en algún tipo de configuración predeterminada, entonces quizás deberíamos agregar eso.

¿El tiempo entre reconexiones MQTT es de 15 a 16 segundos? Entonces podría ser que Mosquito te esté echando y luego sé dónde parchear esto.

TD-er en 29 abr. 2018

En la configuración del controlador openhab. Existe el campo de suscripción.

s0170071 en 29 abr. 2018

Usando el último githib (07bfec4), MQTT también funciona sin problemas aquí usando el controlador openhab y conectándose a Mosquitto. Usando el núcleo 2.4.1.

ghost en 29 abr. 2018

@ td-er vea algunas publicaciones arriba.

s0170071 en 29 abr. 2018

Ya estoy suscrito a / sonoff_lavalamp / # como puede ver en los registros.

Me di cuenta cuando me suscribí a # (entonces, todos los temas). El wifi es estable, pero eso hace que mqtt sea inutilizable;)

Mosquitto no debería expulsar al usuario, el usuario que estoy usando tiene permisos para todos los temas.

louis-lau en 29 abr. 2018

Este es el registro de mosquitto:

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

Parece que se está reconectando y mosquitto está cerrando la antigua conexión.

louis-lau en 29 abr. 2018

He estado investigando la fuente de PubSubClient.
Parece que tiene que haber actividad entrante y saliente dentro del período de tiempo de espera.
Si uno de ellos falla, PubSubClient se desconectará y, por lo tanto, ESPeasy se volverá a conectar.

Intentaré agregar algún tipo de ping automático. Ya hay algunos, pero es posible que la verificación se realice antes de que regrese el ping.

TD-er en 29 abr. 2018

@ louis-lau ¿Puedes de alguna manera encontrar el ajuste de tiempo de vida útil usado en tu Mosquito?

Parece que la configuración de tiempo de espera de MQTT que usamos es de 15 segundos.
Se define como: #define MQTT_KEEPALIVE 15

Véase también https://github.com/knolleary/pubsubclient/issues/239

TD-er en 29 abr. 2018

¡¡¡¡Lo hiciste @ TD-er !!!!!

467279: EVENTO: Reloj # Hora = Sol, 17:24
467588: WD: Tiempo de actividad 8 ConnectFailures 0 FreeMem 16304
481935: MQTT: conexión perdida
481935: EVENTO: MQTT # desconectado
481953: EVENTO: WiFi # desconectado
481969: WIFI: ¡Desconectado! Motivo: '(1) No especificado' Conectado durante 7 m 40 s
482278: WIFI: Intento de conexión de SMC # 0
482278: IP: IP estática: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
483304: EVENTO: WiFi # desconectado
483322: WIFI: ¡Desconectado! Motivo: '(202) Error de autenticación' Conectado durante 1018 ms
484291: WIFI: Intento de conexión de SMC n. ° 1
484292: IP: IP estática: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
488073: WIFI: ¡Conectado! AP: SMC (78: 8A: 20: D1: 9B: D9) Canal: 1 Duración: 3780 ms
488074: IP: IP estática: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
488078: WIFI: IP estática: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 duración: 6 ms
488099: EVENTO: WiFi # conectado
488245: MQTT: conectado al intermediario con ID de cliente: ESPClient_5C: CF: 7F: 0B: 68: 52
488247: Suscrito a: ESP-201 / #
488248: EVENTO: MQTT # conectado
489111: EVENTO: No de tiempo establecido

micropet en 29 abr. 2018

@ TD-er ¿Está seguro de que el pubsubclient tiene problemas? Mi unidad no recibe nada, solo envía valor analógico cada 30 segundos. No hay problemas de conexión MQTT. Si hubiera un problema con la biblioteca, ¿no tendríamos muchos más usuarios quejándose?

ghost en 29 abr. 2018

Tal vez sea una condición de carrera ...

s0170071 en 29 abr. 2018

El corredor de MQTT debe considerar que un cliente está desconectado a 1,5 veces el tiempo de espera.
Pubsubclient envía un ping cuando la última actividad fue hace más de 15 segundos.
Entonces, si se usa el tiempo de espera predeterminado de Mosquito (10 s), entonces el tiempo se vuelve bastante crítico.

En mi configuración, veo una gran cantidad de tráfico MQTT de todos los nodos aquí charlando en el mismo canal (domoticz).
Entonces, el tiempo de espera nunca es un problema aquí.
Pero si solo hay un nodo, hay mucho menos tráfico y con el tiempo de espera predeterminado de ESPeasy establecido exactamente en 1,5 veces el tiempo de espera predeterminado de Mosquito, puede ser un poco crítico.

TD-er en 29 abr. 2018

Luego, podría intentar enviar un valor analógico ficticio cada 5 segundos para verificar si el problema desaparece ...

ghost en 29 abr. 2018

O usa mi última confirmación;)

TD-er en 29 abr. 2018

Mis reconexiones fueron muy rápidas, cada segundo más o menos

s0170071 en 29 abr. 2018

Al desarrollador de MQTT no parece gustarle eso:
No estoy dispuesto a cambiar el valor predeterminado. Habían sido 15 segundos durante más de 7 años. En todo caso, haremos que sea más fácil de personalizar y no depender de la edición del archivo de encabezado.

ghost en 29 abr. 2018

La definición está envuelta con #ifdef
Entonces hay una opción para definirlo en otras partes del código.

En la página de github de PubSubclient, también hay un problema sobre cómo hacerlo configurable.

TD-er en 29 abr. 2018

Otro comentario de su autor:
En el protocolo MQTT, el cliente determina el valor de estado activo utilizado en una conexión. El corredor no tiene nada que decir.

La única opción de configuración keepalive en mosquitto es su puente keepalive, donde actúa como un cliente que se conecta a otro corredor, https://mosquitto.org/man/mosquitto-conf-5.html

ghost en 29 abr. 2018

He comprobado mi configuración de mosquitto. No puedo encontrar ninguna opción de tiempo de espera para las conexiones

ghost en 29 abr. 2018

Este documento analiza el comportamiento del tiempo de espera.

TD-er en 29 abr. 2018

Y el documento dice lo mismo:

El cliente MQTT es responsable de establecer el valor de mantener vivo correcto. Por ejemplo, puede adaptar el intervalo a la intensidad de la señal actual.

Entonces, ¿de dónde vienen los 10 segundos de Mosquitto? ¿Está codificado?

ghost en 29 abr. 2018

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

keepalive_interval segundos
Establezca la cantidad de segundos después de los cuales el puente debe enviar un ping si no se ha producido ningún otro tráfico. El valor predeterminado es 60. Se permite un valor mínimo de 5 segundos.

Grovkillen en 29 abr. 2018

Esa configuración es solo para puente

ghost en 29 abr. 2018

Tenga en cuenta que esto no fue un problema en 20180428 :)

EDITAR: Intentaré tu última confirmación cuando llegue a casa.

louis-lau en 29 abr. 2018

Puede intentar desactivar connectionCheckHandler .

Para ver qué ha cambiado en el último día: https://github.com/letscontrolit/ESPEasy/compare/mega@%7B1day%7D...mega

TD-er en 29 abr. 2018

Recién actualizado a https://github.com/letscontrolit/ESPEasy/commit/4e6e31fdae11476a2f3dfce00e01ed77d1858c00 y el wifi ahora es estable. ¡También se vuelve a conectar ahora cuando reinicio mi AP! Gracias 😄

louis-lau en 29 abr. 2018

(Por cierto, ¿hay alguna forma de alternar la configuración del LED de estado de Wifi usando reglas? Por ejemplo, solo me gustaría habilitarlo si mqtt está desconectado y usarlo para el estado del relé cuando esté conectado).

louis-lau en 29 abr. 2018

No estoy seguro del LED de estado. Se llama desde la función MQTTconnect y desde algunos otros lugares.
¿Pero tal vez podría agregar un problema para que sea seleccionable lo que se muestra a través de ese LED?

Y es bueno escuchar que los problemas de MQTT parecen estar solucionados por el tiempo de espera reducido.
Es posible que tengamos que hacerlo seleccionable.

TD-er en 29 abr. 2018

👍2

¿Podrías alargar un poco más la ventana de REGISTRO?
Quiero decir, aumente el número de líneas.

De lo contrario, ahora va muy bien.

micropet en 29 abr. 2018

Solo los reduje.
Eran 20 líneas, pero con 2.4.0 tenía que haber un poco más de memoria libre, así que la reduje a 10 líneas para dev / test y 15 para normal.

Examinaré el consumo de memoria esta semana y

TD-er en 29 abr. 2018

OK ire a dormir.
¡Muchas gracias por tu arduo trabajo!

micropet en 29 abr. 2018

Sobre esa ventana. A mi modo de ver, hay tres opciones.

Utilice tanta memoria RAM como esté disponible para mantener la información hasta que se solicite. Podría ser dinámico, dependiendo de cuántos complementos estén activos.
Transmítalo al navegador web.
Comprímalo temporalmente y restaure cuando se le solicite. Por ejemplo, utilice más códigos numéricos. Por supuesto, es menos legible.

Me gusta 2. También ofrece una visualización web fluida. Sin embargo, no es tan simple.

s0170071 en 29 abr. 2018

La idea es obtener algún tipo de JavaScript para recopilar el registro y almacenarlo en el navegador.
Hay varias opciones para enviar los datos al navegador, como mantener una conexión abierta o algunas otras técnicas.
Eso deja solo unas pocas líneas de registro necesarias para mantenerse en la memoria.
Y ese búfer también se puede usar para transferir el registro a syslog.

El objeto de caché de registro actualmente no es tan eficiente con la memoria. Mucho margen de mejora.

TD-er en 29 abr. 2018

👍1

También me pregunto ahora si diferentes versiones de mosquitto
que se ejecutan en diferentes sistemas operativos tienen un comportamiento diferente?
Sé que ESPeasy debería ser flexible, pero una actualización mosquitto resolvería problemas para algunos.

Oxyandy en 30 abr. 2018

Solo para entender ...
Por qué obtengo esto directamente después de arrancar mi ESP:

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

En syslog veo dos mensajes IP STATIC y Uptime 0 ConnectFailures 0:

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

DittelHome en 30 abr. 2018

Quizás el término "reconectar" no esté bien elegido.
Es más como "(re) conectar" o "intentos de conexión"
El contador comienza en 0 y en cada intento de conexión es un contador ++.

TD-er en 30 abr. 2018

Cambié el contador inicializándolo a '-1'. Entonces, el primer intento de conexión lo establecerá en 0, por lo que la etiqueta "Número reconecta" ahora tiene sentido nuevamente :)
No pude pensar en un nombre mejor, así que cambié el valor informado;)

Nombrar correctamente sigue siendo la parte más difícil de la programación.

TD-er en 2 may. 2018

Suena bien !

DittelHome en 2 may. 2018

conexión intente x

uzi18 en 2 may. 2018

Desafortunadamente, la última compilación 20180503 (4096 dev) no me funciona: la web ESP no se abre, sino que deja de responder en la consola serie (después del intento de apertura web). La configuración se restablece a los valores predeterminados y establece solo WifiSSID y clave a través de la consola en serie. PING funciona, no se reinicia, no hay mensaje de error.

ghtester en 3 may. 2018

👍1

¿Ha realizado un reinicio en frío después del flash?
Tuve algo similar justo después de flashear.
Un ciclo de energía lo resolvió entonces.

TD-er en 3 may. 2018

Sí, probé el reinicio en frío varias veces, sigue siendo el mismo. Probado desde MSIE y Firefox en Win7. Voy a probar el dispositivo en otra ubicación un par de minutos más tarde (PC / OS diferente, AP diferente).
Inmediatamente después del flash, se reinició y se colgó.

ghtester en 3 may. 2018

Lo he probado ahora mismo, con la versión normal. Por mi parte, no hay problema. No fue necesario reiniciar.

DittelHome en 3 may. 2018

Es extraño que en otra ubicación funcione la web ESP del mismo dispositivo (Win10 + Firefox / MS Edge, AP diferente) pero la consola serie parece "de solo lectura" ...: - /
Actualización: probé con otra aplicación de terminal, la misma, solo lectura de consola en serie. Luego, ejecute Putty (que es mi aplicación de terminal predeterminada) nuevamente y vi que el dispositivo se reiniciaba tan pronto como me conecté con Putty al puerto COM apropiado. Ahora la consola serial acepta comandos y la web también está funcionando ... No entiendo nada ...

ghtester en 3 may. 2018

¿Quizás intentar una limpieza completa del flash y el programa de nuevo?
Parece haber una relación con la conexión wifi y si se está leyendo el puerto serie. He visto a alguien mencionar eso en un hilo. No estoy seguro si fue por un problema de PlatformIO o por LWIP.
He estado leyendo mucho últimamente;)

TD-er en 3 may. 2018

Sí, intentaré eso con la próxima compilación, esta que deseo probar en otra ubicación nuevamente para ver si sigue siendo el mismo problema (la configuración del dispositivo se actualizó un poco mientras tanto).
POR CIERTO. cuando restablecí la configuración por primera vez (después de esta compilación parpadeando, emitiendo el comando Reset desde la consola en serie), de hecho NO restableció la configuración a pesar de que decía "formateo de flash", etc. El dispositivo se reinició y al menos la configuración de WiFi todavía estaba allí como vi intentos de conexión a AP en la consola en serie ... El segundo intento de reinicio desde la consola en serie borró la configuración ...

ghtester en 3 may. 2018

Sí, la biblioteca central almacena la configuración de wifi en un área fuera del SPIFF.
Esto puede afectar los intentos de conexión wifi.

Ya leí en el código (central) que ahora hay soporte para hasta 5 configuraciones de wifi, que puede seleccionar.
Entonces, tal vez también use activamente esa área de almacenamiento, para asegurarme de que no entre en conflicto con nuestra propia configuración.
Lo único que temo es que esas configuraciones se escribirán con demasiada frecuencia. Tengo que comprobar cuándo se está escribiendo.
Pero puede hacer que la conexión wifi sea un poco más predecible cuando esa área también se tiene en cuenta con ESPeasy.

TD-er en 3 may. 2018

👍1

@Oxyandy Ahora presionaré el cambio PlatformIO.ini para usar LWIP2_LOW_MEMORY.
¿Podrías probar esto?
¿Y también la pregunta de si estaba utilizando la tarea / dispositivo 12?
Lo probé en mi nodo y casi de inmediato se desconectó + se negó a conectarse de nuevo.
Eso fue con LWIP1.4

TD-er en 4 may. 2018

👍1

¿Y también la pregunta de si estaba utilizando la tarea / dispositivo 12?

En las pruebas, no solo el primero, un solo interruptor
Sí, hay 15 archivos modificados en GitHub Desktop extrayendo ahora

Oxyandy en 4 may. 2018

Compilado bien, excelente servidor web, usando LWIP2_LOW_MEMORY, la prueba F5, simplemente genial ...
ningún signo de LmacRxBlk: 1 en los registros
Había borrado todas las configuraciones en el nodo, pero lo 'restableceré' y seguiré el proceso, informaré cualquier rareza ...
Wifi conectado al instante primero en ir.

Oxyandy en 4 may. 2018

solo tenga cuidado con la memoria baja de lwIP2, tuve que usar el ancho de banda alto de lwIP2, de lo contrario, los paquetes grandes se truncaron (por ejemplo, sensores con múltiples valores), al menos cuando se usaba fhem como servidor / controlador ...

Actualmente estoy usando la mega rama con esp core de GIT y lwIP2 de alto ancho de banda que funciona bien, excepto que después de un tiempo algunas de las unidades ya no pueden leer los valores de los sensores y, por lo tanto, no lo enviarán al controlador. Sin embargo, la unidad en sí, así como la interfaz web, funcionan sin problemas ... Todavía estoy investigando esto, nunca tuve esto en confirmaciones antes de Mai ...

clumsy-stefan en 4 may. 2018

Probamos LwIP2 con un ancho de banda alto y esos mensajes POST estropeados.
Por ejemplo, las reglas de guardado> 1520 bytes se truncaron.

TD-er en 4 may. 2018

ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
¿Se considera un ataque DoS a los servidores de tiempo?
Después de flashear, me llamaron, tengo páginas y páginas de este bucle

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

Oxyandy en 4 may. 2018

Con el núcleo actual (Master, ESP82xx Core 41a64707, NONOS SDK 2.2.1 (cfd48f3)), los problemas de MTU ya no aparecen.
Tener 10 ESP (Sonoff, NodeMcu, W1pro) ejecutándose desde el 1 de mayo sin problemas.

susisstrolch en 4 may. 2018

FYI ... Actualice la última compilación oficial, restablezca la configuración a través de la serie a los valores predeterminados, ingrese el WiFiSSID y las claves. No se pudo conectar al AP principal a pesar de que era visible (pero una señal débil alrededor de -82). Luego se estrelló como puede ver a continuación.
En otra ubicación, el dispositivo se conectó al AP secundario rápidamente sin ningún problema y hasta ahora está funcionando (pero no hay complementos configurados, no hay reglas activas).
....
....
458745: WIFI: Conexión de IOTAP1 intento n. ° 57
458749: Modo AP: Cliente desconectado: xx: xx: xx: xx: xx: xx Dispositivos conectados: 0
458810: WIFI: ¡Desconectado! Razón: '(201) No se encontró AP' Conectado durante 64 ms
459360: Modo AP: Cliente conectado: xx: xx: xx: xx: xx: xx Dispositivos conectados: 1
471739: WIFI: El ssid del modo AP será ESP_Easy_0 con la dirección 192.168.4.1
471739: WIFI: Intento de conexión de IOTAP2 n. ° 58

Excepción (29):
epc1 = 0x4000e1c3 epc2 = 0x00000000 epc3 = 0x40000f68 excvaddr = 0x00000018 depc = 0x00000000

ctx: sys
sp: 3ffffc50 final: 3fffffb0 desplazamiento: 01a0

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

ets 8 de enero de 2013, primera causa: 2 , modo de arranque: (3,7)

carga 0x4010f000, len 1384, sala 16
cola 8
chksum 0x2d
csum 0x2d
v614f7c32
~ ld
-U88:

INIT: Versión de arranque: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
89: INIT: arranque en caliente n. ° 6
90: FS: Montaje ...
116: FS: Montaje exitoso, se utilizaron 75802 bytes de 957314
436: CRC: suma de comprobación del programa ... OK
442: CRC: SecuritySettings CRC ... OK
548: INIT: RAM libre
549: INIT: I2C
549: INIT: SPI no habilitado
565: INFO: Complementos: 72 [Normal] [Prueba] [Desarrollo] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
566: WIFI: Establecer WiFi en STA
599: WIFI: Conectando IOTAP1 intento # 0
607: WD: Tiempo de actividad 0 Fallos de conexión 0 FreeMem 20616
3461: WIFI: ¡Desconectado! Motivo: '(201) No se encontró AP' Conectado durante 2861 ms
3604: WIFI: Conexión de IOTAP1 intento n. ° 1
6466: WIFI: ¡Desconectado! Razón: '(201) No se encontró AP' Conectado durante 2862 ms
6604: WIFI: Conexión de IOTAP2 intento n. ° 2
9467: WIFI: ¡Desconectado! Razón: '(201) No se encontró AP' Conectado durante 2862 ms
9604: WIFI: Conexión de IOTAP2 intento n. ° 3
12467: WIFI: ¡Desconectado! Razón: '(201) No se encontró AP' Conectado durante 2862 ms
12604: WIFI: Conexión de IOTAP1 intento n. ° 4
15466: WIFI: ¡Desconectado! Razón: '(201) No se encontró AP' Conectado durante 2862 ms
15604: WIFI: Conexión de IOTAP1 intento n. ° 5
18466: WIFI: ¡Desconectado! Razón: '(201) No se encontró AP' Conectado durante 2862 ms
18604: WIFI: establezca WiFi en AP + STA
19524: WIFI: El ssid del modo AP será ESP_Easy_0 con la dirección 192.168.4.1
19524: WIFI: Conexión de IOTAP2 intento n. ° 6
22388: WIFI: ¡Desconectado! Razón: '(201) No se encontró AP' Conectado durante 2863 ms
22603: WIFI: El ssid del modo AP será ESP_Easy_0 con la dirección 192.168.4.1
22603: WIFI: Intento de conexión de IOTAP2 n. ° 7
25463: WIFI: ¡Desconectado! Razón: '(201) No se encontró AP' Conectado durante 2860 ms
25602: WIFI: El ssid del modo AP será ESP_Easy_0 con la dirección 192.168.4.1
25603: WIFI: Conexión de IOTAP1 intento n. ° 8
28464: WIFI: ¡Desconectado! Razón: '(201) No se encontró AP' Conectado durante 2860 ms
28602: WIFI: El ssid del modo AP será ESP_Easy_0 con la dirección 192.168.4.1
28603: WIFI: Conexión de IOTAP1 intento n. ° 9
30606: WD: Tiempo de actividad 1 ConnectFailures 0 FreeMem 18176
...
...

ghtester en 4 may. 2018

Vi ese error "No AP encontrado" también ayer.
Parece estar relacionado con algunas configuraciones incorrectas o dañadas. No solo la configuración que almacenamos, sino también la configuración almacenada en otra parte de la memoria flash, por la biblioteca central.

Las actualizaciones de

@susisstrolch ¿Podría probar para escribir un archivo de reglas que contenga> 1800 bytes?
La versión de ancho de banda alto de LWIP2 estaba corrompiendo las solicitudes HTTP POST cuando superaban una MTU de tamaño.

TD-er en 4 may. 2018

Hola Gijs,
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Si vio el registro, es un patrón, siempre se conecta, MQTT se conecta, actualiza la hora

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

cada 10 a 12 segundos, en bucle así durante horas, oops

Oxyandy en 4 may. 2018

Tamaño de la regla de mi dispositivo pondctrl: Tamaño actual: 1859 caracteres (máximo 2048)
MTU: 534 (lwip de memoria baja 2.x)
Sin problemas: cambió varias veces esta semana.

susisstrolch en 4 may. 2018

Actualmente estamos usando LwIP 2.x con poca memoria, porque la versión de alto ancho de banda estaba dando estos problemas.
@Oxyandy Buscaré el código con respecto a la actualización de la hora y, por supuesto, el ciclo de reconexión.
Este tema se está volviendo cada vez más en el tema :(

TD-er en 4 may. 2018

No lo entiendo, el que compilé homebrew (esta mañana) según su solicitud funcionó muy bien ...
luego, cuando el lanzamiento oficial estuvo disponible, pensé que sería mejor usarlo, me sorprendió la diferencia.
Ahora, con respecto a su última respuesta ... la actualización de la hora está bien ...
el lanzamiento oficial de hoy se conecta a wifi sin problema, conecta MQTT, obtiene el tiempo, luego interrumpe la conexión con "(200) Beacon timeout" y luego se repite cada 11 segundos
Conectar - wifi, MQTT, tiempo, desconectar, repetir
Así que no mires la "actualización de la hora", si permaneciera conectada estaría bien ...

Oxyandy en 4 may. 2018

Eso es extraño. Hay algo realmente extraño en el proceso de construcción de PlatformIO.
Yo mismo he notado algunas veces que construirlo por segunda vez realmente marca la diferencia.
Es como si hubiera algo mal en el nivel del enlazador en PlatformIO.
Es realmente extraño lo que está pasando aquí.

TD-er en 4 may. 2018

probablemente esté en las banderas del compilador o del enlazador. La optimización puede ser una mierda.
El IDE de Arduino tiene este archivo de configuración (platform.txt)

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

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

name=ESP8266 Modules
version=2.5.0-dev

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

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

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

build.vtable_flags=-DVTABLES_IN_FLASH

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

s0170071 en 4 may. 2018

👍1

Para evitar problemas con platformIO, eliminé la carpeta .pioenvs y ejecuté 'Limpiar' de todos modos
Desde la compilación de esta mañana, 2 archivos han cambiado
ESPEasy-Globals.hy Misc.ino (Corregir la corrupción de la configuración de la tarea)

Oxyandy en 4 may. 2018

Comenzando a hacer esto: mi estructura de carpetas actual es GitHub / ESpeasy
Copio la carpeta ESpeasy y le cambio el nombre para incluir la fecha antes de buscar, me ayudará a comparar los cambios localmente.

Oxyandy en 4 may. 2018

FritzBox realizó una actualización automática de firmware. Todos los ESP fallaron al AP Mesh alternativo sin ningún problema.

susisstrolch en 4 may. 2018

@ TD-er dijiste "¿Tiene este tiempo de espera de Beacon con 0504 en cualquier nodo, o solo en unos pocos?"
Ok, para ser justos, tomaré un módulo nuevo y lo flashearé y, en el futuro, flashearé 2 nodos por cada nuevo firmware.
Tengo tiempo de sobra ya que solo son las 4PM en tu parte del mundo

Oxyandy en 4 may. 2018

Ok, un Nodo nuevo, borrado.
Parpadeó con ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
El siguiente registro tiene un comportamiento idéntico al del otro nodo.
¿Puedes ver el patrón en el registro?

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

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

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

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

Oxyandy en 4 may. 2018

Ah, creo que es hora de que configure un punto de acceso especial que ejecute Wirehark

Oxyandy en 4 may. 2018

Usando GitHub Desktop, obtuve la última fuente 'en vivo' que incluye solo 2 archivos modificados de https://github.com/letscontrolit/ESPEasy/commit/92680c5542b76a15db16af198a3a07ed17618c4e ya que mi compilación de trabajo de esta mañana, hizo una versión nocturna y funciona perfectamente ..
¿Por qué las compilaciones nocturnas son diferentes si es la misma fuente, qué está sucediendo de manera diferente en GitHub?

Oxyandy en 4 may. 2018

¿Alguien usa Arduino IDE?
¿Puede construir un "ESP8266 normal 1024" a partir del src actual y descargarlo aquí?
Gracias

Oxyandy en 4 may. 2018

No estoy seguro si esto está relacionado con algunos de los problemas aleatorios que estamos viendo, pero noté que después de un tiempo, mis unidades dejan de enviar datos al controlador. Sin embargo, la interfaz web todavía está en funcionamiento, pero muestra una dirección IP de 0.0.0.0. (ver captura de pantalla). ¿Alguien más está viendo esto?

untitled

clumsy-stefan en 4 may. 2018

¿Qué versión de compilación es esta?

TD-er en 4 may. 2018

@Oxyandy

¿Por qué las compilaciones nocturnas son diferentes si se trata de la misma fuente, qué está sucediendo de manera diferente en GitHub?

Eso es lo que también me pregunto.
Supongo que tiene algo que ver con el hecho de que también tenemos que construirlo dos veces cuando lo construimos nosotros mismos.
Parece haber algo mal con la forma en que compilamos las cosas o con el compilador.
Quizás eso también explique por qué estamos viendo tantas cosas que son muy difíciles, si no imposibles, de reproducir en las últimas semanas.

También hablé de esto con
Le preguntaré a @ psy0rz si es posible construir las compilaciones nocturnas dos veces como prueba.

TD-er en 4 may. 2018

auto compilado de mega-20180503
Construir | 20102 - Mega
Bibliotecas | ESP82xx Core 76a14b1f, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3

clumsy-stefan en 4 may. 2018

¿Podría intentar construirlo dos veces antes de escribirlo en el nodo?
No hay limpieza entre compilaciones, simplemente constrúyalo y vuelva a construir.

TD-er en 4 may. 2018

claro, pero uso Arduino SDK en una mac, no en platformIO ... ¿aún vale la pena intentarlo?

clumsy-stefan en 4 may. 2018

Sí, por favor hágalo, ya que aún no tenemos ni idea de qué lo está causando.
Solo asegúrese de estar usando las mismas bibliotecas centrales que nosotros, ya que Arduino IDE no mira las versiones fijas configuradas en PlatformIO.
Las versiones actuales que usamos son:
ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3

TD-er en 4 may. 2018

ok, lo intentaré ahora y mostraré algunas unidades. Informaré tan pronto como suceda algo ... o nada en absoluto;)

clumsy-stefan en 4 may. 2018

POR CIERTO. la compilación actual puede fallar en cualquier momento manteniendo presionada la tecla F5 en el navegador web al menos en las páginas de Dispositivos o Notificaciones (probablemente en cualquier página web de ESP) durante unos segundos. Puedo repetirlo en cualquier momento desde Firefox en Win10:
...
...
39543696: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39551825: LoadFromFile: config.dat index: 27648 tamaño de datos: 320
39557599: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39566681: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39566879: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39567105: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39567490: Uso de RAM: Solo servidor web: 0, incluido el núcleo: 0
39567690: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39567883: Uso de RAM: Solo servidor web: 0, incluido el núcleo: 0
39568086: Uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39568287: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39568495: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39568701: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39568910: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39569112: Uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39569324: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39569530: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39569739: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39569948: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
39570158: Uso de RAM: Solo servidor web: 0, incluido el núcleo: 0
39570366: Uso de RAM: Solo servidor web: 0, incluido el núcleo: 0
39570582: Uso de RAM: Solo servidor web: 0, incluido el núcleo: 0
39570742: Página web omitida: poca memoria: 1784
39570832: Página web omitida: poca memoria: 1784
39570906: Página web omitida: poca memoria: 1784
39570992: Página web omitida: poca memoria: 1784
39571074: Página web omitida: poca memoria: 1784
39571161: Página web omitida: poca memoria: 1784
39571240: Página web omitida: poca memoria: 1784
39571322: Página web omitida: poca memoria: 1784
39571401: Página web omitida: poca memoria: 1784

Excepción (28):
epc1 = 0x4025cb66 epc2 = 0x00000000 epc3 = 0x401003f2 excvaddr = 0x00000000 depc = 0x00000000

ctx: cont
sp: 3fff4690 final: 3fff4b20 desplazamiento: 01a0

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

ets 8 de enero de 2013, primera causa: 2 , modo de arranque: (3,7)

carga 0x4010f000, len 1384, sala 16
cola 8
chksum 0x2d
csum 0x2d
v614f7c32
~ ld
▒U88:

INIT: Versión de arranque: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
89: INIT: arranque en caliente n. ° 3
90: FS: Montaje ...
115: FS: Montaje exitoso, se utilizaron 75802 bytes de 957314
437: CRC: suma de comprobación del programa ... OK
469: CRC: SecuritySettings CRC ... OK
575: INIT: RAM libre
575: INIT: I2C
575: INIT: SPI no habilitado
1677: INFO: Complementos: 72 [Normal] [Prueba] [Desarrollo] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
1678: EVENTO: Sistema # Wake
1682: WIFI: configurar WiFi en STA
...
...

Luego, el dispositivo se conectó al AP con éxito. Otro choque:

973: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
279178: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
279387: Uso de RAM: solo servidor web: 0, incluido el núcleo: 0
279590: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
279798: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
280321: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
280558: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
280785: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
Excepción fatal 28 (LoadProhibitedCause):
epc1 = 0x4025cb66, epc2 = 0x00000000, epc3 = 0x40100408, excvaddr = 0x00000000, depc = 0x00000000

Excepción (28):
epc1 = 0x4025cb66 epc2 = 0x00000000 epc3 = 0x40100408 excvaddr = 0x00000000 depc = 0x00000000

ctx: cont
sp: 3fff4690 final: 3fff4b20 desplazamiento: 01a0

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

ets 8 de enero de 2013, primera causa: 2 , modo de arranque: (3,7)

carga 0x4010f000, len 1384, sala 16
cola 8
chksum 0x2d
csum 0x2d
v614f7c32
~ ld
▒U89:

INIT: Versión de arranque: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
89: INIT: arranque en caliente n. ° 8
91: FS: Montaje ...
116: FS: Montaje exitoso, se utilizaron 75802 bytes de 957314
438: CRC: suma de comprobación del programa ... OK
469: CRC: SecuritySettings CRC ... OK
575: INIT: RAM libre
576: INIT: I2C
576: INIT: SPI no habilitado
1678: INFO: Complementos: 72 [Normal] [Pruebas] [Desarrollo] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
1678: EVENTO: Sistema # Wake
1683: WIFI: establecer WiFi en STA
...

ghtester en 4 may. 2018

Bueno, eso es con 72 complementos, ¿qué tal si eso se comporta de la misma manera?)

Oxyandy en 4 may. 2018

Eso es normal si inunda la pila de IP con solicitudes. Lo único que ayuda es dar servicio al servidor web con más frecuencia para que el búfer de entrada se libere nuevamente.

s0170071 en 4 may. 2018

Al menos es bueno que sea recuperable: el bloqueo completo sería peor que reiniciar ... Pero es extraño que la causa de inicio no sea siempre la misma; también vi la causa 4.

ghtester en 4 may. 2018

ESP_Easy_mega-20180504_test_ESP8266_1024.bin
Puedo obtener wifi para conectarme (primer intento) y permanecer conectado
F5 (página de dispositivos) no provoca errores ni se bloquea
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Se conecta y falla en un ciclo de 11 segundos una y otra vez - (200) Tiempo de espera de la baliza
ESP_Easy_mega-20180504_normal_ESP8266_1024_ (Autocompilado) .bin
Perfecto

Oxyandy en 4 may. 2018

😕1

@Oxyandy ¿Autorrepetición lenta del teclado? ;-)
El mío se bloquea en todas las páginas web que probé.

ghtester en 4 may. 2018

@ghtester Construiré un conjunto en mi PC, con todo el código actual. Tardará unos 30 minutos en construirse.

TD-er en 4 may. 2018

@ TD-er Muchas gracias por su esfuerzo, lo probaré cuando la nueva compilación esté lista.

ghtester en 4 may. 2018

@ TD-er flasheó mis unidades (16) ahora con ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 construido dos veces antes de flashear ... Veré mañana si todavía están vivos y enviando datos ... tuve que tomar un ancho de banda alto lwIP2, de lo contrario, los datos enviados a través del controlador FHEM se truncan.
pero necesito dormir ahora ... n8

clumsy-stefan en 5 may. 2018

Tenga en cuenta los problemas de HTTP POST con la versión de ancho de banda alto.

Mi compilación ahora se está ejecutando por tercera vez (tenía algún problema con ESP32 que necesitaba ser arreglado y quiero asegurarme de que solo se realiza la vinculación en la última compilación)
Entonces habrá un archivo zip en unos minutos.
Luego me voy a la cama también.

TD-er en 5 may. 2018

Vea la compilación: https://github.com/letscontrolit/ESPEasy/releases/tag/mega-20180505_TD-er

TD-er en 5 may. 2018

TD-er, su compilación, mi hardware, no hay problema con el (normal 1024 8266)
Esperando a que se muestre la compilación diaria, lo intentaremos a continuación;)

Oxyandy en 5 may. 2018

@ TD-er Muchas gracias, se probó rápidamente la versión de desarrollo 4096 (continuará), el problema de reinicio "F5" sigue ahí (el primer intento colgó el dispositivo por completo) y la información del firmware dice que la verificación MD5 falla (supongo que se debe a prueba de construcción). Sin embargo, todo lo demás está bien hasta ahora y se está conectando perfecta y rápidamente a AP.

Compilación 20102: Mega
Bibliotecas ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3
Versión GIT
Complementos 72 [Normal] [Prueba] [Desarrollo]
Compilación Md5 4d44355f4d44355f4d44355f4d44355f
Error de comprobación de md5!
Tiempo de construcción 5 de mayo de 2018 00:33:21
Nombre de archivo binario ThisIsTheDummyPlaceHolderForTheBinaryFilename ...

ghtester en 5 may. 2018

Como se compilaron y lanzaron en GitHub, ambos BIN, con 1 día (1 compilación) de diferencia.
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Confirmado 'defectuoso' de muchas formas diferentes, reinicio, diferentes nodos, etc.
los problemas son consistentes (201 Beacon Timeout) en un ciclo de 11 segundos
Homebrew funciona perfectamente desde la misma fuente.
a
ESP_Easy_mega-20180505_normal_ESP8266_1024.bin
Funcionando perfectamente, los cambios en la fuente son mínimos.
me dice, las versiones de GitHub tienen una falla 'en algún lugar' en la compilación ..
Conectado a Wifi en el primer intento, actualización de tiempo instantánea, no se cayó Wifi una vez,
MQTT manteniendo la conexión
etcétera etcétera -
nada que criticar;)

Oxyandy en 5 may. 2018

Entonces, ¿esto significa que mucho tiempo invertido en las últimas semanas (???) puede deberse a problemas de compilación?
Eso es una lástima, pero al menos me da la confianza de que no me estoy volviendo loco, al ver todo tipo de problemas reportados que no pude reproducir ni explicar.

TD-er en 5 may. 2018

😕1

En cuanto al problema de f5: pruebe con lwip de ancho de banda alto, ya que tenía búferes más grandes. Puede fallar un poco más tarde.

s0170071 en 5 may. 2018

Problemas de compilación: está funcionando a 80 MHz, ¿verdad?

s0170071 en 5 may. 2018

80 MHz es el valor predeterminado, supongo.

TD-er en 5 may. 2018

Sé. Pero establecerlo en 160 puede provocar un comportamiento extraño.

s0170071 en 5 may. 2018

Sí, el problema "F5" es el único problema serio que veo hasta ahora en esta versión especial. De hecho, si lo presiono rápidamente varias veces para actualizar la página web de ESP, surgen problemas:

18084332: EVENTO: Reloj # Hora = Sáb, 08:47 Tiempo de procesamiento : 2 milisegundos
18091174: WD: Tiempo de actividad 302 ConnectFailures 0 FreeMem 14504
bcn_timout, ap_probe_send_start
18112119: Uso de RAM: Solo servidor web: 0, incluido el núcleo: 0
18115167: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18116976: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18119084: LoadFromFile: notification.dat index: 0 datasize: 996
18119089: LoadFromFile: notificación.dat índice: 1024 tamaño de datos: 996
18119092: LoadFromFile: notification.dat index: 2048 datasize: 996
18119129: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18121330: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18121337: WD: Tiempo de actividad 302 ConnectFailures 0 FreeMem 13584
18128862: Uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18130833: Uso de RAM: Solo servidor web: 0, incluido el núcleo: 0
18135120: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18136605: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18138356: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18140067: LoadFromFile: notification.dat index: 0 datasize: 996
18140076: LoadFromFile: notificación.dat índice: 1024 tamaño de datos: 996
18140078: LoadFromFile: notification.dat index: 2048 datasize: 996
18140152: Uso de RAM: Solo servidor web: 0, incluido el núcleo: 0
18144694: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18144700: EVENTO: Reloj # Hora = Sáb, 08:48
18144702: EVENTO: Reloj # Hora = Sáb, 08:48 Tiempo de procesamiento : 2 milisegundos
18148558: Uso de RAM: Solo servidor web: 0, incluido el núcleo: 0
18151336: WD: Tiempo de actividad 303 ConnectFailures 0 FreeMem 12568
18153230: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18153763: Uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18155000: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18155592: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18156416: Uso de RAM: Solo servidor web: 0, incluido el núcleo: 0
18156838: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18164949: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18165234: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18165587: Uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18170770: Uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18170947: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18171120: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18171300: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18171733: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18177686: Uso de RAM: Solo servidor web: 0, incluido el núcleo: 0
bcn_timout, ap_probe_send_start
18181336: WD: Tiempo de actividad 303 ConnectFailures 0 FreeMem 10832
18182865: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18183367: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18188878: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18190025: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18203237: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18203809: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18203817: EVENTO: Reloj # Hora = Sáb, 08:49
18203819: EVENTO: Reloj # Hora = Sáb, 08:49 Tiempo de procesamiento : 2 milisegundos
bcn_timout, ap_probe_send_start
bcn_timout, ap_probe_send_start
bcn_timout, ap_probe_send_start
18496844: uso de RAM: solo servidor web: 0, incluido el núcleo: 0
18496850: WD: Tiempo de actividad 304 ConnectFailures 0 FreeMem 8736
18496856: EVENTO: Reloj # Hora = Sáb, 08:53
18496858: EVENTO: Reloj # Hora = Sáb, 08:53 Tiempo de procesamiento : 2 milisegundos

Después de los últimos tres mensajes bcn_timout, ap_probe_send_start, el dispositivo se congeló durante aproximadamente 60 segundos incluso en la consola serie, luego continuó funcionando sin reiniciar.

Sí, está funcionando a 80 MHz - La información del sistema dice: Frecuencia de chip ESP: 80 MHz

Las respuestas web de ESP son realmente rápidas hasta que trato de actualizar demasiado rápido ...

ghtester en 5 may. 2018

mañana a todos ... mis unidades funcionan de forma estable durante unas 10 horas. sin embargo, los problemas a veces surgen solo después de uno o dos días, así que los dejo funcionando así. una unidad se reinicia dos veces durante la noche (de 16 D1), lo que podría estar relacionado con un complemento o algo así ... los conceptos básicos de sonoff también funcionan sin problemas.

clumsy-stefan en 5 may. 2018

Sé que no pudo ver o explicar TD-er, pero ¿usó las compilaciones de GitHub como prueba?
Podría volver a la fuente de los lanzamientos del mes pasado y compararlo con el homebrew.
He tenido muchos que consideré inútiles, una de mis pestañas en Notepad ++ tiene la lista

Oxyandy en 5 may. 2018

Acerca de F5, no es realmente un problema: lo uso como punto de referencia, no tengo actualización automática para la tecla F5,
así que lo estoy presionando manualmente, viendo el uso de RAM y la salida de registro en serie al mismo tiempo.
"lwip high bandwidth" de la memoria casi instantáneamente
LmacRxBlk:1 errores y no fueron recuperables ..
Lo que me recuerda que debo escribir algo sobre ... en la lista de tareas pendientes ...
Y probaré diferentes configuraciones de compilación nuevamente como medida

Oxyandy en 5 may. 2018

Hmm, no sé si la razón fue que configuré una pantalla LCD en la posición 12, pero poco después perdí la conexión al AP y ya no puedo volver a conectarme (no se encontró AP a pesar de que es visible por wifiscan). Después de reiniciar el mismo problema. Luego, el dispositivo ingresó en modo AP, pero tal vez debido a los subrayados en el nombre SSID, decía:

1127917: WIFI: Error al iniciar el modo AP con SSID: ESP_01_1 IP: 192.168.4.1

Pero el dispositivo era visible como AI-THINKER_XXXXXXX, pude conectarlo, pero cuando intenté cambiar el nombre del dispositivo, etc., experimenté la pérdida de conexiones con el dispositivo, fallas y reinicios, etc. :-(

Actualización: después de varios intentos, cambié el nombre del dispositivo para eliminar el subrayado, pero todavía está antes del número de dispositivo:
599417: WIFI: Error al iniciar el modo AP con SSID: ESP-001_1 IP: 192.168.4.1
Y el dispositivo sigue siendo visible como AI-THINKER_XXXXXXX
Ya no puedo conectarme a mi AP como cliente ... Intentaré restablecer la configuración de fábrica ...

Update2 OK ... Restablecimiento de fábrica, dispositivo visible como ESP_Easy_0 AP ... Configure el WifiSSID y WifiKey a través de la consola en serie, el dispositivo se conecta inmediatamente al AP ...

ghtester en 5 may. 2018

la mayoría de mis unidades aún funcionan bien ... sin embargo, no creo que sea una cuestión de compilar dos veces ... la única diferencia es que algunas bibliotecas se compilan solo la primera vez, luego de eso, cuando el SDK ve que no cambió, no se recompilará ...

otra cosa que voy a intentar ahora es que en lugar de especificar la placa "D1 Mini" en arduino, configuro todos los parámetros yo mismo y uso el módulo "genérico 8266" ... veremos si esto hace una diferencia ...

actualmente lo único que veo son algunos reinicios espontáneos de ciertas unidades ... pero esto podría estar relacionado con otras cosas ...

una pregunta mía: sonoff basic solo tiene 1M de memoria ... ¿alguna posibilidad de actualizar estas cosas con OTA? obviamente siempre dice "no hay suficiente memoria" ... ¿alguna idea?

PD: sobre problemas de compilación, siempre usé binarios autocompilados (otros complementos) desde el principio, y tenía los "mismos" problemas de estabilidad ... así que algunos de ellos realmente podrían estar relacionados con platformIO, otros creo que eran problemas "reales". ..

clumsy-stefan en 5 may. 2018

Puede usar menos complementos al compilar. Mire https://github.com/letscontrolit/ESPEasy/blob/mega/src/define_plugin_sets.h

Nunca podrá usar OTA directamente, pero de esta manera es al menos lo suficientemente pequeño como para OTA en dos etapas. Mira la wiki para ese :)

louis-lau en 5 may. 2018

eso es exactamente lo que hice ... es por eso que siempre estoy compilando automáticamente ... pero incluso con solo 2 complementos habilitados, el boceto usa 500k ...
por eso estoy buscando una solución diferente (por ejemplo, sin interfaz web ... etc.).

clumsy-stefan en 5 may. 2018

500k es lo suficientemente pequeño. Como dije, OTA de dos partes. No puede actualizar directamente. Mira la wiki :)

louis-lau en 5 may. 2018

gracias .. buscando ....;)

agregue: de alguna manera me perdí la parte de dos pasos ...

clumsy-stefan en 5 may. 2018

Con 1M Sonoffs, necesitará usar un cargador inicial que tenga el indicador DOUT en el encabezado,
de la memoria, el del Wiki no lo es, pero es posible que se haya actualizado recientemente.

Oxyandy en 6 may. 2018

Recuerdo algo así, acabo de buscar y estoy usando este para OTA: https://github.com/soif/EspBuddy/blob/master/firmwares/ESPEasyUploader.OTA.1m128.esp8266.bin

louis-lau en 6 may. 2018

Sí, comprobado que es DOUT
Aquí hay uno que armé, es más pequeño
Initial_Firmware_Uploader_Sonoff_1M_DOUT.zip

Oxyandy en 6 may. 2018

Dije que lo haría porque tenía mucha curiosidad ........
Como comparación con Self_Compiled mega-20180422 con GitHub lanzado, hasta ahora, probé solo uno
ESP_Easy_mega-20180422_normal_ESP8266_1024.bin
Dejé un comentario e inicié sesión en su comportamiento aquí https://github.com/letscontrolit/ESPEasy/issues/1301#issuecomment -383433822 (GitHub lanzado)
Misma fuente autocompilada, no es de extrañar, veo un comportamiento diferente al de Nightly.
¡Se mantuvo conectado, horror de shock!
GitHub lanzó mega-20180422, brilló en la parte superior, exactamente el mismo comportamiento que informé cuando lo probé por primera vez.
No permanecería conectado, WIFI : Disconnected! Reason: '(200) Beacon timeout' bicicleta una y otra vez
La causa necesita ser investigada ... suspiro
Lanzamiento de GitHub = ¿no es de confianza?

Oxyandy en 6 may. 2018

Publiqué las banderas del compilador de Arduino ayer más o menos. ¿Qué banderas usa Travis?

s0170071 en 6 may. 2018

👍1

Tengo 16 D1 y 3 básicos ejecutándose en f69e476 autocompilado, Core 2.4.1, lwIP2 High bandwith.
Casi todos ellos con un tiempo de actividad de> 900 min. ahora y sigue funcionando bien. 2 de ellos cambiaron al modo AP hace aproximadamente una hora y no se volvieron a conectar hasta ahora. Esperaré hasta esta noche para ver si se recuperan.

desafortunadamente, el comportamiento no es realmente reproducible, y realmente no puedo proporcionar ninguna evidencia de dónde llegan los problemas, pero continuaré buscando fallas e informaré si encuentro algo ...

@Oxyandy : ¡También volví a compilar una carga para mis trabajos básicos bien! gracias de nuevo por señalarme la dirección correcta ..;)

clumsy-stefan en 6 may. 2018

@ s0170071
Están almacenados en .travis.yml y platformio.ini
Me apresuré a leer, tada, mira lo que encontré
skip_cleanup: true
Editar: lectura adicional, no estoy seguro de si esto se refiere a hacer una construcción limpia .
Admito que es todo nuevo para mí ... ??? ¿Deshabilitar el almacenamiento en caché?

Oxyandy en 6 may. 2018

Travis hace una compilación limpia cada vez, ya que incluso descarga el entorno de Python, etc.

Las compilaciones nocturnas las realiza @ psy0rz , no Travis

TD-er en 6 may. 2018

👍1

Okee dokee, ¿son construcciones limpias?
¿Tratando de entender por qué se comportan de manera diferente?

Oxyandy en 6 may. 2018

¿Qué hay de comparar MD5 de bin1 y bin2?
Indicará si es un problema de tiempo de compilación o tiempo de ejecución ...

susisstrolch en 6 may. 2018

@susisstrolch, ¿ te refieres a cuando te compilas? Es porque el MD5 se calcula después de la compilación. Hay un guión que lo hace por ti.
https://github.com/s0170071/CRC4ESP

-editar: @susisstrolch Puede que te haya
sí, puedes comparar el md5, deberían ser idénticos. Si lo hace fuera de línea, también podría comparar los binarios bit a bit. De esta manera, incluso puede saber dónde está la desviación. Si está avanzado, incluso puede retroceder hasta el código. El archivo .elf debe tener toda la información.

De todos modos, no me importa mucho qué difiere exactamente. Creo que es más importante asegurarse de que todos estén en el mismo binario, sin importar quién lo haya compilado.

Entonces, nuevamente, ¿cuáles son los indicadores de compilación para Arduino, platformio, nightly y travis? Win / Linux ,.

s0170071 en 6 may. 2018

No, me refiero a que en lugar de especular sobre las diferencias en la salida del compilador en las compilaciones automatizadas, simplemente compare el MD5 de ambas compilaciones. Para que pueda saber exactamente si difieren.

susisstrolch en 6 may. 2018

Las banderas para Arduino IDE en Linux son:

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


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

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

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

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

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

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

s0170071 en 6 may. 2018

@ s0170071 Traté de preguntarle a Edwin, pero aún no ha respondido.
Entonces, por ahora, no sabemos exactamente qué se está haciendo para las compilaciones nocturnas.
Y aún permanece el comportamiento extraño (que experimenté también en mi configuración) que compilarlo dos veces da resultados diferentes.
Los binarios entre compilaciones no se pueden comparar mediante una suma de comprobación. Se incluye una marca de tiempo de compilación, que será diferente para cualquier compilación. Por lo tanto, compilar la misma fuente 100 veces dará 100 sumas de comprobación diferentes.
Pero al menos debería brindar la misma funcionalidad y eso parece no estar sucediendo (a veces) entre la primera y la segunda compilación. Y no es así como debería ser.

TD-er en 6 may. 2018

Entonces, para propósitos de prueba y para concretarlo, omitiría configurar todos los cambios de precompilación entre esas compilaciones consecutivas para obtener un src comparable.

susisstrolch en 6 may. 2018

@ s0170071, por lo que obtenemos mucha información de depuración debido a la opción -g al compilar con Arduino IDE.
Quizás un punto para reducir el tamaño ...

susisstrolch en 6 may. 2018

La reducción de tamaño es algo que debemos tener en cuenta en el futuro, pero debe tener cuidado al cambiar los indicadores de optimización. Algunos pueden dar lugar a problemas aún más difíciles de reproducir.

TD-er en 6 may. 2018

los dos untis se recuperaron algunas horas más tarde durante el día, pero otros fallan al azar ... dos cosas que encontré hasta ahora:
Recibo entradas en el registro que dicen:
96493069: IP bloqueada: 0.0.0.0 Permitida: 10.0.0.0 - 10.0.255.255
96517068: WD: Tiempo de actividad 1608 ConnectFailures 0 FreeMem 11544
la primera línea me parece extraña, ¿qué intenta conectar con IP 0.0.0.0? esto podría estar relacionado con los problemas que vi hace algunos días, que la unidad es accesible, pero me dice que tiene IP 0.0.0.0.

En segundo lugar, aunque no se hizo nada durante las últimas 24 horas, veo saltos repentinos en la carga de la CPU, incluso en unidades "pequeñas", que solo están usando la funcionalidad del interruptor (por ejemplo, Nr. 7 en el gráfico adjunto).

¿Alguna posibilidad de averiguar por qué ocurren estos cambios repentinos en la carga de la CPU? el registro no dice nada específico .. (Carga de CPU de hoy y ayer) ...

clumsy-stefan en 6 may. 2018

¿La carga de la CPU salta en el momento de reiniciar?
La forma en que se calcula la carga de la CPU es un poco extraña.
Toma el número de veces que se ejecuta la función de bucle principal en 30 segundos.
Esto se compara con el recuento máximo observado.
Esto significa que durante el funcionamiento, el recuento máximo observado puede aumentar, pero también que puede disminuir repentinamente después de un reinicio.

TD-er en 6 may. 2018

no, no en un reinicio ... solo "al azar" en algún momento ... curiosamente le sucede a varias unidades a la vez ... no tengo ni idea de lo que sucedió allí (no estaba en casa entonces) ... especialmente las unidades 12- 14 son tableros realmente simples sin tareas excepto rssi, carga, tiempo de actividad y mem ... también los gráficos de memoria no muestran signos de cambios significativos ...
todavía ahora, la carga en algunas unidades muestra ~ 50% pero la interfaz web es rápida ..

También tengo en una unidad un reloj impulsado por nfx que cambia cada segundo la posición de las manecillas. Curiosamente, el reloj se detuvo en un punto en el tiempo, pero la unidad continuó funcionando sin problemas ... como si esta tarea ya no se ejecutara ... pero esto podría estar relacionado con el complemento (ya que es uno de los juegos) ... pero podría probablemente apunte a problemas ...

pero como dije, actualmente no tengo ni idea de dónde pueden provenir todos estos problemas ... realmente solo estoy hurgando tratando de encontrar algo ... y dando retroalimentación a todos para una lluvia de ideas ...

de todos modos, muchas gracias por sus esfuerzos y ayuda ... si encuentro algo razonable, lo reportaré ...

clumsy-stefan en 6 may. 2018

También podría significar que todos los servicios cambiaron de disponibilidad en algún momento.
O estuvo disponible, lo que provocó que los nodos hicieran más trabajo.
O ya no estaba disponible. ESPeasy intenta hacer ping a un host para detectar su disponibilidad. Si ese ping falla, detendrá el nodo durante el período de tiempo de espera.

TD-er en 6 may. 2018

¿Cómo se hace ese "ping"? porque veo algún "host desconocido" de vez en cuando ... ¿podría ser que este tiempo de espera sea bastante grande? ¿O el ping o la búsqueda de DNS tienen tiempos de espera cortos? En realidad, ya no uso FQDN, solo IP, por lo que es menos probable que el DNS sea un problema ...

Solo estoy actualizando con la última confirmación ... algunas unidades son fáciles de actualizar y bastante rápidas, otras muy lentas ...

Tengo 4 AP ejecutándose en el mismo SSID, ¿también es posible que a veces seleccione uno peor y luego tenga problemas de velocidad?

clumsy-stefan en 6 may. 2018

Estaba planeando cambiar la forma en que se hace un ping a un ping asincrónico.
Al intentar establecer una conexión, hay una verificación para ver si el host está disponible. Eso se hace mediante ping.

TD-er en 6 may. 2018

y esa es una llamada de bloqueo?

clumsy-stefan en 6 may. 2018

De hecho, es por eso que quiero cambiarlo a alguna variante asíncrona.

TD-er en 6 may. 2018

hmm ... esto podría explicar, cuando la conectividad de la red es débil, que las cosas no son realmente "fluidas" ... especialmente cuando se intenta cargar un nuevo boceto ... ¿es posible aumentar el tiempo de espera del ping si la red tiene mucho de latencia?

clumsy-stefan en 6 may. 2018

Solo se hace al hacer una conexión.
La carga experimentada de un reintento de conexión MQTT que fallará es mucho más notable.
Realmente no hay muchos hosts con los que nos estamos conectando, por lo que tal vez debería haber alguna verificación de disponibilidad asíncrona ejecutándose en segundo plano para ayudar a decidir si volver a conectar o no.
Nota: una búsqueda de DNS también puede bloquear bastante cuando finalmente fallará.

TD-er en 6 may. 2018

¿Podría ser que 0.0.0.0 sea el DNS secundario?

giig1967g en 6 may. 2018

Me di cuenta de esto con DNS, es por eso que ahora solo uso direcciones IP ... No uso MQTT en absoluto, solo el complemento del controlador fhme y las consultas json regulares (de fhem con el complemento HTTPMOD).

Una cosa que probablemente voy a intentar es deshabilitar la conexión en red UDP inter-ESPEasy ... No puedo deshacerme de la sensación de que esto tiene cierta influencia en las unidades, especialmente cuando se ejecutan más de 15 unidades que envían actualizaciones periódicas. ..

clumsy-stefan en 6 may. 2018

después de actualizar todas las unidades a la última mega confirmación, todas las cargas de la CPU volvieron a la "normalidad" ... esta mañana alrededor de las 8 reinicié Nr. 4 y 9, y vea qué pasó con la carga de la CPU, casi todas las unidades tuvieron un pico de aproximadamente 30 minutos. y volvió a la normalidad después de eso ...

sólo una idea rápida: ¿es posible que los eventos UDP recibidos entre ESPEasy se "redistribuyan" a otras unidades y por lo tanto podrían generar un bucle y llenar la pila de la red?

clumsy-stefan en 7 may. 2018

Nunca miré el código de estas 'comunicaciones entre ESPeasy', por lo tanto, no puedo decir nada al respecto.
Esperaría que este protocolo solo envíe sus propios datos y no se haga eco del resto.
Este protocolo consta de 2 partes:

Declarando su propia presencia.
Envío de valores de parámetros de complementos a través de lo que solía ser "sincronización global".

Ese último ahora se reemplaza por "controlador c_013".

Pero no estoy seguro si no es posible un bucle. Por ejemplo, con dispositivos ficticios, importación MQTT, etc.
También puede haber un comportamiento diferente entre las versiones antiguas y las versiones nuevas que utilizan el "controlador 13".

TD-er en 7 may. 2018

ok, gracias por la rápida respuesta ... Voy a apagarlo ahora, resp. configurar el puerto UDP en 0 y ver si algo cambia ...

Agregue: después de cambiarlo, veo que aproximadamente el 50% de las unidades se reinician (sin que se me indique que lo haga) ... y algo de "HTTP: error de conexión" en el registro ...

clumsy-stefan en 7 may. 2018

He notado un problema similar con la carga de la CPU. Wemos está ejecutando un FW autocompilado con 13 complementos. Estoy usando Rest API con Pimatic. Como puede ver, por alguna razón, la carga sube al 90% o más.

jopiekr en 7 may. 2018

para obtener información: desde que apagué la red Inter-ESPEasy estableciendo el puerto en 0 en la configuración avanzada, ¡parece que (la mayoría de) mis problemas han desaparecido! las 20 unidades tienen tiempos de actividad> 20 min. y todavía informan valores con regularidad. web-si está en funcionamiento. Además, el gráfico de CPU ya no muestra estos saltos repentinos. Solo una unidad cambió al modo AP, veré si se recupera ...
probablemente esta necesidad de investigar (en la fuente) ... con muchas unidades, el UDP-cosas probablemente está sobrecargando la pila de red ...
Espero que esto ayude a otros que enfrentan problemas similares ...

clumsy-stefan en 8 may. 2018

Aquí mi experiencia:
6 unidades todas con IP estática y Red Inter-ESPeasy activa.
El último firmware cargado fue "Mega 20180505 Manual construido dos veces". (pero los firmwares anteriores también funcionaban muy bien).
Han estado funcionando durante casi 3 días sin ningún problema.

immagine

giig1967g en 8 may. 2018

Esa es una de las razones por las que quiero esperar unos días antes de hacer algunas correcciones de red / wifi. Simplemente déjelo correr por un tiempo para ver qué está realmente mal e intente leer algunos problemas en la lista de problemas de Arduino.
Ya noté que una serie de problemas sugieren deshabilitar la administración de energía para algunas configuraciones de wifi. Aparentemente, algunas combinaciones de punto de acceso ESP8266 + no funcionan bien con las funciones de administración de energía habilitadas (que están habilitadas de manera predeterminada)
Esa es una opción para agregar a ESPeasy.

Estoy buscando más ideas los próximos días y los viernes / sábados tengo más tiempo para codificar.

TD-er en 8 may. 2018

Como referencia, mi punto de acceso es ASUS RT-AC68U con firmware Merlin

giig1967g en 8 may. 2018

Supongo que la mayoría de los problemas se deben al firmware predeterminado de fábrica para los modelos más económicos y quizás a los puntos de acceso algo más antiguos que no conocían las opciones de ahorro de energía de los dispositivos wifi modernos.
La pregunta sigue siendo si es posible negociar tales características para detectar automáticamente estas características.

TD-er en 8 may. 2018

¿Qué pasa con dejar deshabilitado de forma predeterminada y habilitar solo si se solicita en la página de configuración?
Las opciones de ahorro de energía tienen sentido solo para dispositivos que funcionan con batería, supongo.

giig1967g en 8 may. 2018

También tienen sentido para otros fines.
Más potencia significa más calor y algunos están encerrados con sensores ....;)

TD-er en 8 may. 2018

Además de la alta carga del procesador. Volví a un firmware de fecha 16/03 con 2.3.0 Core y todo volvió a la normalidad. Cargas ahora máx. 25%. Además, el tiempo de respuesta de los wemos vuelve a ser mucho mejor. Tanto con el 08/05 como con el 16/03 no tengo desconexiones WiFi en absoluto. Todavía no tengo idea de qué causó la alta carga. Además, en ambos casos no utilicé udp.

jopiekr en 10 may. 2018

desde la desactivación de UDP, las unidades funcionan sin problemas, excepto las que tienen una pantalla LCD adjunta. Creo que si tienes muchas unidades hablando (> 20), se ocupan demasiado de decodificar todos los mensajes UDP o tienen alguna pérdida de memoria o algo similar. Eso también explicaría los reinicios instantáneos de unidades después del inicio de otra. solo MHO ... necesito depurar más para estar seguro ...

clumsy-stefan en 11 may. 2018

También puede estar relacionado con realizar tareas más largas sin tiempo para algunas llamadas a yield() , lo que también se hace al llamar a delay() .
Me imagino que el complemento LCD (y tal vez algunos otros también) realice algunas tareas que demoren> 10 ms.

TD-er en 11 may. 2018

las unidades con LCD parecen volverse más ocupadas con el tiempo ... cuando intento volver a flashear, necesito reiniciarlas primero, porque después de algunas horas la carga ya no funciona (o lleva años ...)

todas las demás unidades funcionan bien ahora, pero como se dijo, el anuncio entre ESP debe desactivarse ...

al menos WiFi es estable así, no hay otros problemas con la conectividad hasta ahora ... (ejecutando más de 20 unidades por ahora)

clumsy-stefan en 11 may. 2018

¿Tiene el registro habilitado en el puerto serie?
¿Quizás podrías establecer eso en "Ninguno"?

TD-er en 11 may. 2018

hmm ... punto interesante, tengo la "información" predeterminada en el registro del puerto serie, pero desactivé el puerto serie por completo para abajo ... ¿podría causar problemas?

Voy a cambiarlo a "ninguno" en las unidades, veré si eso hace una diferencia.

clumsy-stefan en 11 may. 2018

He escuchado informes antes, sobre los datos que no se obtienen de los búferes seriales se acumularán.
Y me di cuenta de que en un nodo en ejecución, cuando conecté el monitor en serie, recibí datos del momento en que se inició, como un minuto antes.

TD-er en 11 may. 2018

A continuación, la diferencia entre el núcleo 2.3.0 y 2.4.1 10 de mayo he cambiado el FW de 2.4 de nuevo a 2.3. La configuración y las reglas para ambos son exactamente las mismas.

jopiekr en 11 may. 2018

@jopiekr : ¿cuál es el software que está utilizando para imprimir la carga de la CPU?

giig1967g en 11 may. 2018

@ gii1967g es pimatic. Tenerlo funcionando en un OrangePi One durante más de un año sin ningún problema. Como respaldo también en una Raspberry Pi. pimatic.org

jopiekr en 11 may. 2018

cambió todos los registros de serie a ninguno ahora ... Veré qué sucede ...

lo que también es notable es el RSSI wifi ... si las unidades tienen una señal débil, pueden no responder ... como tengo 4AP en ejecución, parece un poco "aleatorio" al que se conectan y no siempre toman el más fuerte una....

clumsy-stefan en 11 may. 2018

He notado que por encima de -77dB pueden dejar de responder. Además, cuando no funcionen con baterías, verifique la renovación del tiempo de arrendamiento de su enrutador. He establecido una regla para reiniciarlos después de 12000 minutos.

jopiekr en 11 may. 2018

Deberían volver a conectarse al último. El primer intento de reconexión es al BSSID de la última conexión activa.
Pero supongo que deberíamos agregar el BSSID a la configuración.

Los últimos días he estado pensando mucho en los problemas de wifi y se me ocurrió algún tipo de solución para los errores que probablemente estén presentes en la biblioteca principal o en una combinación con las versiones de firmware AP que existen.
Actualmente, la biblioteca principal hace un escaneo cuando intenta conectarse usando solo un SSID + pwd.
De esta manera, es mucho más rápido cuando proporciona el canal BSSID + al conectarse.
Porque entonces no tiene que escanear.
Entonces, ¿por qué no escanear nosotros mismos, encontrar el SSID conocido, almacenar todos los canales BSSID + para las redes coincidentes y luego intentar conectarse solo usando el canal BSSID +?
Luego, también tiene la conmutación por error automática y tiene control total sobre cuándo considerar la renovación de una conexión. (y así reiniciar los servicios)

También conoce el RSSI más fuerte, así que conéctese primero al más fuerte e intente siempre reutilizar el último utilizado primero
Y cuando la conexión sea inestable, intente deshabilitar la función de ahorro de energía que está habilitada de forma predeterminada en el núcleo 2.4.x.
Esta función de ahorro de energía puede provocar reconexiones de wifi, bloqueos al navegar por las páginas web o incluso rechazos al conectarse.

Con la función de ahorro de energía habilitada, el wifi se apaga por un tiempo y luego se habilita nuevamente justo a tiempo para recibir la señal de baliza del punto de acceso.
Si no están sincronizados, es posible que algunos paquetes no lleguen al ESP y solo se retransmitirán cuando se reciba la siguiente señal de baliza. (que puede tardar un poco)

No conozco mucho de los detalles específicos de estos problemas de ahorro de energía, pero sé lo suficiente sobre el desarrollo de firmware para saber que es posible que los estándares no se implementen de la misma manera entre los proveedores. Por lo tanto, es muy probable que haya algunas combinaciones de hardware que funcionen de manera menos óptima con las funciones de ahorro de energía habilitadas. Incluso puede ser algún otro dispositivo WiFi que retrase el intervalo de baliza wifi del punto de acceso. Hay demasiadas variables.

Una desconexión temporal de este tipo también puede afectar las búsquedas de DNS y otras interrupciones de la conexión que pueden detener el ESP por un tiempo. Esto también podría afectar la carga de la CPU, ya que ese valor (mal definido) se basa en cuántas veces se ejecuta la función loop () en 30 segundos. Si una llamada a alguna solicitud de resolución de DNS detiene el ESP, el recuento de bucles será bastante bajo y, por lo tanto, se informará de una alta carga de CPU.

TD-er en 11 may. 2018

@jopiekr También podría emitir un reinicio, supongo, por las reglas.
Primero buscaré deshabilitar las opciones de ahorro de energía (y, por supuesto, lo haré seleccionable)

TD-er en 11 may. 2018

@ TD-er sobre el manejo de WiFi: Estoy completamente de acuerdo con la función de administración de energía. Uno debería poder apagarlo, ya que puede causar problemas realmente extraños y dispositivos retrasados ...

Para la reconexión al AP lo veo diferente, siempre trato de conectarme al AP más fuerte para asegurar una buena conexión. solo después de eso probablemente tomaría el último. Simplemente porque si el AP "principal" falla / reinicia / no responde, etc., la unidad se conectará a otra. A partir de ese momento en adelante, siempre tomará ese (peor) hasta que este también falle ... nunca volverá al fuerte, incluso si este vuelve a subir ... también si mueves los dispositivos , podría ser que seleccione el AP anterior aunque ese esté mucho más lejos / tenga una señal más débil ...

Sin embargo, estoy de acuerdo en escanear dentro de su código y luego decidir cuál tomar en función de RSSI y BSSID conocido ...

clumsy-stefan en 11 may. 2018

Es solo el primer intento de volver a conectarse al último BSSID conocido.
Esto dará como resultado una conexión más estable al usar repetidores.
A veces, esos repetidores pueden interrumpir las conexiones cuando están demasiado ocupados manejando otras tareas y pueden parecer menos fuertes al escanear. Los baratos solo tienen una radio para recibir y transmitir, por lo que cuando reciben datos, puede ser que no estén transmitiendo su señal de baliza en el momento en que se realiza un escaneo. Entonces, el RSSI de otro AP puede parecer más fuerte en ese momento.

TD-er en 11 may. 2018

ok, ¿qué tal un escaneo "regular" que realiza un seguimiento de la fuerza? o al menos después de un reinicio debería reevaluar qué punto de acceso elige ...

clumsy-stefan en 11 may. 2018

En el reinicio y si falla el primer intento de reconexión, realizará un escaneo y seleccionará la coincidencia más fuerte para el SSID configurado.

Cambiaré eso para almacenar el BSSID del AP preferido en la configuración, para que ese BSSID sea siempre el preferido.
Las reconexiones son realmente rápidas si también se conoce el canal. (es posible sub 200 mseg, dependiendo del AP utilizado)
Además, la configuración de IP estática tarda entre 20 y 25 ms, en comparación con DHCP, que tarda de 2,5 a 10 segundos.
Eso sería ideal para dispositivos que funcionan con baterías.

Así que hay margen de mejora :)

TD-er en 11 may. 2018

Suena muy prometedor. Hasta ahora tengo 2 meses de duración de la batería con baterías 2AA que aumentan a 3.3V y un sensor DHT que se envía cada 900 segundos. Está en una placa RobotDyn ESP Pro con el regulador de voltaje retirado.

jopiekr en 11 may. 2018

@ TD-er Acabo de probar la compilación de ayer. No veo ninguna diferencia en los tiempos de conexión si uso una IP estática o DHCP. Ambas conexiones tardan unos 3 segundos después del reinicio.

s0170071 en 11 may. 2018

Entonces tienes un servidor DHCP rápido.
Mi Fritzbox tarda unos 2,5 segundos para el DHCP, después de los 2,5 segundos que se conectan a wifi.
Por lo tanto, la configuración del tiempo MQTT connect + NTP tarda entre 6 y 6,5 segundos desde el inicio.

TD-er en 12 may. 2018

Caja Fritz 7490.

s0170071 en 12 may. 2018

actualización rápida: después de deshabilitar InterESP UDP (y eliminar C13 de unidades 1M) y configurar el registro serial en "no" (también deshabilitar el puerto serial) casi todas mis unidades funcionan de forma estable durante las últimas 30+ horas ... una mezcla entre D1 Mini, D1 pro, Sonoff Basic, Dual y 4ch ... 20+ unidades ... ejecutándose en commit desde mega-20180511, autocompilado con Arduino IDE ...

clumsy-stefan en 12 may. 2018

🎉1

Tengo el 7581 como módem y 3 * 1750E como puntos de acceso.

TD-er en 12 may. 2018

Por cierto: estoy ejecutando Mikrotik AP (y un USR realmente antiguo). Vamos a actualizar las unidades ahora con la última confirmación de esta noche ...

clumsy-stefan en 12 may. 2018

Las últimas confirmaciones actualmente solo tratan con el código relacionado con JSON (visor de registro + valores de sensor de actualización).
Todavía no con el código wifi.

TD-er en 12 may. 2018

seguro, pero wifi parece ser "lo suficientemente estable" con las últimas confirmaciones, así que quiero estar al día con mis unidades;)

clumsy-stefan en 12 may. 2018

Lamento traer esto a colación de nuevo, pero sigo teniendo el problema de que el ESP cree que tiene una IP de 0.0.0.0 y deja de hablar con el servidor, bit a nivel de red y web, ¡todo está bien! ver captura de pantalla adjunta, lo probé con diferentes combinaciones de versiones de ESPEasy y esp8266 ...
¿Alguien experimenta esto?
untitled

clumsy-stefan en 31 may. 2018

Muy extraño de hecho, ya que me pregunto cómo se puede ver la página web con tal configuración de IP.
¿O se conecta al ESP a través de su función de punto de acceso?

TD-er en 31 may. 2018

no, conectado a través de la red directamente. ping y http funcionan sin problemas, rápido, (vea que la IP del cliente es 10.0.0.10, que es mi computadora portátil, la red interna es 10.0.0.0/16) ... sí, aunque bastante extraño ...
puede estar relacionado con DHCP o algo así ... después de reiniciar, todo está bien de nuevo ...

¿Podría estar relacionado con el hecho de que solo habilité un controlador (FHEM) y ningún controlador habilitado para MQTT? Vi mucho código mqtt en las fuentes, fuera del complemento del controlador ... solo una suposición ... pero creo que no está realmente relacionado ...

clumsy-stefan en 31 may. 2018

¿Quizás dhcp caducó y no se renovó?

uzi18 en 3 jun. 2018

muy bien podría ser ... probablemente la pila de red todavía tiene una IP activa, pero si la renovación falla, la configuración correspondiente se pone a cero ... aunque no estoy seguro de cómo funciona el código DHCP, pero podría explicar el estado que estoy viendo.

También descubrí que cuando el servidor (en mi caso, fhem) no responde lo suficientemente rápido varias veces, las unidades comienzan a reiniciarse después de un tiempo. podría ser un problema en el código del complemento o en la pila tcp subyacente ... Hice algunos ajustes de rendimiento en el servidor, ya que entonces las unidades funcionan mucho más estables (algunos tiempos de actividad superan las 48 horas ahora).

clumsy-stefan en 4 jun. 2018

Ya he visto más de 10 días de tiempos de conexión (tiempo de actividad sin reconexión) con las últimas versiones.
Es posible hacer que las unidades llenen su memoria RAM con muchas solicitudes.
Y he visto al LWIP hacer cosas extrañas cuando realiza muchas solicitudes. (lectura de la memoria que no contiene datos relacionados con esa solicitud).

TD-er en 4 jun. 2018

Hoy un nodo deja de responder nuevamente. Se desconectó de wifi. No pude conectarme a la red "esp". Dejó de enviar datos al controlador. Tuve que reiniciarlo. Quizás un perro guardián sería una buena solución. Si, por ejemplo, se desconecta una hora del wifi, se reinicia. O tal vez se pueda hacer con reglas, pero no sé cómo :)

melwinek en 9 jun. 2018

Hoy experimenté muchas acciones de Watchdog mientras depuraba un complemento.
Y ahora sé que, a veces, cuando interviene el perro guardián, un nodo puede permanecer detenido.
Entonces, un perro guardián no es la solución perfecta.

¿Es posible que el nodo colgante tuyo nunca se haya reiniciado después de flashear? (presione reiniciar o apagar y encender)

TD-er en 9 jun. 2018

Es posible que no se haya reiniciado después de flashear. Pero fue un flasheo a través de www, no una serie.

melwinek en 10 jun. 2018

De acuerdo, entonces no debería importar si mostraste OTA.
Siempre que haya habido un reinicio / reinicio adecuado después del flash en serie.

TD-er en 10 jun. 2018

Bueno, después de luchar con muchos problemas de estabilidad y extraños problemas de wifi con las últimas versiones de firmware, tuve que volver a las versiones anteriores al final. Por ejemplo, hasta que ocurrió un corte de energía recientemente, un antiguo nodo ESP12E con mega-20180311dev estuvo funcionando durante 70 días, enviando datos de temperatura a ThingSpeak.
En otro nodo, después de actualizar a mega-20180522dev, estaba experimentando un reinicio debido a una excepción cada 24 horas a pesar del restablecimiento a los valores predeterminados, simplemente ejecutándome sin ningún dispositivo configurado, sin NTP configurado, sin controlador ... Nunca sobreviví 48 horas. Después de degradar a mega-20180324 hace dos días y medio, mantuve la configuración, solo habilité NTP nuevamente y hasta ahora se está ejecutando. Aunque hay algunos errores y funciones faltantes en estas versiones anteriores, para mí es actualmente la mejor opción.

ghtester en 4 jul. 2018

Nadie puede hacer mucho si los problemas no se pueden reproducir de forma fiable.
Lo que ayuda un poco es programar un reinicio cada noche. Puedes usar las reglas para eso.

s0170071 en 4 jul. 2018

Lo sé, pero prefiero un nodo estable sin reinicios programados. No sé si la estabilidad se redujo significativamente debido al cambio al núcleo 2.4.1 (tal vez que aún no es lo suficientemente maduro) o si está relacionado con el rediseño de ESP Easy, pero sucedió a pesar del esfuerzo máximo de todos los colaboradores de ESP Easy. Realmente aprecio el arduo trabajo de todos ustedes, pero actualmente ya no puedo usar las últimas versiones de ESP Easy.

ghtester en 4 jul. 2018

Creo que también está relacionado con el complemento utilizado o tal vez con la combinación de complementos.

La semana pasada trabajé en investigar los efectos de los tiempos y estoy seguro de que tendrá un efecto significativo en las tareas de tiempo crítico.

Solo miré algunos de mis nodos, todos ejecutando compilaciones oficiales:

Nombre de archivo binario ESP_Easy_mega-20180513_normal_ESP8266_4096.bin

Unidad 3

Tiempo de actividad 16 días 18 horas 26 minutos
Conectado 5d23h07m
Razón de la última desconexión (201) No se encontró AP
Número reconecta 2

Unidad 5

Tiempo de actividad 11 días 5 horas 22 minutos
Conectado 5d22h57m
Razón de la última desconexión (201) No se encontró AP
Número reconecta 4

Unidad 6

Tiempo de actividad 11 días 5 horas 23 minutos
Conectado 45 m 1 s
Razón de la última desconexión (201) No se encontró AP
Número reconecta 58

Nombre de archivo binario ESP_Easy_mega-20180619_test_ESP8266_4096.bin

Unidad 7

Tiempo de actividad 13 días 20 horas 51 minutos
Conectado 5d23h05m
Razón de la última desconexión (202) Error de autenticación
Número reconecta 2

Hace unos 6 días, tuve algunos problemas con uno de mis puntos de acceso WiFi, que tuve que reiniciar.

La unidad 6 está conectada a la misma que las unidades 3 y 7, pero tiene muchas más reconexiones.
Esas 3 unidades están una al lado de la otra, a un metro de distancia entre sí para comparar diferentes sensores de CO2 (MH-Z19 A, B y SenseAir S8) y todos funcionan con la misma fuente de alimentación (cargador USB IKEA de 3 puertos).

La única diferencia entre ellos es que el que tiene más reconexiones tiene el sensor Senseair.
Por lo tanto, podría ser que la implementación de ese sensor ejerza más presión sobre la rutina de WiFi (menos llamadas de retraso), lo que podría provocar inestabilidad de WiFi.

¿Podría dar una lista de los complementos utilizados?
También hice una solicitud de extracción ayer que registra muchas estadísticas de tiempo. Tal vez puedas crear una compilación basada en esa y ejecutarla durante unos minutos para tener una idea de los complementos que usan demasiado tiempo.

TD-er en 4 jul. 2018

Siempre estoy usando las compilaciones oficiales ya que no puedo preparar y mantener el entorno de desarrollo para estos dispositivos.
La versión mencionada mega-20180522dev, como describí anteriormente, era una configuración completamente vacía, por lo que no se usaron complementos, ni reglas, incluso eliminé el controlador predeterminado Nr1 al final. Nada podría detener el reinicio del nodo debido a una excepción a intervalos de 24 a 40 horas.

ghtester en 4 jul. 2018

No sé si es un problema de wifi, no lo parece, me las arreglé para configurar direcciones IP estáticas para wifi, pero aún así, es muy fácil buscarlas por dhcp y configurarlas diferentes.

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

scandone

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

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

uzi18 en 4 jul. 2018

@ uzi18 ¿Ha configurado todos los campos para la configuración de IP estática?

Si es así, me temo que es un problema conocido (para mí), donde hay alguna sesión anterior almacenada en una región donde (todavía) no borramos los datos en un restablecimiento de fábrica.
Esto significa que en este momento no hay otra forma que borrar todo el flash y comenzar de nuevo con una versión reciente de ESPeasy.
Las versiones posteriores establecen un valor para no hacer que la configuración de wifi sea persistente.

TD-er en 5 jul. 2018

@ TD-er Sí, todos los datos llenados, como puede ver en el registro.
He flasheado el módulo NUEVO, con
INFORMACIÓN: Complementos: 71 [Normal] [Prueba] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
y funciona así.
El módulo solo se tomó de la bolsa original y se destello, especialmente nunca antes aquí.

uzi18 en 5 jul. 2018

@ TD-er: Dos pensamientos sobre eso:

Mi calefacción no ESPEasy para la emisora MQTT funciona perfectamente con el último cliente pubsub. Se vuelve a conectar y así sucesivamente. Tal vez la vigilancia de conectividad ESPEasy esté interfiriendo con lo que ya ha hecho la biblioteca central. ¿Deberíamos tener una forma de deshabilitar todas esas cosas adicionales ping-recnect-wifistate? ¿Solo para probar?
¿Conoce el apagado automático de wifi? https://blog.creations.de/?p=149

s0170071 en 5 jul. 2018

Sería bueno si alguien con wifi bastante inestable pudiera probar este PR: https://github.com/letscontrolit/ESPEasy/pull/1562

TD-er en 12 jul. 2018

@ TD-er acaba de encontrar https://github.com/esp8266/Arduino/pull/4718
se ocupa de los problemas de reconexión de lwip. Se arregla mientras tanto. Tal vez quieras omitirlo ...

s0170071 en 13 jul. 2018

Siempre uso la última versión de GIT del esp8266 ... es por eso que probablemente ya no veo el problema 0.0.0.0 ...

clumsy-stefan en 13 jul. 2018

Ayer nuevamente un nodo después del reinicio del enrutador perdió contacto con la red.
Las reglas funcionaron correctamente.
Este es mi propio interruptor de pared, es difícil desmontarlo para reiniciarlo.

Para facilitar esto en el futuro, modifiqué las reglas:

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

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

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

Ahora la vida será más sencilla :))

melwinek en 18 jul. 2018

Reinicio cada 24 horas. Esto revive un nodo con un firmware de hace 4 semanas dos veces por semana.
Quizás esto debería ser una característica permanente ...

s0170071 en 18 jul. 2018

¿Sigue siendo un problema? Si es así, vuelva a abrir.

Grovkillen en 25 oct. 2018

Nuestro hilo más largo en la lista de problemas ...

TD-er en 25 oct. 2018

Espeasy: Problemas de wifi - nunca termina la historia - ¿volver a wifi no basado en eventos?

Comentario más útil

Todos 388 comentarios

si está definido (ESP8266)

terminara si

undef PLUGIN_BUILD_NORMAL

undef PLUGIN_BUILD_TESTING

undef PLUGIN_BUILD_DEV

definir PLUGIN_BUILD_CUSTOM

undef BUILD_UPLOADER

si está definido (BUILD_UPLOADER)

demás

terminara si

undef BUILD_GIT

definir BUILD_GIT "2abec2b" `

Temas relacionados