Parece estar relacionado con el cambio de serie que hice recientemente.

¿Qué pines gpio usas?

Puede ser, a ver, supongo que has encontrado un punto Gijs :-)

esp01 = Gpio0 Gpio2 (todavía no se han visto problemas)
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

Pedro

Tengo dos nodos aquí que también puedo probar más tarde esta tarde

OK,
La falla no es inmediata, dejan de enviar después de un tiempo y persisten bastante en eso, luego, reiniciar o cambiar a una versión anterior no es suficiente para que envíen datos nuevamente. Necesitan un ciclo de encendido y algo de tiempo entre apagado y encendido.

¿Cuánto dura "después de un rato"?
Acabo de configurar un nodo usando uno de estos sensores y también está conectado un BMP280.
Está utilizando GPIO-14 y -12 para el sensor de CO2.

un par de horas, ayer todo estaba funcionando, esta mañana tenía 3 de 4 con el mismo estado.

¿Y todos arrancaron al mismo tiempo, antes de que dejaran de funcionar?

sí, todos se reiniciaron/actualizaron en una hora, creo, los estaba actualizando ayer por la noche. y durante la noche dejaron de trabajar

Estaba a punto de actualizar mis nodos, pero afortunadamente me di cuenta de esto. @ TD-er, ¿cuál sería el último lanzamiento antes de los cambios en Serial que cree que podría ser el culpable? ¿O sería más útil si actualizo la versión más reciente para ver si experimentaré el mismo problema?

Si las actualizaciones que faltan no son un gran problema, sugeriría la última versión.
Para mantener la versión anterior al envoltorio del puerto serie, podría usar 20181231. (Creo que cometí los cambios este año)

Ayer rebajé los 3 esp "problemáticos" a 20181231, puedo confirmar que todavía están enviando datos sin cambios de hardware, ahora por 24 horas, por lo que esos tres esp todavía usan gpio12 y gpio14 en mi caso

¿Tuviste suerte con la recreación de Gijs?

No, mi nodo sigue enviando valores y está ejecutando la compilación desde el 16 de enero. (núcleo 2.5.0)

Usé ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin en esos nodos, que tiene el núcleo 2.4.1, creo.

@pwassink Eso es correcto.
También puede ver la compilación principal en la página de información del sistema.

Instalé esa versión ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin de regreso al esp02 aquí, veamos si sucede nuevamente

Mmm,
Tal vez el día de la semana o la posición de la luna tenga cierta influencia,
No vi que la falla volviera a ocurrir aquí en los últimos días.

Parece estar funcionando bien aquí también.
Era casi luna llena cuando lo reportaste, así que supongo que debería haber sido así ;)

Actualizar,

Dejé esp02 ejecutándose con la versión ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin que aún funciona como debería.

Ayer actualicé el resto de mis nodos a ESP_Easy_mega-20190121_normal_core_241_ESP8266_4096.bin

Y esp-18 volvió a fallar a las 06:55 hora local, todo funciona como debería, excepto el sensor de Co2 MHZ19, en la pestaña de dispositivos muestra el "último valor conocido" desde aproximadamente las 07:00 y nuevamente con las mismas entradas en el archivo de registro:
MHZ19: Error, tiempo de espera al intentar leer
MHZ19: Respuesta desconocida: 0 0 0 0 0 0 0 0 0

Esp-18 está usando Gpio 14/12
es un Nodemcu con Ch340 version 2 de 3 de ali
El reinicio remoto a través de la consola web no resolvió el problema
nuevamente muestra las entradas mencionadas anteriormente varias veces
Después del ciclo de encendido
78640: MHZ19: Error, tiempo de espera al intentar leer
78641: MHZ19: Error de lectura: suma de comprobación = 202 / 0 bytes leídos => 255/168/12/161/226/255/0/0/0/
78643: MHZ19: se desplazó 1 byte para intentar corregir la alineación del búfer
Después de un tiempo más:
255652: MHZ19: Valor PPM: 1584 Valores Temp/S/U: 25/0/0.00
255656: EVENTO: Rik-CO2#PPM=1584.00
255656: EVENTO: Rik-CO2#PPM=1584,00 Tiempo de procesamiento : 1 milisegundos
255659: EVENTO: Rik-CO2#Temperature=25.00
255659: EVENTO: Rik-CO2#Temperature=25.00 Tiempo de procesamiento :1 milisegundos
255662: EVENTO: Rik-CO2#U=0,00
255662: EVENTO: Rik-CO2#U=0,00 Tiempo de procesamiento : 1 milisegundos

