Espeasy: MQTT para de funcionar desde 20181008

Em 20181004, o seguinte mudou:

• [sendHttp] # 1830 Definir o tempo limite e saída antecipada no tempo limite atingido
• [WiFiClient] Defina o tempo limite e torne-o configurável para controladores
• [Núcleo 2.4.1] Mova de volta para o núcleo 2.4.1 de 2.4.2

E em 20181006:

• [WiFi] Adicionar atraso às tentativas de conexão em ControllerSettings

Você poderia testar a compilação 20181003 e talvez esses outros 2 também para diminuir o problema?

vou tentar, mas temo não ser capaz de fazer até sábado. ;-)

Você tem ideia de quanto tempo leva para que a conexão MQTT seja perdida?
E de alguma forma coincide com uma reconexão wi-fi?

Pelo que pude ver, não houve perda de wi-fi.
que a conexão MQTT foi perdida foi bastante rápido esta manhã (10 min), mas eu também tive horas de acordo com a última entrada do IOBroker ...
Vou tentar iniciar pelo menos uma das 3 compilações esta noite.

Apenas como um cheque; Você mesmo constrói ou usa compilações noturnas?

outra coisa a verificar:

tem certeza de que o MQTT está parando de funcionar?
Meu um aqui mostra depois de um tempo "Conexão PERDIDA", mas tudo ainda está funcionando com MQTT.

O único bug que vejo é a mensagem "Conexão perdida" enquanto tudo ainda está funcionando.
Por exemplo, recebo minutos de tempo de atividade pelo controlador MQTT.
Depois de um tempo (entre 10 minutos e 10 horas), vejo "Conexão perdida", mas os minutos ainda contam para enviar por MQTT.

Greetz
Sascha

O MQTT deve fazer uma reconexão assim que detectar que não está mais conectado.
Veja também @ Sasch600xt outro problema relacionado:
https://github.com/letscontrolit/ESPEasy/issues/1873#issuecomment -431170001

Algumas compilações antes de 20180927, aquela que você relata que está funcionando bem, adicionei uma correção para controladores MQTT em que o cliente MQTT no ESP se dará um novo ID de cliente, apenas para evitar que o corretor recuse uma nova conexão quando o corretor ainda assume uma conexão existente desse cliente e o cliente pensa que está desconectado.

Você pode aumentar a configuração de tempo limite do controlador? O padrão era 1000 ms, antes de introduzir essa configuração e a primeira construção tinha 100 ms como padrão. Mais tarde, mudei o padrão (para novas configurações) para 300 mseg.
Portanto, talvez você possa tentar configurá-lo para 300 ou mais (não mais que 1000 ms) apenas como um teste. (não importa a versão, pelo menos uma que costumava falhar)

Eu tive o mesmo problema com 1 (de 5) unidades. Eu brinquei um pouco com as configurações do controlador MQTT (intervalo mínimo de envio, profundidade máxima da fila, tentativas máximas e ação de fila cheia); configurações que funcionam agora para mim com esta unidade: 1000ms, 5/5 e "Delete Oldest".

Ok notícias ...
Parece que é o mesmo problema que o blb4github comentou 12 horas atrás. Peguei uma NOVA Unidade e funciona até agora sem Problemas !!!! Parece que o "antigo" tem problemas de memória ou de temporização. Vou tentar aumentar o tempo limite neste ... mantê-lo informado ;-)
Btw .. (Desculpe .. Selfbuild com Atom .. porque eu não quero todos os Plugins ... Mas até agora sempre deu certo ..) Vocês todos estão fazendo um ótimo trabalho nisso ... e pelo que eu descobri é apenas isso (e, portanto, aquele com o SW mais recente) que tem esse problema. Vou aumentar as configurações e informá-lo.

Atenciosamente Peter

@fraeggle, é possível colar aqui imagens de páginas de informações do sistema de módulos bons e ruins? (seções esp e de armazenamento)

E alguma descrição do hardware.
Por exemplo, tenho a sensação de que recentemente houve algumas mudanças nos módulos sonoff.
Sonoff basic e o S20

