Parece estar relacionado à mudança de serial que fiz recentemente.

Quais pinos gpio você usa?

Pode ser, vamos ver, acho que você encontrou um ponto Gijs :-)

esp01 = Gpio0 Gpio2 (nenhum problema visto ainda)
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

Peter

Eu tenho dois nós aqui também posso testar no final da tarde

OK,
A falha não é imediata, eles param de enviar depois de um tempo e persistem bastante nisso, reiniciar ou fazer downgrade de sw não é suficiente para que eles enviem dados novamente. Eles precisam de um ciclo de energia e algum tempo entre desligar e ligar.

Quanto tempo é "depois de um tempo"?
Acabei de configurar um nó usando um desses sensores e também um BMP280 está conectado.
Ele está usando GPIO-14 e -12 para o sensor de CO2.

um par de horas, ontem tudo estava funcionando, esta manhã eu tinha 3 de 4 com o mesmo status.

E todos eles inicializaram ao mesmo tempo, antes de todos pararem de funcionar?

sim, todos foram reiniciados/atualizados dentro de uma hora, eu acho, estava atualizando-os ontem à noite. e durante a noite eles pararam de trabalhar

Eu estava prestes a atualizar meus nós, mas felizmente notei isso. @TD-er qual seria a versão mais recente antes das alterações no Serial que você acha que podem ser o culpado? Ou seria mais útil se eu atualizasse a versão mais recente para ver se terei o mesmo problema?

Se alguma atualização ausente não for grande coisa, sugiro a versão mais recente.
Para manter a versão anterior ao wrapper da porta serial, você pode usar 20181231. (Acho que confirmei as alterações este ano)

eu fiz o downgrade dos 3 "problemas" esp's para 20181231 ontem, posso confirmar que eles ainda estão enviando dados sem alterações de hardware, agora por 24h, então esses três esp ainda estão usando gpio12 e gpio14 no meu caso

Alguma sorte em recriá-lo Gijs?

Não, meu nó ainda está enviando valores e está executando a compilação a partir de 16 de janeiro. (núcleo 2.5.0)

eu usei o ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin nesses nós, que tem o núcleo 2.4.1 eu acredito?

@pwassink Isso está correto.
Você também pode ver a compilação do núcleo na página sysinfo.

Eu instalei essa versão ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin de volta para o esp02 aqui, vamos ver se acontece novamente

Hmm,
Talvez o dia da semana ou a posição da lua tenha uma certa influência,
Eu não vi a falha recorrente aqui nos últimos dias.

Parece estar funcionando bem aqui também.
Era quase lua cheia quando você relatou, então acho que deveria ter sido isso ;)

Atualizar,

deixei o esp02 rodando com a versão ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin que ainda está rodando como deveria.

Ontem eu atualizei o resto dos meus nós para ESP_Easy_mega-20190121_normal_core_241_ESP8266_4096.bin

E o esp-18 ficou bozo novamente às 06:55, horário local, tudo está funcionando como deveria, exceto o sensor MHZ19 Co2, na guia de dispositivos está exibindo o "último valor bom conhecido" de aproximadamente 07:00 e novamente com as mesmas entradas no Logfile:
MHZ19: Erro, tempo limite ao tentar ler
MHZ19: Resposta desconhecida: 0 0 0 0 0 0 0 0 0

Esp-18 está usando Gpio 14/12
é um Nodemcu com Ch340 versão 2 de 3 de ali
A reinicialização remota via console da Web não resolveu o problema
novamente ele está exibindo as entradas mencionadas acima várias vezes
Após ciclo de energia
78640: MHZ19: Erro, tempo limite ao tentar ler
78641: MHZ19: Erro de leitura: soma de verificação = 202/0 bytes lidos => 255/168/12/161/226/255/0/0/0/
78643: MHZ19: Deslocado 1 byte para tentar corrigir o alinhamento do buffer
Depois de mais algum tempo:
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 Tempo de processamento: 1 milissegundos
255659: EVENTO: Rik-CO2#Temperatura=25,00
255659: EVENTO: Rik-CO2#Temperature=25.00 Tempo de processamento:1 milissegundos
255662: EVENTO: Rik-CO2#U=0,00
255662: EVENTO: Rik-CO2#U=0,00 Tempo de processamento: 1 milissegundos

