Espeasy: Problemas de wi-fi - história que nunca termina - voltar ao wi-fi não baseado em eventos?

Criado em 23 abr. 2018  ·  388Comentários  ·  Fonte: letscontrolit/ESPEasy

Como muitos de vocês notaram nas últimas semanas, houve muitos problemas com o wi-fi.
Tudo começou quando mudei a forma como o wi-fi opera para ser baseado em eventos.

  • IP estático não funciona
  • Loops de inicialização (ESP32)
  • Conectado, mas a transferência de dados não é possível (NTP não pode se conectar a 0.0.0.0)
  • Nenhum AP encontrou erros
  • O carregamento da página de configuração do modo AP não está funcionando (alterado para o núcleo 2.4.0 para isso)
  • Erros de tempo limite de beacon => sem reconexão adequada
  • Vários outros problemas relacionados com wi-fi.

Alguns desses erros estão relacionados à versão do núcleo, e a atualização para o núcleo 2.4.0 apresenta muitos outros problemas.
E depois há o problema com as configurações corrompidas que também existiam neste período. Isso não estava relacionado à conexão baseada em eventos wi-fi, mas me fez procurar muitos outros problemas que não eram realmente problemas, mas apenas configurações corrompidas.

Então, no momento, a máquina de estado wi-fi que escrevi é excessivamente complexa devido às muitas correções que não foram corrigidas, porque as coisas não estavam quebradas.
E ainda há outros problemas reais, causados ​​pelo núcleo 2.4.0 ou problemas de wi-fi ainda abertos.

Portanto, agora temos que escolher:

  1. Volte para sloooowwww mas wi-fi estável (ainda há alguns problemas com MQTT quando a conexão é perdida)
  2. Invista um pouco mais de tempo para obter o wi-fi baseado em eventos da maneira certa + tente fazer o núcleo 2.4.1 funcionar.
  3. Invista um pouco mais de tempo para obter wi-fi baseado em eventos da maneira certa, mas ainda volte ao núcleo 2.3.0
  4. Alguma solução intermediária para fazer wi-fi assíncrono com núcleo 2.3.0

O Core 2.3.0 parece dar muito menos problemas e deixar mais memória livre.
Então, acho que essa é minha base preferida.
Isso significa que, para wi-fi baseado em eventos, ainda há alguns problemas com relação ao carregamento da página de configuração quando a configuração inicial é necessária.

De qualquer forma, isso tem que parar agora e ficar estável novamente.
Atualmente, existem muitos problemas em mãos que são muito difíceis de ver como problemas separados.

Alguma outra sugestão?

Core related Stabiliy Wifi Fixed Discussion
Fonte
picture TD-er

Comentários muito úteis

Não tenho certeza sobre o LED de status. Ele é chamado a partir da função MQTTconnect e de alguns outros locais.
Mas talvez você pudesse adicionar um problema para torná-lo selecionável o que está sendo mostrado por meio daquele LED?

E bom saber que os problemas do MQTT parecem ter sido corrigidos pelo tempo limite reduzido.
Podemos ter que torná-lo selecionável.

picture TD-er em 29 abr. 2018
👍2

Todos 388 comentários

Eu realmente não posso falar sobre isso a partir de um nível de programação, mas pelo que tenho visto é que, com exceção do endereço IP estático, ao configurar uma unidade "totalmente nova", o wi-fi parece funcionar multar. Não vi nenhum problema de conexão com instalações "frescas" com os firmwares mais recentes. As páginas da Web carregam rápido e tudo parece rápido e responsivo. É quando você tenta atualizar é quando a maioria desses problemas parece estar acontecendo. Parece que há um problema de corrupção ao atualizar para um firmware mais recente.

Também notei que muitos firmwares compilados por usuários estão tendo problemas de wi-fi. Só de ler todos esses posts tem essa impressão. Eu posso estar completamente errado sobre isso. Não estou tentando dizer isso como um fato, mas apenas uma possibilidade.

Não posso falar com o MQTT porque não o uso.

Apenas meus 2 centavos no valor ...

Budman1758 picture Budman1758 em 23 abr. 2018

Se você está inclinado para a opção 3, eu o apoio totalmente. Eu odiaria nos ver abandonando as melhorias que seu Wi-Fi baseado em eventos nos deu. Core 2_4_x pode ser mais fácil de reverter / ir para cima?

Grovkillen picture Grovkillen em 23 abr. 2018
👍1

Da perspectiva de um usuário:
Eu iria em frente e usaria o novo Core 2.4.1 assim que possível.
Os usuários sempre podem usar versões mais antigas.

DittelHome picture DittelHome em 23 abr. 2018
❤1 👍1

Não se esqueça, o núcleo 2.4.x corrige alguns problemas:
A oscilação do PWM é história (# 1156 foi corrigido com o núcleo 2.4.0)
Série com pacote grande também são fixos ...
Em algum ponto, temos que fazer a transição para o novo núcleo. Voltar para 2.3.0 significa apenas adiar o problema. No final, temos que fazer o trabalho de qualquer maneira. Meus ESPs são definitivamente melhores com 2.4.0

DittelHome picture DittelHome em 23 abr. 2018
👍2

A meu ver, o núcleo 2_4_x acontecerá, mas talvez não seja necessário agora. Tomamos uma má decisão quando avançamos com a atualização de núcleo e abordagem baseada em eventos de wi-fi ao mesmo tempo. Devíamos ter feito um após o outro. Quando nós, então, ao mesmo tempo, tivemos uma atualização nas configurações globais, o problema ficou extremamente difícil de localizar. Apoio fortemente a ideia de voltar a 2_3_0 durante a correção da estabilidade do wi-fi + correção da corrupção das configurações.

Depois disso, podemos lançar o v2.1.0 e, em seguida, focar em tornar o núcleo 2_4_x estável para v2.2.0

Grovkillen picture Grovkillen em 23 abr. 2018
👍2

Depois de limpar as configurações e enviar a versão de 22.04. Até agora tudo está funcionando. Pelo menos por enquanto :) Só a memória livre não é suficiente, mesmo em NORMAL. Vamos ver como vai continuar.

melwinek picture melwinek em 23 abr. 2018

Eu tenho que concordar com @ Budman1758 e @melwinek : Eu também descobri que partindo de uma unidade limpa não há nenhum problema com Wifi, IP estático e configurações.
O principal problema é o fato de que, para atualizar, agora preciso limpar manualmente todas as unidades, atualizá-las novamente e reconstruir suas configurações.

giig1967g picture giig1967g em 23 abr. 2018
👍2

Acho que não devemos esquecer que oficialmente ainda estamos no processo de passar do R120 estável para o 2.1.0 estável e as configurações não serão convertidas entre esses dois lançamentos, fazendo com que você precise começar do zero de qualquer maneira. O que fizemos com a atualização do núcleo 2_4_x foi fazer um "ponto de interrupção" mais uma vez. Se podemos viver com isso, então não é um problema. Eu concordo que uma instalação limpa é realmente estável (pelo menos em NORMAL, que eu testo com mais frequência). E NORMAL é a única parte que realmente estará no lançamento, teste e dev estão apenas no lançamento noturno de desenvolvimento de qualquer maneira.

Grovkillen picture Grovkillen em 23 abr. 2018

O que quero dizer é: se o firmware desenvolvido atualmente funciona e é estável em uma configuração limpa, isso significa que não há nada de errado com ele. Eu não voltaria para 2.3 ou para wi-fi antigo.

giig1967g picture giig1967g em 23 abr. 2018
👍1

Sim, eu ouço você e meio que concordo. A única coisa é que criamos outro ponto de interrupção que eu acho que está bom, pois ainda é beta.

Grovkillen picture Grovkillen em 23 abr. 2018
👍1

Embora seja um retrocesso do qual não gosto, receio que seria realmente melhor voltar ao núcleo 2_3_0 por enquanto, pois acho que alguns problemas estranhos podem acontecer devido à falta de memória livre em 2_4_0.

ghtester picture ghtester em 23 abr. 2018

@ giig1967g Concordo com você. Eu acredito que existem alguns problemas de corrupção acontecendo. Pode ser o que está atrapalhando o wi-fi vs seu ter um monte de problemas inerentes.

Budman1758 picture Budman1758 em 23 abr. 2018

Ainda há opções para fazer com que o uso da memória atinja um ponto aceitável.
Acho que posso obter cerca de 3 a 4 kB a mais de memória em 1 noite de programação. (embora seja necessário alterar todos os arquivos de plug-in)
E a importação de MQTT também é algo que realmente é uma dor que deve ser resolvido em breve.
E o plugin Switch tem muitas funcionalidades que deve ser dividido.

Vou pensar sobre isso hoje, o que devemos fazer, então, por favor, adicione mais sugestões / argumentos :)

TD-er picture TD-er em 23 abr. 2018
👍1

@ TD-er Você está certo com SWITCH.
A maioria das pessoas usa apenas ON / OFF para interruptor / relé.
E neste plugin existe um servo, dimmer e provavelmente algo assim.
Isso poderia ser separado.

melwinek picture melwinek em 23 abr. 2018

Ele também está lidando com coisas muito específicas para MQTT e / ou Domoticz. Isso não deve fazer parte do plugin.

TD-er picture TD-er em 23 abr. 2018

@ TD-er Em muitos casos, ajudaria a me compilar, após remover plugins desnecessários, em muitos casos eu preciso apenas SWITCH, FHEM Controller, DHT.
Mas depois dessas aventuras com configurações estou com medo de compilar sozinho. Especialmente depois de sua postagem: https://github.com/letscontrolit/ESPEasy/issues/1292

melwinek picture melwinek em 23 abr. 2018

Você deu uma olhada, como o wi-fi é realizado em outros projetos (por exemplo, tasmota)?

Sobre a memória: eu te disse: sorria:
Acho que há muitos recursos raramente usados ​​no núcleo - a decisão, se uma solicitação de recurso principal for implementada, deve ser muito mais rígida - agora é um pouco como o Natal para todos ...
Talvez uma votação com certo limite ajudasse.

Se possível, o núcleo deve primeiro ser limpo dos recursos raramente usados ​​(ou transformado em um plug-in) e, em seguida, otimizado. Além disso, pode-se pensar em interfaces adicionais para plug-ins, para permitir a troca de mais funcionalidade fora do núcleo.

M0ebiu5 picture M0ebiu5 em 23 abr. 2018

@ M0ebiu5 Concordo.
O que deve acontecer é que os novos recursos serão desenvolvidos em um branch separado, em seguida, reúna alguns deles e mescle-os em um branch candidato a lançamento e teste-os.
Em seguida, libere e mescle os recursos usados ​​no branch master (ou branch dev, ou como quiser).

E uma coisa que aprendi é perguntar duas vezes sobre o que é observado, o que deve ser observado e qual versão é usada. Isso tornará as coisas muito mais claras e levará a menos erros.
Parte disso deve ser feito no próprio código para fazer algum tipo de pegada para ser capaz de ver (e registrar) qual software é usado.

Além disso, os plug-ins devem ser apenas plug-ins para fazer a interface de um sensor com alguns valores de saída.
Talvez plug-ins que geram saída (como telas) não devam ser usados ​​da mesma forma que os de entrada.
Portanto, obtemos algo como:

  • Sensor para ler um dispositivo e gerar medições
  • Saída (exibição?) Para os valores presentes. Também pode ser algo diferente de um display, por exemplo JSON ou uma imagem.
  • Controlador para fazer interface com o mundo externo (entrada e saída)
  • Regras para processar dados e eventos.
  • Notificações para converter eventos em outra coisa. Na verdade, parece um controlador mais elaborado.
  • Comandos para fazer alguma configuração básica ou mudanças / atualizações temporárias (não persistentes) e executar algumas ações (por exemplo, reinicializar)
  • Página da Web para configurar todos eles.

Mas esse redesenho exigirá algum esforço.

TD-er picture TD-er em 23 abr. 2018

@ TD-er você está certo, mas eu faria as mudanças em pequenos passos - porque a maioria das peças está funcionando de forma estável e grandes mudanças podem colocar essa estabilidade em risco.

Novas interfaces para o núcleo são uma forma possível. Eles não influenciarão o comportamento atual e apenas plug-ins novos ou fortemente alterados os usarão. Levará mais tempo para transformar para uma arquitetura limpa, mas com um risco menor e o esforço também será distribuído ao longo do tempo.

M0ebiu5 picture M0ebiu5 em 23 abr. 2018

Concordo que essas mudanças devem ser feitas à vontade.
É mais uma visão do redesenho para o futuro.

TD-er picture TD-er em 23 abr. 2018

No entanto, o nó de 22.04 perdeu a conexão.
Reinicializar o roteador não ajuda.
A redefinição do ESP ajudará, mas estou longe.
Portanto, a melhor versão em meus nós é mega-20180410.
Talvez porque esteja no núcleo 2.3?
Talvez, no entanto, uma boa solução fosse voltar a 2.3 por algum tempo?

melwinek picture melwinek em 24 abr. 2018

Não, ontem à noite vi o problema (no código e acontecendo nas minhas próprias unidades).
Meus nós não se reconectaram quando obtiveram um erro de 'tempo limite de beacon', que é um motivo comum para a desconexão. É um erro lógico no código, mas já passava da 1h30 e eu não queria consertar naquele momento. Certamente já teria passado da hora da construção noturna para consertá-lo, então isso não importava mais;)

TD-er picture TD-er em 24 abr. 2018
👍2

relacionado: # 1064

s0170071 picture s0170071 em 25 abr. 2018

Acabei de atualizar 6 dispositivos com a versão atual ESP_Easy_mega-20180425_test_ESP8266_4096.bin.

Acho que com esta versão atingimos um ponto baixo absoluto.
Todos os dispositivos não puderam ser alcançados na rede após algumas horas.

micropet picture micropet em 25 abr. 2018

É por isso que irei, de uma forma ou de outra, retornar a uma versão wi-fi funcional.

Talvez devêssemos remover o build de hoje, apenas para evitar que outros carreguem o mesmo.

TD-er picture TD-er em 25 abr. 2018

Eu sugeriria construir agora uma nova versão 04.25 no núcleo 2.3.0 e substituir a atual :)

melwinek picture melwinek em 25 abr. 2018

Não tenho controle sobre o servidor de compilação.
e 2 versões com o mesmo número de compilação nunca é uma boa ideia.

Eu sei que @Grovkillen pode remover a compilação de hoje.

TD-er picture TD-er em 25 abr. 2018

Você acha que eu deveria removê-lo @ TD-er? Um novo será construído amanhã.

Grovkillen picture Grovkillen em 25 abr. 2018

Aparentemente, é ainda pior em comparação com a construção de ontem.
Então, sim, remova-o.

TD-er picture TD-er em 25 abr. 2018

Feito

Grovkillen picture Grovkillen em 25 abr. 2018

E o platformio.ini também foi alterado.
Portanto, aconteça o que acontecer, a construção de amanhã não será tão ruim quanto a de hoje.

TD-er picture TD-er em 25 abr. 2018

Sinto pânico por aqui. Não se preocupe, ainda há esperança.
Primeiro, vamos tomar uma: cerveja: ou: cervejas: Agora,
obrigado @ TD-er por avançar tão incansavelmente apesar de suas preocupações, obrigado @Grovkillen por apoiá-lo. Obrigado a todos os outros também. E obrigado a todos por discutir novas ideias tão abertamente.

Dito isso, deixe-me dizer o seguinte:

  1. De acordo com minha experiência, não há nada de errado com as versões de núcleo mais recentes, exceto para 2.4.1 que tem um vazamento de memória wificlient (e uma solução alternativa).
  2. As versões mais antigas do branch master até o ponto em que houve uma decisão de abandonar o 2.0 funcionaram bastante estáveis ​​com essas versões principais. E rápido.
  3. Nós realmente deveríamos (ênfase em sério!) Focar na estabilidade. Sem novos recursos por um tempo (a menos que melhore a estabilidade), menos ESP32 e menos caça à memória, menos aceleração, menos tudo, menos estabilidade. Vamos fingir que planejamos voar para a lua. Sério. Essa coisa precisa funcionar. Ele precisa tolerar falhas de bit único, reinicializações, flutuações de energia e estresse de temperatura.
    Quero dizer programação tolerante a falhas. Pronto. Pode ser divertido se você envolver sua mente em torno disso.

Qual é o próximo ? Se eu fosse um desenvolvedor central, optaria por essa configuração baseada em json. O mais cedo possível. Parece ser a raiz do mal atual, assim como o servidor da web com uso intensivo de memória era um tempo atrás.

s0170071 picture s0170071 em 25 abr. 2018

Sinto pânico por aqui. Não se preocupe, ainda há esperança.
Primeiro, vamos ter um 🍺 ou 🍻 agora,
obrigado @ TD-er por avançar tão incansavelmente apesar de suas preocupações, obrigado @Grovkillen por apoiá-lo. Obrigado a todos os outros também. E obrigado a todos por discutir novas ideias tão abertamente.

100% concordam !!!

Não sei se esse erro já é conhecido:
Depois de um ou dois dias, parece que o servidor web não funciona mais. A publicação MQTT ainda está funcionando.
Estou usando a versão normal de 04.22.

DittelHome picture DittelHome em 25 abr. 2018

@ TD-er, pessoalmente, votarei em algo novo como 2.4.1 para tentar.

uzi18 picture uzi18 em 25 abr. 2018

1+

micropet picture micropet em 25 abr. 2018

1+

susisstrolch picture susisstrolch em 25 abr. 2018

Sinto pânico por aqui. Não se preocupe, ainda há esperança.

Não é pânico, é pura frustração;)
O fato é que eu realmente testo as coisas aqui e em minutos (pelo menos parece que sim) as compilações falham ainda mais do que antes.
Estou acostumado a programar contra caixas pretas e também contra rev. projetar essas caixas pretas.
Mas parece que o feedback que vejo nos registros é completamente diferente da realidade.
Agora está claro que houve vários problemas nas últimas semanas, devido a bugs nas bibliotecas centrais, configurações corrompidas e algumas alterações que fiz pareciam estar relacionadas a alguns bugs no firmware do AP.

E minha opinião pessoal sobre o software é que ele deve ser estável como uma rocha e a velocidade vem em segundo lugar.
Mas nas últimas semanas o aumento de velocidade está bom, mas a estabilidade foi piorando a cada dia, não importa o que eu tentasse.

Portanto, agora é a hora de fazer uma parada firme e focar primeiro na estabilidade. Você poderia chamar isso de 'pânico', mas na verdade é uma espécie de retrocesso para realmente focar no que está acontecendo.
Agora sei muito mais sobre wi-fi do que há um mês, então devo ser capaz de fazer um pacote bem projetado. Mas isso leva tempo e eu realmente quero chegar a algum ponto de estabilidade e ter algum momento de tranquilidade na minha cabeça para fazê-la funcionar como deveria.
E ainda há muito espaço para tornar as coisas ainda mais rápidas, porque já vi o ik conectar-se ainda mais rápido :)
Mas isso é para a próxima versão.

Sobre o resto das questões principais:

  • uso de memória
  • Importação / exportação JSON de configurações
  • Redesenho de importação MQTT
  • alguns plugins como P001-switch devem ser alterados.
  • O que sobrou.
TD-er picture TD-er em 25 abr. 2018
❤1

para mim (e provavelmente apenas para mim) mudar para 2.4.1 ou mesmo GIT Core não melhorou, o oposto foi o caso. Eu tentei cerca de 20 combinações diferentes de versões core, mage-commits e lwIP. Voltar para 2.3.0, especialmente o lwIP 1.4, era a única maneira de mantê-lo funcionando de maneira estável. Mas, novamente, apenas minha visão disso em meu ambiente específico ...

E sim, muito obrigado @TD-er e @Grovkillen pelo excelente trabalho que fazem e pelo tempo que investem para a comunidade!

clumsy-stefan picture clumsy-stefan em 25 abr. 2018
👍1

Obrigado a todos, @ TD-er resume o caminho a seguir muito bem.

Sobre o resto das questões principais:
• uso de memória
• Importação / exportação JSON de configurações
• Redesenho de importação MQTT
• alguns plug-ins como P001-switch devem ser alterados.
• O que sobrou.

E vamos reverter para 2.3.0 para o lançamento de amanhã e testar isso por um tempo.

Grovkillen picture Grovkillen em 25 abr. 2018

A maioria de minhas imagens de auto-construção são baseadas em rev. 491c9b8b (2.4.1 + x).
A única coisa que vejo são reinicializações aleatórias com meu dispositivo Sonof 4ch. Infelizmente, é parte do meu controle de lagoa, então sem chance de conectar uma interface serial para melhor monitoramento, o Syslog é bastante inutilizável, porque a informação relevante é cuspida antes que o WIFI esteja instalado e funcionando.