@fraeggle Você também poderia realizar uma limpeza completa do nó problemático e começar a limpar?
Arquivos bin vazios são incluídos nos arquivos ZIP de lançamento.

Oi TD-er
Eu havia apagado o nó defeituoso antes ... Já que alterei as configurações de tempo limite para 800 ms
é estável. A tensão está sendo atualizada a cada 120 segundos.

Hardware nada de especial .... porque ainda estou esperando a chegada de INA219 .. ;-)

Atenciosamente Peter

ai infelizmente fechei ..

Mas eu acho que com esta "workaroud" ela pode ser fechada ... Eu realmente acho que é um problema da Unidade agora ..
O que você acha disso TD-er?

Ainda assim, é estranho que as unidades sejam diferentes neste aspecto.
Isso sugere que a estabilidade do wi-fi é pior em uma unidade

concordo, mas acho que esta unidade simplesmente tem uma faixa de tolerância muito grande. Como eu disse, desde que mudei para 800 ms funciona bem ...
então, se você concordar, fecharei este, devido ao fato de que existe a possibilidade de alterar o tempo limite.

Obrigado pela ajuda..

saudações Peter

Eu encontrei "desde 20181007 MQTT Open Hab mostra" Conexão perdida "# 1873.
Talvez seja o mesmo problema?
TD-er me diga se eu posso ajudar criando logs ou algo assim ...
Usando Openhab (com IOBroker). mas até agora nenhum erro após definir o tempo limite para 800 ms

O broker MQTT para OpenHAB que você está executando está instalado em um computador em sua própria rede ou externo?
E se for local, talvez esteja instalado em um computador que não tem recursos?

Eu também tenho um teste em execução desde 394 minutos em 20181020.
Tempo limite em 800 ms.
Às vezes, ele aparece como Desconectado após 24 horas ou mais. Mas nunca cheguei a 2 dias.
E novamente, para mim tudo ainda está funcionando depois que mostra "Conexão perdida". Portanto, é apenas a mensagem que está confundindo para mim. Manterei você informado

Conexão perdida é apenas uma mensagem informativa que indica ... a conexão foi perdida.
Mas deve reiniciar uma nova conexão.
Na página sysinfo você pode ver quantas vezes a conexão WiFi foi perdida e reconstruída e também quanto tempo ela está conectada ao WiFi desde a última (re) conexão ao ponto de acesso.

Assim que a conexão WiFi for interrompida, ele também assumirá que a conexão MQTT deve ser reconstruída, portanto, considerará que a conexão com o broker MQTT foi perdida.
Até 4 semanas atrás, era possível que o broker MQTT não aceitasse a nova tentativa de conexão, uma vez que o broker ainda considerava o cliente conectado.
Isso pode resultar em tentativas indefinidas de reconexão, quando o cliente continua tentando se conectar e o corretor não aceita a conexão.
Alterei o ID do cliente MQTT em cada reconexão (adicionando o número de reconexões ao ID do cliente) para que o corretor o considerasse um novo cliente.
Isso resulta em uma reconexão rápida, com como único inconveniente, o corretor enviaria o LWT (última vontade e testamento), pois assume que o cliente está desconectado.

Se isso resultar em comportamento indesejado, posso transformá-lo em uma nova estratégia.
Por exemplo, em uma tentativa de reconexão que falha, posso tentar enviar uma mensagem de desconexão apropriada primeiro.

Em suma, existem inúmeras opções em que a conexão com o corretor pode ser perdida e não tenho certeza por que no seu caso ela foi perdida.
Pode ser um tempo limite, uma desconexão de WiFi, alguma resposta desconhecida do corretor ou qualquer outro motivo.

OK, entendi.
Declaração muito boa, obrigado.
Estou no minuto 507 agora / Controlador HAB aberto / tempo limite de 800ms.
Até agora está tudo bem :)

Devo definir o tempo limite padrão para novas instâncias de um controlador de volta para 1000 ms?

bem ...... me dê mais 36 horas ..... então eu sei melhor sobre o bug está chegando também com 800ms ou não.

Minuto 629 agora sem problemas ...