Parece funcionar novamente agora, mas precisou do ciclo de energia cerca de 2 minutos sem energia

Precisa fazer algo naquele momento? Pode ser algo que possa levar a um soluço do wifi no ESP?

Nada mesmo,

Não há redefinições agendadas, reinicializações, backups, redefinições de wfi, limpezas dhcp ou qualquer motivo externo naquele momento

E o wifi continua funcionando bem, é apenas a leitura do mhz19 que para, todos os outros sensores (baseados em i2c) no mesmo esp ainda funcionam

Esta manhã às 03:00 aconteceu novamente com o Esp-18 rodando a versão 0121 Mega, Mesmos erros no esp-logfile de antes, outros sensores funcionam bem

E às 19:05 o esp02 rodando com o ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.bin também travou, mesma situação acima, sem dados mais e as mesmas entradas no logging.

Novamente 2 soluços hoje, esp02 e esp18 ambos deram errado novamente mesmas falhas no log
Software 2 versões envolvidas, 0116 e 0121 ambas 2.4.1 core e 4 Mb versão
hardware do esp02 é um nodemcu-d1-mini / esp18 é um nodemcu-v2 ambos usam gpio12/gpio14

Você pode tentar esta compilação em um de seus nós?

ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Ele está sendo executado em um dos meus nós com um MH-Z19 e agora tem um tempo de atividade de 54 dias 23 horas 21 minutos
Isso desde uma queda de energia...
Este está funcionando bem com atualizações regulares do valor de CO2.

Eu irei,

mas eu já mencionei antes que até a versão mega 20181231 core 2.4.1 normal 4Mb nenhum dos problemas de estabilidade relatados foram vistos, então por que esta versão específica?

vou baixar essa versão específica e instalá-la nos nós de medição de co2 eesp02 e esp18, mas os problemas apareceram na faixa mega-2019 * não antes na minha humilde opinião Gijs ..

OK, então não adianta mesmo.

Essa versão específica está sendo executada em uma versão que tenho que parece ser (infelizmente incomum) estável.
E você está certo, se estava funcionando bem até 20181231, então não vale a pena tentar os mais antigos.

No entanto,
Esp02 e esp18 estão sendo executados em ESP_Easy_mega-20181109_normal_ESP8266_4096.bin agora
Esp01 e Esp08 estão rodando em ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin

E vamos ver

Observação, meu olho acabou de perceber que a versão 1109 tem o número de compilação 20102, então isso é muito antigo e diferente?

Gijs,

Eu poderia ter encontrado outra pista sobre este assunto.

alguns minutos atrás meu Esp08 A nodemcu ch340V2 4Mb rodando ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin parou de enviar co2data também.

Snippet 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: Erro de leitura: soma de verificação = 120/248 bytes lidos => 255/134/5/183/71/128/15/112/248/
370515677: MHZ19: Deslocado 1 bytes para tentar corrigir o alinhamento do buffer
370517702: EVENTO: Relógio#Hora=Qua,12:19
370517755: EVENTO: Relógio#Hora=Qua,12:19 Tempo de processamento :53 milissegundos
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 é a primeira vez que vejo essa falha, talvez ..

Um erro de soma de verificação deve ser tratado com mais tranquilidade.
Talvez devêssemos adicionar algum limite sobre quando começar a mudar para procurar um novo bom começo.
Ou um algoritmo melhor para entrar em sincronia novamente.
Até onde eu sei, não houve nenhuma mudança no código para isso em mais de um ano. Houve apenas uma mudança na maneira como a conexão da porta serial está sendo criada, então realmente não sei por que isso leva a esses problemas.

Eu tenho a ideia de que o próprio sensor mhz19 entra em um estado "bloqueado" após algumas horas de falha de comunicação ou como resultado de não conseguir obter dados. ?
Motivação: uma reinicialização ou mesmo uma atualização completa do sw não resolve esse status, o mhz19 tem que ficar sem energia por um minuto ou mais para recuperar a vida, encontrei esse comportamento quando ele está travado no status que se parece com:
MHZ19: Erro, tempo limite ao tentar ler
MHZ19: Resposta desconhecida: 0 0 0 0 0 0 0 0 0