É bastante utilizável - contanto que você use a biblioteca lwIP 'v2 Higher Bandwith'.
Caso contrário, você verá problemas com fragmentação de MTU com pacotes> 512Bytes (fora de ordem, com informações de janela impróprias).

Os ESPEasy Revs (meus repositórios) de trabalho são

commit 3576619181926b3adff5a1a133390eb71e808ae9
Unir: 9038bd2 d083a58
Autor: Susis Strolch
Data: Sexta-feira, 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

e
commit daf39a064d3633fe1eccfa33576fafbccd7611a7
Unir: 2a96218 806a275
Autor: Susis Strolch
Data: Seg, 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)

Qualquer ESPEasy após a sexta-feira 13 de abril mostra resultados horríveis - falando que não funcionam - mesmo ao apagar todo o flash antes de piscar o binário (via Arduino IDE).

Então, eu sugiro ir com 2.4.1 (ou posterior) e polir ESPEasy (WIFI e configuração).
O próprio núcleo parece estar ok até agora.

susisstrolch picture susisstrolch em 25 abr. 2018

rsrs @ Sexta -
Então, o que é "polonês ESPEasy (WIFI e configuração)." ?
Um ramo diferente ..?
Polônia também conhecida como polonês ou polonês como em lustre e brilho, ha

Oxyandy picture Oxyandy em 26 abr. 2018
😄1 👎1

@susisstrolch Como faço para detectar erros como esse?
"problemas com fragmentação de MTU com pacotes> 512Bytes (fora de serviço, com informação de janela imprópria)."

Oxyandy picture Oxyandy em 26 abr. 2018

Basta enviar a solicitação preparada para o servidor web espeasy, com cabeçalho adicional com no mínimo 512 caracteres

uzi18 picture uzi18 em 26 abr. 2018
👍1

@Oxyandy : executando tcpdump em meu servidor FHEM e analisando com WireShark, descobri que os últimos 512 bytes de uma resposta JSON de ~ 700 bytes foram enviados primeiro, seguidos pelo cabeçalho HTTP.
E esses dois pacotes simplesmente faltavam as informações da janela TCP.
Pode enviar mais detalhes a pedido ...
polir como lustrar e brilhar

susisstrolch picture susisstrolch em 26 abr. 2018
👍1

Para mim, a versão de 22.04.2018 com Core 2.4.1 funciona muito bem.
sysinfo

micropet picture micropet em 26 abr. 2018

Você também poderia verificar o meu trabalho de ontem, mas depois baseado no 2.4.1?
https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability

Em 2.3.0 eu ainda tinha problemas com IP estático.
Ainda não testei o modo AP com a página de configuração.

TD-er picture TD-er em 26 abr. 2018

Acabei de mostrar um wemos com a sua versão
[wi-fi] Tentativa de tornar o wi-fi baseado em eventos mais simples).

Vesion corre ...

O que eu deveria fazer agora?

micropet picture micropet em 26 abr. 2018

Merda, do meu último teste (22.04.1018) 4 de 8 dispositivos desligaram após cerca de 7 horas.

micropet picture micropet em 26 abr. 2018

Eu acho que nenhum log? :(
Os nós travaram (travaram) ou simplesmente não se reconectaram?
Eles respondem ao ping e, portanto, apenas o servidor da web desativado ou muito ocupado (a reconexão do MQTT consome muitos recursos)?

TD-er picture TD-er em 26 abr. 2018

Enquanto isso, pendure 5 dispositivos.
Eu não tenho um log. O servidor da web não está acessível. O ping também não funciona.

eles estão simplesmente mortos.

micropet picture micropet em 26 abr. 2018

Você realmente deve tentar registrá-lo. Pode nos dar algumas dicas úteis

Grovkillen picture Grovkillen em 26 abr. 2018

Eu registro a versão de Gijs. Já está funcionando há 55 minutos. :)

micropet picture micropet em 26 abr. 2018

oh, eu posso vencer isso! Tenho 12 dispositivos rodando entre 45 e 263Min's na versão Gijs (com esp core do GIT) 😀 e ainda assim todos felizes ...

clumsy-stefan picture clumsy-stefan em 26 abr. 2018

Sim, os tempos mudaram.
No passado, meus dispositivos funcionavam por semanas.

Hoje ficamos felizes quando trabalham algumas horas. :)

micropet picture micropet em 26 abr. 2018
😄1

Um dos meus dispositivos em casa ainda está executando a construção que fiz em 20171231 e está com 60 dias de atividade hoje.

Então, eu sei o que você quer dizer :(

TD-er picture TD-er em 26 abr. 2018

Então, vamos pegar a versão 2017123, então podemos nos concentrar em outras coisas. :)

micropet picture micropet em 26 abr. 2018
👍1

Hora local: | 26/04/2018 17:47:23
Tempo de atividade: | 0 dias 2 horas 27 minutos
Carregar: | 10% (LC = 9371)
Mem grátis: | 10336 (9544 - sendContentBlocking)
IP: | 192.168.0.201
Wifi RSSI: | -67 dB

micropet picture micropet em 26 abr. 2018

Ei, por que não pegar essa versão de 60 dias, marcá-la com 2.0 e escrever alguns pontos sobre problemas conhecidos (não faltando recursos)

s0170071 picture s0170071 em 26 abr. 2018
👍2

@ s0170071 realmente precisamos de 75% do produto funcionando e muitos problemas resolvidos após o lançamento?

uzi18 picture uzi18 em 26 abr. 2018

Talvez não seja necessário voltar tão longe ... Esta é a última reinicialização manual:

Tempo de atividade: 21 dias 3 horas 32 minutos
Carga: 32% (LC = 6281)
Mem grátis: 14328 (13392 - parseTemplate3)

Construir | 20100 - Mega (núcleo 2_3_0)
Versão GIT | mega-20180308
Plugins | 72 [Normal] [Teste] [Desenvolvimento]
Build Md5 | eb5a94ae675cb343cc387319fd8c4f9a
Verificação Md5 | passado.
Tempo de construção | 8 de março de 2018 03:05:36
Nome de arquivo binário | firmware.bin

ghtester picture ghtester em 26 abr. 2018

6 dispositivos estão funcionando por 5 horas - um novo recorde.

micropet picture micropet em 26 abr. 2018

Já são mais de 30 horas;)

TD-er picture TD-er em 26 abr. 2018

Eu tenho agora quase todos (12+) dispositivos rodando nas mudanças do @TD-er de tonigt. Todos os Wemos D1 Mini's com uma variedade de sensores e relés acoplados (todos diferentes). A maioria deles tem agora 10h + uptime. Vou mostrar os últimos também agora.
Eu tive duas ou três reinicializações espontâneas de um ou dois dispositivos, mas isso também pode ser de plug-ins ou sensores com defeito (eu também uso alguns plug-ins devel e até mudei a configuração para suportar 24tarefas e usando esp GIT core, alguns até mesmo sem limpar o config primeiro). Mas eles sempre voltaram e se conectaram à rede com sucesso!

Portanto, para mim, esta é a versão mais estável que tive até agora. semelhante ao que eu tinha antes do núcleo 2.4.0.

Portanto, eu votaria para mesclar as mudanças @ TD-er de hoje à noite, testá-lo e seguir em frente ... Mas isso é apenas MHO ...

E obrigado a @ TD-er pela rápida correção de bugs (tente) !! Para mim funcionou !!

clumsy-stefan picture clumsy-stefan em 26 abr. 2018
👍1

Eu também reiniciei um dispositivo, mas ele foi reconectado imediatamente.
Todos os dispositivos são Wemos D1 mini.

Eu executei a versão de teste aqui com 71 plug-ins.
Nos dispositivos estão quase apenas BME280, Pir, MH-Z19 e um sensor de poeira e alguns Leds.

O servidor web reage muito rápido.
No momento estou muito satisfeito com esta versão e o Core 2.4.1.

micropet picture micropet em 26 abr. 2018

Talvez já seja conhecido (em caso afirmativo, ignore-o)
Instalei um ESP pro mini com ESP_Easy_mega-20180422_normal_ESP8266_4096.bin (núcleo 2.4.0).
Está a funcionar há 3 dias!
A GUI não está mais acessível, somente após a inicialização a frio. (testet com outro esp)
O ping está ok, a publicação de mqtt também funciona, a troca de GPIO por http também funciona.
O "único" problema, o gui não está acessível.
Ou seja, o ESP funciona às cegas, está tudo bem, só a GUI não responde.
Depois de digitar o ip no navegador, obterá:

ily: sans-serif; tamanho da fonte: 12pt; margem: 0px; preenchimento: 0px; dimensionamento da caixa: caixa de borda; } h1 {tamanho da fonte: 16pt; cor: # 07D; margem: 8px 0; font-weig190; cor: # 07D; } .button {margin: 4px; preenchimento: 4px 16px; cor de fundo: # 07D; cor: #FFF; decoração de texto: nenhum; raio da borda: 4px; borda: 190 190 ative; cursor: ponteiro; tamanho da fonte: 12pt; -webkit-user-select: nenhum; -moz-user-select: nenhum; -ms-u

Habilitei o registro com meu segundo dispositivo após a reinicialização a frio, depois que o dispositivo deixar de responder, um relatará o registro aqui, se desejado.

DittelHome picture DittelHome em 26 abr. 2018

Você também pode registrar o uso de memória? Só para ver se há algum vazamento de memória no 2.4.1, conforme relatado por alguns.

TD-er picture TD-er em 26 abr. 2018

Sim, exatamente o mesmo que tenho com a versão de 22.04.2018.
O dispositivo está funcionando, mas o servidor da web não está acessível.

micropet picture micropet em 26 abr. 2018

Vou tentar registrá-lo.
Parece constante.

Mem grátis: | 9792 (9008 - sendContentBlocking)

micropet picture micropet em 26 abr. 2018

Você quer dizer sysheap?

unbenannt

micropet picture micropet em 26 abr. 2018

@ uzi18 você não pode ter ambos,

s0170071 picture s0170071 em 26 abr. 2018

@ TD-er Se você deixar a janela Regras aberta por alguns minutos, todas as regras desaparecerão.

micropet picture micropet em 26 abr. 2018

Isso é com 2.3.0?

TD-er picture TD-er em 26 abr. 2018

Eu tenho 2.4.1

micropet picture micropet em 26 abr. 2018

Oi,
Estou testando 20180426. Funciona, mas é muito lento em comparação com 20180424.
Para mim, o core 2.4.0 estava funcionando perfeitamente bem e estável.
Com a nova versão, o MQTT demorou mais de 1 minuto para se conectar, enquanto a versão anterior demorou a metade do tempo.
Tive sorte com o core 2.4.0? Ou é apenas uma questão de configuração?

giig1967g picture giig1967g em 26 abr. 2018

Acho a versão do @TD-er de ontem com Core 2.4.1 extremamente rápida.

Depois de ligar a tensão, leva apenas alguns segundos para que a interface da web seja alcançada.
As mensagens MQTT chegam imediatamente.

micropet picture micropet em 26 abr. 2018

apenas para os interessados. Estou rastreando CPU, memória e RSSI. Anexado um gráfico de todas as unidades. Você pode ver claramente no uso de memória, quando fiz a atualização para o núcleo 2.4.x. No entanto, a memória parece estar estável (por exemplo, sem vazamento) ...
Os dispositivos 1-11 e 16 estão "em uso" com sensores etc. os outros são simplesmente D1s sem nada conectado.

image

clumsy-stefan picture clumsy-stefan em 26 abr. 2018

Olá @micropet : como posso usar a versão de ontem com o núcleo 2.4.1?

Estou começando a achar que talvez os Wemos sejam mais estáveis ​​que o SONOS?
Eu uso o wemos também

giig1967g picture giig1967g em 26 abr. 2018

Com:
https://github.com/TD-er/ESPEasy/commits/bugfix/wifi_stability
e em plataforma:
[core_2_4_1]
plataforma = [email protected]

micropet picture micropet em 26 abr. 2018

@micropet e @ TD-er: Acabei de compilar o branch de estabilidade de wi-fi com o núcleo 2.4.1.
UAU. Incrivelmente rápido.
O deixará em execução pelos próximos 3 dias e apresentará um relatório. Ele contém regras bastante complexas ...
Por enquanto: 7 segundos para se conectar ao MQTT em comparação com 60 com a versão 2.3.0 20180426.

Vejo algumas reconexões no 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 picture giig1967g em 26 abr. 2018

@ giig1967g Alguma chance de você fazer um arquivo bin para que eu possa baixar? Versão 4meg? Ainda aprendendo o processo de compilação ....

Budman1758 picture Budman1758 em 26 abr. 2018

firmware.zip

micropet picture micropet em 26 abr. 2018
👍1

@ giig1967g, como eu disse - extremamente rápido e também parece estável.

Agora eu tinha uma reconexão em 7 horas.

micropet picture micropet em 26 abr. 2018

@ giig1967g A execução de IP estático ainda apresenta alguns problemas com meu novo código.
Especialmente ao executar com MQTT.
O DHCP parece estar funcionando bem.

Amanhã será um dia muito agitado para mim, já que é "Kingsday" e a família real estará em Groningen. Também fui convidado a estar lá para - talvez - contar ao rei sobre nossos problemas aqui.
Portanto, irei para a cama agora e minha sugestão é não mesclar o código hoje ao branch principal. Amanhã continuaremos o desenvolvimento e faremos o melhor código de conexão wi-fi possível :)

TD-er picture TD-er em 26 abr. 2018

ok, encontrei um problema em 20180426 (2.3.0) e WifistabilityBranch (2.4.1).
Se eu desligar o roteador e ligá-lo novamente, a unidade não se reconectará ao Wifi, apesar de gravar em serial "Wifi # Connected". A unidade está funcionando (serial e regras ok), mas sem conexão WiFi, portanto, nenhuma interface da web.

giig1967g picture giig1967g em 26 abr. 2018

@ TD-he, vamos fazer isso. Saudações ao rei - talvez ele tenha outra ideia. :)
E boa noite.

micropet picture micropet em 26 abr. 2018

@ TD-er: boa sorte com seus problemas da vida real ...

giig1967g picture giig1967g em 26 abr. 2018
👍2

Alguns aqui, se eu desconectar o WIFI por 0,2 segundos:

29113846: ACT: timerSet, 1,60
29115651: MQTT: Conexão perdida
29115652: EVENTO: MQTT # desconectado
29115689: MQTT: Falha ao conectar ao corretor
29115690: EVENTO: WiFi # desconectado
29115706: WIFI: desconectado! Motivo: '(1) Não especificado' Conectado por 8h04m <-------- !!
29116189: MQTT: Falha ao conectar ao corretor
29116939: MQTT: Falha ao conectar ao corretor
29117860: WD: Uptime 485 ConnectFailures 6 FreeMem 16416
29117881: MQTT: Falha ao conectar ao corretor
29117938: MQTT: Falha ao conectar ao corretor
29119189: MQTT: Falha ao conectar ao corretor
29120689: MQTT: Falha ao conectar ao corretor
29120736: DS: Temperatura: 19,94 (28-ff-b8-ea-b4-16-3-ed)
29120738: EVENTO: DS18b20 # Temperatura = 19,94
29122440: MQTT: Falha ao conectar ao corretor
29124440: MQTT: Falha ao conectar ao corretor
29126441: MQTT: Falha ao conectar ao corretor
29128442: MQTT: Falha ao conectar ao corretor

micropet picture micropet em 26 abr. 2018

@ giig1967g
Você pode procurar a função para iniciar / parar o servidor da web e adicionar return; na primeira linha dessa função.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585

Acho que há algum problema em chamar a função 'gotIP' ao usar IP estático.
Esse também é o motivo da instabilidade ao executar MQTT + IP estático.

TD-er picture TD-er em 26 abr. 2018

Mas isso provavelmente é para @ TD-er uma bagatela. :)

micropet picture micropet em 26 abr. 2018

Hm, não estou olhando.
Acho melhor você fazer isso amanhã.
Além disso, trabalho aqui com DHCP.

micropet picture micropet em 26 abr. 2018

Parece-me que a estabilidade com o meu hardware é sempre 'melhor' (não perfeita) com compilações de núcleo 2.3.0

  • tentei 2.4.0 e 2.41 - eles são piores ...

0403 mega normal - parece funcionar e as versões anteriores ..
Qualquer pessoa que ainda esteja com problemas como eu pode tentar 0403 por favor ..
@susisstrolch & @ uzi18 - obrigado por suas respostas. Tenho uma ideia melhor de como posso ver as comunicações agora - o adaptador wirehark & ​​usb wi-fi 2.4g funcionará, tenho bastante reserva
Obrigado

Oxyandy picture Oxyandy em 26 abr. 2018

O meu está funcionando há quase 17 horas agora. Conexão única

Grovkillen picture Grovkillen em 27 abr. 2018

atualização de minhas unidades (nome | tempo de atividade em minutos | último disco. razão | wi-fi conectado em 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

uma reinicialização da unidade 10 (também pode estar relacionada a plug-ins). todas as unidades com controlador DHCP e FHEM, bem como atualizações de status JSON regulares (chamadas via HTTPMOD de fhem).
servidor web em todos eles ainda em execução e muito responsivo. nunca usei static-ip ou setup-page embora.

então, para mim, esta parece ser uma versão bastante estável.

como ficarei praticamente offline nos próximos 4 dias, verei na próxima semana quantos ainda estão vivos 😃

Oh, e saudações ao rei! Espero que ele também goste de IoT 😀

clumsy-stefan picture clumsy-stefan em 27 abr. 2018

@ desajeitado-stefan esta versão? https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability
e qual núcleo?
Você já tentou reiniciar o roteador?

melwinek picture melwinek em 27 abr. 2018

@melwinek git commit: d582cab938f041f622f2d4d8016b3d4bada55580 do branch master esp8266 (então o último commit no branch master do desenvolvimento do núcleo).

clumsy-stefan picture clumsy-stefan em 27 abr. 2018

@ clumsy-stefan core 2.3.0, 2.4.0 ou 2.4.1?

melwinek picture melwinek em 27 abr. 2018

último commit do GIT! (então Issume é o núcleo 2.4.1+)

clumsy-stefan picture clumsy-stefan em 27 abr. 2018

Não consigo encontrar este commit.
O mais recente é: https://github.com/letscontrolit/ESPEasy/commit/d780f1a07fdcd4eec394a0677866c2a9778eb696
Você pode fornecer um link?

melwinek picture melwinek em 27 abr. 2018

@ desajeitado-stefan eu entendo, você escreveu git para o núcleo.
Qual commit do ESPEasy você compila?

melwinek picture melwinek em 27 abr. 2018

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

clumsy-stefan picture clumsy-stefan em 27 abr. 2018

@ TD-er:

@ giig1967g
Você pode procurar a função para iniciar / parar o servidor da web e adicionar um retorno; na primeira linha dessa função.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585

Acho que há algum problema em chamar a função 'gotIP' ao usar IP estático.
Esse também é o motivo da instabilidade ao executar MQTT + IP estático.

Oi, o problema não é o servidor web, é a unidade que parece estar conectada ao Wifi, mas não é. Não é possível fazer ping, não é possível enviar MQTT, etc.

giig1967g picture giig1967g em 27 abr. 2018

O github mais recente funciona perfeitamente aqui no núcleo 2.4.1. Sem problemas de conexão, sem vazamentos de membros

ghost picture ghost em 27 abr. 2018

@mvdbro Você usa um dispositivo esp32 ou esp8266?

weisskopfjens picture weisskopfjens em 27 abr. 2018

Eu uso ESP8266 e ESP32. Ambos funcionam bem.

Nota:
Sempre usando IP estático
Usando apenas plug-ins de que preciso (mantém a memória RAM em um mínimo seguro. Acho que o conjunto padrão tem muitos plug-ins carregados)

ghost picture ghost em 27 abr. 2018
👍1

Excelente! :sorriso:
Eu tento o núcleo 2.4.1 no meu esp8266 também.
Static e dhcp estão funcionando.
O dnsserver e o portal cativo funcionam.
ntp funciona!

weisskopfjens picture weisskopfjens em 27 abr. 2018

@Feuerreiter : você tentou desligar e ligar o roteador para ver se a unidade reconecta?
No meu caso, o log diz que reconectou, mas não o fez.

giig1967g picture giig1967g em 27 abr. 2018

@ giig1967g Eu tentaria mais tarde em casa. Eu fiz o teste no meu carro com meu celular como hotspot. ;-)

weisskopfjens picture weisskopfjens em 27 abr. 2018