estranho ... descoberto após a mudança para 800ms.
Razão da última desconexão | (200) Tempo limite de Beacon
Número reconecta | 3
O que das Beacon Timeout significa?
MQTT ainda em execução, mas agora o mesmo que Sasch600txt. Mas diferente de antes ... MQTT ainda funcionando
apenas o corretor diz que este não está conectado.

Para obter mais informações sobre o quadro Beacon, consulte Wikipedia
Resumindo, o ponto de acesso envia periodicamente um pacote contendo informações sobre a rede.
Esse intervalo é normalmente de 100 TU (102,4 mseg).
O módulo ESP está tentando ouvir este beacon todas as vezes, mas por vários motivos pode perder um quadro de beacon. O tempo limite é superior a 100 TU, portanto, deve perder alguns desses quadros de beacon para relatar um tempo limite de beacon.
As razões para perder esse quadro de beacon são:

• muito ocupado processando outras tarefas de bloqueio (muito provavelmente)
• ponto de acesso não está enviando um beacon devido à alta demanda de tráfego de outros (dependendo da marca / modelo / configurações)
• Perturbações de RF (provavelmente não devido à frequência com que ocorrem)
• desvio do relógio (pouco provável)

Portanto, o "tempo limite do beacon" está acontecendo de vez em quando nos nós ESP.
Estou trabalhando muito para fazer com que cada plugin / controlador use intervalos curtos de tempo para tornar as tarefas o mínimo possível de bloqueio.

posso confirmar tudo que fraeggle disse.
Em algum momento esta noite eu tenho "Conexão perdida"

Tenha um bom fim de semana :)
Sascha

@fraeggle :
se aparecer como "Conexão perdida", tente entrar nas configurações do controlador do ESPEasy, simplesmente desabilite o controlador -> salvar, habilite-o novamente -> salvar. Então, pelo menos para mim, ele aparece como conectado novamente. Não é uma solução, mas pelo menos interessante :) é este IPSymcon que você está usando?

@ TD-er:
tarefas muito ocupadas? bem ...... na "UNIDADE DE TESTE" que estou executando aqui, envio apenas minutos de tempo de atividade a cada 60 segundos ... nada mais está sendo executado nesta unidade ... provavelmente o menor sistema possível

@ Sasch600xt, os termos "muito ocupado" talvez não sejam os melhores para descrever o problema real.
A maneira do Arduino de fazer as coisas é:

• ligue para setup()
• chame loop() repetidamente.

Além disso, a versão do Arduino para ESP8266 (e ESP32 Arduino) está executando algumas tarefas fora do loop() para a parte do Arduino.
Essas tarefas são sobre processos em segundo plano, como lidar com a conexão de rede e o tráfego de entrada, etc.
As tarefas em segundo plano são executadas apenas em:

• fim de loop()
• ao chamar delay() ou yield() de dentro do espaço do Arduino.

Se uma execução de loop levar mais de 102,4 ms e nenhuma chamada para yield () ou delay () for feita, o nó ESP terá perdido um intervalo de beacon.
Além disso, se estiver executando várias tarefas de bloqueio que estão sempre ocupadas no momento em que o ponto de acesso WiFi está enviando o beacon, vários beacons serão perdidos.

Ao examinar o log serial (com o nível de depuração habilitado), você verá as estatísticas de tempo.
Alguns deles podem fazer várias dezenas de ms e, portanto, são candidatos a causar esses motivos de 'desconexão'.

Eu poderia adicionar uma tarefa ao agendador para tentar ouvir o beacon a cada 102,4 ms. A única coisa é que não tenho certeza de como ver quando tal farol foi visto.

Sobre este problema, eu poderia olhar para a desconexão / reconexão do MQTT quando uma conexão foi perdida.
Qual corretor você está usando? Estou usando o Mosquito aqui e está funcionando bem com o comportamento atual.

ok, "muito ocupado" foi um pouco fácil de dizer sobre mim :)

Estou usando um script em execução no meu eviroment housecontrol ipsymcon para o corretor MQTT

Greetz
Sascha

Oi Sascha .. Usando IOBroker.
@ TD-er voltou para o Build 27092018. O corretor diz que ainda estou conectado ...
Muito confuso .. SEM erros em 14 horas (número reconecta | 0)