A falha do esp08 nesta manhã ainda era solucionável com uma opção de reinicialização remota do console da web, portanto, não era o mesmo que o bloqueio completo após várias horas que encontrei e relatei algumas vezes.

Mas descobri isso depois:
em aproximadamente 1800, hora local, ele entrou no status bloqueado, redefiniu, reiniciou através do ciclo de energia do console, nada funcionou desta vez, o dispositivo precisava de um re-flash com a versão mega 20181231 de 4 mb e voltou à vida. Esp08 está usando a combinação Gpio12/14 e também é um modelo nodemcu v2 ch340

Parece muito estranho, já que o plugin envia um comando para coletar novos dados do sensor para o MH-Z19
Então, eu não entendo por que mesmo uma reinicialização suave não está funcionando.
Vou adicionar também algumas estatísticas para ver com que frequência ocorre um erro de soma de verificação (recebimento final)
Se isso acontecer muito, também pode acontecer ao enviar dados para o sensor e talvez o sensor seja colocado em algum modo de comando desconhecido.
Talvez alguma configuração do resistor pull-up tenha mudado quando mudei a maneira como os pinos seriais são configurados??

Pode,

vou investigar um pouco mais amanhã ou durante o próximo fim de semana talvez eu seja capaz de encontrar algo, esse sensor não é tão amplamente usado que ninguém sofre comportamento idêntico?

Ou não usado por pessoas que executam as compilações mais recentes

Eu tenho 2 MH-Z19b, ambos rodando na compilação de teste 20190116 sem problemas

Ok, apenas curioso exatamente qual versão do núcleo da compilação de teste e quais Gpios você está usando?

Vejo que 1 está executando ESP_Easy_mega-20190116_test_core_250_beta_ESP8266_4096.bin, o outro ESP_Easy_mega-20190121_test_core_250_beta_ESP8266_4096.bin. Em ambos os sensores conectados ao GPIO 13 e 12

Então esse é outro núcleo e um outro GPIO que você está usando em 13/12 em vez do GPIO 14/12 que eu uso aqui

Hoje atualizei 4 de 4 para a versão ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin

vamos ver

Agora que penso nisso, pode haver outra mudança na biblioteca SWserial usada desde o início deste ano.
Costumávamos ter nossa própria versão da biblioteca SWserial, que corrigi para usar menos memória iRAM.
Mas agora estamos usando a versão incluída na biblioteca principal e para o núcleo 2.5.0 esta pode ser uma versão mais recente do que antes.
Também pode haver alguma mudança no uso de interrupções em conexões de baixa velocidade. (9600 bauds e inferior)
Devo olhar para isso também.

Ainda não explica por que o sensor aparentemente pode ficar tão confuso que precisa ser desligado para funcionar normalmente novamente.

Dentro de 3 horas após a atualização para ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin meu esp18 foi bloqueado novamente, a reinicialização do webconsole não funcionou, foi necessário desligar novamente.
o outro ainda está funcionando, vai adicionar aqui se congelar o MHZ19 também

Sim, o outro esp18 parou de enviar dados de CO2 razoáveis ​​às 19:05 desta noite, então a falha é persistente no mega 202 core 2.4.1 de ontem, pelo menos.
Esse está de volta e atualizado para a versão 20181231 agora também.

Por volta da meia-noite, o terceiro esp, esp02 congelou com as leituras de Co2, também rebaixadas para 20181231 agora

O único que ainda está rodando no ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin é o que está usando Gpio-0/Gpio-2, os outros três que congelaram estão usando Gpio14/gpio12.
Eu não acho que isso é mais uma coincidência,

vou mudar a fiação do esp02 para Gpio-0/Gpio-2 e atualizá-lo para a versão 0202 core 2.4.1 novamente e podemos ver se isso permanece vivo após essa alteração do gpio.
Feito

Acabei de adicionar um commit para melhorar a leitura.
Consulte https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7c

Você pode construir uma versão de teste para ele, ou você quer que eu construa uma?

Se você puder me fornecer um bin, ficarei feliz em colocá-lo em ambos ainda em gpio12/14 executando esp's
e então é certo que o arquivo é o mesmo, sem influências locais etc..

OK, levou algum tempo, mas aqui está a compilação de teste