@mvdbro

Acho que o conjunto padrão tem muitos plug-ins carregados

Eu concordo. Deve haver alguma pré-seleção nos plug-ins, ou talvez uma melhor verificação em todos eles para não usar mais memória do que o absolutamente necessário quando não usados.
E há muita memória a ganhar quando se olha de perto as grandes estruturas que contêm informações sobre os plug-ins disponíveis.

TD-er picture TD-er em 27 abr. 2018

[PlatformIO] Core atualizado para 2.4.1
1+

Acho que é uma boa decisão.
Não tenho problemas desde ontem à tarde.

micropet picture micropet em 27 abr. 2018

Como postei em outro tópico:
Para quem precisa de um pouco de ajuda na construção, acabei de construir uma versão do patch que escrevi 2 dias atrás, mas agora com o núcleo 2.4.1:
TD-er_wifi_stability_core-2.4.1

TD-er picture TD-er em 27 abr. 2018

A memória permanece bastante constante.
Afunda um pouco nos primeiros 15 minutos.
(Eles não podem ser vistos aqui)
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 picture micropet em 27 abr. 2018

Enquanto isso, 8 dispositivos estão funcionando desde o meio-dia de ontem.
Nenhum deles ficou preso.

Um ficou indisponível por cerca de 15 minutos - de repente, ele estava de volta à rede.
No geral, um resultado agradável.

micropet picture micropet em 27 abr. 2018

Muito bom ouvir.
Esperemos que @Oxyandy também possa compartilhar resultados positivos semelhantes com a última compilação que compartilhei.
Seus nós foram os mais críticos ao usar 2.4.x

TD-er picture TD-er em 27 abr. 2018

@ TD-er Morning, finalmente encontrei este post depois de fazer um catch up
0403 usando 2.4.1 correu bem a noite toda ..
Agora piscando de seu último rar normal 1024 8266
conecta-se na primeira tentativa, atualiza o tempo imediatamente, sem erros de wi-fi (até agora) e permanece conectado (até agora),
o servidor web responde sempre ..
Precisa de um pouco mais de tempo para testar, mas parece bom

Oxyandy picture Oxyandy em 27 abr. 2018

É bom ouvir isso :)

Vou dar uma olhada no problema de NTP relatado por @ giig1967g e, em seguida, enviar esse código para o repositório ESPeasy.
Vamos esperar pelo melhor.

Seria muito bom se pudéssemos deixar o wi-fi como está e continuar com o resto.

TD-er picture TD-er em 27 abr. 2018
❤1 👍1

Espero que você possa ajustar algumas coisas sobre as quais forneço feedback, uma vez que as coisas se mostrem estáveis ​​novamente.
Vou tentar alguns testes específicos com sua fonte wifi_stability_core-2.4.1 do Github
e talvez conserte meus problemas de longa data, se a fonte não mudou radicalmente

Oxyandy picture Oxyandy em 27 abr. 2018

Se você tiver algumas correções, compartilhe-as.

TD-er picture TD-er em 28 abr. 2018

@ giig1967g Eu fiz os testes. Desconexões muito curtas não são problema. AP desligado e imediatamente ligado. Meu mcunode se conecta se o AP estiver de volta. Meu pc já está conectado a outro AP.

weisskopfjens picture weisskopfjens em 28 abr. 2018

Também comecei a testar com D1-Mini e BME280

ESPEasy: commit 2abec2b0bb74018ea76203886f683761796091a2
Unir: 16d3a9f 29f89b6
Autor: Susis Strolch [email protected]
Data: 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

Core: commit 41a64707f149d01ace37c903f448d5e3f1cee5d8
Autor: Marcel Stör [email protected]
Data: Qui, 26 de abril 01:46:17 2018 +0200

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

Custom.h:
`#warning" ** Usando configurações do arquivo custom.h * "

se definido (ESP8266)

// ativa a atualização do Arduino OTA.
// Nota: Isso adiciona cerca de 10kb ao tamanho do firmware e 1kb de RAM extra.
// #define FEATURE_ARDUINO_OTA

// ativa o modo mDNS (adiciona cerca de 6kb de RAM e alguns bytes de IRAM)
// #define FEATURE_MDNS

fim se

undef PLUGIN_BUILD_NORMAL

undef PLUGIN_BUILD_TESTING

undef PLUGIN_BUILD_DEV

definir PLUGIN_BUILD_CUSTOM

undef BUILD_UPLOADER

se definido (BUILD_UPLOADER)

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

senão

// definir nossos próprios plugins
#define USES_P001 // Switch
# 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

fim se

undef BUILD_GIT

definir BUILD_GIT "2abec2b" `

susisstrolch picture susisstrolch em 28 abr. 2018

Parece que há alguns problemas com o NTP:
`
INIT: Versão de inicialização: 2abec2b (ESP82xx Core 41a64707)

80: INIT: inicialização a quente # 2

81: FS: Montagem ...

106: FS: montagem bem-sucedida, usou 7.6053 bytes de 957314

115: CRC: Nenhuma soma de verificação de memória de programa encontrada. Verifique a saída de crc2.py

144: CRC: CRC de configurações de segurança ... OK

227: INIT: RAM livre

227: INIT: I2C

227: INIT: SPI não habilitado

232: INFO: Plug-ins: 8 (ESP82xx Core 41a64707)

233: EVENTO: Sistema # Wake

241: WIFI: Definir WiFi para STA
242: WIFI: Tentativa de conectar SusiconStrolch nº 0
355: EVENTO: Sistema # Inicialização
364: WD: Uptime 0 ConnectFailures 0 FreeMem 31504
3987: BMx280: BME280 detectado
5575: BME280: ponto de orvalho 8,03C
5576: BME280: Endereço: 0x76
5576: BME280: Temperatura: 18,49
5576: BME280: Umidade: 50,75
5576: BME280: Pressão Barométrica: 1010,58
5583: EVENTO: BMx280 # Temperatura = 18,49
5592: EVENTO: BMx280 # Umidade = 50,75
5597: EVENTO: BMx280 # Pressão = 1010,58
5853: Fuso horário atual: DST time start: 2018-03-25 02:00:00 offset: 120 minSTD time start: 2018-10-28 03:00:00 offset: 60 min
5853: EVENTO: Tempo # inicializado
5862: EVENTO: Relógio # Hora = Sáb, 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) Ch: 13 Duração: 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 duração: 17 ms
5913: Fuso horário atual: início do horário de verão: 2036-03-30 02:00:00 deslocamento: 120 min Início do horário STD: 2036-10-26 03:00:00 deslocamento: 60 min
5914: EVENTO: Tempo # definido
5921: EVENTO: WiFi # conectado
5928: Servidor Web: iniciar
5935: EVENTO: Relógio # Hora = Qui, 07: 28
`
5853: Fuso horário atual: início do horário de verão: 25/03/2018 02:00:00
5913: Fuso horário atual: início do horário de verão: 2036-03-30 02:00:00 deslocamento: 120 min. Início do horário de verão:

susisstrolch picture susisstrolch em 28 abr. 2018

Esse é um código de erro -1 conhecido e ainda convertido em bug de tempo.

s0170071 picture s0170071 em 28 abr. 2018

Hmm, ainda me pergunto como a chamada para NTP pode resultar em -1.

@susisstrolch
Que versão é essa? ESPeasy usou o valor BUILD_GIT para determinar o que deve ser corrigido nos arquivos de configuração e talvez em outros arquivos também. É algum tipo de versão interna usada para determinar os patches necessários. (caso existam)
quando você altera esse valor, pode resultar em coisas estranhas.

TD-er picture TD-er em 28 abr. 2018

Acho que está relacionado ao UDP. Não vejo nenhum dos meus outros dispositivos. E vice-versa.

susisstrolch picture susisstrolch em 28 abr. 2018

@susisstrolch Isso é com IP estático ou com DHCP?

TD-er picture TD-er em 28 abr. 2018

O patch @ TD-er baseado em BUILD_GIT é uma má ideia, porque ele muda em forks, branches e commits locais.
Deve haver algum tipo / variável diferente - pode ser BUILD_FEATURE - que controla tal comportamento.

susisstrolch picture susisstrolch em 28 abr. 2018

Como quase nunca reinicializo meu AP, passei despercebido que uma reconexão falha com a fonte github mais recente (20180428). Tentei obter algum status interno para ver o que está acontecendo:

Após a inicialização:
chamada para Wifi.status (): 3 significa WL_CONNECTED
variável wifiStatus: 3 significa ESPEASY_WIFI_SERVICES_INITIALIZED

Após reiniciar o AP
chamada para Wifi.status (): 3 significa WL_CONNECTED
variável wifiStatus: 0 significa ESPEASY_WIFI_DISCONNECTED

isso não muda com o tempo e o ESP nunca se reconecta

Apenas me perguntando por que a chamada Wifi.status () ao core ainda relata um status 3 (WL_CONNECTED)
Isso ocorre porque o wi-fi baseado em eventos interfere no status do núcleo interno?

O comportamento é o mesmo no núcleo 2_3_0 e 2_4_1

ghost picture ghost em 28 abr. 2018

Isso é com DHCP

susisstrolch picture susisstrolch em 28 abr. 2018

E eu esperaria após a reinicialização normal:

chamada para Wifi.status (): 3 significa WL_CONNECTED
variável wifiStatus: 1 significa ESPEASY_WIFI_CONNECTED

em vez de:
chamada para Wifi.status (): 3 significa WL_CONNECTED
variável wifiStatus: 3 significa ESPEASY_WIFI_SERVICES_INITIALIZED

ghost picture ghost em 28 abr. 2018

Hmm, essa é uma boa pergunta @mvdbro
Talvez o status WL_CONNECTED nunca seja atualizado porque não está chamando a função para atualizar esse status.
Apenas de memória, eu diria que a função é chamada na biblioteca principal quando o evento "obteve IP" é manipulado.
Vou examinar essa área do código da biblioteca principal.
Obrigado por notar.

@susisstrolch OK, também tentarei com DHCP aqui.
Minhas unidades de teste podem ver umas às outras por meio da comunicação interna do ESPeasy UDP, mas atualmente estão rodando em IP estático, já que isso deu a maioria dos problemas ultimamente.

TD-er picture TD-er em 28 abr. 2018

@ TD-er espere - irá verificar se é um problema relacionado ao núcleo.

susisstrolch picture susisstrolch em 28 abr. 2018

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

Na verdade, desde que o status interno não seja definido como 'obtido IP', ele não retornará WL_CONNECTED.

Sobre a diferença nos nomes das variáveis ​​entre o enum / define no ESPeasy e a biblioteca principal.
Os estados da biblioteca central não refletem realmente o estado verdadeiro, uma vez que você pode estar conectado e não ter um IP.

TD-er picture TD-er em 28 abr. 2018

Talvez seja melhor manter este tópico para problemas de conexão / reconexão de Wi-Fi apenas para que isso possa ser corrigido em primeiro lugar.

ghost picture ghost em 28 abr. 2018

Acho que estes são os códigos eficazes usados:

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

códigos wifiStatus:
ESPEASY_WIFI_DISCONNECTED 0
ESPEASY_WIFI_CONNECTED 1
ESPEASY_WIFI_GOT_IP 2
ESPEASY_WIFI_SERVICES_INITIALIZED 3

ghost picture ghost em 28 abr. 2018

Eu acho que pode muito bem estar relacionado ao problema de conexão / reconexão wi-fi.
Com o IP estático, simplesmente não há evento para "obtido IP", portanto, seu tratamento atual pode estar incompleto, o que está causando alguns desses problemas.

TD-er picture TD-er em 28 abr. 2018

Então, depois de reiniciar o AP
chamada para Wifi.status (): 3 significa WL_CONNECTED
Isso não está correto.

Se o Wifi.status () não funcionar como esperado, isso seria um bug grave do núcleo do Arduino. Isso não deveria ser relatado no rastreador de problemas do github?

ghost picture ghost em 28 abr. 2018

@susisstrolch Acabei de experimentar o mesmo. Atualizado um dispositivo configurado em bom estado e pronto para uso. Não descobriu outras unidades.

Solução: verifique a entrada da porta UDP. (65500) O meu tinha acabado de desaparecer. Outra reinicialização e estava funcionando.
Devemos realmente escolher a configuração baseada em JSON !!!

s0170071 picture s0170071 em 28 abr. 2018

@mvdbro Acabei de encontrar isso, veja o topo da página 39:
https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf
Portanto, agora vou testar para ver se temos que definir a configuração de IP (novamente) após o processamento do evento de conexão.

TD-er picture TD-er em 28 abr. 2018

Alguém pode testar o código neste PR: https://github.com/letscontrolit/ESPEasy/pull/1328

TD-er picture TD-er em 28 abr. 2018

@ s0170071 - confirmado - configuração da porta UDP alterada.

susisstrolch picture susisstrolch em 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 você pode ver, o DHCP é iniciado mesmo quando definido como IP estático ...

E aqui está o meu 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 picture susisstrolch em 28 abr. 2018

99: CRC: Nenhuma soma de verificação de memória de programa encontrada. Verifique a saída de crc2.py
130: CRC: CRC de configurações de segurança ... OK
211: INIT: RAM livre
211: INIT: I2C
211: INIT: SPI não habilitado
1042: INFO: Plugins: 71 [Normal] [Teste] (ESP82xx Core 2_4_1)
1042: EVENTO: Sistema # Wake
1089: WIFI: Definir WiFi para STA
1091: WIFI: Conectando tentativa SMC # 0
1103: EVENTO: Sistema # Inicialização
1111: ACT: Publicar ESP-201 / IP, 0.0.0.0
1124: ACT: timerSet, 1,60
1152: WD: Uptime 0 ConnectFailures 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) Ch: 1 Duração: 3795 ms
4888: EVENTO: WiFi # ChangedAccesspoint
4910: IP: IP estático: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4911: WIFI: IP estático: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 duração: 25 ms
5009: Fuso Horário Atual: DST time start: 2018-03-25 02:00:00 offset: 120 minSTD time start: 2018-10-28 03:00:00 offset: 60 min
5010: EVENTO: Tempo # inicializado
5027: EVENTO: WiFi # conectado
5044: Servidor Web: iniciar
5127: MQTT: reconexão intencional
5182: MQTT: Conectado ao corretor com ID de cliente: ESPClient_5C: CF: 7F: 0B: 68: 52
5184: Inscrito em: ESP-201 / #
5185: EVENTO: MQTT # Conectado
5846: EVENTO: Relógio # Hora = Sáb, 16: 19

micropet picture micropet em 28 abr. 2018

@susisstrolch É estranho iniciar o DHCP, já que escrevi um patch para ele recentemente.
Talvez algo tenha mudado no 2.4.1?

O que você fez para obter informações extras de depuração?

TD-er picture TD-er em 28 abr. 2018

Eu simplesmente configurei o nível de depuração para „Depurar mais“ ...

susisstrolch picture susisstrolch em 28 abr. 2018

@susisstrolch Você também parece ter outra saída de depuração gerada pela biblioteca principal.
Não vejo isso no meu log da porta serial.

Editar:
Encontrado, Serial.setDebugOutput é chamado de Setup (). Portanto, uma simples reinicialização foi o suficiente :)

TD-er picture TD-er em 28 abr. 2018

Aqui está uma interação de SYSHEAP e Uptime.

sysheap

micropet picture micropet em 28 abr. 2018

Estou curioso para saber como ficará o gráfico do sistema depois de um ou dois dias.

TD-er picture TD-er em 28 abr. 2018

Se ele não falhar, veremos. :)

micropet picture micropet em 28 abr. 2018

Todos os gráficos parecem diferentes: este é o dispositivo com sua última alteração e um IP estático.

esp-201 sysheap

micropet picture micropet em 28 abr. 2018

Qual era a versão do gráfico anterior?

TD-er picture TD-er em 28 abr. 2018

O primeiro gráfico, a versão especial sua da noite passada. Com DHCP

micropet picture micropet em 29 abr. 2018

Interessante.
Vou adicionar algum log do sysheap aos meus nós também.

TD-er picture TD-er em 29 abr. 2018

Eu entro no openHAB. Também é ótimo com Grafana.

micropet picture micropet em 29 abr. 2018

Devo mostrar seus commits atuais? Então meu gráfico se perde no ESP-201.

micropet picture micropet em 29 abr. 2018

Acho que os testes de estabilidade do wi-fi são mais importantes no momento.

TD-er picture TD-er em 29 abr. 2018

Ok, vou fazer.

micropet picture micropet em 29 abr. 2018

OK, está online.

INIT: Versão de inicialização: (ESP82xx Core 2_4_1)
92: INIT: Inicialização a quente # 2
94: FS: Montagem ...
118: FS: montagem bem-sucedida, usou 76.806 bytes de 957314
131: CRC: Nenhuma soma de verificação de memória de programa encontrada. Verifique a saída de crc2.py
162: CRC: CRC de configurações de segurança ... OK
243: INIT: RAM livre
243: INIT: I2C
243: INIT: SPI não habilitado
1073: INFO: Plugins: 71 [Normal] [Teste] (ESP82xx Core 2_4_1)
1073: EVENTO: Sistema # Wake
1120: WIFI: Definir WiFi para STA
1152: WIFI: Tentativa de conexão SMC nº 0
1153: IP: IP estático: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
1155: WIFI: O status da estação SDK difere do status do Arduino. Status do SDK: 1 status do Arduino: 6
1172: EVENTO: Sistema # Inicialização
1178: ACT: NeoPixelAll, 0,0,0,0
1189: ACT: Publicar ESP-201 / IP, 192.168.0.201
1201: ACT: timerSet, 1,60
1226: WD: Uptime 0 ConnectFailures 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) Ch: 1 Duração: 3798 ms
4953: EVENTO: WiFi # ChangedAccesspoint
4974: IP: IP estático: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4975: WIFI: O status da estação SDK difere do status do Arduino. Status do SDK: 5 status do Arduino: 3
4980: WIFI: IP estático: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 duração: 24 ms
5102: Fuso horário atual: DST time start: 2018-03-25 02:00:00 offset: 120 minSTD time start: 2018-10-28 03:00:00 offset: 60 min
5103: EVENTO: Tempo # inicializado
5123: EVENTO: WiFi # conectado
5140: Servidor Web: iniciar
5141: WIFI: O status da estação SDK difere do status do Arduino. Status do SDK: 5 status do Arduino: 3
5223: MQTT: reconexão intencional
5261: MQTT: Conectado ao corretor com ID do cliente: ESPClient_5C: CF: 7F: 0B: 68: 52
5264: Assinado em: ESP-201 / #
5265: EVENTO: MQTT # Conectado
5912: EVENTO: Relógio # Hora = Dom, 00: 14
31226: WD: Uptime 1 ConnectFailures 0 FreeMem 15968

micropet picture micropet em 29 abr. 2018

Também estendi as informações na página sysinfo.
Adicionado um contador de reconexão e configuração estática / DHCP usada (e a versão do SDK)

Também inclui uma verificação de reconexão forçada, que reconectará quando não for conectado por um tempo.

TD-er picture TD-er em 29 abr. 2018

Devo interromper o WIFI por 0,2 segundos?

micropet picture micropet em 29 abr. 2018

Por favor, tente travá-lo :)

TD-er picture TD-er em 29 abr. 2018

OK

micropet picture micropet em 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, 00h18: 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! Motivo: '(1) Não especificado' Conectado por 4 m 10 s
255560: WIFI: O status da estação SDK difere do status do Arduino. Status do SDK: 5 status do Arduino: 3
255571: MQTT: Conexão perdida
255572: EVENTO: MQTT # desconectado
255610: MQTT: Falha ao conectar ao corretor
256110: MQTT: Falha ao conectar ao corretor
256860: MQTT: Falha ao conectar ao corretor
257860: MQTT: Falha ao conectar ao corretor
259110: MQTT: Falha ao conectar ao corretor
260610: MQTT: Falha ao conectar ao corretor
262360: MQTT: Falha ao conectar ao corretor
264360: MQTT: Falha ao conectar ao corretor
266360: MQTT: Falha ao conectar ao corretor
268360: MQTT: Falha ao conectar ao corretor
270360: MQTT: Falha ao conectar ao corretor
271226: WD: Uptime 5 ConnectFailures 22 FreeMem 17224
271247: MQTT: Falha ao conectar ao corretor
272360: MQTT: Falha ao conectar ao corretor
274360: MQTT: Falha ao conectar ao corretor
276360: MQTT: Falha ao conectar ao corretor
278360: MQTT: Falha ao conectar ao corretor
280360: MQTT: Falha ao conectar ao corretor
282360: MQTT: Falha ao conectar ao corretor
284360: MQTT: Falha ao conectar ao corretor
286291: EVENTO: Relógio # Hora = Dom, 00: 19
286359: MQTT: Falha ao conectar ao corretor
288360: MQTT: Falha ao conectar ao corretor
290360: MQTT: Falha ao conectar ao corretor