Parece funcionar de nuevo ahora, pero necesitó el ciclo de encendido durante aproximadamente 2 minutos sin energía

¿Necesita hacer algo en ese momento? ¿Puede ser algo que podría provocar un problema de wifi en el ESP?

Nada en absoluto,

No hay reinicios programados, reinicios, copias de seguridad, reinicios de wfi, limpiezas de dhcp o cualquier razón externa en ese momento

Y el wifi sigue funcionando bien, es solo la lectura del mhz19 que se detiene, todos los demás sensores (basados ​​en i2c) en el mismo esp todavía funcionan

Esta mañana a las 03:00 volvió a pasar con Esp-18 ejecutando la versión 0121 Mega, Mismos errores en esp-logfile que antes, otros sensores funcionan bien

Y a las 19:05, el esp02 que se ejecutaba con ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.bin también falló, la misma situación que la anterior, ya no hay datos y las mismas entradas en el registro.

Nuevamente 2 contratiempos hoy, esp02 y esp18 salieron mal nuevamente con las mismas fallas en el registro
Software 2 versiones involucradas, 0116 y 0121 ambas versiones 2.4.1 core y 4 Mb
el hardware de esp02 es un nodemcu-d1-mini / esp18 es un nodemcu-v2 ambos usan gpio12/gpio14

¿Puedes probar esta compilación en uno de tus nodos?

ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Se está ejecutando en uno de mis nodos con un MH-Z19 y ahora tiene un tiempo de actividad de 54 días 23 horas 21 minutos
Eso es desde un corte de energía...
Este funciona bien con actualizaciones periódicas del valor de CO2.

voy a,

pero ya he mencionado antes que hasta la versión mega 20181231 core 2.4.1 normal 4Mb ninguno de los problemas de estabilidad informados se han visto, entonces, ¿por qué esta versión específica?

Descargaré esa versión específica y la instalaré en los nodos de medición de co2 eesp02 y esp18, pero los problemas aparecieron en el rango mega-2019* no antes, en mi humilde opinión, Gijs.

OK, entonces no sirve de nada.

Esa versión específica se ejecuta en una versión que tengo que parece ser estable (lamentablemente inusual).
Y tienes razón, si funcionó bien hasta 20181231, entonces realmente no vale la pena probar los más antiguos.

Sin embargo,
Esp02 y esp18 se están ejecutando en ESP_Easy_mega-20181109_normal_ESP8266_4096.bin ahora
Esp01 y Esp08 se ejecutan en ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin

y veremos

Observación, mi ojo acaba de captar que la versión 1109 tiene el número de compilación 20102, ¿así que eso es muy anterior y diferente?

Gijs,

Podría haber encontrado otra pista sobre este tema.

Hace un par de minutos, mi Esp08 A nodemcu ch340V2 4Mb ejecutando ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin también dejó de enviar co2data.

Fragmento de registro
370508579: UDP: 60:01:94:0F:AF:9D,192.168.3.46,17
370508785: UDP: 24:0A:C4:82:F2:B8,192.168.3.51,21
370509501: UDP: 60:01:94:0C:2E:FD,192.168.3.48,19
370514624: UDP: 5C:CF:7F:82:FD:47,192.168.3.31,2
370515674: MHZ19: Error de lectura: suma de comprobación = 120/248 bytes leídos => 255/134/5/183/71/128/15/112/248/
370515677: MHZ19: se desplazó 1 byte para intentar corregir la alineación del búfer
370517702: EVENTO: Reloj#Hora=Mié,12:19
370517755: EVENTO: Clock#Time=Wed,12:19 Tiempo de procesamiento : 53 milisegundos
370520257: UDP: 60:01:94:0B:94:5C,192.168.3.30,1
370520460: UDP: 60:01:94:02:0E:E8,192.168.3.36,7
370523940: UDP: 18:FE:34:E2:18:84,192.168.3.35,6
370529880: UDP: BC:DD:C2:EA:3D:BC,192.168.3.54,24

Esta es la primera vez que veo esta falla, tal vez ...

Un error de suma de comprobación debe manejarse con más gracia.
Tal vez deberíamos agregar algún umbral sobre cuándo comenzar a cambiar para buscar un nuevo buen comienzo.
O un mejor algoritmo para volver a sincronizar.
Hasta donde yo sé, no ha habido ningún cambio en el código para esto en más de un año. Solo ha habido un cambio en la forma en que se crea la conexión del puerto serie, por lo que realmente no sé por qué conduce a estos problemas.