Entendi,

Esp08 e esp18 estão rodando nesta versão de teste com o núcleo 2.4.1 agora, ambos usam gpio12/14

Vamos ver !

Você também deve ver algum indicador mostrando o número de linhas processadas e o número de falhas de CRC

Sim, eu também os tenho no console agora!

deixará esses 2 e verá em determinado intervalo se esses contadores aumentam.
Manterei-o informado ..

Ambos os sensores em uso nos nós de teste são versões B para que a detecção funcione também

Checksum (aprovado/reprovado): | 11/0
-- 08 --
Detectado: | MH-Z19B

Checksum (aprovado/reprovado): | 8/0
-- 18 --
Detectado: | MH-Z19B

Você também tem uma mistura de MH-Z19 A/B ou apenas as versões B mais recentes?
Não deve importar, apenas curioso.

Você também tem uma mistura de MH-Z19 A/B ou apenas as versões B mais recentes?
Não deve importar, apenas curioso.

Versões B, apenas adicionei essa informação, a detecção funcionou também :-)

pequena atualização, todos ainda estão funcionando bem, aqueles com sua versão especial esp8 e 18 mostram contadores crescentes, mas ainda sem falhas ou erros de soma de verificação, os valores atuais são:

Esp08: Checksum (aprovado/reprovado): | 1795/0
Esp18: Checksum (aprovado/reprovado): | 724/0

e o outro que falhou bastante consistente esp02 também ainda está em execução agora com o Gpio alterado
e assim di-mini tem agora o mhz19 no Gpio-0/Gpio-2 e mega 20190202 versão core 2.4.1

Bummer acidentalmente apagou o post aqui, tente recriar da minha memória:

Ontem à noite, três dos meus esp's 02, 08 e 18 ficaram vermelhos no Domoticz, sem dados do sensor de Co2.
dois deles têm a versão especial core 2.4.1 e gpio 12/14. Uma reinicialização do console web não resolveu, e apenas produziu: MHZ19: Resposta desconhecida: 0 0 0 0 0 0 0 0 0 mas as medições de co2 esp18 ganharam vida de volta após aproximadamente uma hora, às 0:56 começou a enviar valores adequados novamente.

O Esp08 também recebeu uma reinicialização, e o esp02 também (aquele que tem gpio0/2 agora igual ao esp01) ambos não se recuperaram, e esta manhã ambos tiveram um desligamento de 2 minutos, depois disso ambos voltaram à vida ok.

Agora alterei a versão do software no esp02 para ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4 para que possamos testar essa versão do núcleo também, a alteração do gpio não fez diferença executando a versão antiga (atual 2.4.1) ficou clara
esp02 mostrou uma única falha de checksum hoje: Checksum (aprovado/reprovado): | 79/1

Eu também ativei o syslog para esp08 apenas no começo, com as configurações abaixo, se você quiser uma configuração específica, por favor, pergunte.

Talvez você também possa detalhar suas configurações no post (também pode ser o próximo post, não há necessidade de editar este) mostrando o seguinte:

• Sua unidade interna nr (para sua própria referência como "02, 08, 18)
• Build em execução
• nº de sucesso/falha (se disponível)
• tipo de falha/problema

As informações detalhadas são (para mim) mais fáceis de seguir em comparação com o texto descritivo.
Eu também respondo do meu telefone às vezes.

esp08/18 ESP_Easy_mega-20190202-58-PR_2235_normal_ESP8266_4096 core 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 funcionando bem, exceto para leituras de co2

22:57 esp08 congelado novamente, contadores Checksum (aprovado/reprovado): | 1077/2 coloca o syslog de lado quando encontrado.
05:05 esp18 congelado novamente, contadores Checksum (aprovado/reprovado): | 1076/2
06:25 esp08 congelado novamente, sem contadores, esp foi travado completamente desta vez, obteve syslog
12:57 esp18 congelado novamente. contadores Checksum (aprovado/reprovado): | 116/2
20:43 esp18 congelado novamente, contadores Checksum (aprovado/reprovado): | 316/2 tentou o comando mhzreset
Nenhuma mudança, o sensor está enviando a resposta desconhecida mhz19 0 0 0 0 0 0 0 0
mensagem repetidas vezes, tentei várias tentativas sem solução, desliguei o nó.

Gijs,

Fiz algumas análises no último syslog do esp08, durante as horas em que ele está rodando vi 78 ocorrências de:
2019-02-08T05:27:07.581181+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Resposta desconhecida: ff 0 0 0 0 0 0 0 0

Pesquisa automatizada usando #cat messages-crash-esp08-0625 |grep MHZ19 | resposta grep | grep 'ff 0 0 0 0 0 0 0 0' | wc -l

e depois de alterar esse cmdline para a segunda variante de resposta desconhecida, o linux contou 408 vezes esta linha:
2019-02-08T10:44:06.855432+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Resposta desconhecida: 0 0 0 0 0 0 0 0 0

Os contadores de erro de soma de verificação em sua versão de depuração personalizada não foram superiores a 2, tanto quanto eu vi durante os últimos dias.
a primeira mensagem de erro (MHZ19: Resposta desconhecida: ff 0 0 0 0 0 0 0 0) veio algumas vezes seis ou mais diretamente uma após a outra antes de congelar esta manhã.

Parece que o próprio sensor está travando, mas não consigo pensar em uma razão pela qual ele esteja fazendo isso agora.
Em nossa fonte existe um comando para chamar o reset do sensor MH-Z19, mas isso não está documentado no datasheet.
Então não sei o status dele.
Você poderia tentar chamar esse comando em um nó que está preso assim?

Edit: esse comando é mhzreset

Tem que haver alguma mudança feita após o mega 20181231 2.4.1. Versão de 4Mb que tem esse resultado no MHZ19 até onde eu encontrei. esse está funcionando por semanas sem problemas, mesmo no gpio 12/14.

vai tentar na próxima vez que algo parar de funcionar, às 23:20 descobri que o esp18 estava congelado, mhzreset não mudou isso, veja o log acima.

o comando mhzreset não abre uma janela de comando no webconsole, não informa Ok de volta ou assim, após várias tentativas encontrei no syslog:
<5>1 2019-02-08T23:25:34.164674+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Reset do sensor enviado!
<5>1 2019-02-08T23:25:36.313828+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Reset do sensor enviado!
tão fácil diz que foi enviado, mas não parece em um sabor que o mhz19 entenda ou goste :-)

Esse comando parece fazer algo para a versão 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

Portanto, parece que não pode ser usado na versão B.

Eu poderia assumir que algo como esse comando também é usado de alguma forma na inicialização/init do plugin?
o que pode explicar por que uma reinicialização/redefinição sem ciclo de energia não resolve o problema.

Não vi falhas até esta tarde:
15:43 esp08 congelado novamente, contadores Checksum (aprovado/reprovado): | 2316/2 coloque o systlog de lado.

E só para ter certeza, esses nós estavam funcionando bem em versões de firmware mais antigas?

Sim, até que o ESP_Easy_mega-20181231_normal_ESP8266_4096 esteja e ainda esteja ok,
Eles correriam por semanas sem problemas

Examinei as mudanças recentes na biblioteca SWserial, já que é a que estamos usando agora.
Uma das mudanças feitas ali foi não usar mais interrupções nas transferências TX para 9600 bauds.
Você pode tentar esta compilação de teste ?

NB Eu também removi as compilações do núcleo 2.5.0, pois elas agem de forma estranha ao servir páginas da web.

Esp08 e Esp18 executando ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
esses dois também enviam seus dados para um servidor syslog para que os dados de log sejam gravados

Os outros dois seguirão amanhã, um deles pode ser um Mhz19A, E é.

A configuração de Hw agora é:
Esp01 tem o MHZ19A em gpio0/gpio2
Esp02 tem o MHZ19B em gpio0/gpio2
Esp08 tem o MHZ19B em gpio12/gpio14
Esp18 tem o MHZ19B em gpio12/gpio14

Todos eles na mesma versão de teste do esp-easy agora, rodando em:
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

atualizar

06:01 esp08 congelado novamente, contadores perdidos (causado pelo usuário) coloque o syslog de lado.

05:21 Esp18 congelado, Checksum (aprovado/reprovado): | 1460/0, coloquei o syslog de lado
12:53 Esp08 frozen , Checksum (aprovado/reprovado): | 1351/28, deixaram o syslog de lado