micropet picture micropet em 29 abr. 2018

Só para esta verificação, você poderia deixá-la nesse estado por 4 minutos?
Vou reduzir o intervalo do ticker para esta verificação (atualmente é de 240 segundos)

TD-er picture TD-er em 29 abr. 2018

OK, eu quero.

micropet picture micropet em 29 abr. 2018

240 segundos são muito longos

micropet picture micropet em 29 abr. 2018

Sim, eu sei, vou mudar isso.
Acabei de tirar a ideia desta edição: https://github.com/esp8266/Arduino/issues/4445

TD-er picture TD-er em 29 abr. 2018

nenhuma coisa....

432148: MQTT: Falha ao conectar ao corretor
434148: MQTT: Falha ao conectar ao corretor
436148: MQTT: Falha ao conectar ao corretor
438147: MQTT: Falha ao conectar ao corretor
440148: MQTT: Falha ao conectar ao corretor
442147: MQTT: Falha ao conectar ao corretor
444148: MQTT: Falha ao conectar ao corretor
446148: MQTT: Falha ao conectar ao corretor
448148: MQTT: Falha ao conectar ao corretor
450147: MQTT: Falha ao conectar ao corretor
451222: WD: Uptime 8 ConnectFailures 446 FreeMem 17384
451243: MQTT: Falha ao conectar ao corretor
452148: MQTT: Falha ao conectar ao corretor
453907: EVENTO: Relógio # Hora = Dom, 00: 29
454148: MQTT: Falha ao conectar ao corretor
456148: MQTT: Falha ao conectar ao corretor
458148: MQTT: Falha ao conectar ao corretor

micropet picture micropet em 29 abr. 2018

Eu vou dormir, até amanhã.

micropet picture micropet em 29 abr. 2018

acabei de encontrar outro problema, possivelmente relacionado ao UDP:
em uma nova unidade de redefinição de fábrica simples, use os comandos seriais
mulher
wifissid
Salve 

reinicie, vá para as configurações avançadas e verifique o ssdp. Reinício.
Ele entra em um loop de inicialização e:

 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 picture s0170071 em 29 abr. 2018

bom Dia a todos.
Para mim, a reconexão ainda não funciona.

INIT: Versão de inicialização: (ESP82xx Core 2_4_1)
92: INIT: Inicialização a quente # 8
94: FS: Montagem ...
118: FS: montagem bem-sucedida, usou 76.806 bytes de 957314
131: CRC: Nenhuma soma de verificação de memória de programa encontrada. Verifique a saída de crc2.py
162: CRC: CRC de configurações de segurança ... OK
243: INIT: RAM livre
243: INIT: I2C
243: INIT: SPI não habilitado
1073: INFO: Plugins: 71 [Normal] [Teste] (ESP82xx Core 2_4_1)
1074: EVENTO: Sistema # Wake
1121: WIFI: Definir WiFi para STA
1153: WIFI: Tentativa de conexão SMC nº 0
1154: IP: IP estático: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
1155: WIFI: O status da estação SDK difere do status do Arduino. Status do SDK: 1 status do Arduino: 6
1173: EVENTO: Sistema # Inicialização
1179: ACT: NeoPixelAll, 0,0,0,0
1190: ACT: Publicar ESP-201 / IP, 192.168.0.201
1201: ACT: timerSet, 1,60
1226: WD: Uptime 0 ConnectFailures 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) Ch: 1 Duração: 3770 ms
4926: EVENTO: WiFi # ChangedAccesspoint
4947: IP: IP estático: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4947: WIFI: O status da estação SDK difere do status do Arduino. Status do SDK: 5 status do Arduino: 3
4953: WIFI: IP estático: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 duração: 23 ms
5066: Fuso horário atual: DST time start: 2018-03-25 02:00:00 offset: 120 minSTD time start: 2018-10-28 03:00:00 offset: 60 min
5066: EVENTO: Tempo # inicializado
5087: EVENTO: WiFi # conectado
5104: Servidor Web: iniciar
5104: WIFI: O status da estação SDK difere do status do Arduino. Status do SDK: 5 status do Arduino: 3
5186: MQTT: reconexão intencional
5222: MQTT: Conectado ao corretor com ID de cliente: ESPClient_5C: CF: 7F: 0B: 68: 52
5225: Inscrito em: ESP-201 / #
5226: EVENTO: MQTT # Conectado
5906: EVENTO: Relógio # Hora = Dom, 10: 01
31227: WD: Uptime 1 ConnectFailures 0 FreeMem 16336
47905: EVENTO: Relógio # Hora = Dom, 10: 02
61229: WD: Uptime 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: Regras # Timer = 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 / Horário, 10:02:14
62030: ACT: Publicar ESP-201 / Uptime, 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ão: '(1) Não especificado' Conectado por 1 m 2 s
67310: WIFI: O status da estação SDK difere do status do Arduino. Status do SDK: 5 status do Arduino: 3
67316: MQTT: Conexão perdida
67317: EVENTO: MQTT # desconectado
67357: MQTT: Falha ao conectar ao corretor
67856: MQTT: Falha ao conectar ao corretor
68606: MQTT: Falha ao conectar ao corretor
69607: MQTT: Falha ao conectar ao corretor
70857: MQTT: Falha ao conectar ao corretor
72357: MQTT: Falha ao conectar ao corretor
74107: MQTT: Falha ao conectar ao corretor
76106: MQTT: Falha ao conectar ao corretor
78107: MQTT: Falha ao conectar ao corretor
80107: MQTT: Falha ao conectar ao corretor
82106: MQTT: Falha ao conectar ao corretor
84106: MQTT: Falha ao conectar ao corretor
86107: MQTT: Falha ao conectar ao corretor
88106: MQTT: Falha ao conectar ao corretor
90107: MQTT: Falha ao conectar ao corretor
91228: WD: Uptime 2 ConnectFailures 30 FreeMem 17368
91250: MQTT: Falha ao conectar ao corretor
92107: MQTT: Falha ao conectar ao corretor
94107: MQTT: Falha ao conectar ao corretor
96106: MQTT: Falha ao conectar ao corretor
98107: MQTT: Falha ao conectar ao corretor
100107: MQTT: Falha ao conectar ao corretor
102107: MQTT: Falha ao conectar ao corretor
104106: MQTT: Falha ao conectar ao corretor
106107: MQTT: Falha ao conectar ao corretor
107905: EVENTO: Relógio # Hora = Dom, 10: 03
108107: MQTT: Falha ao conectar ao corretor
110107: MQTT: Falha ao conectar ao corretor
112107: MQTT: Falha ao conectar ao corretor
114107: MQTT: Falha ao conectar ao corretor
116107: MQTT: Falha ao conectar ao corretor
118107: MQTT: Falha ao conectar ao corretor
120107: MQTT: Falha ao conectar ao corretor
121228: WD: Uptime 2 ConnectFailures 62 FreeMem 17368
121249: MQTT: Falha ao conectar ao corretor
121926: DS: Temperatura: 19,75 (28-ff-b8-ea-b4-16-3-ed)
121927: EVENTO: DS18b20 # Temperatura = 19,75
122107: MQTT: Falha ao conectar ao corretor
122905: EVENTO: Regras # Timer = 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 / Horário, 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: Falha ao conectar ao corretor
126106: MQTT: Falha ao conectar ao corretor
128107: MQTT: Falha ao conectar ao corretor
130107: MQTT: Falha ao conectar ao corretor
132107: MQTT: Falha ao conectar ao corretor
134107: MQTT: Falha ao conectar ao corretor
136107: MQTT: Falha ao conectar ao corretor
138107: MQTT: Falha ao conectar ao corretor
140107: MQTT: Falha ao conectar ao corretor
142107: MQTT: Falha ao conectar ao corretor
144107: MQTT: Falha ao conectar ao corretor
146107: MQTT: Falha ao conectar ao corretor
148107: MQTT: Falha ao conectar ao corretor
150107: MQTT: Falha ao conectar ao corretor
151228: WD: Uptime 3 ConnectFailures 94 FreeMem 17368
151249: MQTT: Falha ao conectar ao corretor
152107: MQTT: Falha ao conectar ao corretor
154107: MQTT: Falha ao conectar ao corretor
156107: MQTT: Falha ao conectar ao corretor
158107: MQTT: Falha ao conectar ao corretor
160107: MQTT: Falha ao conectar ao corretor
162107: MQTT: Falha ao conectar ao corretor
164107: MQTT: Falha ao conectar ao corretor
166107: MQTT: Falha ao conectar ao corretor
167905: EVENTO: Relógio # Hora = Dom, 10: 04
168107: MQTT: Falha ao conectar ao corretor
170107: MQTT: Falha ao conectar ao corretor
172107: MQTT: Falha ao conectar ao corretor
174106: MQTT: Falha ao conectar ao corretor
176106: MQTT: Falha ao conectar ao corretor
178107: MQTT: Falha ao conectar ao corretor
180107: MQTT: Falha ao conectar ao corretor
181228: WD: Uptime 3 ConnectFailures 126 FreeMem 17368
181250: MQTT: Falha ao conectar ao corretor
181926: DS: Temperatura: 19,75 (28-ff-b8-ea-b4-16-3-ed)
181927: EVENTO: DS18b20 # Temperatura = 19,75
182107: MQTT: Falha ao conectar ao corretor
183905: EVENTO: Regras # Timer = 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 / Horário, 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: Falha ao conectar ao corretor
186106: MQTT: Falha ao conectar ao corretor
188107: MQTT: Falha ao conectar ao corretor
190106: MQTT: Falha ao conectar ao corretor
192107: MQTT: Falha ao conectar ao corretor
194106: MQTT: Falha ao conectar ao corretor
196106: MQTT: Falha ao conectar ao corretor
198106: MQTT: Falha ao conectar ao corretor
200106: MQTT: Falha ao conectar ao corretor
202106: MQTT: Falha ao conectar ao corretor
204106: MQTT: Falha ao conectar ao corretor
206106: MQTT: Falha ao conectar ao corretor
208106: MQTT: Falha ao conectar ao corretor
210106: MQTT: Falha ao conectar ao corretor
211228: WD: Uptime 4 ConnectFailures 158 FreeMem 17368
211249: MQTT: Falha ao conectar ao corretor
212106: MQTT: Falha ao conectar ao corretor
214106: MQTT: Falha ao conectar ao corretor
216106: MQTT: Falha ao conectar ao corretor
218106: MQTT: Falha ao conectar ao corretor
220106: MQTT: Falha ao conectar ao corretor
222106: MQTT: Falha ao conectar ao corretor
224106: MQTT: Falha ao conectar ao corretor
226106: MQTT: Falha ao conectar ao corretor
227905: EVENTO: Relógio # Hora = Dom, 10: 05
228107: MQTT: Falha ao conectar ao corretor
230107: MQTT: Falha ao conectar ao corretor
232107: MQTT: Falha ao conectar ao corretor
234107: MQTT: Falha ao conectar ao corretor
236106: MQTT: Falha ao conectar ao corretor
238106: MQTT: Falha ao conectar ao corretor
240106: MQTT: Falha ao conectar ao corretor
241228: WD: Uptime 4 ConnectFailures 190 FreeMem 17368
241249: MQTT: Falha ao conectar ao corretor
241925: DS: Temperatura: 19,75 (28-ff-b8-ea-b4-16-3-ed)
241927: EVENTO: DS18b20 # Temperatura = 19,75
242107: MQTT: Falha ao conectar ao corretor
244106: MQTT: Falha ao conectar ao corretor
244908: EVENTO: Regras # Timer = 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: Falha ao conectar ao corretor
248106: MQTT: Falha ao conectar ao corretor
250106: MQTT: Falha ao conectar ao corretor
252106: MQTT: Falha ao conectar ao corretor
254106: MQTT: Falha ao conectar ao corretor
256106: MQTT: Falha ao conectar ao corretor
258106: MQTT: Falha ao conectar ao corretor
260106: MQTT: Falha ao conectar ao corretor
262106: MQTT: Falha ao conectar ao corretor
264106: MQTT: Falha ao conectar ao corretor
266107: MQTT: Falha ao conectar ao corretor

micropet picture micropet em 29 abr. 2018

ESP32 - últimas alterações (28-04-2018) MQTT parar trabalho, NTP parar trabalho
(I.P. estático)

flexiti picture flexiti em 29 abr. 2018

@flexiti
O MQTT perde a conexão a cada segundo se você não assinar e apenas tentar 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

Tente inserir algo na linha de assinatura, mesmo que não o use. Funcionou para mim.

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 picture s0170071 em 29 abr. 2018

@ TD-er
este tópico está ficando um pouco sobrecarregado e parece que há vários problemas de estabilidade / wi-fi. Eu sugiro mover todos os problemas para um problema separado do github e marcá-los com uma palavra-chave, por exemplo
[WIFICORE] ssdp
[WIFICORE] MQTT subscription needed
[WIFICORE] Unit not found - port setting vanished
[WIFICORE] ticker interval

s0170071 picture s0170071 em 29 abr. 2018

Só para relatar, acabei de atualizar de mega-20180428 para mega-20180429.

No mega-20180428, o wi-fi estava estável no geral, mas não se reconectava após uma desconexão.
no mega-20180429 o wi-fi está muito instável e não consigo pingar sem obter muitos timeouts de leitura.

Estou usando um sonoff básico, compilando os lançamentos com #define PLUGIN_SET_SONOFF_BASIC para tornar a caixa pequena o suficiente para OTA.
Não tenho certeza se isso ajuda, voltando para mega-20180428 entretanto.

louis-lau picture louis-lau em 29 abr. 2018

@ louis-lau Você poderia testar novamente com o commit + merge mais recente que acabei de fazer?

TD-er picture TD-er em 29 abr. 2018

Este é o último commit
screenshot

louis-lau picture louis-lau em 29 abr. 2018

@ louis-lau E o log do próprio nó?
Se ele tentar se reconectar a um broker MQTT, a resposta será mais lenta e há atualmente um manipulador de reconexão em segundo plano para reconectar quando houver muitas falhas de reconexão MQTT.
Ah, e às vezes, depois de uma tentativa de flash, é melhor fazer uma redefinição do nó (não redefinir as configurações, como pressionar o botão de redefinição). Às vezes, sobra de configuração ainda presente no nó após o flashing, o que pode levar a resultados estranhos.

TD-er picture TD-er em 29 abr. 2018

@ louis-lau a sonoff basic?
eu também amo 0429, 0428 foi terrível
Posso saber mais sobre suas configurações 'gerais', por favor?
E como auto-compilado, é compilado com 2.4.1 Core?
Acabei de testar 0429 flash fresco em um nó em branco e funciona perfeitamente.
Minha tentativa anterior com 0429 foi uma atualização para um nó de conjunto estático pré-configurado. perfeito também
Minhas placas são datadas de 5-5-2017

Oxyandy picture Oxyandy em 29 abr. 2018

@Oxyandy
2.4.2 core ????

TD-er picture TD-er em 29 abr. 2018

Isso é tudo que eu tenho 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 , vou tentar uma redefinição de fábrica. Não fiz nenhuma alteração antes de compilar, exceto a sinalização do plug-in básico sonoff e as configurações de rede em Custom.h.

louis-lau picture louis-lau em 29 abr. 2018

Você está certo, funciona bem com as configurações de fábrica 😄.

Vou tentar restaurar, ver se quebra novamente.

louis-lau picture louis-lau em 29 abr. 2018

Parece apenas uma reinicialização?

No web log você obterá um pouco mais de linhas, já que este possui um buffer de 15 linhas.
Também na página sysinfo você pode obter mais informações.

Os logs gravados no servidor syslog podem não estar completos, pois este não recebe dados quando o wi-fi é desconectado.

TD-er picture TD-er em 29 abr. 2018

Tudo bem, começou a acontecer de novo quando habilitei o controlador mqtt.
E parei quando o desativei.

Vou tentar obter um registro melhor, é um pouco difícil quando você não consegue se conectar a ele na metade do tempo.
Qual nível de log? depurar?

louis-lau picture louis-lau em 29 abr. 2018

As conexões MQTT também são mostradas no nível de informações.
Informações mostram erro + informações.
Dessa forma, você não está enchendo o buffer de log do weblog muito rápido para exibir.

TD-er picture TD-er em 29 abr. 2018

Ok, quando eu paro o servidor mqtt também funciona normalmente, somente quando o servidor está rodando a conexão atinge o tempo limite.

Isso é tudo que consegui obter do registro:
screenshot

louis-lau picture louis-lau em 29 abr. 2018

Que tipo de controlador MQTT é esse? Domoticz? OpenHAB?

Ou você está tentando fazer importMQTT?

Também existe um botão de cópia na página da web que mostra o log.
Essa página é atualizada a cada N segundos, o que permite colar o texto entre as atualizações em um editor de texto.
Não é perfeito, eu sei, mas é melhor do que nada :)

Editar:
Por favor, também dê uma olhada nas regras, se estas estiverem completas.
Ainda há um problema ao salvar as regras. Este salvamento pode não ser o conjunto de regras completo inserido.

TD-er picture TD-er em 29 abr. 2018

Usando o githib mais recente (07bfec42347d13ad49dda907654a36bf747df3bc), Wifi se conecta sem problemas em todos os meus nós. Agora também reconecta corretamente após a reinicialização do AP. Usando o núcleo 2.4.1.

ghost picture ghost em 29 abr. 2018

Hehe, uma vez que está realmente carregado, tenho muito pouco tempo, então eu apenas tirei uma captura de tela. Estou usando o controlador openhab mqtt, o servidor é mosquitto.

EDIT: não usando regras agora. Só para ter certeza de que esse não é o problema.

louis-lau picture louis-lau em 29 abr. 2018

Mesmo aqui. Tente se inscrever em qualquer tópico. Isso resolveu meu problema.

-------- Ursprüngliche Nachricht --------
Von: Louis Laureys [email protected]
Gesendet: 29. abril 2018 16:23:54 MESZ
An: letscontrolit / ESPEasy [email protected]
CC: s0170071 [email protected] , Menção mençã[email protected]
Betreff: Re: [letscontrolit / ESPEasy] Problemas de wi-fi -nunca terminar a história- voltar para wi-fi não baseado em eventos? (# 1302)

Hehe, uma vez que está realmente carregado, tenho muito pouco tempo, então eu apenas tirei uma captura de tela. Estou usando o controlador openhab mqtt, o servidor é mosquitto.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/letscontrolit/ESPEasy/issues/1302#issuecomment -385255207

s0170071 picture s0170071 em 29 abr. 2018

@ s0170071 Onde esta assinatura deve ser feita?
Se isso estiver em algum tipo de configuração padrão, talvez devêssemos adicioná-lo.

O tempo entre as reconexões MQTT é de cerca de 15 a 16 segundos? Então pode ser que o Mosquito está expulsando você e eu sei onde consertar isso.

TD-er picture TD-er em 29 abr. 2018

Nas configurações do controlador openhab. Existe o campo de inscrição.

s0170071 picture s0170071 em 29 abr. 2018

Usando o githib mais recente (07bfec4), MQTT também funciona sem problemas aqui usando o controlador openhab e conectando-se ao Mosquitto. Usando o núcleo 2.4.1.

ghost picture ghost em 29 abr. 2018

@ td-er veja alguns posts acima.

s0170071 picture s0170071 em 29 abr. 2018

Já estou inscrito em / sonoff_lavalamp / # como você pode ver nos logs.

Eu percebi quando me inscrevi em # (então, todos os tópicos). O wi-fi está estável, mas isso torna o mqtt inutilizável;)

O Mosquitto não deveria expulsar o usuário, o usuário que estou usando tem permissão para todos os tópicos.

louis-lau picture louis-lau em 29 abr. 2018

Este é o mosquito a registrar:

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 está se reconectando e o mosquitto está fechando a conexão antiga.

louis-lau picture louis-lau em 29 abr. 2018

Estive pesquisando a fonte do PubSubClient.
Parece que deve haver atividade de entrada e saída dentro do período de tempo limite.
Se um deles falhar, o PubSubClient se desconectará e, portanto, o ESPeasy se reconectará.

Vou tentar adicionar algum tipo de ping automático. Já existe algum, mas pode ser que a verificação seja feita antes do retorno do ping.

TD-er picture TD-er em 29 abr. 2018

@ louis-lau Você consegue encontrar a configuração de tempo usado para manter vivo em seu Mosquito?

Parece que a configuração de tempo limite MQTT que usamos é de 15 segundos.
É definido como: #define MQTT_KEEPALIVE 15

Veja também https://github.com/knolleary/pubsubclient/issues/239

TD-er picture TD-er em 29 abr. 2018

Uau, você conseguiu @ TD-er !!!!!

467279: EVENTO: Relógio # Hora = Dom, 17: 24
467588: WD: Uptime 8 ConnectFailures 0 FreeMem 16304
481935: MQTT: Conexão perdida
481935: EVENTO: MQTT # desconectado
481953: EVENTO: WiFi # desconectado
481969: WIFI: desconectado! Motivo: '(1) Não especificado' Conectado por 7 m 40 s
482278: WIFI: Conectando tentativa SMC # 0
482278: IP: IP estático: 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) Falha de autenticação' Conectado por 1018 ms
484291: WIFI: Tentativa # 1 de conexão SMC
484292: IP: IP estático: 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) Ch: 1 Duração: 3780 ms
488074: IP: IP estático: 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
488078: WIFI: IP estático: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 duração: 6 ms
488099: EVENTO: WiFi # conectado
488245: MQTT: Conectado ao corretor com ID do cliente: ESPClient_5C: CF: 7F: 0B: 68: 52
488247: Inscrito em: ESP-201 / #
488248: EVENTO: MQTT # Conectado
489111: EVENTO: Tempo # Definir