Tengo la idea de que el sensor mhz19 en sí entra en un estado "bloqueado" después de un par de horas de falta de comunicación o como resultado de no poder obtener datos. ?
Motivación: un reinicio o incluso una actualización completa de sw no resuelve ese estado, el mhz19 tiene que estar impotente durante un minuto más o menos para recuperar la vida, encontré este comportamiento cuando está atascado en el estado que se ve así:
MHZ19: Error, tiempo de espera al intentar leer
MHZ19: Respuesta desconocida: 0 0 0 0 0 0 0 0 0

La falla de esp08 esta mañana todavía se podía resolver con una opción de reinicio remoto desde la consola web, por lo que no era lo mismo que el bloqueo completo después de varias horas que encontré e informé un par de veces.

Pero encontré esto después:
Aproximadamente a las 1800 hora local, entró en estado bloqueado, reinicio, reinicio a través del ciclo de encendido de la consola, nada funcionó esta vez, el dispositivo necesitaba una nueva actualización con la versión mega 20181231 de 4 MB y luego volvió a la vida. Esp08 está usando la combinación Gpio12/14 y también es un modelo nodemcu v2 ch340

Suena bastante extraño, ya que el complemento envía un comando para recopilar nuevos datos del sensor al MH-Z19.
Así que no entiendo por qué incluso un reinicio suave no funciona.
Agregaré también algunas estadísticas para ver con qué frecuencia ocurre un error de suma de verificación (extremo receptor)
Si eso sucede con frecuencia, también puede suceder al enviar datos al sensor y tal vez el sensor se ponga en algún modo de comando desconocido.
¿Quizás alguna configuración de resistencia pull-up ha cambiado cuando cambié la forma en que se configuran los pines seriales?

Que podría,

lo investigaré un poco más mañana o durante el próximo fin de semana tal vez pueda encontrar algo, ¿ese sensor no es tan usado que nadie sufre un comportamiento idéntico?

O no utilizado por personas que ejecutan las últimas compilaciones

Tengo 2 MH-Z19b, ambos funcionando en la versión de prueba 20190116 sin problemas

Ok, solo por curiosidad, ¿qué versión central de la compilación de prueba y qué Gpio está usando?

Veo que 1 está ejecutando ESP_Easy_mega-20190116_test_core_250_beta_ESP8266_4096.bin, el otro ESP_Easy_mega-20190121_test_core_250_beta_ESP8266_4096.bin. En ambos sensores conectados a GPIO 13 y 12

Entonces ese es otro núcleo y otro GPIO que está usando en 13/12 en lugar de GPIO 14/12 que uso aquí

Hoy actualicé 4 de 4 a la versión ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin

vamos a ver

Ahora que lo pienso, puede haber otro cambio en la biblioteca SWserial utilizada desde principios de este año.
Solíamos tener nuestra propia versión de la biblioteca SWserial, que parcheé para usar menos memoria iRAM.
Pero ahora estamos usando la versión incluida en la biblioteca central y para el núcleo 2.5.0, esta puede ser una versión más nueva que la anterior.
También puede haber algún cambio en el uso de interrupciones en conexiones de baja velocidad. (9600 baudios e inferior)
Debo investigar eso también.

Todavía no explica por qué el sensor aparentemente puede estropearse tanto que necesita apagarse para volver a funcionar con normalidad.

Dentro de las 3 horas posteriores a la actualización a ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin, mi esp18 se bloqueó nuevamente, el reinicio de la consola web no funcionó, se requirió apagar nuevamente.
el otro todavía funciona, se agregará aquí si congela el MHZ19 también

Sí, el otro esp18 dejó de enviar datos razonables de CO2 a las 19:05 esta noche, por lo que la falla persiste en el mega 202 core 2.4.1 de ayer al menos.
Ese está de vuelta y ahora también se ha degradado a la versión 20181231.

Alrededor de la medianoche, el tercer esp, esp02 se congeló con las lecturas de Co2, también degradadas a 20181231 ahora

El único que aún se ejecuta en ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin es el que usa Gpio-0/Gpio-2, los otros tres que se congelaron usan Gpio14/gpio12.
ya no creo que esto sea una coincidencia,

Cambiaré el cableado de esp02 a Gpio-0/Gpio-2 y lo actualizaré a la versión 0202 core 2.4.1 nuevamente y podríamos ver si sigue vivo después de este cambio de gpio.
Hecho

Acabo de agregar un compromiso para hacer algunas mejoras en la lectura.
Ver https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7c