A compilação do núcleo 2.4.1 não foi incluída nessa compilação de teste, então acabei de criar uma contendo apenas essa versão do núcleo. compilação do núcleo 2.4.1 do mesmo código que em ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
Esse usa uma versão mais antiga da biblioteca SoftwareSerial.
Se isso estiver funcionando, alterarei a biblioteca serial SW usada.

Iniciando a atualização para a versão especial: firmware.bin para todos os 4 nós agora, finalizado às 12:30

A primeira coisa que notei, o Esp08 estava congelado, esta atualização de firmware reiniciou o MHZ19B, voltou ao vivo, e o init quero dizer: sensor está me dando um valor C02 razoável, isso parecia muito mais rápido também

Estou executando a antiga biblioteca SWserial em um nó de teste também e, de fato, está funcionando muito melhor
Por exemplo, o monitoramento de energia da Eastron estava com cerca de 20 a 30% das linhas recebidas corrompidas, mas agora está funcionando perfeitamente. (nenhuma soma de verificação com falha ainda)

Acabei de fazer uma nova compilação de teste em que mudei muito em relação ao wrapper serial HW/SW.
Ele agora funciona com o plug-in Eastron para SWserial e HW serial e SWserial agora está usando a biblioteca antiga que usamos até 20180131.

Então, na verdade, é o mesmo que a versão 0202, mas com a mesma serial lib da versão 20181231, vou atualizá-los diretamente .. apenas um momento

ESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin instalado
em Esp0/02/08/18 agora

vamos ver ..

Sim e tem o wrapper HWserial/SWserial, então deve ser fácil mudar para HWserial assim que você estiver usando os pinos corretos para eles.

Ainda preciso adicionar GPIO2 como opção extra para HWserial0 e ainda há algumas limpezas a serem feitas no código.

Como as primeiras horas se passaram, eles ainda estão funcionando, após a última atualização, não consigo ver nenhum desconhecido
resposta ff 7 x 0 ou 8 vezes 0 mensagens no syslog de esp08 ou esp18 mais.

Demorou algum tempo para examinar os dados do syslog de 2 nós:
Esp08 ainda tem uma resposta desconhecida com códigos variados de vez em quando,
Esp18 ainda não produziu nenhuma falha

Bom de se ouvir.
Acho que tivemos alguns problemas em que os dados enviados para os sensores foram corrompidos.
Então o próprio sensor pode falhar, eu acho.

Com o plugin Eastron (enviando muito mais dados) o número de erros de checksum foi reduzido significativamente.
De cerca de 20 - 30% de erros de CRC nas mensagens para próximo de 0. (1 erro em 10.000 mensagens) usando SWserial.

Ainda funcionando bem, todos os quatro

Olhou para a lista fixa da versão 20190215, essa versão agora é a mesma que estou executando nos 4 nós de medição de Co2 aqui?

Quase o mesmo.
Pelo menos o código da porta serial e do seu plugin é o mesmo.

Depois deixo como está e continuo testando com o "especial"

Não ficou claro para mim o que estava incluído no lançamento e o que não, alguns dos números correspondiam.

Sim, o grande PR que fundi ontem foi a fonte de todas as compilações de teste que fiz nas últimas semanas.

Esp08 congelado às 14:17, contadores Checksum (aprovado/reprovado): | 3292/70, syslog reservado para análise posterior

E uma reinicialização simples (ou salvar configurações) do nó reiniciou o sensor (não desligou)?

Vou tentar isso da próxima vez, apenas liguei depois de verificar os contadores.

Esp08 congelado novamente, contadores Checksum (aprovado/reprovado): | 2660/55

salvar os parâmetros do dispositivo de co2 resolveu o congelamento!

Esp08 18:18 congelado novamente, contadores Checksum (aprovado/reprovado): | 2660/55

salvar os parâmetros do dispositivo de co2 resolveu o congelamento!

OK, então é possível realizar um reset.
Adicionarei uma verificação para N respostas desconhecidas e, em seguida, executarei uma inicialização novamente.

Isso pode resolver esse problema completamente.