micropet picture micropet em 29 abr. 2018

@ TD-er Tem certeza de que o pubsubclient está tendo problemas? Minha unidade não recebe nada, apenas envia valor analógico a cada 30 segundos. Sem problemas de conexão MQTT. Se houvesse um problema com a biblioteca, não teríamos muito mais usuários reclamando?

ghost picture ghost em 29 abr. 2018

Talvez seja uma condição de corrida ...

s0170071 picture s0170071 em 29 abr. 2018

O broker MQTT deve considerar um cliente como desconectado em 1,5x o tempo limite.
Pubsubclient envia um ping quando a última atividade foi há mais de 15 segundos.
Portanto, se o tempo limite padrão do Mosquito (10s) estiver sendo usado, o tempo está se tornando bastante crítico.

Na minha configuração, vejo muito tráfego MQTT de todos os nós aqui conversando no mesmo canal (domoticz).
Portanto, o tempo limite nunca é um problema aqui.
Mas se houver apenas um nó, haverá muito menos tráfego e com o tempo limite padrão do ESPeasy definido em exatamente 1,5x o tempo limite padrão do Mosquito, pode ser um pouco crítico.

TD-er picture TD-er em 29 abr. 2018

Então ele pode tentar enviar um valor analógico fictício a cada 5 segundos para verificar se o problema desaparece ...

ghost picture ghost em 29 abr. 2018

Ou use meu último commit;)

TD-er picture TD-er em 29 abr. 2018

Minhas reconexões foram muito rápidas, a cada segundo ou mais

s0170071 picture s0170071 em 29 abr. 2018

O desenvolvedor MQTT não parece gostar disso:
Não estou inclinado a alterar o valor padrão. Foram 15 segundos por 7 anos ou mais. Se for o caso, vamos tornar mais fácil personalizar e não depender da edição do arquivo de cabeçalho.

ghost picture ghost em 29 abr. 2018

A definição é envolvida com #ifdef
Portanto, há uma opção para defini-lo em outras partes do código.

Na página do github do PubSubclient, também há um problema sobre como torná-lo configurável.

TD-er picture TD-er em 29 abr. 2018

Outro comentário de seu autor:
No protocolo MQTT, o cliente determina o valor de manutenção de atividade usado em uma conexão. O corretor não tem voz sobre isso.

A única opção de configuração de keepalive no mosquitto é seu keepalive de ponte - onde ele atua como um cliente se conectando a outro corretor - https://mosquitto.org/man/mosquitto-conf-5.html

ghost picture ghost em 29 abr. 2018

Verifiquei minha configuração de mosquito. Não é possível encontrar nenhuma opção de tempo limite para conexões

ghost picture ghost em 29 abr. 2018

Este documento discute o comportamento do tempo limite.

TD-er picture TD-er em 29 abr. 2018

E o documento afirma o mesmo:

O cliente MQTT é responsável por definir o valor correto de keep alive. Por exemplo, ele pode adaptar o intervalo à intensidade do sinal atual.

Então, de onde vem o tempo de Mosquitto de 10 segundos? Está codificado?

ghost picture ghost em 29 abr. 2018

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

keepalive_interval seconds
Defina o número de segundos após o qual a ponte deve enviar um ping se nenhum outro tráfego tiver ocorrido. O padrão é 60. Um valor mínimo de 5 segundos é permitido.

Grovkillen picture Grovkillen em 29 abr. 2018

Essa configuração é apenas para fazer a ponte

ghost picture ghost em 29 abr. 2018

Lembre-se de que isso não foi um problema em 20180428 :)

EDIT: Vou tentar seu último commit quando chegar em casa.

louis-lau picture louis-lau em 29 abr. 2018

Você pode tentar desativar o connectionCheckHandler .

Para ver o que mudou no último dia: https://github.com/letscontrolit/ESPEasy/compare/mega@%7B1day%7D...mega

TD-er picture TD-er em 29 abr. 2018

Acabei de atualizar para https://github.com/letscontrolit/ESPEasy/commit/4e6e31fdae11476a2f3dfce00e01ed77d1858c00 e wi-fi agora está estável. Ele também se reconecta agora quando eu reinicio meu AP! Obrigada 😄

louis-lau picture louis-lau em 29 abr. 2018

(aliás, há alguma maneira de alternar a configuração do LED de status de Wi-Fi usando regras? Por exemplo, eu só gostaria de ativá-lo se mqtt estiver desconectado e usá-lo para o status de relé quando conectado).

louis-lau picture louis-lau em 29 abr. 2018

Não tenho certeza sobre o LED de status. Ele é chamado a partir da função MQTTconnect e de alguns outros locais.
Mas talvez você pudesse adicionar um problema para torná-lo selecionável o que está sendo mostrado por meio daquele LED?

E bom saber que os problemas do MQTT parecem ter sido corrigidos pelo tempo limite reduzido.
Podemos ter que torná-lo selecionável.

TD-er picture TD-er em 29 abr. 2018
👍2

Você poderia aumentar a janela de LOG um pouco mais?
Quer dizer, aumente o número de linhas.

Caso contrário, está indo muito bem agora.

micropet picture micropet em 29 abr. 2018

Eu apenas os reduzi.
Eram 20 linhas, mas com 2.4.0 deveria haver um pouco mais de mem livre, então eu reduzi para 10 linhas para dev / test e 15 para normal.

Analisarei o consumo de memória esta semana e

TD-er picture TD-er em 29 abr. 2018

OK, vou dormir.
Muito obrigado pelo seu trabalho árduo!

micropet picture micropet em 29 abr. 2018

Sobre aquela janela. A meu ver, existem três opções.

  1. Use o máximo de memória RAM disponível para manter as informações até que sejam solicitadas. Pode ser dinâmico, dependendo de quantos plugins estão ativos.
  2. Transmita para o navegador da web.
  3. Compacte-o temporariamente e restaure quando solicitado. Por exemplo, use mais códigos numéricos. É menos legível, é claro.

Eu gosto de 2. Oferece uma exibição da web suave também. Não é tão simples assim.

s0170071 picture s0170071 em 29 abr. 2018

A ideia é obter algum tipo de JavaScript para coletar o log e armazená-lo no navegador.
Existem várias opções para entregar os dados ao navegador, como manter uma conexão aberta ou algumas outras técnicas.
Isso deixa apenas algumas linhas de registro necessárias para serem mantidas na memória.
E esse buffer também pode ser usado para transferir o log para o syslog.

O objeto de cache de log atualmente não é tão eficiente com memória. Muito espaço para melhorias.

TD-er picture TD-er em 29 abr. 2018
👍1

Também me pergunto agora se as diferentes versões de mosquito
rodando em diferentes sistemas operacionais tem um comportamento diferente?
Eu sei que ESPeasy deve ser flexível, mas uma atualização de mosquito resolveria problemas para alguns.

Oxyandy picture Oxyandy em 30 abr. 2018

Só para entender ...
Por que eu sou direto depois de inicializar meu ESP isto:

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

No syslog, vejo duas mensagens IP STATIC e 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 picture DittelHome em 30 abr. 2018

Talvez o termo "reconectar" não seja bem escolhido.
É mais como "(re) conectar" ou "tentativas de conexão"
O contador começa em 0 e a cada tentativa de conexão é um contador ++.

TD-er picture TD-er em 30 abr. 2018

Mudei o contador inicializando-o como '-1'. Portanto, a primeira tentativa de conexão configurará para 0, portanto, o rótulo "Número reconecta" agora faz sentido novamente :)
Não consegui pensar em um nome melhor, então alterei o valor relatado;)

A nomenclatura adequada ainda é a parte mais difícil da programação.

TD-er picture TD-er em 2 mai. 2018

Parece bom !

DittelHome picture DittelHome em 2 mai. 2018

conexão tente x

uzi18 picture uzi18 em 2 mai. 2018

Infelizmente, a última compilação 20180503 (4096 dev) não funciona para mim - a web do ESP não abre, em vez disso, ela para de responder no console serial (após a tentativa de abertura da web). As configurações são redefinidas para os padrões e definem apenas WifiSSID e chave por meio do console serial. PING funciona, sem reinicializações, sem mensagem de erro.

ghtester picture ghtester em 3 mai. 2018
👍1

Você executou uma reinicialização a frio após o flash?
Eu tive algo semelhante logo após piscar.
Um ciclo de energia resolveu então.

TD-er picture TD-er em 3 mai. 2018

Sim, tentei reinicializar a frio várias vezes, ainda é o mesmo. Testado em MSIE e Firefox em Win7. Vou testar o dispositivo em outro local, alguns minutos depois (PC / SO diferente, AP diferente).
Logo após o flash, ele reiniciou e travou.

ghtester picture ghtester em 3 mai. 2018

Eu tentei agora, com a versão normal. Do meu lado, sem problemas. Nenhuma reinicialização de energia foi necessária.

DittelHome picture DittelHome em 3 mai. 2018

É estranho em outro local onde a web ESP do mesmo dispositivo funciona (Win10 + Firefox / MS Edge, AP diferente), mas o console serial parece "somente leitura" ...: - /
Update - tentei outro aplicativo de terminal - o mesmo console serial somente leitura. Em seguida, execute o putty (que é meu aplicativo de terminal padrão) novamente e vi o dispositivo reiniciando assim que conectei o putty à porta COM apropriada. Agora o console serial aceita comandos e a web também está funcionando ... Não entendi nada ...

ghtester picture ghtester em 3 mai. 2018

Talvez tente limpar completamente o flash e programar novamente?
Parece haver uma relação entre a conexão wi-fi e se a porta serial está sendo lida. Eu vi alguém mencionando isso em um tópico. Não tenho certeza se isso foi um problema de PlatformIO ou LWIP.
Tenho lido muito ultimamente;)

TD-er picture TD-er em 3 mai. 2018

Sim, vou tentar isso com alguma próxima construção, esta que desejo testar em outro local novamente para ver se ainda é o mesmo problema (configuração do dispositivo atualizada um pouco nesse meio tempo).
POR FALAR NISSO. quando eu redefini as configurações pela primeira vez (após este build piscar, emitindo o comando Reset do console serial), na verdade NÃO redefiniu as configurações, apesar de dizer "flash de formatação" etc. O dispositivo foi reiniciado e pelo menos as configurações de WiFi ainda estavam lá como eu vi tentativas de conexão ao AP no console serial ... A segunda tentativa de reinicialização do console serial apagou as configurações ...

ghtester picture ghtester em 3 mai. 2018

Sim, a biblioteca central armazena as configurações de wi-fi em uma área fora do SPIFF.
Isso pode afetar as tentativas de conexão wi-fi.

Já li no código (principal) que agora há suporte para até 5 configurações de wi-fi, que você pode selecionar.
Então, talvez eu também use ativamente essa área de armazenamento, para ter certeza de que não entrará em conflito com nossas próprias configurações.
A única coisa que temo é que essas configurações sejam gravadas com muita frequência. Tenho que verificar quando isso está sendo escrito.
Mas pode tornar a conexão wi-fi um pouco mais previsível quando essa área também está sendo levada em consideração com o ESPeasy.

TD-er picture TD-er em 3 mai. 2018
👍1

@Oxyandy Agora irei enviar por push a alteração PlatformIO.ini para usar LWIP2_LOW_MEMORY.
Você poderia testar isso?
E também a questão de saber se você estava usando a tarefa / dispositivo 12?
Acabei de testá-lo em meu nó e quase imediatamente ele se desconectou e se recusou a ficar online novamente.
Isso foi com LWIP 1.4

TD-er picture TD-er em 4 mai. 2018
👍1

E também a questão de saber se você estava usando a tarefa / dispositivo 12?

Nos testes, não apenas o primeiro, um único switch
Sim, existem 15 arquivos alterados no GitHub Desktop puxando agora

Oxyandy picture Oxyandy em 4 mai. 2018

Compilado bem, servidor web ótimo, usando LWIP2_LOW_MEMORY, o teste F5, ótimo ..
nenhum sinal de LmacRxBlk: 1 nos registros
Eu havia apagado todas as configurações do Nó, mas irei 'redefini-lo' e passar pelo processo, relatando quaisquer esquisitices.
Wifi conectado instantaneamente primeiro.

Oxyandy picture Oxyandy em 4 mai. 2018

só tome cuidado com a memória baixa do lwIP2, tive que usar a largura de banda alta do lwIP2, caso contrário, os pacotes grandes ficaram truncados (por exemplo, sensores com vários valores), pelo menos ao usar fhem como um servidor / controlador ...

No momento, estou usando o mega branch com esp core do GIT e lwIP2 de largura de banda alta que funciona bem, exceto que depois de algum tempo algumas das unidades não conseguem mais ler os valores dos sensores e, portanto, não os enviam para o controlador. a unidade em si, bem como a webinterface funcionam perfeitamente ... Eu ainda estou investigando isso, nunca tive isso em commits antes de Mai ..

clumsy-stefan picture clumsy-stefan em 4 mai. 2018

Tentamos largura de banda alta LwIP2 e mensagens de POST bagunçadas.
Por exemplo, regras de salvamento> 1520 bytes foram truncadas.

TD-er picture TD-er em 4 mai. 2018

ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
É um ataque DoS aos servidores de horário?
Depois que eu pisquei fui chamado, tenho páginas e páginas desse loop

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 picture Oxyandy em 4 mai. 2018

Com o núcleo atual (Master, ESP82xx Core 41a64707, NONOS SDK 2.2.1 (cfd48f3)) os problemas de MTU não aparecem mais.
Tendo 10 ESPs (Sonoff, NodeMcu, W1pro) em execução desde 1º de maio sem problemas.

susisstrolch picture susisstrolch em 4 mai. 2018

Para sua informação ... Atualize a versão oficial mais recente, redefina as configurações via serial para os padrões, insira o WiFiSSID e as chaves. Não foi possível conectar ao AP primário, apesar de estar visível (mas um sinal fraco de cerca de -82). Então travou como você pode ver abaixo.
Em outro local, dispositivo conectado ao AP secundário rapidamente sem nenhum problema e até agora está funcionando (mas sem plug-ins configurados, sem regras ativas).
....
....
458745: WIFI: Conectando IOTAP1 tentativa # 57
458749: Modo AP: Cliente desconectado: xx: xx: xx: xx: xx: xx Dispositivos conectados: 0
458810: WIFI: desconectado! Motivo: '(201) Nenhum AP encontrado' Conectado por 64 ms
459360: Modo AP: Cliente conectado: xx: xx: xx: xx: xx: xx Dispositivos conectados: 1
471739: WIFI: O ssid do modo AP será ESP_Easy_0 com o endereço 192.168.4.1
471739: WIFI: Conectando IOTAP2 tentativa # 58

Exceção (29):
epc1 = 0x4000e1c3 epc2 = 0x00000000 epc3 = 0x40000f68 excvaddr = 0x00000018 depc = 0x00000000

ctx: sys
sp: 3ffffc50 end: 3fffffb0 offset: 01a0

pilha >>>
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 3ffeed30
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
<<

data de 8 de janeiro de 2013, primeira causa: 2 , modo de inicialização: (3,7)

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

INIT: versão de inicialização: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
89: INIT: Inicialização a quente # 6
90: FS: Montagem ...
116: FS: montagem bem-sucedida, usou 75.802 bytes de 957314
436: CRC: soma de verificação do programa ... OK
442: CRC: CRC de configurações de segurança ... OK
548: INIT: RAM livre
549: INIT: I2C
549: INIT: SPI não habilitado
565: INFO: Plugins: 72 [Normal] [Teste] [Desenvolvimento] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
566: WIFI: Definir WiFi para STA
599: WIFI: Conectando IOTAP1 tentativa # 0
607: WD: Uptime 0 ConnectFailures 0 FreeMem 20616
3461: WIFI: desconectado! Motivo: '(201) Nenhum AP encontrado' Conectado por 2861 ms
3604: WIFI: Conectando IOTAP1 tentativa # 1
6466: WIFI: desconectado! Motivo: '(201) Nenhum AP encontrado' Conectado por 2862 ms
6604: WIFI: Conectando IOTAP2 tentativa # 2
9467: WIFI: desconectado! Motivo: '(201) Nenhum AP encontrado' Conectado por 2862 ms
9604: WIFI: Conectando IOTAP2 tentativa # 3
12467: WIFI: desconectado! Motivo: '(201) Nenhum AP encontrado' Conectado por 2862 ms
12604: WIFI: Conectando IOTAP1 tentativa # 4
15466: WIFI: desconectado! Motivo: '(201) Nenhum AP encontrado' Conectado por 2862 ms
15604: WIFI: Conectando IOTAP1 tentativa # 5
18466: WIFI: desconectado! Motivo: '(201) Nenhum AP encontrado' Conectado por 2862 ms
18604: WIFI: Definir WiFi para AP + STA
19524: WIFI: O ssid do modo AP será ESP_Easy_0 com o endereço 192.168.4.1
19524: WIFI: Conectando IOTAP2 tentativa # 6
22388: WIFI: desconectado! Motivo: '(201) Nenhum AP encontrado' Conectado por 2863 ms
22603: WIFI: O ssid do modo AP será ESP_Easy_0 com o endereço 192.168.4.1
22603: WIFI: Conectando IOTAP2 tentativa # 7
25463: WIFI: desconectado! Motivo: '(201) Nenhum AP encontrado' Conectado por 2860 ms
25602: WIFI: O ssid do modo AP será ESP_Easy_0 com o endereço 192.168.4.1
25603: WIFI: Conectando IOTAP1 tentativa # 8
28464: WIFI: desconectado! Motivo: '(201) Nenhum AP encontrado' Conectado por 2860 ms
28602: WIFI: O ssid do modo AP será ESP_Easy_0 com o endereço 192.168.4.1
28603: WIFI: Conectando IOTAP1 tentativa # 9
30606: WD: Uptime 1 ConnectFailures 0 FreeMem 18176
...
...

ghtester picture ghtester em 4 mai. 2018

Também ontem vi o erro "Nenhum AP encontrado".
Parece estar relacionado a algumas configurações incorretas ou corrompidas. Não apenas as configurações que armazenamos, mas talvez também as configurações armazenadas em outra parte do flash, pela biblioteca central.

As atualizações do

@susisstrolch Você poderia testar a gravação de um arquivo de regras contendo> 1800 bytes?
A versão de largura de banda alta LWIP2 estava corrompendo as solicitações HTTP POST quando elas excediam um MTU de tamanho.

TD-er picture TD-er em 4 mai. 2018

Oi Gijs,
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Se você viu o log, é um padrão, sempre conecta, MQTT conecta, atualiza o tempo

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

a cada 10 a 12 segundos, em loop assim por horas, opa

Oxyandy picture Oxyandy em 4 mai. 2018

Tamanho da regra do meu dispositivo pondctrl: Tamanho atual: 1859 caracteres (máx. 2048)
MTU: 534 (low mem lwip 2.x)
Sem problemas - alterado várias vezes esta semana.

susisstrolch picture susisstrolch em 4 mai. 2018