¿Puedes construir una versión de prueba para él, o quieres que yo construya una?

Si pudiera proporcionarme un contenedor, estaré encantado de ponerlo en ambos todavía en gpio12/14 ejecutando esp
y luego es seguro que el archivo es el mismo, sin influencias locales, etc.

OK, tomó algo de tiempo, pero aquí está la versión de prueba

Entiendo,

Esp08 y esp18 se están ejecutando en esta versión de prueba con el núcleo 2.4.1 ahora, ambos usan gpio12/14

Vamos a ver !

También debería ver algún indicador que muestre la cantidad de líneas procesadas y la cantidad de fallas de CRC

¡Sí, ahora también los tengo en la consola!

dejará esos 2 y verá en cierto intervalo si esos contadores aumentan.
Mantente informado..

Ambos sensores en uso en los nodos de prueba son versiones B, por lo que la detección también funcionó.

Suma de comprobación (pasa/falla): | 11/0
-- 08 --
Detectado: | MH-Z19B

Suma de comprobación (pasa/falla): | 8/0
-- 18 --
Detectado: | MH-Z19B

¿Tiene también una combinación de MH-Z19 A/B o solo las versiones B más nuevas?
No debería importar, solo curiosidad.

¿Tiene también una combinación de MH-Z19 A/B o solo las versiones B más nuevas?
No debería importar, solo curiosidad.

Versiones B, acabo de agregar esa información, la detección también funcionó :-)

pequeña actualización, todos siguen funcionando bien, los que tienen su versión especial esp8 y 18 muestran contadores crecientes pero aún no tienen fallas ni errores de suma de verificación, los valores actuales son:

Esp08: Checksum (pasa/falla): | 1795/0
Esp18: Checksum (aprobado/fallido): | 724/0

y el otro que falló bastante consistente esp02 también se sigue ejecutando ahora con el Gpio modificado
y así di-mini tiene ahora el mhz19 en Gpio-0/Gpio-2 y mega 20190202 versión core 2.4.1

Bummer borró accidentalmente la publicación aquí, intente recrear fuera de mi memoria:

Ayer por la noche, tres de mis esp 02, 08 y 18 se pusieron rojos en Domoticz, sin datos del sensor de Co2.
dos de ellos tienen la versión especial core 2.4.1 y gpio 12/14. Un reinicio de la consola web no lo resolvió, y solo produjo: MHZ19: Respuesta desconocida: 0 0 0 0 0 0 0 0 0 pero las mediciones de esp18 co2 recuperaron la vida después de aproximadamente una hora, a las 0:56 comenzó a enviar valores correctos nuevamente.

Esp08 también recibió un reinicio, y esp02 también (ese tiene gpio0/2 ahora igual que esp01) ambos no se recuperaron, y esta mañana ambos se apagaron por 2 minutos, después de eso ambos volvieron a la vida bien.

Ahora cambié la versión del software en esp02 a ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4 para que podamos probar esa versión central también, el cambio de gpio no hizo una diferencia al ejecutar la versión anterior (actual 2.4.1) quedó claro
esp02 mostró una sola falla de suma de verificación hoy: Suma de verificación (aprobado/fallido): | 79/1

También activé syslog para esp08 solo al principio, con las configuraciones a continuación, si desea una configuración específica, pregunte.

Tal vez también pueda detallar sus configuraciones en la publicación (también puede ser la próxima publicación, no es necesario editar esta) mostrando lo siguiente:

• Su unidad interna nr (para su propia referencia como "02, 08, 18)
• construir en ejecución
• nr de éxito/fallo (si está disponible)
• tipo de falla/problema

La información detallada es (para mí) más fácil de seguir en comparación con el texto descriptivo.
También respondo desde mi teléfono a veces.

esp08/18 ESP_Easy_mega-20190202-58-PR_2235_normal_ESP8266_4096 núcleo 2.4.1 gpio12/14
esp01/02 ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4096 gpio 0/2

-- congelado significa que funciona bien a excepción de las lecturas de co2

22:57 esp08 congelado de nuevo, contadores Checksum (pasa/falla): | 1077/2 puso syslog a un lado cuando lo encontró.
05:05 esp18 congelado de nuevo, contadores Checksum (pasa/falla): | 1076/2
06:25 esp08 congelado de nuevo, sin contadores, esp se bloqueó por completo esta vez, obtuve syslog
12:57 esp18 congelada de nuevo. contadores Suma de comprobación (aprobado/fallido): | 116/2
20:43 esp18 congelado de nuevo, contadores Checksum (pasa/falla): | 316/2 probó el comando mhzreset
Sin cambios, el sensor está enviando la respuesta desconocida mhz19 0 0 0 0 0 0 0 0
mensaje una y otra vez, probé varios intentos sin solución, encendió y encendió el nodo.

Gijs,

Hice un análisis en el último syslog de esp08, durante las horas en que se ejecuta vi 78 ocurrencias de:
2019-02-08T05:27:07.581181+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Respuesta desconocida: ff 0 0 0 0 0 0 0 0

Búsqueda automática usando #cat mensajes-crash-esp08-0625 |grep MHZ19 | respuesta grep | grep 'ff 0 0 0 0 0 0 0 0' | wc-l

y después de cambiar esa línea de comandos a la segunda variante de respuesta desconocida, Linux contó 408 veces esta línea:
2019-02-08T10:44:06.855432+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Respuesta desconocida: 0 0 0 0 0 0 0 0 0

Los contadores de errores de suma de comprobación en su versión de depuración personalizada no superaron los 2 por lo que vi durante los últimos días.
el primer mensaje de error (MHZ19: Respuesta desconocida: ff 0 0 0 0 0 0 0 0) apareció un par de veces, seis o más, uno tras otro antes de congelarse esta mañana.

Parece que el sensor en sí se está bloqueando, pero no puedo pensar en una razón por la que lo está haciendo ahora.
En nuestra fuente hay un comando para llamar al reinicio del sensor MH-Z19, pero eso no está documentado en la hoja de datos.
Entonces desconozco su estado.
¿Podría intentar llamar a ese comando en un nodo que está atascado así?

Editar: ese comando es mhzreset

Tiene que haber algún cambio realizado después del mega 20181231 2.4.1. Versión de 4Mb que tiene estos resultados en el MHZ19 por lo que he encontrado todavía. ese está funcionando durante semanas sin problema incluso en gpio 12/14.

lo intentaré la próxima vez que algo deje de funcionar, a las 23:20 encontré que esp18 estaba congelado, mhzreset no cambió eso, vea el registro anterior.

el comando mhzreset no abre una ventana de comando en la consola web, no informa Ok más o menos, después de varios intentos que encontré en el syslog:
<5>1 2019-02-08T23:25:34.164674+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Enviado reset sensor!
<5>1 2019-02-08T23:25:36.313828+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Enviado reset sensor!
tan fácil dice que ha sido enviado, pero parece que no tiene un sabor que mhz19 entienda o le guste :-)

Ese comando parece hacer algo por la versión MH-Z19 A.

127136: MHZ19: Sent sensor reset!
137272: MHZ19: Unknown response: ff ff ff ff ff ff ff ff ff
152275: MHZ19: Unknown response: ff 31 f5 4b 42 32 30 30 d
167277: MHZ19: Bootup detected! PPM value: 5000 Temp/S/U values: 23/1/15000.00
197279: MHZ19: Bootup detected! PPM value: 400 Temp/S/U values: 23/1/15000.00
<repeat a few times>
257279: MHZ19: PPM value: 906 Temp/S/U values: 24/64/11554.00

Entonces parece que no se puede usar en la versión B.

¿Podría suponer que algo así como ese comando también se usa de alguna manera en el inicio / inicialización del complemento?
lo que podría explicar por qué un reinicio / reinicio sin ciclo de encendido no resuelve el problema.

No vi fallas hasta esta tarde:
15:43 esp08 congelado de nuevo, contadores Checksum (pasa/falla): | 2316/2 dejó el syslog a un lado.

Y solo para estar seguro, ¿estos nodos funcionaban bien en versiones de firmware anteriores?

Sí, hasta que ESP_Easy_mega-20181231_normal_ESP8266_4096 estaba y sigue estando bien,
Funcionarían durante semanas sin problemas.

Investigué los cambios recientes en la biblioteca SWserial, ya que esa es la que estamos usando ahora.
Uno de los cambios realizados allí fue dejar de usar interrupciones en las transferencias de TX para 9600 baudios.
¿Puedes probar esta versión de prueba ?

NB: también eliminé las compilaciones principales 2.5.0, ya que actúan de manera extraña cuando sirven páginas web.

Esp08 y Esp18 ejecutando ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
esos dos también envían sus datos a un servidor syslog para que los datos de registro se registren

Los otros dos seguirán mañana, uno de ellos podría ser un Mhz19A, y lo es.