Por enquanto, todo o problema serial que ocorreu em todos eles parece ter desaparecido agora no modelo A e com dois dos três sensores do modelo Mhz19B.
Esp08, que é um modelo B, é o único que eu vi com uma variável "resposta desconhecida (toda vez que uma mudança) valor Hex" ainda nos arquivos de log, se esse sensor pudesse ser redefinido fora do plugin ao se comportar mal, pode ser a solução.

Atualizando tudo para Mega 201902026 4Mb agora.

A primeira coisa que notei, o sensor de Co2 tipo mhz19B está fornecendo valores corretos quase instantaneamente após o flash de uma nova imagem, muito mais rápido do que antes.

Isso soa realmente promissor! Estive assistindo a este tópico, esperando por um momento que eu pudesse finalmente atualizar. :grin: Eu tenho um nó que tem um MH-Z19 e um PMS7003 anexados. O MH-Z19 está funcionando > 90% do tempo, mas ocasionalmente tive que redefinir o ESP para isso.

O PMS7003 parece estar falhando muito mais. Na maioria das vezes, mesmo a redefinição não ajuda, mas desconectar a energia por alguns segundos pode corrigi-lo. Eu tenho suspeitado que seu conector pode ser o culpado, mas não consegui depurá-lo. Este tópico me deixou curioso se ainda poderia ser relacionado ao firmware... Vou tentar quando tiver certeza de que não causará problemas com o MH-Z19, pois seus dados são mais importantes.

E sim, notei que # 2349 só tocou no código MH-Z19, mas a compilação que estou executando é "20100 - Mega (core 2_4_0)", que suponho ser bastante antiga.

Quero dizer que é raro ver tanta persistência de ambos os lados de um problema. Acho que muitos teriam desistido depois de alguns dias. Tiro o chapéu para você deste espectador @TD-er e @pwassink!

Você pode querer esperar mais 1 dia antes de atualizar.
Agora estou trabalhando em alguns patches para conectividade de rede.

Obrigado pela informação! Eu estava planejando esperar os relatórios do @pwassink por um momento de qualquer maneira (com preguiça).

Apenas saiba que muita coisa mudou desde sua construção atual e, infelizmente, nem tudo positivo.
Um dos problemas que ainda estamos tentando resolver é a reinicialização do watchdog de hardware. Então você pode querer manter um backup das configurações atuais que você tem e anotar a versão atual que você está usando. Só pra ter certeza.
Espero melhorar um pouco essas reinicializações com as correções de hoje, mas como essas reinicializações têm várias causas diferentes, não acho que as correções de hoje lidarão com todas elas.

Nota tomada. Só posso imaginar a dificuldade de evitar a regressão em um sistema como o ESPEasy. Estarei relatando quaisquer regressões depois de fazer a atualização (como questões separadas, é claro).

Estou planejando atualizar dois ESP's que tenho aqui. Com base apenas neles, posso observar se há regressão no manuseio do sensor MH-Z19, PMSx003, BMx280, TSL2561, DHT22 ou OLED SSD1306. O TSL2561 no outro ESP tende a parar de retornar dados aleatoriamente também (muito raro). Ele está executando a compilação "20102 - Mega".

Essa não é a compilação, mas o formato de arquivo interno (confuso, eu sei) Você pode encontrar o nome/data da compilação na página sysinfo.

Está no campo "build" pelo menos. O nome do arquivo binário é "ThisIsTheDummyPlaceHolderForTheBinaryFilename64ByteLongFilenames". Eu provavelmente fiz o flash direto do PlatformIO. Eu posso ter alguma dificuldade em exibir a mesma versão como era há quase um ano. Eu realmente não fiz nenhuma anotação para não mencionar uma etiqueta. :joy: Bem, acho que posso fazer um backup do firmware se não me sentir aventureiro o suficiente.

Nenhum carimbo de data/hora de compilação na página sysinfo?

Há um carimbo de data/hora, mas não ajudará muito, pois não me lembro se havia puxado o código mais recente antes de fazer isso. Mas é claro que dá alguma estimativa.

Este não é o ESP que hospeda o MH-Z19 e o PMS7003.

Mas acho que isso está fugindo do assunto. Desculpe por seqüestrar o tópico temporariamente e obrigado por responder aos meus comentários de qualquer maneira!

em que versão isso foi corrigido?