No momento, estamos usando LwIP 2.x com pouca memória, porque a versão de largura de banda alta apresentava esses problemas.
@Oxyandy , examinarei o código referente à atualização de tempo e, é claro, ao loop de reconexão.
Este assunto está se tornando cada vez mais no assunto :(

TD-er picture TD-er em 4 mai. 2018

Não entendi, o que compilei homebrew (esta manhã) de acordo com sua solicitação funcionou muito bem.
então, quando o lançamento oficial estava disponível, achei melhor usá-lo, fiquei chocado com a diferença.
Agora, em relação à sua última resposta .. atualização de horário está bem ..
o lançamento oficial de hoje conecta-se ao wi-fi sem problemas, conecta-se MQTT, obtém o tempo e, em seguida, interrompe a conexão com "(200) Tempo limite de beacon" e faz um loop a cada 11 segundos
Conectar - wi-fi, MQTT, hora, desconectar, repetir
Então não olhe para "atualização de horário", se ficasse conectado estaria tudo bem ...

Oxyandy picture Oxyandy em 4 mai. 2018

Isso é estranho. Há algo muito estranho no processo de construção do PlatformIO.
Eu também percebi algumas vezes que construí-lo pela segunda vez realmente faz a diferença.
É como se houvesse algo errado no nível do vinculador no PlatformIO.
É muito estranho o que está acontecendo aqui.

TD-er picture TD-er em 4 mai. 2018

provavelmente está nos sinalizadores do compilador ou do vinculador. A otimização pode ser uma droga.
O Arduino IDE tem este arquivo de configuração (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 picture s0170071 em 4 mai. 2018
👍1

Para evitar problemas com o platformIO, excluí a pasta .pioenvs e executei 'Limpar' mesmo assim
Desde a compilação desta manhã - 2 arquivos foram alterados
ESPEasy-Globals.h & Misc.ino (corrige a corrupção das configurações de tarefa)

Oxyandy picture Oxyandy em 4 mai. 2018

Começando a fazer isso: minha estrutura de pastas atual é GitHub / ESpeasy
Eu copio a pasta ESpeasy e a renomeio para incluir a data antes de fazer uma busca, me ajudará a comparar as alterações localmente.

Oxyandy picture Oxyandy em 4 mai. 2018

O FritzBox fez uma atualização automática do firmware. Todos os ESPs falharam no AP de malha alternativo sem problemas.

susisstrolch picture susisstrolch em 4 mai. 2018

@ TD-er você disse "Você tem esse tempo limite de Beacon com 0504 em qualquer nó, ou apenas alguns?"
Ok, para ser justo, vou pegar um novo módulo e flash que e no futuro flash 2 nós a cada novo firmware.
Eu tenho tempo de sobra, pois são apenas 4 da tarde na sua parte do mundo

Oxyandy picture Oxyandy em 4 mai. 2018

Ok, um nó totalmente novo, apagado.
Atualizado com ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
O log abaixo tem comportamento idêntico ao do outro nó.
Você pode ver o padrão no log?

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 picture Oxyandy em 4 mai. 2018

Ah, acho que é hora de configurar um ponto de acesso especial executando o wirehark

Oxyandy picture Oxyandy em 4 mai. 2018

Usando o GitHub Desktop, busquei a fonte 'ao vivo' mais recente, que inclui apenas 2 arquivos alterados de https://github.com/letscontrolit/ESPEasy/commit/92680c5542b76a15db16af198a3a07ed17618c4e desde minha compilação de trabalho desta manhã, fez uma versão noturna e funciona perfeitamente ..
Por que as compilações noturnas são diferentes se é a mesma fonte, o que está acontecendo de forma diferente no GitHub?

Oxyandy picture Oxyandy em 4 mai. 2018

Alguém está usando o Arduino IDE?
Você é capaz de construir um "ESP8266 normal 1024" a partir do src atual e despejá-lo aqui?
Obrigado

Oxyandy picture Oxyandy em 4 mai. 2018

não tenho certeza se isso está relacionado a alguns dos problemas aleatórios que estamos vendo, mas percebi que, depois de algum tempo, minhas unidades param de enviar dados para o controlador. No entanto, a interface da web ainda está ativa e funcionando, mas mostra um endereço IP de 0.0.0.0. (veja a imagem). Alguém mais está vendo isso?

untitled

image

clumsy-stefan picture clumsy-stefan em 4 mai. 2018

Que versão de compilação é esta?

TD-er picture TD-er em 4 mai. 2018

@Oxyandy

Por que as compilações noturnas são diferentes se é a mesma fonte, o que está acontecendo de forma diferente no GitHub?

Isso é o que também estou me perguntando.
Eu acho que tem algo a ver com o fato de que às vezes também temos que construí-lo duas vezes ao construí-lo nós mesmos.
Parece haver algo errado com a maneira como compilamos as coisas ou com o compilador.
Isso talvez também explique por que estamos vendo tantas coisas que são muito difíceis, senão impossíveis, de reproduzir nas últimas semanas.

Discuti isso também com @arendst da Tasmota, e ele confirmou que também precisa reconstruir de vez em quando para obter uma boa versão funcional.
Vou perguntar a @ psy0rz se é possível construir as compilações noturnas duas vezes como um teste.

TD-er picture TD-er em 4 mai. 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 picture clumsy-stefan em 4 mai. 2018

Você poderia tentar construí-lo duas vezes, antes de gravá-lo no nó?
Não há limpeza entre as compilações, apenas construa e construa novamente.

TD-er picture TD-er em 4 mai. 2018

com certeza, mas eu uso o Arduino SDK em um mac, não platformIO ... ainda quer tentar?

clumsy-stefan picture clumsy-stefan em 4 mai. 2018

Sim, por favor, já que não temos idéia do que está causando isso.
Apenas certifique-se de usar as mesmas bibliotecas principais que usamos, já que o Arduino IDE não olha para as versões fixas definidas em PlatformIO.
As versões atuais que usamos são:
ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3

TD-er picture TD-er em 4 mai. 2018

ok, vou tentar isso agora e piscar algumas unidades. Vou relatar assim que algo acontecer ... ou nada;)

clumsy-stefan picture clumsy-stefan em 4 mai. 2018

POR FALAR NISSO. a compilação atual pode travar a qualquer momento mantendo F5 pressionado no navegador da web pelo menos nas páginas de dispositivo ou de notificações (provavelmente em qualquer página da web do ESP) por alguns segundos. Posso repetir a qualquer momento do Firefox no Win10:
...
...
39543696: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39551825: LoadFromFile: índice config.dat: 27648 tamanho de dados: 320
39557599: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39566681: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39566879: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39567105: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39567490: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39567690: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39567883: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39568086: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39568287: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39568495: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39568701: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39568910: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39569112: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39569324: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39569530: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39569739: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39569948: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39570158: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39570366: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39570582: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
39570742: Página da web ignorada: pouca memória: 1784
39570832: Página da web ignorada: pouca memória: 1784
39570906: Página da web ignorada: pouca memória: 1784
39570992: Página da web ignorada: pouca memória: 1784
39571074: Página da web ignorada: pouca memória: 1784
39571161: Página da web ignorada: pouca memória: 1784
39571240: Página da web ignorada: pouca memória: 1784
39571322: Página da Web ignorada: pouca memória: 1784
39571401: Página da web ignorada: pouca memória: 1784

Exceção (28):
epc1 = 0x4025cb66 epc2 = 0x00000000 epc3 = 0x401003f2 excvaddr = 0x00000000 depc = 0x00000000

ctx: cont
sp: 3fff4690 end: 3fff4b20 offset: 01a0

pilha >>>
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
<<

data de 8 de janeiro de 2013, primeira causa: 2 , modo de inicialização: (3,7)

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

INIT: versão de inicialização: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
89: INIT: Inicialização a quente # 3
90: FS: Montagem ...
115: FS: montagem bem-sucedida, usou 75.802 bytes de 957314
437: CRC: soma de verificação do programa ... OK
469: CRC: CRC de configurações de segurança ... OK
575: INIT: RAM livre
575: INIT: I2C
575: INIT: SPI não habilitado
1677: INFO: Plugins: 72 [Normal] [Teste] [Desenvolvimento] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
1678: EVENTO: Sistema # Wake
1682: WIFI: Definir WiFi para STA
...
...

O dispositivo foi então conectado ao AP com sucesso. Outra falha:

973: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
279178: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
279387: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
279590: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
279798: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
280321: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
280558: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
280785: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
Exceção fatal 28 (LoadProhibitedCause):
epc1 = 0x4025cb66, epc2 = 0x00000000, epc3 = 0x40100408, excvaddr = 0x00000000, depc = 0x00000000

Exceção (28):
epc1 = 0x4025cb66 epc2 = 0x00000000 epc3 = 0x40100408 excvaddr = 0x00000000 depc = 0x00000000

ctx: cont
sp: 3fff4690 end: 3fff4b20 offset: 01a0

pilha >>>
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
<<

data de 8 de janeiro de 2013, primeira causa: 2 , modo de inicialização: (3,7)

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

INIT: versão de inicialização: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
89: INIT: inicialização a quente # 8
91: FS: Montagem ...
116: FS: montagem bem-sucedida, usou 75.802 bytes de 957314
438: CRC: soma de verificação do programa ... OK
469: CRC: CRC de configurações de segurança ... OK
575: INIT: RAM livre
576: INIT: I2C
576: INIT: SPI não habilitado
1678: INFO: Plugins: 72 [Normal] [Teste] [Desenvolvimento] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
1678: EVENTO: Sistema # Wake
1683: WIFI: Definir WiFi para STA
...

ghtester picture ghtester em 4 mai. 2018

Bem, isso é com 72 plugins, que tal normal isso se comporta da mesma forma;)

Oxyandy picture Oxyandy em 4 mai. 2018

Isso é normal se você inundar a pilha de IP com solicitações. A única coisa que ajuda é atender ao servidor da Web com mais frequência, para que o buffer de entrada seja liberado novamente.

s0170071 picture s0170071 em 4 mai. 2018

Pelo menos é bom que possa ser recuperado - travar completo seria pior do que reiniciar ... Mas é estranho que a causa da inicialização não fosse a mesma todas as vezes - eu vi também a causa 4.

ghtester picture ghtester em 4 mai. 2018

ESP_Easy_mega-20180504_test_ESP8266_1024.bin
Consigo conectar o wi-fi (primeira tentativa) e permanecer conectado
F5 (página Dispositivos) não causa erros ou falha
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Conecta-se e falha em um ciclo de 11 segundos repetido - (200) Tempo limite de Beacon
ESP_Easy_mega-20180504_normal_ESP8266_1024_ (Self_Compiled) .bin
Perfeito

Oxyandy picture Oxyandy em 4 mai. 2018
😕1

@Oxyandy Repetição automática lenta do teclado? ;-)
A minha trava em todas as páginas da web que experimentei.

ghtester picture ghtester em 4 mai. 2018

@ghtester irei construir um conjunto no meu PC, com todo o código atual. A construção levará cerca de 30 minutos.

TD-er picture TD-er em 4 mai. 2018

@ TD-er Muito obrigado pelo seu esforço, vou testá-lo quando a nova compilação estiver pronta.

ghtester picture ghtester em 4 mai. 2018

@ TD-er atualizou minhas unidades (16) agora com ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 construído duas vezes antes de piscar ... Vou ver amanhã se eles ainda estão vivos e enviando dados ... Tive que usar lwIP2 com largura de banda alta, caso contrário os dados enviados via FHEM-Controller ficam truncados!
mas precisa dormir agora .... n8

clumsy-stefan picture clumsy-stefan em 5 mai. 2018

Esteja ciente dos problemas do HTTP POST com a versão de largura de banda alta.

Minha compilação está agora em execução pela terceira vez (tive algum problema ESP32 que precisava ser corrigido e quero ter certeza de que apenas a vinculação é feita na última compilação)
Portanto, haverá um arquivo zip em alguns minutos.
Então vou para a cama também.

TD-er picture TD-er em 5 mai. 2018

Veja a compilação: https://github.com/letscontrolit/ESPEasy/releases/tag/mega-20180505_TD-er

TD-er picture TD-er em 5 mai. 2018

TD-er, sua construção, meu hardware, nenhum problema com o (normal 1024 8266)
Esperando que a compilação diária seja exibida, tentarei isso a seguir;)

Oxyandy picture Oxyandy em 5 mai. 2018

@ TD-er Muito obrigado, testei rapidamente a versão 4096 dev (para continuar), o problema de reinicialização "F5" ainda está lá (a primeira tentativa desligou o dispositivo completamente) e as informações do firmware dizem que a verificação MD5 falhou (suponho que seja devido a construção de teste). No entanto, tudo o resto está bem até agora e está se conectando perfeita e rapidamente ao AP.

Build 20102 - Mega
Bibliotecas ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3
Versão GIT
Plugins 72 [Normal] [Teste] [Desenvolvimento]
Build Md5 4d44355f4d44355f4d44355f4d44355f
Falha na verificação Md5!
Tempo de compilação 5 de maio de 2018 00:33:21
Nome de arquivo binário ThisIsTheDummyPlaceHolderForTheBinaryFilename ...

ghtester picture ghtester em 5 mai. 2018

Conforme compilado e lançado no GitHub, esses dois BINs, com 1 dia (1 compilação) de diferença.
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Confirmado 'defeituoso' de muitas maneiras diferentes, reinicialização, nós diferentes, etc.
os problemas consistentes (201 Beacon Timeout) em um loop de 11 segundos
Homebrew funcionando perfeitamente da mesma fonte.
para
ESP_Easy_mega-20180505_normal_ESP8266_1024.bin
Funcionando perfeitamente, as mudanças na fonte sendo mínimas
me diz, as versões do GitHub apresentam uma falha 'em algum lugar' na compilação.
Primeira tentativa conectada ao Wi-Fi, atualização instantânea da hora, sem conexão do Wi-Fi nenhuma vez,
MQTT mantendo a conexão
etc etc -
nada a culpar;)

Oxyandy picture Oxyandy em 5 mai. 2018

Então isso significa que muito tempo gasto nas últimas semanas (???) pode ser devido a problemas de compilação?
Isso é lamentável, mas pelo menos me dá confiança de que não estou perdendo a cabeça ao ver todos os tipos de problemas relatados que não consegui reproduzir nem explicar.

TD-er picture TD-er em 5 mai. 2018
😕1

Quanto ao problema f5: tente lwip com largura de banda alta, pois ele tinha buffers maiores. Ele pode travar um pouco mais tarde.

s0170071 picture s0170071 em 5 mai. 2018

Problemas de compilação: você está rodando a 80 MHz, certo?

s0170071 picture s0170071 em 5 mai. 2018

80 MHz é o padrão, eu acho.

TD-er picture TD-er em 5 mai. 2018

Eu sei. Mas configurá-lo para 160 pode causar um comportamento estranho.

s0170071 picture s0170071 em 5 mai. 2018

Sim, o problema "F5" é o único problema sério que vejo até agora nesta construção especial. Na verdade, se eu apenas pressioná-lo várias vezes rapidamente para atualizar a página da web do ESP, isso causa problemas:

18084332: EVENTO: Relógio # Tempo = Sáb, 08: 47 Tempo de processamento
18091174: WD: Uptime 302 ConnectFailures 0 FreeMem 14504
bcn_timout, ap_probe_send_start
18112119: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18115167: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18116976: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18119084: LoadFromFile: índice notification.dat: 0 datasize: 996
18119089: LoadFromFile: índice notification.dat: 1024 datasize: 996
18119092: LoadFromFile: índice notification.dat: 2048 datasize: 996
18119129: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18121330: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18121337: WD: Uptime 302 ConnectFailures 0 FreeMem 13584
18128862: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18130833: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18135120: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18136605: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18138356: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18140067: LoadFromFile: índice notification.dat: 0 datasize: 996
18140076: LoadFromFile: índice notification.dat: 1024 datasize: 996
18140078: LoadFromFile: índice notification.dat: 2048 datasize: 996
18140152: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18144694: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18144700: EVENTO: Relógio # Hora = Sáb, 08: 48
18144702: EVENTO: Relógio # Tempo = Sáb, 08: 48 Tempo de processamento
18148558: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18151336: WD: Uptime 303 ConnectFailures 0 FreeMem 12568
18153230: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18153763: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18155000: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18155592: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18156416: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18156838: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18164949: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18165234: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18165587: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18170770: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18170947: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18171120: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18171300: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18171733: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18177686: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
bcn_timout, ap_probe_send_start
18181336: WD: Uptime 303 ConnectFailures 0 FreeMem 10832
18182865: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18183367: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18188878: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18190025: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18203237: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18203809: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18203817: EVENTO: Relógio # Hora = Sáb, 08: 49
18203819: EVENTO: Relógio # Tempo = Sáb, 08: 49 Tempo de processamento
bcn_timout, ap_probe_send_start
bcn_timout, ap_probe_send_start
bcn_timout, ap_probe_send_start
18496844: Uso de RAM: apenas servidor da Web: 0 incluindo núcleo: 0
18496850: WD: Uptime 304 ConnectFailures 0 FreeMem 8736
18496856: EVENTO: Relógio # Hora = Sáb, 08: 53
18496858: EVENTO: Relógio # Hora = Sáb, 08: 53 Tempo de processamento

Após as últimas três mensagens bcn_timout, ap_probe_send_start, o dispositivo foi congelado por cerca de 60 segundos, mesmo no console serial, então continuou funcionando sem reinicializar.

Sim, está funcionando a 80 MHz - as informações do sistema dizem: ESP Chip Freq: 80 MHz

As respostas da web do ESP são muito rápidas até que tento atualizar muito rapidamente ...

ghtester picture ghtester em 5 mai. 2018

manhã tudo ... minhas unidades funcionam estáveis ​​por cerca de 10 horas agora. no entanto, às vezes os problemas só surgem depois de um ou dois dias, então eu os deixo funcionando assim. uma unidade é reiniciada duas vezes durante a noite (de 16 D1's), o que pode estar relacionado ao plugin ou algo parecido ... o básico do sonoff também funciona perfeitamente.

clumsy-stefan picture clumsy-stefan em 5 mai. 2018

Eu sei que você não pode ver ou explicar o TD-er, mas você usou as compilações do GitHub como um teste?
Posso voltar à fonte de lançamentos no mês passado e comparar com homebrew
Já tive muitos que considerei inúteis, uma das minhas guias no Notepad ++ tem a lista

Oxyandy picture Oxyandy em 5 mai. 2018

Sobre F5, não é realmente um problema - eu uso isso como uma referência, não tenho atualização automática para a tecla F5,
então estou acessando manualmente, observando o uso de RAM e a saída de log serial ao mesmo tempo.
"lwip high bandwidth" da memória foi quase instantâneo
LmacRxBlk:1 erros e eles não foram recuperáveis ​​..
O que me lembra que devo escrever algo sobre .. na lista de tarefas ..
E vou tentar diferentes configurações de compilação novamente como medida

Oxyandy picture Oxyandy em 5 mai. 2018

Hmm, não sei se o motivo foi eu configurei um display LCD na posição 12, mas logo depois disso perdi a conexão com o AP e não consigo mais reconectar (Nenhum AP encontrado apesar de ser visível pelo wifiscan). Depois de reinicializar o mesmo problema. Em seguida, o dispositivo entrou em modo AP, mas talvez devido aos sublinhados no nome SSID ele disse:

1127917: WIFI: Erro ao iniciar o modo AP com SSID: ESP_01_1 IP: 192.168.4.1

Mas o dispositivo estava visível como AI-THINKER_XXXXXXX, eu consegui conectá-lo, mas quando tentei alterar o nome do dispositivo, etc. Perdi conexões com o dispositivo, travamento e reinicializações etc ... :-(

Atualizar - depois de várias tentativas, renomeei o dispositivo para remover o sublinhado, mas ainda há antes do número do dispositivo:
599417: WIFI: Erro ao iniciar o modo AP com SSID: ESP-001_1 IP: 192.168.4.1
E o dispositivo ainda é visível como AI-THINKER_XXXXXXX
Não consigo mais conectar ao meu AP como cliente ... Vou tentar redefinir as configurações de fábrica ...

Update2 OK ... Reset de fábrica, dispositivo visível como ESP_Easy_0 AP ... Defina o WifiSSID e WifiKey através do console serial, dispositivo imediatamente conectado ao AP ...

ghtester picture ghtester em 5 mai. 2018

a maioria das minhas unidades ainda funciona bem ... no entanto, não acho realmente que seja uma questão de compilar duas vezes ... a única diferença é que algumas bibliotecas são compiladas apenas na primeira vez, depois disso, quando o SDK vê que elas não mudou não vai recompilar ...

outra coisa que vou tentar agora é em vez de especificar a placa "D1 Mini" no arduino, eu mesmo defino todos os parâmetros e uso o módulo "8266 genérico" ... veremos se isso faz diferença ...

atualmente, a única coisa que vejo são algumas reinicializações espontâneas de certas unidades ... mas isso pode estar relacionado a outras coisas ...

uma pergunta minha: sonoff basic tem apenas 1M de memória ... alguma chance de atualizar essas coisas OTA? obviamente, sempre afirma "memória insuficiente" ... alguma ideia?

PS: sobre os problemas de compilação, eu sempre usei binários auto-compilados (outros plug-ins) desde o início, e tive os "mesmos" problemas de estabilidade ... então alguns deles poderiam realmente estar relacionados ao platformIO, outros eu acho que eram problemas "reais". ..

clumsy-stefan picture clumsy-stefan em 5 mai. 2018

Você pode usar menos plug-ins ao compilar. Veja https://github.com/letscontrolit/ESPEasy/blob/mega/src/define_plugin_sets.h

Você nunca será capaz de OTA diretamente, mas dessa forma é pelo menos pequeno o suficiente para OTA em dois estágios. Veja o wiki para esse aqui :)

louis-lau picture louis-lau em 5 mai. 2018

foi exatamente o que eu fiz ... é por isso que estou sempre compilando sozinho ... mas mesmo com apenas 2 plugins habilitados o sketch usa 500k ...
é por isso que estou procurando uma solução diferente (por exemplo, sem interface da web ... etc.) ..

clumsy-stefan picture clumsy-stefan em 5 mai. 2018

500k é pequeno o suficiente. Como eu disse, duas partes OTA. Você não pode atualizar diretamente. Olhe para o wiki :)