Hw config es ahora:
Esp01 tiene el MHZ19A en gpio0/gpio2
Esp02 tiene el MHZ19B en gpio0/gpio2
Esp08 tiene el MHZ19B en gpio12/gpio14
Esp18 tiene el MHZ19B en gpio12/gpio14

Todos ellos en la misma versión de prueba de esp-easy ahora, ejecutándose en:
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

actualizar

06:01 esp08 congelado de nuevo, contadores perdidos (causado por el usuario) dejar el syslog a un lado.

05:21 Esp18 congelado, Checksum (pasa/falla): | 1460/0, he dejado de lado syslog
12:53 Esp08 congelado , Checksum (pasa/falla): | 1351/28, he dejado de lado syslog

La compilación principal 2.4.1 no se incluyó en esa compilación de prueba, así que hice una que solo contenía esa versión principal. compilación core 2.4.1 del mismo código que en ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
Ese usa una versión anterior de la biblioteca SoftwareSerial.
Si eso funciona, cambiaré la biblioteca serial SW usada.

Comenzando la actualización a la versión especial: firmware.bin para los 4 nodos ahora, terminado a las 12:30

Lo primero que noté, Esp08 estaba congelado, esta actualización de firmware reinició el MHZ19B, volvió vivo, y el inicio quiero decir: el sensor me está dando un valor de C02 razonable, esto también parecía mucho más rápido

También estoy ejecutando la antigua biblioteca SWserial en un nodo de prueba y, de hecho, está funcionando mucho mejor.
Por ejemplo, el monitoreo de energía de Eastron tenía alrededor del 20 al 30% de las líneas recibidas dañadas, pero ahora funciona perfectamente. (todavía no hay sumas de comprobación fallidas)

Acabo de hacer una nueva compilación de prueba en la que cambié mucho con respecto al envoltorio serial HW/SW.
Ahora funciona con el complemento Eastron para SWserial y HW serial y SWserial ahora usa la biblioteca anterior que usamos hasta 20180131.

Entonces, esto es en realidad lo mismo que la versión 0202 pero con la misma biblioteca serial que la versión 20181231, los actualizaré directamente ... solo un momento

Instalado ESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin
el Esp0/02/08/18 ahora

vamos a ver ..

Sí, y tiene el envoltorio HWserial/SWserial, por lo que debería ser fácil cambiar a HWserial tan pronto como esté usando los pines correctos para ellos.

Todavía necesito agregar GPIO2 como opción adicional para HWserial0 y todavía hay algo de limpieza que hacer en el código.

Como pasaron las primeras horas siguen funcionando, después de la última actualización no veo ninguna incógnita
respuesta ff 7 x 0 u 8 veces 0 mensajes en el syslog de esp08 o esp18 más.

Tomó algún tiempo para mirar en los datos de syslog de 2 nodos:
Esp08 todavía tiene una respuesta desconocida con códigos variables de vez en cuando,
Esp18 aún no ha producido ningún fallo

bueno escuchar
Creo que tuvimos algunos problemas en los que los datos enviados a los sensores se corrompieron.
Entonces el sensor mismo puede fallar, supongo.