Estou instalando o IObroker agora no meu computador, só para ver o que está acontecendo.

Editar:
45 minutos depois e ainda não consigo fazer o IObroker funcionar em meus computadores.
Não tenho certeza do que está acontecendo aqui, mas o instalador do Windows simplesmente não funciona (o arquivo bat de serviço não está em lugar nenhum) e a instalação no Linux simplesmente não termina. Ele continua tentando fazer a mesma instalação do npm indefinidamente.
Testado no Ubuntu 18.04 em um host de CPU Intel e Bash no Windows (Ubuntu 18.04)

não tenho certeza com o windows .. eu acho que existem algumas dependências de software. Executando no Raspberry.
para Windows ioBroker verwendet Node.js als Plattform und setzt diese voraus. (Download: http://nodejs.org/download/) primeiro node.js deve ser instalado.

Também tenho um problema com um módulo com 4 sensores DS18B20 conectados.
Achei que fosse o meu RasPi, mas peguei uma imagem limpa do Raspbian Streth e instalei mosquitto e node-red nela. Mesmo problema, a conexão é interrompida após 6-12 horas.

Painel: https://emoncms.org/Edegem/scrtmp2e
As 4 curvas do ESP são CV_aanvoer, CV_retour e Sanitair_warm, Sanitair_koud

@fluppie se você usa compilações oficiais?

Não, eu me construo com PlatformIO / Atom
EDIT: Ha, eu não li bem, vou tentar uma compilação oficial.

Vamos assistir!

Oi

Eu tenho / tive o mesmo problema, estou usando HomeAssistant, mas depois de ESPEasy_mega-20181111 fw o problema parece resolvido para mim.

THX
T

O meu ainda estava perdendo a conexão após 2-3 dias. Vou atualizar para: ESP_Easy_mega-20181112_normal_ESP8266_4096.bin

Vamos ver!

O meu foi perder o controle. após 1-10 horas. Tenho um tempo de atividade de aproximadamente 10h30min e todos (5pcs) os módulos relacionados conectados. :-)

parece que valeria a pena tentar ... ainda em 2709 porque precisa de uma conexão estável. Por favor, mantenha-me informado. :-))

Você também pode acompanhar via: https://emoncms.org/Edegem/scrtmp2e e verificar se os gráficos CV_ e Sanitair_ estão lá :).

1 dia de atividade e ainda ok. :-)

Você também pode acompanhar via: https://emoncms.org/Edegem/scrtmp2e e verificar se os gráficos CV_ e Sanitair_ estão lá :).

:-D Sanitair_warm quase 60 C? pequena fogueira? ;-)
Vou tentar a firma .. Obrigado ...

Eu estava tomando banho ;-)

1 dia ... ainda conectado :-D
usando 12112018