louis-lau picture louis-lau em 5 mai. 2018

thx .. pesquisando ....;)

adicionar: de alguma forma eu perdi a parte das duas etapas ....

clumsy-stefan picture clumsy-stefan em 5 mai. 2018

Com 1M Sonoffs, você precisará usar um Uploader inicial que tem a bandeira DOUT no cabeçalho,
de memória, o que está no Wiki não é, mas pode ter sido atualizado recentemente.

Oxyandy picture Oxyandy em 6 mai. 2018

Lembro-me de algo assim, acabei de pesquisar um Estou usando este para OTA: https://github.com/soif/EspBuddy/blob/master/firmwares/ESPEasyUploader.OTA.1m128.esp8266.bin

louis-lau picture louis-lau em 6 mai. 2018

Sim, verifiquei que é DOUT
Aqui está um que juntei é menor
Initial_Firmware_Uploader_Sonoff_1M_DOUT.zip

Oxyandy picture Oxyandy em 6 mai. 2018

Eu disse que faria porque estava muito curioso ........
Em comparação com o Self_Compiled mega-20180422 com o GitHub lançado, até agora - tentei apenas um
ESP_Easy_mega-20180422_normal_ESP8266_1024.bin
Eu deixei um comentário e loguei sobre seu comportamento aqui https://github.com/letscontrolit/ESPEasy/issues/1301#issuecomment -383433822 (GitHub lançado)
Mesma fonte auto-compilada, nenhuma surpresa, vejo um comportamento diferente do Nightly.
Permaneceu conectado, horror de choque!
O GitHub lançou o mega-20180422, exibido no topo, exatamente o mesmo comportamento que relatei quando tentei pela primeira vez.
Não conseguia ficar conectado, WIFI : Disconnected! Reason: '(200) Beacon timeout' pedalando continuamente
A causa precisa ser investigada ... suspiro
GitHub lançado = não é confiável?

Oxyandy picture Oxyandy em 6 mai. 2018

Eu postei os sinalizadores do compilador Arduino ontem ou assim. Quais sinalizadores o Travis usa?

s0170071 picture s0170071 em 6 mai. 2018
👍1

Tenho 16 D1 e 3 básicos em execução no f69e476 compilado automaticamente, Core 2.4.1, lwIP2 de largura de banda alta.
Quase todos eles com um tempo de atividade de> 900Min. agora e ainda funcionando bem. 2 deles mudaram para o modo AP cerca de uma hora atrás e não se reconectaram até agora. Vou esperar até hoje à noite e ver se eles se recuperam.

infelizmente, o comportamento não é realmente reproduzível e não posso fornecer nenhuma evidência de onde os problemas surgem, mas continuarei procurando por falhas e relatarei se eu encontrar alguma coisa ...

@Oxyandy : Eu também recompilei um upload para o meu básico funcionar bem! obrigado novamente por me apontar a direção certa ..;)

clumsy-stefan picture clumsy-stefan em 6 mai. 2018

@ s0170071
Eles são armazenados em .travis.yml & platformio.ini
Eu acelerei a leitura, tada, olha o que eu encontrei
skip_cleanup: true
Edit: Leitura adicional Não tenho certeza se isso se refere a fazer uma compilação limpa ?
Eu admito que é tudo novo para mim ... ??? Desativando o cache?

Oxyandy picture Oxyandy em 6 mai. 2018

Travis sempre faz uma compilação limpa, já que até baixa o ambiente Python, etc.

As compilações noturnas são feitas por @ psy0rz , não por Travis

TD-er picture TD-er em 6 mai. 2018
👍1

Okee dokee, então eles são compilações limpas?
Tentando entender por que eles se comportam de maneira diferente?

Oxyandy picture Oxyandy em 6 mai. 2018

Que tal comparar MD5 de bin1 e bin2?
Ele indicará se é um problema de tempo de compilação ou tempo de execução ...

susisstrolch picture susisstrolch em 6 mai. 2018

@susisstrolch, você quer dizer quando compila a si mesmo? É porque o MD5 é calculado após a compilação. Existe um script que faz isso para você.
https://github.com/s0170071/CRC4ESP

-edit :
sim, você pode comparar os md5, eles devem ser idênticos. Se você fizer isso offline, também poderá comparar os binários bit a bit. Desta forma, você pode até dizer onde está o desvio. Se você for avançado, pode até rastrear o código. O arquivo .elf deve conter todas as informações.

De qualquer forma, não me importo muito com o que exatamente difere. Acho que é mais importante ter certeza de que todos estão no mesmo binário - não importa quem o compilou.

Então, novamente, quais são os sinalizadores de compilação para Arduino, platformio, nightly e travis? Win / Linux ,.

s0170071 picture s0170071 em 6 mai. 2018

Não - Quero dizer, em vez de especular sobre as diferenças na saída do compilador em compilações automatizadas, simplesmente compare o MD5 de ambas as compilações. Então você pode dizer exatamente se eles são diferentes.

susisstrolch picture susisstrolch em 6 mai. 2018

Sinalizadores para Arduino IDE no Linux são:

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 picture s0170071 em 6 mai. 2018

@ s0170071 Tentei perguntar ao Edwin, mas ele ainda não respondeu.
Portanto, por enquanto, não sabemos exatamente o que está sendo feito para as compilações noturnas.
E ainda permanece o comportamento estranho (que também experimentei na minha configuração) de que compilá-lo duas vezes dá resultados diferentes.
Os binários entre as compilações não podem ser comparados por meio de uma soma de verificação. Há um carimbo de data / hora de compilação incluído, que será diferente para qualquer compilação. Portanto, compilar a mesma fonte 100 vezes resultará em 100 somas de verificação diferentes.
Mas pelo menos deve dar a mesma funcionalidade e isso parece não estar acontecendo (às vezes) entre a primeira e a segunda compilação. E _Isso_ não é como deveria ser.

TD-er picture TD-er em 6 mai. 2018

Portanto, para fins de teste e para acertar, eu pularia a configuração de todas as alterações de pré-compilação entre essas compilações consecutivas para obter um src comparável.

susisstrolch picture susisstrolch em 6 mai. 2018

@ s0170071 portanto, obtemos muitas informações de depuração por causa da opção -g ao compilar com o Arduino IDE.
Talvez um ponto para reduzir o tamanho ...

susisstrolch picture susisstrolch em 6 mai. 2018

A redução de tamanho é algo que devemos observar no futuro, mas você deve tomar cuidado ao alternar os sinalizadores de otimização. Alguns podem levar a problemas ainda mais difíceis de reproduzir.

TD-er picture TD-er em 6 mai. 2018

os dois untis se recuperaram algumas horas depois durante o dia, mas outros estão falhando aleatoriamente ... duas coisas que eu achei até agora:
Recebo entradas no log dizendo:
96493069: IP bloqueado: 0.0.0.0 Permitido: 10.0.0.0 - 10.0.255.255
96517068: WD: Uptime 1608 ConnectFailures 0 FreeMem 11544
a primeira linha me parece estranha, o que tenta se conectar com o IP 0.0.0.0? isso pode estar relacionado aos problemas que vi alguns dias atrás, que a unidade está acessível, mas me diz que tem IP 0.0.0.0.

segunda coisa, embora nada tenha sido feito durante as últimas 24h, vejo pulos repentinos na carga da CPU, mesmo em unidades "pequenas", que estão apenas usando a funcionalidade de switch (por exemplo. Nr. 7 no gráfico em anexo).

Alguma chance de descobrir por que essas mudanças repentinas na carga da CPU ocorrem? o log não diz nada específico .. (carga da CPU de hoje e ontem) ...
image
image

clumsy-stefan picture clumsy-stefan em 6 mai. 2018

A carga da CPU salta no momento de uma reinicialização?
A forma como a carga da CPU é calculada é um pouco estranha.
Leva o número de vezes que a função de loop principal é executada em 30 segundos.
Isso é comparado com a contagem máxima observada.
Isso significa que, durante a operação, a contagem máxima observada pode aumentar, mas também pode diminuir repentinamente após uma reinicialização.

TD-er picture TD-er em 6 mai. 2018

não, não na reinicialização ... apenas "aleatoriamente" em algum ponto ... curiosamente, isso acontece com várias unidades ao mesmo tempo ... Não tenho ideia do que aconteceu lá (não estava em casa então) ... especialmente as unidades 12- 14 são placas realmente simples, sem tarefas exceto rssi, load, uptime e mem ... também os gráficos de memória não mostram sinais de mudanças significativas ...
ainda agora, carregar em algumas unidades mostra ~ 50%, mas a interface da web é rápida ..

também tenho em uma unidade um relógio nfx conduzido que muda a cada segundo a posição dos ponteiros. curiosamente, o relógio parou em um ponto no tempo, mas a unidade continuou a funcionar sem problemas ... como se essa tarefa não fosse mais executada ... mas isso poderia ser relacionado ao plugin (já que é um dos playgound) .. mas poderia provavelmente aponta para problemas ...

mas como eu disse, atualmente estou absolutamente sem nenhuma pista de onde todos esses problemas podem vir .. realmente apenas fuçando tentando encontrar algo .... e dando feedback a todos para brainstorming ....

de qualquer forma, muito obrigado por seus esforços e ajuda ... se eu encontrar algo razoável, relatarei ...

clumsy-stefan picture clumsy-stefan em 6 mai. 2018

Também pode significar que algum serviço mudou de disponibilidade em algum momento.
Ou se tornou disponível, o que fez com que os nós realmente fizessem mais trabalho.
Ou não estava mais disponível. ESPeasy tenta fazer algum ping em um host para detectar sua disponibilidade. Se o ping falhar, ele irá parar o nó durante o período de tempo limite.

TD-er picture TD-er em 6 mai. 2018

como esse "ping" é feito? porque vejo algum "host desconhecido" de vez em quando ... será que esse tempo limite é muito grande? ou o ping ord DNS lookup tem tempos limite curtos? na verdade, eu não uso mais FQDNs, apenas IPs, então é menos provável que DNS seja um problema ...

Estou apenas atualizando com o commit mais recente ... algumas unidades são fáceis de atualizar e bastante rápidas, outras muito lentas ...

Eu tenho 4 APs rodando no mesmo SSID, você também pode selecionar um pior e depois ter problemas de velocidade?

clumsy-stefan picture clumsy-stefan em 6 mai. 2018

Eu estava planejando mudar a forma como o ping é feito para o ping assíncrono.
Ao tentar fazer uma conexão, há uma verificação para ver se o host está disponível. Isso é feito via ping.

TD-er picture TD-er em 6 mai. 2018

e isso é uma chamada de bloqueio?

clumsy-stefan picture clumsy-stefan em 6 mai. 2018

De fato, é por isso que quero alterá-lo para alguma variante assíncrona.

TD-er picture TD-er em 6 mai. 2018

hmm .. isso pode explicar, quando a conectividade de rede é fraca, que as coisas não são realmente "fluentes" ... especialmente ao tentar fazer upload de um novo esboço ... é possível aumentar o tempo limite de ping se a rede tiver muito de latência?

clumsy-stefan picture clumsy-stefan em 6 mai. 2018

Isso só é feito ao fazer uma conexão.
A carga experimentada de uma nova tentativa de conexão MQTT que falhará é muito mais perceptível.
Não há muitos hosts com os quais estamos nos conectando, então talvez deva haver alguma verificação de disponibilidade assíncrona em execução em segundo plano para ajudar a decidir se devemos ou não reconectar.
NB, uma pesquisa de DNS também pode bloquear quando eventualmente falhar.

TD-er picture TD-er em 6 mai. 2018

será que 0.0.0.0 é o DNS secundário?

giig1967g picture giig1967g em 6 mai. 2018

Percebi isso com o DNS, é por isso que eu só uso endereços IP agora ... Eu não uso MQTT de forma alguma, apenas o plugin do controlador fhme, bem como consultas json regulares (de fhem com o plugin HTTPMOD).

uma coisa que provavelmente vou tentar é desativar a rede UDP entre ESPEasy ... Não consigo me livrar da sensação de que isso tem alguma influência nas unidades, especialmente ao executar mais de 15 unidades que enviam atualizações regulares. ..

clumsy-stefan picture clumsy-stefan em 6 mai. 2018

depois de atualizar todas as unidades para o último mega commit, todas as cargas da CPU voltaram ao "normal" ... esta manhã por volta das 8 eu reiniciei o Nr. 4 e 9, e veja o que aconteceu com a carga da CPU, quase todas as unidades tiveram um pico de cerca de 30min. e voltou ao normal depois disso ....

apenas uma ideia rápida: é possível que os eventos UDP inter-ESPEasy recebidos sejam "redistribuídos" para outras unidades e, portanto, possam gerar um loop e preencher a pilha da rede?
image

clumsy-stefan picture clumsy-stefan em 7 mai. 2018

Eu nunca olhei para o código dessas 'comunicações entre ESPeasy', portanto, não posso dizer nada sobre isso.
Eu esperaria que esse protocolo estivesse apenas enviando seus próprios dados e não ecoando o resto.
Este protocolo consiste em 2 partes:

  1. Afirmando sua própria presença.
  2. Envio de valores de parâmetro de plug-ins por meio do que costumava ser "sincronização global".

Este último foi substituído por "controlador c_013".

Mas não tenho certeza se não há um loop possível. Por exemplo, com dispositivos fictícios, importação MQTT, etc.
Também pode haver um comportamento diferente entre versões antigas e novas versões que usam o "controlador 13".

TD-er picture TD-er em 7 mai. 2018

ok, obrigado pela resposta rápida ... Vou desligar agora, resp. configurando a porta UDP para 0 e veja se alguma coisa muda ...

Adicionar: após alterá-lo, vejo cerca de 50% das unidades reiniciando (sem ser instruído a fazê-lo) ... e algum "HTTP: falha na conexão" no log ....

clumsy-stefan picture clumsy-stefan em 7 mai. 2018

Tenho notado um problema semelhante com a carga da CPU. O wemos está rodando um FW auto compilado com 13 plugins. Estou usando a API Rest com Pimatic. Como você pode ver por algum motivo, a carga sobe para 90% ou mais.
image

jopiekr picture jopiekr em 7 mai. 2018

para informações: desde que desliguei a rede Inter-ESPEasy definindo a porta para 0 nas configurações avançadas, parece que (a maioria) meus problemas desapareceram! todas as 20 unidades têm tempos de atividade> 20min. e ainda estão relatando valores regularmente. web-se instalado e funcionando. também o gráfico da CPU não mostra mais desses saltos repentinos. Apenas uma unidade mudou para modo AP, vou ver se recupera ..
provavelmente isso precisa ser investigado (na fonte) ... com muitas unidades, o material UDP provavelmente está sobrecarregando a pilha da rede ...
espero que isso ajude outras pessoas que enfrentam problemas semelhantes ...

clumsy-stefan picture clumsy-stefan em 8 mai. 2018

Aqui minha experiência:
6 unidades todas com IP Estático e Rede Inter-ESPeasy ativa.
O firmware mais recente carregado foi "Mega 20180505 Manual construído duas vezes". (mas os firmwares anteriores também funcionavam muito bem).
Eles estão funcionando há quase 3 dias sem nenhum problema.

immagine

giig1967g picture giig1967g em 8 mai. 2018

Esse é um dos motivos pelos quais quero esperar alguns dias antes de fazer algumas correções de wi-fi / rede. Deixe-o funcionar por um tempo para ver o que está realmente errado e tente ler alguns problemas na lista de problemas do Arduino.
Já notei que uma série de problemas sugere desativar o gerenciamento de energia para algumas configurações wi-fi. Aparentemente, algumas combinações de ponto de acesso ESP8266 + não funcionam bem com os recursos de gerenciamento de energia habilitados (que são habilitados por padrão)
Essa é uma opção para adicionar ao ESPeasy.

Procuro mais ideias nos próximos dias e sexta / sábado tenho mais tempo para codificar.

TD-er picture TD-er em 8 mai. 2018

Para referência, meu ponto de acesso é ASUS RT-AC68U com firmware Merlin

giig1967g picture giig1967g em 8 mai. 2018

Eu acho que a maioria dos problemas são com o firmware padrão de fábrica para os modelos mais baratos e talvez pontos de acesso um pouco mais antigos que não estavam cientes das opções de economia de energia dos dispositivos wi-fi modernos.
A questão permanece se é possível negociar tais recursos para detectar automaticamente esses recursos.

TD-er picture TD-er em 8 mai. 2018

Que tal deixar desabilitado por padrão e habilitar somente se solicitado na página de configurações?
As opções de economia de energia fazem sentido apenas para dispositivos operados por bateria, eu suponho.

giig1967g picture giig1967g em 8 mai. 2018

Eles também fazem sentido para outros fins.
Mais energia significa mais calor e alguns são incluídos com sensores ....;)

TD-er picture TD-er em 8 mai. 2018

Além da alta carga do processador. Voltei para um FW datado de 16/03 com 2.3.0 Core e tudo voltou ao normal. Carrega agora no máximo. 25%. Além disso, o tempo de resposta do wemos é muito melhor novamente. Tanto no dia 08/05 quanto no dia 16/03 eu não tenho nenhuma conexão Wi-Fi. Ainda não tenho ideia do que causou a alta carga. Também em ambos os casos não fiz uso do udp.

jopiekr picture jopiekr em 10 mai. 2018

desde a desativação do UDP, as unidades funcionam sem problemas, exceto aquelas que têm um LCD conectado. Eu acho que se você tem muitas unidades falando (> 20), elas ficam muito ocupadas decodificando todas as mensagens UDP ou têm algum vazamento de memória ou algo semelhante. Isso também explicaria as reinicializações espontâneas das unidades após o início de outra. apenas MHO ... preciso depurar mais para ter certeza ...

clumsy-stefan picture clumsy-stefan em 11 mai. 2018

Também pode estar relacionado à realização de tarefas mais longas sem tempo para algumas chamadas para yield() , o que também é feito ao chamar delay() .
Posso imaginar o plugin LCD (e talvez alguns outros também) fazer algumas tarefas que levam> 10 mseg.

TD-er picture TD-er em 11 mai. 2018

as unidades com LCD parecem ficar mais ocupadas com o tempo ... ao tentar fazer o reflash eu preciso reiniciá-las primeiro, porque depois de algumas horas o upload não funciona mais (ou leva séculos ...)

todas as outras unidades funcionam bem agora, mas como disse, o anúncio inter ESP deve ser desativado ...

pelo menos o WiFi está estável assim, nenhum outro problema de conectividade até agora ... (funcionando com mais de 20 unidades até agora)

clumsy-stefan picture clumsy-stefan em 11 mai. 2018

Você tem o registro habilitado na porta serial?
Você poderia definir como "Nenhum"?

TD-er picture TD-er em 11 mai. 2018

hmm .. ponto interessante, eu tenho a "informação" padrão no log da porta serial, mas desabilitei a porta serial completamente para baixo ... isso poderia levar a problemas?

Vou mudar para "nenhum" nas unidades, vou ver se isso faz diferença ..

clumsy-stefan picture clumsy-stefan em 11 mai. 2018

Já ouvi relatos antes, sobre os dados que não estão sendo buscados nos buffers seriais que se acumulam.
E acabei de perceber que em um nó em execução, quando conectei o monitor serial, recebi os dados de volta ao momento em que ele inicializou, como um minuto antes.