Con el complemento Eastron (enviando muchos más datos), la cantidad de errores de suma de verificación se redujo significativamente.
Desde aproximadamente 20 - 30% de errores CRC en los mensajes hasta cerca de 0 (1 error en 10'000 mensajes) usando SWserial.

Sigue funcionando bien, los cuatro

Miré la lista fija de la versión 20190215, ¿esa versión ahora es la misma que la versión que estoy ejecutando en los 4 nodos de medición de Co2 aquí?

Casi lo mismo.
Al menos el código para el puerto serie y su complemento es el mismo.

Luego lo dejo como está y sigo probando con el "especial"

No estaba claro para mí qué se incluyó en el lanzamiento y qué no, algunos de los números coincidieron.

Sí, el gran PR que fusioné ayer fue la fuente de todas las compilaciones de prueba que hice las últimas semanas.

Esp08 congelado a las 14:17, contadores Checksum (pasa/falla): | 3292/70, syslog reservado para un análisis más detallado

¿Y un simple reinicio (o guardar la configuración) del nodo reinició el sensor (no lo apagó)?

Lo intentaré la próxima vez, solo lo encendí después de verificar los contadores.

Esp08 congelado de nuevo, contadores Checksum (pasa/falla): | 2660/55

¡El guardado de los parámetros del dispositivo co2 resolvió la congelación!

Esp08 18:18 congelados de nuevo, contadores Checksum (pasa/falla): | 2660/55

¡El guardado de los parámetros del dispositivo co2 resolvió la congelación!

OK, entonces es posible realizar un reinicio.
Agregaré una verificación de N respuestas desconocidas y luego realizaré un inicio nuevamente.

Eso podría resolver este problema por completo.

Por ahora, todo el problema de serie que teníamos en todos ellos parece haber desaparecido en el modelo A y con dos de los tres sensores del modelo Mhz19B.
Esp08, que es un modelo B, es el único que he visto con una variable "respuesta desconocida (cada vez que cambia) Valor hexadecimal" todavía en los archivos de registro, si este sensor se puede restablecer fuera del complemento cuando se comporta mal, podría ser la solución.

Actualizando todo a Mega 201902026 4Mb ahora.

Lo primero que noté, el sensor de Co2 tipo mhz19B está dando valores correctos casi instantáneamente después de flashear una nueva imagen, mucho más rápido que antes también.

¡Esto suena realmente prometedor! He estado viendo este hilo, esperando un momento en el que finalmente pudiera actualizar. :grin: Tengo un nodo que tiene un MH-Z19 y un PMS7003 adjuntos. MH-Z19 ha estado funcionando más del 90 % del tiempo, pero ocasionalmente he tenido que reiniciar el ESP para eso.

Sin embargo, el PMS7003 parece estar fallando mucho más. La mayoría de las veces, incluso reiniciar no ayuda, pero desconectar la alimentación durante unos segundos podría solucionarlo. He estado sospechando que su conector podría ser el culpable, pero no me he metido en depurarlo. Este hilo me despertó la curiosidad de si todavía podría estar relacionado con el firmware... Voy a intentarlo cuando pueda estar seguro de que no causará problemas con el MH-Z19, ya que sus datos son más importantes.

Y sí, noté que #2349 solo tocó el código MH-Z19, pero la versión que estoy ejecutando es "20100 - Mega (core 2_4_0)", que supongo que es bastante antigua.

Quiero decir que es raro ver tal persistencia de ambos lados de un problema. Creo que muchos se habrían dado por vencidos después de unos días. ¡Me quito el sombrero de parte de este espectador @TD-er y @pwassink!

Es posible que desee esperar 1 día más antes de actualizar.
Ahora estoy trabajando en algunos parches para la conectividad de red.

Gracias por la info! De todos modos, estaba planeando esperar los informes de @pwassink por un momento (perezoso).

Solo sepa que muchas cosas han cambiado desde su compilación actual y, lamentablemente, no todo es positivo.
Uno de los problemas que aún estamos tratando de abordar es el reinicio del mecanismo de vigilancia del hardware. Por lo tanto, es posible que desee mantener una copia de seguridad de la configuración actual que tiene y anotar la versión actual que está utilizando. Sólo para estar seguro.
Espero mejorar un poco estos reinicios con las correcciones de hoy, pero dado que estos reinicios tienen varias causas diferentes, no creo que las correcciones de hoy los solucionen todos.

Nota tomada. Solo puedo imaginar la dificultad de evitar la regresión en un sistema como ESPEasy. Estaré informando cualquier regresión después de que haga la actualización (como problemas separados, por supuesto).

Estoy planeando actualizar dos ESP que tengo aquí. Basado en eso, solo puedo observar si hay regresión en el manejo de pantalla MH-Z19, PMSx003, BMx280, TSL2561, sensor DHT22 o OLED SSD1306. TSL2561 en el otro ESP tiende a dejar de devolver datos al azar también (aunque es bastante raro). Está ejecutando la compilación "20102 - Mega".

Esa no es la compilación, sino el formato de archivo interno (confuso, lo sé). Puede encontrar el nombre/fecha de compilación en la página de información del sistema.

Está en el campo "construir" al menos. El nombre del archivo binario es "ThisIsTheDummyPlaceHolderForTheBinaryFilename64ByteLongFilenames". Probablemente lo mostré directamente desde PlatformIO. Es posible que tenga algunas dificultades para actualizar la misma versión que hace casi un año. Realmente no hice ninguna nota por no mencionar una etiqueta. :joy: Bueno, supongo que puedo hacer una copia de seguridad del firmware si no me siento lo suficientemente aventurero.

¿No hay marca de tiempo de compilación en la página de información del sistema?

Hay una marca de tiempo, pero no ayudará mucho, ya que no recuerdo si introduje el último código antes de hacerlo. Pero, por supuesto, da algo de estadio.

Sin embargo, este no es el ESP que alberga el MH-Z19 y el PMS7003.

Pero supongo que esto se está desviando del tema. ¡Perdón por secuestrar temporalmente el hilo y gracias por responder a mis comentarios de todos modos!

¿En qué versión se arregló esto?

después de unas horas obtengo MHZ19: Respuesta desconocida: 0 0 0 0 0 0 0 0 0
reiniciar no lo arreglará, tiene que desenchufarlo y volver a enchufarlo

estoy usando un wemos 1d mini pro, ¿esta versión tiene la solución?

Construir:⋄ | 20104 - Mega
-- | --
Bibliotecas del sistema:⋄ | ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 Compatibilidad con PUYA
Compilación Git:⋄ | mega-20191003
Complementos:⋄ | 46 [Normal]
Compilación Md5: | 3180a4d3e118166b3414444513a6169
Comprobación md5: | aprobado.
Tiempo de construcción:⋄ | 3 de octubre de 2019 02:15:29
Nombre de archivo binario:⋄ | ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

Gracias

Sí, y versiones anteriores también.
Sugeriría probar con la compilación 20190928, ya que la de octubre tuvo algunos otros problemas (que estoy solucionando durante la última semana más o menos)

También es posible que desee ver la cantidad de errores de lectura que se muestran en la página del complemento, después de que haya estado funcionando durante algunas horas.

Por ejemplo, una de mis propias unidades (tiempo de actividad de 3 días)

Nota: el filtro (configurado en "Usar inestable" en la captura de pantalla) no tiene significado en el sensor MH-Z19B, solo se aplica a la versión -A.

Y otro:

Como puede ver, el número de lecturas fallidas es mínimo.
Si tiene algunos errores allí, es posible que tenga otro problema a la mano.

esos 11 reinicios en los que intento que se inicie de nuevo sin volver a conectarlo, no recuerdo haber visto ningún error, pero puedo darle otra oportunidad, ¿debería usar Software Serial?

Hardware Serial es el mejor, pero también debe deshabilitar el puerto serie en Herramientas->Avanzado->Puerto serie. (como se indica en su captura de pantalla :))