Após ~ 3 dias e 3 horas, uma das minhas unidades perdeu a conexão MQTT. :-( (mega-20181112 4096 VCC fw)

@redskinhu :
só para ter certeza, ele ainda está funcionando bem depois que a unidade perdeu a conexão MQTT?
porque, do meu lado, está apenas aparecendo como "conexão perdida", mas ainda funciona bem com todas as ações MQTT.

Greetz
Sascha

Na verdade, uma conexão perdida não é incomum de vez em quando.
Contanto que a conexão esteja sendo reconstruída sem intervenção humana, não há problema.
As conexões WiFi serão reiniciadas de vez em quando e não há nada que você possa fazer para evitá-lo.
Assim que essa conexão for perdida, ele notifica os clientes MQTT no mesmo nó para reconectar.

Parece algum tipo de problema relacionado ao LWT. O MQTT não está totalmente desconectado, o ESPEasy envia / recebe mensagens MQTT, mas o LWT não é renovado, então o HomeAssistant não recebeu a mensagem LWT conectado antes de mostrar que o sensor / comutador relevante está indisponível. Esta é a minha teoria ...

Meu Ainda conectado e ao contrário do meu primeiro post, mesmo MQTT LWT me diz conectado. Parece bom.

Na verdade, uma conexão perdida não é incomum de vez em quando.
Contanto que a conexão esteja sendo reconstruída sem intervenção humana, não há problema.
As conexões WiFi serão reiniciadas de vez em quando e não há nada que você possa fazer para evitá-lo.
Assim que essa conexão for perdida, ele notifica os clientes MQTT no mesmo nó para reconectar.

OK, existe a possibilidade de renovar o LWT conectado neste caso?

Ele deve enviar o LWT no momento em que renovar a conexão.

Eu tenho um nó agora que é mostrado desconectado no LWT e envia medições muito bem. Uma construção um pouco mais antiga ... talvez isso lhe diga algo

Versão GIT: | mega-20181008
Tempo de atividade: | 3 dias 17 horas 36 minutos

Eu vi coisas estranhas quando o nó ESP pensa que foi desconectado e precisa se reconectar, mas o corretor discorda.

Oi

Fiz uma pequena investigação. Parece que apenas o LWT é o problema. Um dos meus ESP produziu novamente essa coisa de "desconectado" do MQTT.

Tudo está funcionando bem, sensores / interruptores. Mas o Home Assistant não pôde vê-los porque na configuração eu forneci os detalhes do LWT.

- platform: mqtt
  name: "Socket 02"
  command_topic: "home/Socket02_ESP12F/GPIO/13"
  state_topic: "home/Socket02_ESP12F/Relay/State"
  availability_topic: "home/Socket02_ESP12F/status/LWT"
  payload_available: "Connected"
  payload_not_available: "Connection Lost"
  payload_on: "1"
  payload_off: "0"
  qos: 1

Eu verifiquei o tráfego do MQTT: recebi os dados do sensor e consegui ligar / desligar o GPIO. Está tudo bem ex. o LWT.

E depois eu publiquei uma mensagem LWT "Conectado" e tudo voltou ao normal.

Espero que ajude.

T

PS:
Estou pensando em uma regra que pode publicar a mensagem LWT Connected se a mensagem LWT for Disconnected, mas infelizmente não consigo importar strings MQTT ;-)

De qualquer forma, estou ansioso pelo lançamento do novo fw. 4 longos dias ....

Estive ausente na segunda / terça e nos dias seguintes foram muito ocupados;)

Vou dar uma olhada no LWT para ver se consigo descobrir por que ele não foi publicado na reconexão.

Qual é a configuração de tempo limite do broker MQTT?
Estou pensando na possibilidade de o corretor presumir uma conexão perdida, mas o nó ESP ainda age como se tivesse estado ativo e ainda esteja conectado.

Tentei 100-1000 ms. Agora 300. Não importa.

Não no controlador, no corretor.
Esses tempos são da ordem de 10 a 15 segundos.
Portanto, verifique na configuração do corretor o tempo limite que está sendo usado.

Não mudei nada sobre o tempo limite de LWT e não consegui encontrar nenhuma configuração relevante na configuração do Mosquitto. Precisa ser o padrão. Não consegui encontrar nenhuma configuração de tempo limite de LWT nos documentos também.

Não, não é o tempo limite de LWT, o tempo limite do corretor.
Se um cliente não enviar uma mensagem no período de tempo limite, o corretor irá considerá-lo desconectado.
Portanto, se o cliente usar outra configuração de tempo limite, pode ser que o corretor considere o cliente desconectado e o cliente não tente se reconectar.

O que entendi da especificação mqtt que o corretor envia LWT quando não recebe uma mensagem do cliente dentro do período de manutenção que é definido pelo cliente. Nada para configurar no lado do corretor.

Consulte https://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over

E

https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament

Isso é verdade, mas o que eu quero saber é o que esse "período de manutenção da vida" significa do lado do corretor.
Eu sei que está fixo no lado ESPeasy.
Mas se eles não estiverem sincronizados um com o outro, você verá coisas estranhas acontecendo.

hm eu não tenho nenhuma possibilidade de definir algo assim

Mas ainda diz "Conectado". 4 dias :-D

apenas tinha um mega-20181006 fazendo o mesmo. LWT não atualizado para Online, mas normalmente está funcionando MQTT

@ jimmys01 Você consegue ver no seu corretor se ele está baseando a decisão no ID do cliente? (isso muda quando a conexão é perdida)
Essa mudança de ID do cliente é algo que adicionei nas compilações do final de setembro.