TD-er picture TD-er em 11 mai. 2018

Com isso, a diferença entre o núcleo 2.3.0 e 2.4.1 em 10 de maio, mudei o FW de 2.4 de volta para 2.3. As configurações e regras para ambos são exatamente as mesmas.
image

jopiekr picture jopiekr em 11 mai. 2018

@jopiekr : qual é o software que você está usando para imprimir a carga da CPU?

giig1967g picture giig1967g em 11 mai. 2018

@ gii1967g é pimatic. Faça-o funcionar em um OrangePi One por mais de um ano sem problemas. Como backup também em um Raspberry Pi. pimatic.org

jopiekr picture jopiekr em 11 mai. 2018

mudou todos os logs seriais para nenhum agora ... Vou ver o que acontece ...

o que também é notável é o wi-fi RSSI .. se as unidades recebem um sinal fraco, elas podem não responder ... como eu tenho 4APs funcionando parece um pouco "aleatório" ao qual eles se conectam e nem sempre levam o mais forte 1....

clumsy-stefan picture clumsy-stefan em 11 mai. 2018

Notei que acima de -77dB eles podem parar de responder. Além disso, quando eles não funcionam com bateria, verifique a renovação do tempo de aluguel do roteador. Eu criei uma regra para reiniciá-los após 12.000 minutos.
image

jopiekr picture jopiekr em 11 mai. 2018

Eles devem se reconectar ao último. A primeira tentativa de reconexão é com o BSSID da última conexão ativa.
Mas acho que devemos adicionar o BSSID às configurações.

Nos últimos dias, estive pensando muito sobre os problemas de wi-fi e descobri algum tipo de solução alternativa para os bugs provavelmente presentes na biblioteca principal ou na combinação com as versões de firmware AP existentes
Atualmente, o lib principal faz uma varredura ao tentar se conectar usando apenas um SSID + pwd.
Dessa forma, é muito mais rápido fornecer o canal BSSID + ao conectar.
Porque então não é necessário digitalizar.
Então, por que não fazer a varredura nós mesmos, encontrar o SSID conhecido, armazenar todos os canais BSSIDs + para as redes correspondentes e, em seguida, tentar conectar-se usando apenas o canal BSSID +.
Você também terá o failover automático e controle total sobre quando considerar a renovação de uma conexão. (e assim reinicie os serviços)

Você também conhece o RSSI mais forte, então conecte-se ao mais forte primeiro e sempre tente reutilizar o último usado primeiro
E quando a conexão estiver instável, tente desabilitar o recurso de economia de energia que é habilitado por padrão no núcleo 2.4.x.
Este recurso de economia de energia pode causar reconexões de wi-fi, travamentos ao navegar pelas páginas da web ou até mesmo rejeições ao conectar.

Com o recurso de economia de energia habilitado, o wi-fi é desligado por um tempo e depois habilitado novamente a tempo de receber o sinal do beacon do ponto de acesso.
Se esses estiverem fora de sincronia, alguns pacotes podem não chegar ao ESP e só serão retransmitidos quando o próximo sinal de beacon for recebido. (o que pode demorar um pouco)

Não sei muito sobre os detalhes desses problemas de economia de energia, mas conheço o suficiente sobre desenvolvimento de firmware para saber que os padrões podem não ser implementados da mesma forma entre os fornecedores. Portanto, é muito provável que haja algumas combinações de hardware que operarão de forma menos otimizada com os recursos de economia de energia ativados. Pode até ser algum outro dispositivo Wi-Fi que atrasa o intervalo do sinalizador wi-fi do ponto de acesso. Existem muitas variáveis.

Essa desconexão temporária também pode afetar as pesquisas de DNS e outras interrupções de conexão que podem paralisar o ESP por um tempo. Isso também pode afetar a carga da CPU, uma vez que esse valor (mal definido) é baseado em quantas vezes a função loop () está sendo executada em 30 segundos. Se uma chamada para alguma solicitação de resolução de DNS paralisar o ESP, a contagem de loops será muito baixa e, portanto, uma alta carga de CPU relatada.

TD-er picture TD-er em 11 mai. 2018

@jopiekr Você também pode reiniciar o
Irei primeiro desabilitar as opções de economia de energia (e torná-las selecionáveis, é claro)

TD-er picture TD-er em 11 mai. 2018

@ TD-er sobre o manuseio do WiFi: Concordo totalmente com a função de gerenciamento de energia. Deve-se ser capaz de desligá-lo, pois pode causar problemas muito estranhos e dispositivos lentos ...

Para a reconexão ao AP eu vejo diferente, sempre tentaria conectar ao AP mais forte para garantir uma boa conexão. só depois disso provavelmente pegaria o último. Simplesmente porque se o AP "principal" travar / reiniciar / não responder, etc., a unidade se conectaria a outro. Daquele ponto em diante sempre levará aquele (pior) até que este também falhe ... nunca voltará para o forte, mesmo que este esteja voltando ... também se você mover os dispositivos ao redor , pode ser que selecione o AP anterior mesmo que este esteja muito mais longe / tenha sinal mais fraco ...

Eu concordo, porém, em escanear seu código e, em seguida, decidir qual tomar com base em RSSI e BSSID conhecido ...

clumsy-stefan picture clumsy-stefan em 11 mai. 2018

É apenas a primeira tentativa de reconectar ao último BSSID conhecido.
Isso resultará em uma conexão mais estável ao usar repetidores.
Esses repetidores podem, às vezes, perder conexões quando estão muito ocupados lidando com outras tarefas e podem parecer menos fortes durante a varredura. Os baratos têm apenas um rádio para recepção e transmissão, então, ao receberem dados, pode ser que não estejam transmitindo o sinal do beacon no momento da varredura. Portanto, o RSSI de outro AP pode parecer mais forte naquele momento.

TD-er picture TD-er em 11 mai. 2018

ok, que tal uma varredura "regular" que monitora a força? ou, pelo menos, após uma reinicialização, ele deve reavaliar o ponto de acesso escolhido ...

clumsy-stefan picture clumsy-stefan em 11 mai. 2018

Na reinicialização e se a primeira tentativa de reconectar falhar, ele executará uma varredura e escolherá a correspondência mais forte para o SSID definido.

Vou mudar isso para armazenar o BSSID do AP preferido nas configurações, para que esse BSSID seja sempre o preferido.
As reconexões são muito rápidas se o canal também for conhecido. (sub 200 mseg é possível, dependendo do AP usado)
Além disso, a configuração do IP estático leva cerca de 20 a 25 ms, em comparação com o DHCP, que leva de 2,5 a 10 segundos.
Isso seria ideal para dispositivos alimentados por bateria.

Portanto, há espaço para melhorias :)

TD-er picture TD-er em 11 mai. 2018

Parece muito promissor. Até agora eu tenho 2 meses de vida útil da bateria com baterias 2AA até 3,3V e um sensor DHT enviando a cada 900s. Isso está em uma placa RobotDyn ESP Pro com regulador de tensão removido.

jopiekr picture jopiekr em 11 mai. 2018

@ TD-er Tentei a compilação de ontem. Não consigo ver nenhuma diferença nos tempos de conexão se eu usar um IP estático ou dhcp. Ambas as conexões levam cerca de 3 segundos após a reinicialização.

s0170071 picture s0170071 em 11 mai. 2018

Então você tem um servidor DHCP rápido.
Meu Fritzbox leva cerca de 2,5 segundos para o DHCP, após os 2,5 segundos para se conectar ao wi-fi.
Portanto, a configuração do tempo MQTT connect + NTP leva cerca de 6 a 6,5 ​​segundos a partir da inicialização.

TD-er picture TD-er em 12 mai. 2018

Fritz box 7490.

s0170071 picture s0170071 em 12 mai. 2018

atualização rápida: depois de desabilitar InterESP UDP (e remover C13 de unidades 1M) e definir o registro serial para "não" (também desabilitando a porta serial) quase todas as minhas unidades funcionam estáveis ​​nas últimas 30+ horas ... uma mistura entre D1 Mini, D1 pro, Sonoff Basic, Dual e 4ch ... mais de 20 unidades ... rodando no commit do mega-20180511, auto compilado com Arduino IDE ...

clumsy-stefan picture clumsy-stefan em 12 mai. 2018
🎉1

Eu tenho o 7581 como modem e 3 * 1750E como pontos de acesso.

TD-er picture TD-er em 12 mai. 2018

BTW: Estou rodando em AP's Mikrotik (e um USR bem antigo). Indo atualizar as unidades agora com o último commit desta noite ...

clumsy-stefan picture clumsy-stefan em 12 mai. 2018

Os commits mais recentes atualmente lidam apenas com o código relacionado a JSON (visualizador de log + valores de sensor de atualização).
Ainda não com o código wi-fi.

TD-er picture TD-er em 12 mai. 2018

claro, mas o wi-fi parece estar "estável o suficiente" com os últimos commits, então quero estar atualizado com minhas unidades;)

clumsy-stefan picture clumsy-stefan em 12 mai. 2018

desculpe trazer isso à tona novamente, mas ainda expiereince o problema que o ESP pensa que tem um IP de 0.0.0.0 e para de falar com o servidor, bit em uma rede e nível web está tudo bem! veja a captura de tela em anexo, tentei com uma combinação de versão diferente de ESPEasy e esp8266 ...
alguém mais sabe disso?
untitled

clumsy-stefan picture clumsy-stefan em 31 mai. 2018

De fato, muito estranho, já que me pergunto como você pode ver a página da web com tal configuração de IP.
Ou você se conecta ao ESP por meio de sua função de ponto de acesso?

TD-er picture TD-er em 31 mai. 2018

não, conectado via rede diretamente. ping e http funcionam sem problemas, rápido, (veja o IP do cliente é 10.0.0.10 que é o meu laptop, a rede interna é 10.0.0.0/16) ... sim, muito estranho ..
pode estar relacionado ao DHCP ou algo assim .. após uma reinicialização está tudo bem novamente ..

Isso pode estar relacionado ao fato de que eu habilitei apenas um controlador (FHEM) e nenhum controlador habilitado para MQTT? Eu vi muito código mqtt nos fontes, fora do plugin do controlador ... apenas um palpite ... mas eu acho que não está relacionado ...

clumsy-stefan picture clumsy-stefan em 31 mai. 2018

Talvez o dhcp tenha expirado e não tenha sido renovado?

uzi18 picture uzi18 em 3 jun. 2018

pode muito bem ser ... provavelmente a pilha de rede ainda tem um IP ativo, mas se a renovação falhar, a configuração da resposta é zerada ... não tenho certeza de como o código DHCP funciona, mas pode explicar o estado que estou vendo.

também descobri que quando o servidor (no meu caso fhem) não está respondendo rápido o suficiente um certo número de vezes, as unidades começam a reiniciar depois de algum tempo. pode ser um problema no código do plug-in ou na pilha tcp subjacente ... Fiz alguns ajustes de desempenho no servidor, desde então as unidades rodam muito mais estáveis ​​(alguns têm uptimes acima de 48h agora).

clumsy-stefan picture clumsy-stefan em 4 jun. 2018

Já vi mais de 10 dias de tempo de atividade de conexão (tempo de atividade sem qualquer reconexão) com as versões mais recentes.
É possível fazer com que as unidades preencham sua memória ram com muitos pedidos.
E eu vi o LWIP fazer coisas estranhas ao fazer muitos pedidos. (leitura da memória não contendo dados relacionados a essa solicitação.)

TD-er picture TD-er em 4 jun. 2018

Hoje, um nó para de responder novamente. Ele se desconectou do wi-fi. Não consegui me conectar à rede "esp". Ele parou de enviar dados para o controlador. Eu tive que reiniciá-lo. Talvez um cão de guarda seja uma boa solução. Se, por exemplo, uma hora for desconectado do wi-fi, ele reinicia. Ou talvez possa ser feito com regras, mas não sei como :)

melwinek picture melwinek em 9 jun. 2018

Hoje eu experimentei muitas ações de Watchdog enquanto depurava um plugin.
E eu sei agora que às vezes, quando o watchdog intervém, um nó pode permanecer parado.
Portanto, um cão de guarda não é a solução perfeita.

É possível que o seu nó suspenso nunca tenha sido reiniciado após o flash? (pressione reset ou desligue e ligue)

TD-er picture TD-er em 9 jun. 2018

É possível que não tenha ocorrido reinicialização após o flash. Mas foi um flashing via www, não um serial.

melwinek picture melwinek em 10 jun. 2018

OK, então não importa se você fez o flash OTA.
Contanto que tenha havido uma reinicialização / reinicialização adequada após o flash serial.

TD-er picture TD-er em 10 jun. 2018

Bem, depois de lutar contra muitos problemas de estabilidade e estranhos problemas de wi-fi com os últimos lançamentos de firmware, tive que voltar para as versões anteriores no final. Por exemplo, até que a queda de energia aconteceu recentemente, um nó ESP12E antigo com mega-20180311dev estava trabalhando por 70 dias, enviando dados de temperatura para ThingSpeak.
Em outro nó após a atualização para mega-20180522dev, eu estava tendo uma reinicialização devido à exceção a cada 24 horas, apesar de redefinir para os padrões, apenas executando sem qualquer dispositivo configurado, sem NTP configurado, sem controlador ... Nunca sobrevivi 48 horas. Após o downgrade para mega-20180324 dois dias e meio atrás, manteve a configuração, apenas habilitei o NTP novamente e até agora ele está funcionando. Embora existam alguns bugs e recursos ausentes nessas versões mais antigas, para mim é atualmente a melhor escolha.

ghtester picture ghtester em 4 jul. 2018

Não há muito que alguém possa fazer se os problemas não forem reproduzíveis de forma confiável.
O que ajuda um pouco é agendar uma reinicialização todas as noites. Você pode usar as regras para isso.

s0170071 picture s0170071 em 4 jul. 2018

Eu sei, mas prefiro um nó estável sem reinicializações programadas. Não sei se a estabilidade diminuiu significativamente devido à mudança para o núcleo 2.4.1 (talvez que ainda não esteja maduro o suficiente) ou se está relacionado ao redesenho do ESP Easy, mas aconteceu apesar do esforço máximo de todos os contribuidores do ESP Easy. Eu realmente aprecio o trabalho árduo de todos vocês, mas atualmente não posso mais usar os últimos lançamentos do ESP Easy.

ghtester picture ghtester em 4 jul. 2018

Acho que também está relacionado ao plug-in usado ou talvez à combinação de plug-ins.

Na semana passada, trabalhei analisando os efeitos dos timings e tenho certeza de que isso terá um efeito significativo nas tarefas de tempo crítico.

Acabei de olhar alguns dos meus nós, todos executando compilações oficiais:

Nome de arquivo binário ESP_Easy_mega-20180513_normal_ESP8266_4096.bin

Unidade 3

  • Tempo de atividade 16 dias 18 horas 26 minutos
  • 5d23h07m conectado
  • Último motivo de desconexão (201) Nenhum AP encontrado
  • Número reconecta 2

Unidade 5

  • Tempo de atividade 11 dias 5 horas 22 minutos
  • 5d22h57m conectado
  • Último motivo de desconexão (201) Nenhum AP encontrado
  • Número reconecta 4

Unidade 6

  • Tempo de atividade 11 dias 5 horas 23 minutos
  • Conectado 45 m 1 s
  • Último motivo de desconexão (201) Nenhum AP encontrado
  • Número reconecta 58

Nome de arquivo binário ESP_Easy_mega-20180619_test_ESP8266_4096.bin

Unidade 7

  • Tempo de atividade 13 dias 20 horas 51 minutos
  • 5d23h05m conectado
  • Último motivo de desconexão (202) Falha de autenticação
  • Número reconecta 2

Há cerca de 6 dias, tive alguns problemas com um dos meus pontos de acesso WiFi, que tive de reiniciar.

A unidade 6 está conectada ao mesmo que as unidades 3 e 7, mas tem muito mais conexões reconectadas.
Essas 3 unidades estão próximas uma da outra, a um metro uma da outra para comparar diferentes sensores de CO2 (MH-Z19 A, B e SenseAir S8) e todos alimentados pela mesma fonte de alimentação (carregador USB de 3 portas IKEA).

A única diferença entre eles é que aquele com mais reconexões possui o sensor Senseair.
Portanto, pode ser que a implementação desse sensor coloque mais pressão na rotina WiFi (menos chamadas de atraso), o que pode levar à instabilidade do WiFi.

Você poderia dar uma lista de plugins usados?
Também fiz uma solicitação de pull ontem que registra muitas estatísticas de tempo. Talvez você possa fazer uma compilação baseada nela e executá-la por alguns minutos para ter uma ideia dos plug-ins usando muito tempo.

TD-er picture TD-er em 4 jul. 2018

Estou sempre usando as compilações oficiais, pois não sou capaz de preparar e manter o ambiente de desenvolvimento para esses dispositivos.
A versão mencionada mega-20180522dev, como descrevi acima, era uma configuração completamente vazia, então absolutamente nenhum plug-in usado, nenhuma regra, eu até apaguei o controlador Nr1 padrão no final. Nada poderia impedir a reinicialização do nó devido à exceção em intervalos de cerca de 24 a 40 horas.

ghtester picture ghtester em 4 jul. 2018

Não sei se é problema de wi-fi - não parece, eu consegui definir endereços IP estáticos para wi-fi, mas espeasy ainda buscá-lo por dhcp e definir diferente.

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 picture uzi18 em 4 jul. 2018

@ uzi18 Você definiu todos os campos para configuração de IP estático?

Em caso afirmativo, infelizmente é um problema conhecido (para mim), onde há alguma sessão anterior armazenada em uma região onde (ainda) não apagamos dados em uma redefinição de fábrica.
Isso significa que, neste momento, não há outra maneira a não ser limpar todo o flash e começar novamente com uma versão recente do ESPeasy.
As versões posteriores definem um valor para não tornar as configurações de wi-fi persistentes.

TD-er picture TD-er em 5 jul. 2018

@ TD-er Sim, todos os dados preenchidos - como você vê no log.
Eu abri um NOVO módulo, com
INFO: Plugins: 71 [Normal] [Testing] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3)
e funciona assim.
O módulo só foi tirado da bolsa original e exibido, especialmente nunca antes aqui.

uzi18 picture uzi18 em 5 jul. 2018

@ TD-er: Duas reflexões sobre isso:

  1. Meu aquecimento não ESPEasy para o transmissor MQTT está funcionando perfeitamente usando o cliente pubsub mais recente. Reconecta e assim por diante. Talvez a vigilância da conectividade ESPEasy esteja interferindo no que já foi feito pela biblioteca central. Devemos ter uma maneira de desabilitar todas essas coisas adicionais de ping-reconnect-wifistate? Apenas para teste?
  2. Você está ciente do desligamento automático do wi-fi? https://blog.creations.de/?p=149
s0170071 picture s0170071 em 5 jul. 2018

Seria bom se alguém com wi-fi instável pudesse testar este PR: https://github.com/letscontrolit/ESPEasy/pull/1562

TD-er picture TD-er em 12 jul. 2018

@ TD-er acabou de tropeçar em https://github.com/esp8266/Arduino/pull/4718
lida com problemas de reconexão lwip. Entretanto, foi corrigido. Talvez você queira pular isso ...

s0170071 picture s0170071 em 13 jul. 2018

Eu sempre uso a versão mais recente do GIT do esp8266 .. é por isso que provavelmente não vejo mais o problema 0.0.0.0 ...

clumsy-stefan picture clumsy-stefan em 13 jul. 2018

Ontem novamente um nó após a reinicialização do roteador perdeu contato com a rede.
As regras funcionaram corretamente.
Este é o meu próprio interruptor de parede, é difícil desmontá-lo para reiniciá-lo.

Para facilitar isso no futuro, modifiquei as regras:

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

Agora a vida será mais simples :))

melwinek picture melwinek em 18 jul. 2018

Eu reinicio a cada 24h. Isso revive um nó com um firmware de 4 semanas atrás, duas vezes por semana.
Talvez isso devesse ser um recurso permanente ...

s0170071 picture s0170071 em 18 jul. 2018

Isso ainda é um problema? Em caso afirmativo, reabra.

Grovkillen picture Grovkillen em 25 out. 2018

Nosso tópico mais longo na lista de problemas ....

TD-er picture TD-er em 25 out. 2018
Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

Barracuda09 picture Barracuda09  ·  5Comentários
jobst picture jobst  ·  5Comentários
SANCLA picture SANCLA  ·  4Comentários
ronnythomas picture ronnythomas  ·  3Comentários
ghtester picture ghtester  ·  3Comentários