No estoy seguro de si algún adaptador USB a serie presente en la placa puede tener un efecto en la comunicación.
En caso de duda, puede cambiar a la serie de software.

Compilación: ESP_Easy_mega_20201130_normal_ESP8266_4M1M
reportando a FHEM.
Tuve un problema similar: el sensor MH-Z190B se congela cada pocas horas y sigue bajando a 400 cuando uso hardware en serie.
Después de cambiar a la serie de software, parece funcionar normalmente y ya no se congela.
2 capturas de pantalla adjuntas.

El BME280 conectado con I2C funciona bien y sigue informando todo el tiempo

Mmm eso es extraño.
¿A qué puerto serie HW estaba conectado?
¿Qué más está conectado a la placa? (por ejemplo, USB a chip serie)
¿Está "Usar serial" desmarcado en la página Herramientas->Avanzado?

Está conectado a GPIO-13 (D7) <- TX y GPIO-15 (D8) -> RX (primero en HW ahora en SW) ya que quería usar TXD0 y RXD0 para leer los mensajes a través del puerto USB (CH340 ) del Wemos D1 mini.
¿"Usar serial" significa "Configuración serial - Habilitar puerto serial:" marcado? Dejé esto marcado para poder leer los mensajes por USB.

HW serial en un ESP8266 usa Serial0.
Si también envía registros al mismo puerto serie, el sensor puede bloquearse ya que no comprende los "comandos" que recibe cuando los registros se envían a través de ese puerto.

Si conecta algo al puerto serie HW, ya no debería enviar otros datos. Por lo tanto, debe deshabilitar "Usar serie" en la página herramientas-> Avanzado.

Ayer compré un segundo Sensor MH-Z19C. Este parece funcionar bien con HW-Serial en Serial2. Como todos los sensores estaban conectados a los pines D7 (GPIO 13) y D8 (GPIO 13) (RXD2 y TXD2), no debería haber ningún conflicto con Serial0 (Pines RXD0 (GPIO3) y TXD0 (GPIO1)) hasta donde yo estoy. entender el Pinout. Creo que el primer sensor (MH-Z19B de otro proveedor) era simplemente falso y no funcionaba correctamente en absoluto...
Así que tenga cuidado al comprar esos sensores. El segundo que obtuve ayer estaba en un empaque mucho mejor con el logotipo de Winsen y un certificado de prueba adjunto. El proveedor parece ser más serio que el que me vendió el primero.