@ TD-er, encontrei uma maneira de reproduzir isso! Eu desautorizo ​​o wemos do roteador mikrotik e ele conecta direto de volta, mas o LWT fica offline enquanto o mqtt ainda está funcionando. Envie-me construções para testar à vontade

Você também pode ver o ID do cliente no broker MQTT?
Se tiver um "-1" ou algo atrás do ID do cliente, significa que aceita o novo ID do cliente.
Se não, então pode ter algo a ver com a mudança de IDs de cliente que fiz há algum tempo.

Não descobri onde o id do cliente está no Mosquitto, mas os logs mostram que nenhum cliente está desconectado e um novo está conectado, provavelmente porque o processo de desautorização e autenticação do wifi é mais rápido que a pulsação do protocolo MQTT.

Nova conexão depois de reiniciar o esp e o corretor

 New connection from 10.10.1.53 on port 1883.
1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').

Desautorize o cliente e o cliente se reconecta. O corretor desta vez deixou o cliente LWT online por algum motivo ...

1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965308: New connection from 10.10.1.53 on port 1883.

Segunda desautorização

1542965308: New client connected from 10.10.1.53 as aquariums_1_1 (c1, k10, u'openhabian').
1542965308: Socket error on client aquariums_1, disconnecting.
1542965385: New connection from 10.10.1.53 on port 1883.

A partir dessa reconexão e no LWT permanecer offline, as mensagens MQTT funcionam bem. Observe o _1_1 extra no nome do cliente.

1542965385: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965385: Socket error on client aquariums_1_1, disconnecting.
1542965448: Socket error on client aquariums_1, disconnecting.

OK, então vou reverter a alteração do ID do cliente.
Talvez também seja possível verificar remotamente se o cliente é considerado conectado?
Tenho visto recusas de conexão quando o corretor considera o cliente ainda conectado e o cliente tenta se reconectar.
Tentar novamente em intervalos curtos manterá esse status e, portanto, o cliente nunca será capaz de se reconectar.

Alguma atualização de status sobre isso?

Não, ainda não.
Mas como estamos fazendo algum progresso (finalmente) em outras questões de estabilidade, acho que será o próximo na minha lista.
Obrigado pelo ping;)

Tornei opcional a alteração do ID do cliente na reconexão. (Ferramentas => Avançado, próximo às outras configurações MQTT)

Feche o problema se estiver funcionando agora.
Vou defini-lo como fixo.

Por que mudar o ID do cliente mesmo assim?

Houve relatos de o corretor rejeitando tentativas de conexão, desde que o corretor presumisse que o cliente ainda estava conectado.
Então, o cliente foi rejeitado e tentou novamente.
Mas de alguma forma essas reconexões acionaram algo no lado do corretor para considerar as tentativas de conexão como atividade recente daquele cliente e, portanto, nunca consideraria o cliente desconectado.

Ok, isso resolveu, mas a solução não é autoexplicativa para os outros que veem essa caixa de seleção.
Talvez adicione um pop-up que explicará como marcá-lo se houver problemas de reconexão após uma perda de wi-fi
Uma pesquisa nos problemas do tasmota mostrará que eles tinham problemas de aparência semelhantes, relacionados à retenção do MQTT, pareciam ser um problema do corretor.
Também tive um cliente que não se reconectou ao wi-fi depois de desautorizá-lo ... preciso investigar isso.

Vamos adicionar isso à documentação .
Estamos trabalhando muito para tornar a documentação atualizada e também mover muita documentação do wiki para os ReadTheDocs. Isso possibilita ter documentação por versão.
Os arquivos docs também estão incluídos no repositório GitHub.

Idealmente, um commit para uma correção no código também conterá uma atualização na documentação.
Vou encerrar agora este problema.
Se você tiver mais informações sobre o outro problema que mencionou, abra um novo problema para ele.

Oi

Instalei a versão 20190110 recentemente. Parece promissor. Sem problemas de LWT após 5 dias de teste. :-)
Tenho alguns nós com a opção "MQTT alterar ClientId ao reconectar" ativada e alguns com desativada.

Boas notícias!

T