depois de algumas horas eu recebo MHZ19: Resposta desconhecida: 0 0 0 0 0 0 0 0 0
reinicialização não vai corrigi-lo tem que desligá-lo e conectá-lo novamente

estou usando um wemos 1d mini pro, essa versão tem a correção nele?

Construir:⋄ | 20104 - Mega
-- | --
Bibliotecas do Sistema:⋄ | ESP82xx Core 2_5_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: suporte 2.1.2 PUYA
Compilação do Git:⋄ | mega-20191003
Plugins:⋄ | 46 [Normal]
Construir Md5: | 3180a4d3e118166b3414444513a6169
Verificação Md5: | passado.
Tempo de construção:⋄ | 3 de outubro de 2019 02:15:29
Nome do arquivo binário:⋄ | ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

obrigado

Sim e versões anteriores também.
Eu sugeriria tentar com a compilação 20190928, já que a de outubro teve alguns outros problemas (que estou corrigindo na última semana)

Você também pode querer dar uma olhada no número de erros de leitura mostrados na página do plug-in, depois que ele estiver em execução por algumas horas.

Por exemplo, uma das minhas próprias unidades (3 dias de atividade)

NB o filtro (definido para "Use Unstable" na captura de tela) não tem significado no sensor MH-Z19B, é aplicável apenas para a versão -A.

E um outro:

Como você pode ver, o número de leituras com falha é mínimo.
Se você tiver alguns erros lá, você pode ter outro problema em mãos.

essas 11 redefinições em que estou tentando inicializá-lo novamente sem plugá-lo novamente, não me lembro de ver nenhum erro, mas posso dar outra chance, devo usar o Software Serial?

Hardware Serial é o melhor, mas você também deve desabilitar a porta serial em Tools->Advanced->Serial Port. (como é indicado na sua captura de tela :))

Não tenho certeza se algum adaptador USB para serial presente na placa pode afetar a comunicação.
Em caso de dúvida, você pode mudar para serial de software.

Compilação: ESP_Easy_mega_20201130_normal_ESP8266_4M1M
reportando ao FEM.
Eu tive um problema semelhante: o sensor MH-Z190B congela a cada poucas horas e continua caindo para 400 quando uso serial de hardware.
Depois de mudar para o software serial, parece funcionar normalmente e não congela mais.
2 capturas de tela em anexo.

O BME280 conectado com I2C funciona bem e mantém relatórios o tempo todo

Hum isso é estranho.
Em qual porta serial de HW ele foi conectado?
O que mais está conectado à placa? (por exemplo, USB para chip serial)
A opção "Usar serial" está desmarcada na página Ferramentas->Avançadas?

Está conectado ao GPIO-13 (D7) <- TX e GPIO-15 (D8) -> RX (primeiro em HW agora em SW) pois queria usar o TXD0 e RXD0 para ler as mensagens via porta USB (CH340 ) do Wemos D1 mini.
"Usar serial" significa "Configurações seriais - habilitar porta serial:" marcada? Deixei marcado para poder ler as mensagens por USB.

Serial HW em um ESP8266 usa Serial0.
Se você enviar também logs para a mesma porta serial, o sensor pode travar, pois não entende os "comandos" que recebe quando os logs são enviados por essa porta.

Se você conectar algo à porta serial HW, não deverá mais enviar outros dados. Assim, você deve desabilitar "Usar Serial" na página de ferramentas->Avançadas.

Ontem, recebi um segundo Sensor MH-Z19C. Este parece funcionar bem com HW-Serial em Serial2. Como todos os sensores foram conectados aos pinos D7 (GPIO 13) e D8 (GPIO 13) (RXD2 e TXD2) não deve haver nenhum conflito com Serial0 (Pinos RXD0 (GPIO3) e TXD0 (GPIO1)) até onde eu estou entendendo a pinagem. Eu acho que o primeiro sensor (MH-Z19B de outro fornecedor) era apenas um falso não funcionando corretamente, ...
Portanto, tenha cuidado ao comprar esses sensores. A segunda, que ganhei ontem, estava em uma embalagem muito melhor com o logotipo da Winsen e um certificado de teste junto. O fornecedor parece ser mais sério do que aquele que me vendeu o primeiro.