Je ne peux vraiment pas en parler au niveau de la programmation, mais il me semble d'après ce que j'ai vu qu'à l'exception de l'adresse IP statique, lors de la configuration d'une unité "tout neuve", le wifi semble fonctionner amende. Je n'ai vu aucun problème de connexion avec les installations "fraîches" avec les derniers firmwares. Les pages Web se chargent rapidement et tout semble rapide et réactif. C'est lorsque vous essayez de mettre à niveau que la plupart de ces problèmes semblent se produire. On dirait qu'il y a un problème de corruption lors de la mise à niveau vers un firmware plus récent.

Je remarque également qu'il semble que de nombreux firmwares compilés par les utilisateurs rencontrent des problèmes de wifi. Rien qu'en lisant tous ces articles, j'ai cette impression. Je peux me tromper complètement à ce sujet cependant. Je n'essaie pas de dire cela comme un fait, mais juste une possibilité.

Je ne peux pas parler à MQTT car je ne l'utilise pas.

Juste ma valeur de 2 cents.....

Budman1758 le 23 avr. 2018

Si vous penchez pour l'option 3, je vous soutiens pleinement. Je détesterais nous voir abandonner les améliorations que votre WiFi basé sur des événements nous a apportées. Core 2_4_x pourrait-il être plus facile de revenir en amont ?

Grovkillen le 23 avr. 2018

👍1

Du point de vue d'un utilisateur :
J'irais de l'avant et utiliserais le nouveau Core 2.4.1 dès que possible.
Les utilisateurs peuvent toujours utiliser des versions plus anciennes.

DittelHome le 23 avr. 2018

❤1 👍1

N'oubliez pas, le core 2.4.x corrige quelques problèmes :
Le scintillement PWM est de l'histoire ancienne (#1156 est corrigé avec le noyau 2.4.0)
Les numéros de série avec de gros paquets sont également corrigés...
À un moment donné, nous devons faire la transition vers le nouveau noyau. Revenir à 2.3.0 signifie uniquement reporter le problème. En fin de compte, nous devons faire le travail de toute façon. Mes ESP sont nettement meilleurs avec la 2.4.0

DittelHome le 23 avr. 2018

👍2

À mon avis, le noyau 2_4_x arrivera mais peut-être pas nécessaire pour le moment. Nous avons pris une mauvaise décision en allant de l'avant avec la mise à jour principale et l'approche basée sur les événements wifi en même temps. Nous aurions dû les faire l'un après l'autre. Lorsque nous avons ensuite, en même temps, eu une mise à jour dans les paramètres globaux, le problème est devenu exceptionnellement difficile à cerner. Je soutiens fortement l'idée de revenir à 2_3_0 lors de la correction de la stabilité wifi + correction de la corruption des paramètres.

Après cela, nous pouvons, espérons-le, publier la version 2.1.0, puis nous concentrer sur la stabilité du noyau 2_4_x pour la version 2.2.0.

Grovkillen le 23 avr. 2018

👍2

Après avoir effacé les paramètres et téléchargé la version du 22.04. Jusqu'ici tout fonctionne. Du moins pour l'instant :) Seule la mémoire libre ne suffit pas, même en NORMAL. On verra comment ça va se passer.

melwinek le 23 avr. 2018

Je suis d'accord avec @Budman1758 et @melwinek : j'ai également trouvé qu'à partir d'une unité propre, il n'y a aucun problème avec le Wifi, l'IP statique et les paramètres.
Le principal problème est le fait que pour mettre à niveau, je dois maintenant nettoyer manuellement toutes les unités, les reflasher et reconstruire leur configuration.

giig1967g le 23 avr. 2018

👍2

Je suppose que nous ne devons pas oublier qu'officiellement, nous sommes toujours en train de passer de la R120 stable à la version 2.1.0 stable et que les paramètres ne seront pas convertis entre ces deux versions, ce qui vous obligera à repartir de zéro de toute façon. Ce que nous avons fait avec la mise à jour du noyau 2_4_x, c'est de créer à nouveau un "point d'arrêt". Si nous pouvons vivre avec cela, ce n'est pas un problème. Je suis d'accord qu'une installation propre est vraiment stable (du moins sur NORMAL, que je teste le plus souvent). Et NORMAL est la seule partie qui sera réellement dans la version, le test et le développement ne sont de toute façon que dans la version de développement nocturne.

Grovkillen le 23 avr. 2018

Ce que je veux dire, c'est que si le firmware développé actuellement fonctionne et est stable sur une configuration propre, cela signifie qu'il n'y a rien de mal à cela. Je ne reviendrais pas à 2.3 ou à l'ancien wifi.

giig1967g le 23 avr. 2018

👍1

Oui je vous entends et je suis plutôt d'accord. La seule chose est que nous créons un autre point d'arrêt, ce qui, je suppose, est correct puisqu'il est encore en version bêta.

Grovkillen le 23 avr. 2018

👍1

Bien que ce soit un retour en arrière que je n'aime pas, je crains qu'il ne soit vraiment préférable de revenir au noyau 2_3_0 pour l'instant car je pense que des problèmes étranges peuvent survenir en raison d'un manque de mémoire libre sur 2_4_0.

ghtester le 23 avr. 2018

@ giig1967g Je suis d'accord avec toi là-bas. Je pense cependant qu'il y a des problèmes de corruption. C'est peut-être ce qui gâche le wifi par rapport à ses nombreux problèmes inhérents.

Budman1758 le 23 avr. 2018

Il existe encore des options pour obtenir une utilisation de la mémoire à un niveau acceptable.
Je pense que je peux obtenir environ 3 à 4 Ko de mémoire de plus en 1 soirée de programmation. (besoin de changer tous les fichiers de plugin cependant)
Et l'importation MQTT est également quelque chose qui est vraiment une douleur qui devrait être résolue bientôt.
Et le plugin Switch a lui-même trop de fonctionnalités qui devraient être divisées.

Je vais y réfléchir aujourd'hui, ce que nous devrions faire, alors s'il vous plaît ajouter plus de suggestions/arguments :)

TD-er le 23 avr. 2018

👍1

@TD-er Vous avez raison avec SWITCH.
La plupart des gens n'utilisent que ON / OFF pour le commutateur / le relais.
Et dans ce plugin, il y a un servo, un gradateur et probablement quelque chose.
Cela pourrait être séparé.

melwinek le 23 avr. 2018

Il gère également des choses très spécifiques à MQTT et/ou Domoticz. Cela ne devrait pas faire partie du plugin.

TD-er le 23 avr. 2018

@TD-er Dans de nombreux cas, cela m'aiderait à me compiler, après avoir supprimé les plugins inutiles, dans de nombreux cas, je n'ai besoin que de SWITCH, FHEM Controller, DHT.
Mais après ces aventures avec les réglages j'ai peur de me compiler. Surtout après ton post : https://github.com/letscontrolit/ESPEasy/issues/1292

melwinek le 23 avr. 2018

Avez-vous regardé comment le wifi est réalisé dans d'autres projets (par exemple tasmota) ?

A propos de la mémoire : je te l'ai dit :sourire:
Je pense qu'il y a beaucoup trop de fonctionnalités rarement utilisées dans le noyau - la décision, si une demande de fonctionnalité de base est implémentée, devrait être beaucoup plus stricte - maintenant c'est un peu comme Noël pour tout le monde...
Peut-être qu'un vote avec une certaine limite aiderait.

Si possible, le noyau doit d'abord être nettoyé de ces fonctionnalités rarement utilisées (ou transformé en plugin), puis optimisé. En outre, on pourrait penser à des interfaces supplémentaires pour les plugins, pour permettre d'échanger plus de fonctionnalités en dehors du noyau.

M0ebiu5 le 23 avr. 2018

@M0ebiu5 D'accord.
Ce qui devrait arriver, c'est que les nouvelles fonctionnalités seront développées sur une branche distincte, puis en collecter quelques-unes et les fusionner dans une branche release candidate et les tester.
Ensuite, libérez et fusionnez les fonctionnalités utilisées dans la branche master (ou branche dev, ou quel que soit votre nom).

Et une chose que j'ai apprise est de demander deux fois ce qui est observé, ce qui devrait être observé et quelle version est utilisée. Cela rendra les choses beaucoup plus claires et conduira à moins d'erreurs.
Une partie de cela doit être fait dans le code lui-même pour créer une sorte d'empreinte permettant de voir (et de consigner) quel logiciel est utilisé.

De plus, les plugins devraient être juste des plugins pour interfacer un capteur avec certaines valeurs de sortie.
Peut-être que les plugins qui génèrent une sortie (comme les affichages) ne devraient pas être utilisés de la même manière que ceux d'entrée.
On obtient donc quelque chose comme :

Capteur pour lire un appareil et générer des mesures
Sortie (affichage ?) pour présenter les valeurs. Cela peut aussi être autre chose qu'un affichage, par exemple JSON ou une image.
Contrôleur pour interfacer avec le monde extérieur (entrée et sortie)
Règles de traitement des données et des événements.
Notifications pour convertir les événements en autre chose. En fait, cela ressemble à un contrôleur plus élaboré.
Commandes pour effectuer une configuration de base ou des modifications/mises à jour temporaires (non persistantes) et effectuer certaines actions (par exemple, redémarrer)
Page Web pour les configurer tous.

Mais une telle refonte demandera pas mal d'efforts.

TD-er le 23 avr. 2018

@TD-er vous avez raison, mais je ferais les changements par petites étapes - car la plupart des pièces fonctionnent de manière stable et de gros changements pourraient mettre cette stabilité en danger.

De nouvelles interfaces vers le noyau sont une voie possible. Ils n'influenceront pas le comportement actuel et seuls les plugins nouveaux ou fortement modifiés les utiliseront. Il faudra plus de temps pour se transformer en une architecture propre, mais avec un risque moindre et l'effort sera également étalé dans le temps.

M0ebiu5 le 23 avr. 2018

Je suis d'accord que ces changements devraient être faits à l'aise.
Il s'agit plutôt d'une vue sur la refonte pour l'avenir.

TD-er le 23 avr. 2018

Cependant, le nœud du 22.04 a perdu la connexion.
La réinitialisation du routeur n'aide pas.
La réinitialisation de l'ESP aidera, mais je suis loin.
Ainsi, la meilleure version sur mes nœuds est mega-20180410.
Peut-être parce que c'est sur le core 2.3 ?
Peut-être, cependant, une bonne solution serait-il de revenir à 2.3 pendant un certain temps ?

melwinek le 24 avr. 2018

Non, hier soir, j'ai vu le problème (dans le code et se produisant dans mes propres unités).
Mes nœuds ne se sont pas reconnectés lorsqu'ils ont reçu une erreur de « délai d'expiration de la balise », ce qui est une raison assez courante pour se déconnecter. C'est une erreur logique dans le code, mais il était déjà plus de 1h30 du matin et je ne voulais pas la corriger à ce moment-là. Il aurait certainement été plus que temps de construire la nuit pour le réparer, alors cela n'avait plus d'importance ;)

TD-er le 24 avr. 2018

👍2

lié: #1064

s0170071 le 25 avr. 2018

Je viens de flasher 6 appareils avec la version actuelle ESP_Easy_mega-20180425_test_ESP8266_4096.bin.

Je pense qu'avec cette version, nous avons atteint un point bas absolu.
Tous les appareils n'étaient pas joignables sur le réseau après quelques heures.

micropet le 25 avr. 2018

C'est pourquoi je vais -d'une manière ou d'une autre- revenir à une version wifi fonctionnelle.

Peut-être devrions-nous également supprimer la version d'aujourd'hui, juste pour empêcher les autres de charger la même chose.

TD-er le 25 avr. 2018

Je suggérerais de construire maintenant une nouvelle version 04.25 sur le noyau 2.3.0 et de remplacer l'actuelle :)

melwinek le 25 avr. 2018

Je n'ai pas le contrôle sur le serveur de build.
et 2 versions avec le même numéro de build n'est jamais une bonne idée.

Je sais que @Grovkillen peut supprimer la version d'aujourd'hui.

TD-er le 25 avr. 2018

Vous pensez que je devrais le supprimer @TD-er ? Un nouveau sera construit demain.

Grovkillen le 25 avr. 2018

Apparemment, c'est encore pire par rapport à la construction d'hier.
Alors oui, enlevez-le.

TD-er le 25 avr. 2018

Fait

Grovkillen le 25 avr. 2018

Et platformio.ini est également modifié.
Donc quoi qu'il arrive, la construction de demain ne sera pas aussi mauvaise que celle d'aujourd'hui.

TD-er le 25 avr. 2018

Je sens la panique ici. Ne vous inquiétez pas, il y a encore de l'espoir.
Tout d'abord, prenons une :beer: ou :beers: Maintenant,
merci @TD-er d'avoir pris d'assaut malgré vos inquiétudes, merci @Grovkillen de l' avoir soutenu. Merci aussi à tous les autres. Et merci à tous d'avoir discuté de nouvelles idées si ouvertement.

Ceci étant dit, permettez-moi de dire ceci :

D'après mon expérience, il n'y a rien de mal avec les nouvelles versions de base, à l'exception de la 2.4.1 qui a une fuite de mémoire wificlient (et une solution de contournement).
Les anciennes versions de la branche master jusqu'au moment où il y a eu une décision d'abandonner la 2.0 fonctionnaient de manière assez stable avec ces versions de base. Et vite.
Nous devrions vraiment (nous insistons sur vraiment !) nous concentrer sur la stabilité. Pas de nouvelles fonctionnalités pendant un certain temps (à moins d'améliorer la stabilité) moins d'ESP32 et moins de recherche de mémoire, moins d'accélération moins tout sauf la stabilité. Imaginons que nous prévoyions de voler vers la lune. Pour de vrai. Cette chose doit fonctionner. Il doit tolérer les pannes d'un seul bit, les redémarrages, les fluctuations de puissance et les contraintes de température.
Je veux dire la programmation à tolérance de panne. C'est fait. Cela peut être amusant si vous y réfléchissez.

Et après ? Si j'étais un développeur principal, j'opterais pour cette configuration basée sur json. Au plus vite. On dirait que la racine actuelle du mal, tout comme le serveur Web gourmand en mémoire l'était il y a quelque temps.

s0170071 le 25 avr. 2018

Je sens la panique ici. Ne vous inquiétez pas, il y a encore de l'espoir.
Tout d'abord, ayons un ou 🍻 Maintenant,
merci @TD-er d'avoir pris d'assaut malgré vos inquiétudes, merci @Grovkillen de l' avoir soutenu. Merci aussi à tous les autres. Et merci à tous d'avoir discuté de nouvelles idées si ouvertement.

100% d'accord !!!

Je ne sais pas si cette erreur est déjà connue :
Après un ou deux jours, il semble que le serveur Web ne fonctionne plus. La publication MQTT fonctionne toujours.
J'utilise la version normale du 04.22.

DittelHome le 25 avr. 2018

@TD-er personnellement, je voterai pour quelque chose de nouveau comme 2.4.1 à essayer.

uzi18 le 25 avr. 2018

1+

micropet le 25 avr. 2018

1+

susisstrolch le 25 avr. 2018

Je sens la panique ici. Ne vous inquiétez pas, il y a encore de l'espoir.

Ce n'est pas de la panique, c'est de la pure frustration ;)
Le fait est que je teste vraiment des trucs ici et en quelques minutes (au moins c'est comme ça), les builds échouent encore pire qu'avant.
Je suis habitué à programmer contre des boîtes noires, et aussi rev. concevoir ces boîtes noires.
Mais cela donne l'impression que les commentaires que je pense voir dans les journaux sont complètement différents de la réalité.
Maintenant, il est clair qu'il y a eu plusieurs problèmes au cours des dernières semaines, en raison de bogues dans les bibliothèques principales, de paramètres corrompus et de quelques modifications que j'ai apportées semblaient être liées à certains bogues dans le micrologiciel AP.

Et mon opinion personnelle sur le logiciel est qu'il doit être stable comme un roc et que la vitesse vient en second.
Mais les semaines dernières, l'augmentation de la vitesse est OK, mais la stabilité se détériorait de jour en jour, peu importe ce que j'essayais.

Alors maintenant, le temps est venu de faire une halte ferme et de se concentrer d'abord sur la stabilité. Vous pourriez appeler cela « de la panique », mais en fait, c'est une sorte de recul pour vraiment se concentrer sur ce qui se passe.
J'en sais maintenant beaucoup plus sur le wifi qu'il y a un mois, donc je devrais pouvoir faire un package bien conçu. Mais cela prend du temps et je veux vraiment atteindre un certain point de stabilité et avoir un moment d'aisance dans ma tête pour que cela fonctionne comme il se doit.
Et puis il y a encore beaucoup de place pour rendre les choses encore plus rapides, car j'ai vu ik se connecter encore plus rapidement :)
Mais c'est pour la prochaine version.

À propos du reste des principaux problèmes :

utilisation de la mémoire
Importation/exportation JSON des paramètres
Refonte de l'importation MQTT
certains plugins comme P001-switch devraient être modifiés.
Ce qui reste.

TD-er le 25 avr. 2018

❤1

pour moi (et probablement juste pour moi) le passage à la 2.4.1 ou même à GIT Core ne s'est pas amélioré, c'était le contraire. J'ai essayé environ 20 combinaisons différentes de versions de base, mage-commits et lwIP. Revenir à 2.3.0, en particulier à lwIP 1.4, était le seul moyen de le rendre stable. Mais encore une fois, juste ma vision de cela dans mon environnement spécifique...

Et oui, un grand merci @TD-er et @Grovkillen pour l'excellent travail qu'ils font et le temps qu'ils investissent pour la communauté !

clumsy-stefan le 25 avr. 2018

👍1

Merci à tous, @TD-er résume assez bien la route à suivre.

À propos du reste des principaux problèmes :
• utilisation de la mémoire
• Importation/exportation JSON des paramètres
• Refonte de l'importation MQTT
• certains plugins comme P001-switch devraient être modifiés.
• Ce qui reste.

Et nous allons revenir à la version 2.3.0 pour la version de demain et tester cela pendant un certain temps.

Grovkillen le 25 avr. 2018

La plupart de mes images d'auto-construction sont basées sur la version principale de la version Rev. 491c9b8b (2.4.1 + x).
La seule chose que je vois, ce sont des redémarrages aléatoires avec mon appareil Sonof 4ch. Malheureusement, cela fait partie de mon contrôle de bassin, donc aucune chance de connecter une interface série pour une meilleure surveillance, Syslog est assez inutilisable, car les informations pertinentes sont crachées avant que le WIFI ne soit opérationnel.

C'est assez utilisable - tant que vous utilisez la bibliothèque lwIP 'v2 Higher Bandwith'.
Sinon, vous verrez des problèmes de fragmentation MTU avec des packages > 512 octets (hors service, avec des informations de fenêtre incorrectes).

Les ESPEasy Revs qui fonctionnent (mes repos) sont

commettre 3576619181926b3adff5a1a133390eb71e808ae9
Fusionner : 9038bd2 d083a58
Auteur : Susis Strolch
Date: ven 13 avr 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

et
commettre daf39a064d3633fe1eccfa33576fafbccd7611a7
Fusionner : 2a96218 806a275
Auteur : Susis Strolch
Date: Lun 9 Avr 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)

Tout ESPEasy après le vendredi 13 avril montre des résultats horribles - parlants qui ne fonctionnent pas -, même lors de l'effacement de l'intégralité du flash avant de flasher le binaire (via Arduino IDE).

Donc, je suggérerais d'aller avec 2.4.1 (ou plus tard) et de polir ESPEasy (WIFI et config).
Le noyau lui-même semble être ok jusqu'à présent.

susisstrolch le 25 avr. 2018

lol @Vendredi 13, un jour de malchance en effet..
Alors qu'est-ce que le "polish ESPEasy (WIFI et config)." ?
Une branche différente..?
Pologne aka polonais ou polonais comme dans buff & shine, ha

Oxyandy le 26 avr. 2018

😄1 👎1

@susisstrolch Comment
"problèmes de fragmentation MTU avec des packages > 512 octets (hors service, avec des informations de fenêtre incorrectes)."

Oxyandy le 26 avr. 2018

Envoyez simplement une demande préparée pour le serveur Web espeasy, avec un en-tête supplémentaire avec un minimum de 512 caractères

uzi18 le 26 avr. 2018

👍1

@Oxyandy : en exécutant tcpdump sur mon serveur FHEM et en analysant avec WireShark, j'ai trouvé que les 512 derniers octets d'une réponse JSON d'environ 700 octets étaient envoyés en premier, suivis de l'en-tête HTTP.
Et ces deux packages manquaient simplement les informations de la fenêtre TCP.
Peut envoyer plus de détails sur demande...
polir comme dans buff & shine

susisstrolch le 26 avr. 2018

👍1

Pour moi, la version du 22.04.2018 avec Core 2.4.1 fonctionne assez bien.
sysinfo

micropet le 26 avr. 2018

Pourriez-vous également vérifier mon travail d'hier, mais construit ensuite sur 2.4.1 ?
https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability

Dans la version 2.3.0, j'avais toujours des problèmes avec l'adresse IP statique.
Je n'ai pas encore testé le mode AP avec la page de configuration.

TD-er le 26 avr. 2018

Je viens de flasher un wemos avec ta version
[wifi] Tenter de simplifier le wifi basé sur les événements).

La version court.....

Qu'est-ce que je devrais faire maintenant?

micropet le 26 avr. 2018

Merde, d'après mon dernier test (22.04.1018), 4 appareils sur 8 ont raccroché après environ 7 heures.

micropet le 26 avr. 2018

Je suppose qu'il n'y a pas de log ? :(
Les nœuds se sont-ils plantés (se bloquent) ou ne se sont tout simplement pas reconnectés ?
Répondent-ils au ping, et donc seul le serveur web est désactivé ou trop occupé (la reconnexion MQTT prend beaucoup de ressources) ?

TD-er le 26 avr. 2018

Pendant ce temps, accrochez 5 appareils.
Je n'ai pas de journal. Le serveur Web n'est pas accessible. Ping ne fonctionne pas non plus.

ils sont juste morts.

micropet le 26 avr. 2018

Vous devriez vraiment essayer de le connecter. Cela pourrait nous donner des conseils utiles

Grovkillen le 26 avr. 2018

J'enregistre la version de Gijs. Il tourne depuis 55 minutes maintenant. :)

micropet le 26 avr. 2018

oh, je peux battre ça ! J'ai 12 appareils fonctionnant entre 45 et 263Min sur la version Gijs (avec le noyau esp de GIT) 😀 et toujours tous heureux...

clumsy-stefan le 26 avr. 2018

Oui, les temps ont changé.
Dans le passé, mes appareils fonctionnaient pendant des semaines.

Aujourd'hui, je suis heureux quand ils travaillent quelques heures. :)

micropet le 26 avr. 2018

😄1

L'un de mes appareils à la maison exécute toujours la version que j'ai créée en 20171231 et passe à 60 jours de disponibilité aujourd'hui.

Alors je sais ce que tu veux dire :(

TD-er le 26 avr. 2018

Prenons ensuite la version 2017123, puis nous pourrons nous concentrer sur d'autres choses. :)

micropet le 26 avr. 2018

👍1

micropet le 26 avr. 2018

Hé, pourquoi ne pas prendre cette version de 60 jours, la marquer avec 2.0 et écrire quelques puces sur les problèmes connus (pas de fonctionnalités manquantes)

s0170071 le 26 avr. 2018

👍2

@s0170071 avons-nous vraiment besoin d'un produit fonctionnel à 75 % et de nombreux problèmes résolus après la sortie ?

uzi18 le 26 avr. 2018

Peut-être n'y a-t-il pas besoin de revenir en arrière si loin... Ceci provient du dernier redémarrage manuel :

Disponibilité : 21 jours 3 heures 32 minutes
Charge : 32 % (CL=6281)
Mémoire libre : 14328 (13392 - parseTemplate3)

ghtester le 26 avr. 2018

6 appareils fonctionnent depuis 5 heures - un nouveau record.

micropet le 26 avr. 2018

Cela fait déjà plus de 30 heures ;)

TD-er le 26 avr. 2018

J'ai maintenant presque tous les appareils (12+) fonctionnant sur les modifications de @TD-er depuis tonigt. Tous les Wemos D1 Mini avec une variété de capteurs et de relais attachés (tous différents). La plupart d'entre eux ont maintenant plus de 10h de disponibilité. Je vais flasher les derniers aussi maintenant.
J'ai eu deux ou trois redémarrages spontanés à partir d'un ou deux appareils, mais cela peut aussi provenir de plugins ou de capteurs défectueux (j'utilise également des plugins de développement et j'ai même modifié la configuration pour prendre en charge 24 tâches et utiliser le noyau esp GIT, certains même sans effacer le configuration en premier). Mais ils sont toujours revenus et connectés au réseau avec succès !

C'est donc pour moi la version la plus stable que j'ai eu jusqu'à présent. similaire à ce que j'avais avant le noyau 2.4.0.

Par conséquent, je voterais pour fusionner les modifications de @TD-er à partir de ce soir, les tester et passer à autre chose... Mais ce n'est que MHO...

Et merci à @TD-er pour la correction rapide du bug (essayez) !! Pour moi ça a marché !!

clumsy-stefan le 26 avr. 2018

👍1

J'ai également eu un redémarrage sur un appareil, mais il s'est reconnecté immédiatement.
Tous les appareils sont des Wemos D1 mini.

J'ai exécuté la version de test ici avec 71 plugins.
Sur les appareils se trouvent presque uniquement des BME280, Pir, MH-Z19 et un capteur de poussière et quelques Leds.

Le serveur Web réagit très rapidement.
Pour le moment je suis très satisfait de cette version et du Core 2.4.1.

micropet le 26 avr. 2018

Peut-être que c'est déjà connu (si c'est le cas, veuillez l'ignorer)
J'ai installé un ESP pro mini avec ESP_Easy_mega-20180422_normal_ESP8266_4096.bin (core 2.4.0).
Il tourne depuis 3 jours !
L'interface graphique n'est plus accessible, uniquement après un démarrage à froid. (teste avec un autre esp)
Le ping est ok, le travail de publication de mqtt également, le commutateur GPIO sur http fonctionne également.
Le "seul" problème, l'interface graphique n'est pas accessible.
En d'autres termes, l'ESP fonctionne en aveugle, tout va bien, seule l'interface graphique ne répond pas.
Après avoir tapé l'adresse IP dans le navigateur, obtenez :

ily : sans empattement ; taille de la police : 12 pt ; marge : 0px ; remplissage : 0px ; dimensionnement de la boîte : boîte de bordure ; }h1 {taille de la police : 16pt ; couleur : #07D ; marge : 8px 0 ; font-weig190 ; couleur : #07D ; }.button {marge : 4px ; rembourrage : 4px 16px ; couleur d'arrière-plan : #07D ; couleur : #FFF ; texte-décoration : aucun ; rayon de bordure : 4px ; frontière : 190 190 ative ; curseur : pointeur ; taille de la police : 12 pt ; -webkit-user-select : aucun ; -moz-user-select : aucun ; -ms-u

J'ai activé la journalisation avec mon deuxième appareil après un redémarrage à froid, une fois que l'appareil ne répondra plus, le journal sera signalé ici, si vous le souhaitez.

DittelHome le 26 avr. 2018

Pourriez-vous également enregistrer l'utilisation de la mémoire ? Juste pour voir s'il y a une fuite de mémoire dans la 2.4.1 comme signalé par certains.

TD-er le 26 avr. 2018

Oui, exactement la même chose que j'ai avec la version du 22.04.2018.
L'appareil fonctionne mais le serveur Web n'est pas accessible.

micropet le 26 avr. 2018

Je vais essayer de l'enregistrer.
Semble constant.

Mémoire libre : | 9792 (9008 - sendContentBlocking)

micropet le 26 avr. 2018

Tu veux dire sysheap ?

unbenannt

micropet le 26 avr. 2018

@uzi18 vous ne pouvez pas avoir les deux, la pointe et la stabilité. La version 60 jours est stable, non ?

s0170071 le 26 avr. 2018

@TD-er Si vous laissez la fenêtre Règles ouverte pendant quelques minutes, toutes les règles disparaîtront.

micropet le 26 avr. 2018

C'est avec 2.3.0?

TD-er le 26 avr. 2018

j'ai 2.4.1

micropet le 26 avr. 2018

Salut,
Je teste 20180426. Fonctionne mais c'est vraiment lent par rapport à 20180424.
Pour moi, le core 2.4.0 fonctionnait parfaitement bien et stable.
Avec la nouvelle version, MQTT a pris plus d'une minute pour se connecter tandis que la version précédente était la moitié du temps.
Suis-je simplement chanceux avec le noyau 2.4.0 ? Ou c'est juste une question de configuration ?

giig1967g le 26 avr. 2018

Je trouve la version de @TD-er d'hier avec Core 2.4.1 extrêmement rapide.

Après la mise sous tension, il ne faut que quelques secondes pour atteindre l'interface web.
Les messages MQTT arrivent immédiatement.

micropet le 26 avr. 2018

juste pour les intéressés. Je suis le suivi du processeur, de la mémoire et du RSSI. Ci-joint un graphique de toutes les unités. Vous pouvez clairement voir l'utilisation de la mémoire lorsque j'ai effectué la mise à niveau vers le noyau 2.4.x. Cependant, la mémoire semble être stable (par exemple pas de fuite)...
Les appareils 1-11 et 16 sont "en cours d'utilisation" avec des capteurs, etc. les autres sont simplement des D1 sans rien attaché.

clumsy-stefan le 26 avr. 2018

Salut @micropet : comment puis-je utiliser la version d'hier avec le core 2.4.1 ?

Je commence à penser que Wemos est peut-être plus stable que SONOS ?
j'utilise aussi Wemos

giig1967g le 26 avr. 2018

Avec:
https://github.com/TD-er/ESPEasy/commits/bugfix/wifi_stability
et dans platformio :
[core_2_4_1]
plateforme = [email protected]

micropet le 26 avr. 2018

@micropet et @TD-er : Je viens de compiler la branche de stabilité wifi avec le core 2.4.1.
WOW. Incroyable rapide.
Le laissera fonctionner pendant les 3 prochains jours et fera rapport. Il contient des règles assez complexes...
Pour l'instant : 7 secondes pour se connecter à MQTT contre 60 avec la version 2.3.0 20180426.

Je vois des reconnexions dans 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 le 26 avr. 2018

@ giig1967g Avez -vous une chance de créer un fichier bin pour que je puisse télécharger? version 4 Mo ? Toujours en train d'apprendre le processus de compilation...

Budman1758 le 26 avr. 2018

firmware.zip

micropet le 26 avr. 2018

👍1

@ giig1967g, comme je l'ai dit - extrêmement rapide et il semble également stable.

J'ai maintenant eu une reconnexion en 7 heures.

micropet le 26 avr. 2018

@ giig1967g L' exécution d'une adresse IP statique a toujours des problèmes avec mon nouveau code.
Surtout lors de l'exécution avec MQTT.
DHCP semble fonctionner correctement.

Demain va être une journée très chargée pour moi, car c'est le "Kingsday" et la famille royale sera à Groningue. Je suis également invité à être là pour -peut-être- parler au roi de nos problèmes ici.
Je vais donc aller me coucher maintenant et ma suggestion est de ne pas fusionner le code aujourd'hui avec la branche principale. Demain nous continuerons le développement et ferons le meilleur code de connexion wifi possible :)

TD-er le 26 avr. 2018

ok, j'ai trouvé un problème sur 20180426 (2.3.0) et WifistabilityBranch (2.4.1).
Si j'éteins le routeur puis le rallume, l'unité ne se reconnecte pas au Wifi malgré l'inscription en série "Wifi#Connected". L'unité fonctionne (série et règles ok) mais pas de connexion WiFi donc pas d'interface web.

giig1967g le 26 avr. 2018

@ TD-he, faisons ça. Salutations au roi - peut-être qu'il a une autre idée. :)
Et bonne nuit.

micropet le 26 avr. 2018

@TD-er : bonne chance avec tes vrais problèmes...

giig1967g le 26 avr. 2018

👍2

Certains ici, si je déconnecte le WIFI pendant 0,2 seconde :

29113846 : ACT : timerSet,1,60
29115651 : MQTT : Connexion perdue
29115652 : ÉVÉNEMENT : MQTT#Déconnecté
29115689 : MQTT : Échec de la connexion au courtier
29115690 : ÉVÉNEMENT : WiFi#Déconnecté
29115706 : WIFI : Déconnecté ! Raison : '(1) Non spécifié' Connecté depuis 8h04m <-------- !!
29116189 : MQTT : Échec de la connexion au courtier
29116939 : MQTT : Échec de la connexion au courtier
29117860 : WD : Uptime 485 ConnectFailures 6 FreeMem 16416
29117881 : MQTT : Échec de la connexion au courtier
29117938 : MQTT : Échec de la connexion au courtier
29119189 : MQTT : Échec de la connexion au courtier
29120689 : MQTT : Échec de la connexion au courtier
29120736 : DS : Température : 19,94 (28-ff-b8-ea-b4-16-3-ed)
29120738 : ÉVÉNEMENT : DS18b20#Température=19,94
29122440 : MQTT : Échec de la connexion au courtier
29124440 : MQTT : Échec de la connexion au courtier
29126441 : MQTT : Échec de la connexion au courtier
29128442 : MQTT : Échec de la connexion au courtier

micropet le 26 avr. 2018

@giig1967g
Vous pouvez rechercher la fonction pour démarrer/arrêter le serveur Web et ajouter un return; sur la première ligne de cette fonction.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585

Je suppose qu'il y a un problème avec l'appel de la fonction 'gotIP' lors de l'utilisation d'une adresse IP statique.
C'est aussi la raison de l'instabilité lors de l'exécution de MQTT + IP statique.

TD-er le 26 avr. 2018

Mais c'est probablement pour @ TD-er une bagatelle. :)

micropet le 26 avr. 2018

Hm, je ne regarde pas à travers.
Je pense que tu ferais mieux de faire ça demain.
De plus, je travaille ici avec DHCP.

micropet le 26 avr. 2018

Il me semble que la stabilité avec mon matériel est toujours "meilleure" (pas parfaite) avec les versions de base 2.3.0

essayé 2.4.0 & 2.41 -- ils sont pires...

0403 méga normal - semble juste fonctionner et versions antérieures ..
Toute personne ayant encore des problèmes comme moi peut essayer 0403 s'il vous plaît ..
@susisstrolch & @uzi18 - merci à tous les deux pour vos réponses .. J'ai une meilleure idée de la façon dont je peux voir les communications maintenant - l'adaptateur wireshark & usb wifi 2.4g fonctionnera, j'en ai beaucoup de rechange
Merci

Oxyandy le 26 avr. 2018

Le mien tourne depuis presque 17 heures maintenant. Connexion unique

Grovkillen le 27 avr. 2018

mise à jour depuis mes unités (nom|temps de disponibilité en minutes|dernier disque. raison|wifi connecté en ms) :
wemos_mini_01_sysinfo | 1220 | 200 | 6462869
wemos_mini_02_sysinfo | 1223 | 1 | 19359544
wemos_mini_03_sysinfo | 657 | 1 | 1018597
wemos_mini_04_sysinfo | 1078 | 201 | 439668
wemos_mini_05_sysinfo | 650 | 6 | 9194816
wemos_mini_06_sysinfo | 927 | 1 | 955432
wemos_mini_07_sysinfo | 1142 | 1 | 14078412
wemos_mini_08_sysinfo | 730 | 1 | 7848454
wemos_mini_09_sysinfo | 1005 | 1 | 5536489
wemos_mini_10_sysinfo | 550 | 201 | 465734
wemos_mini_11_sysinfo | 662 | 4 | 15658520
wemos_mini_12_sysinfo | 1211 | 1 | 17915701
wemos_mini_13_sysinfo | 1211 | 1 | 17896590
wemos_mini_14_sysinfo | 1210 | 1 | 17882406
wemos_mini_15_sysinfo | 753 | 1 | 58904600
wemos_mini_16_sysinfo | 1197 | 1 | 17210855

un redémarrage de l'unité 10 (pourrait également être lié aux plugins). toutes les unités avec contrôleur DHCP et FHEM ainsi que des mises à jour régulières de l'état JSON (appelées via HTTPMOD à partir de fhem).
serveur Web sur chacun d'eux toujours en cours d'exécution et très réactif. jamais utilisé static-ip ou setup-page cependant.

donc pour moi cela semble être une version plutôt stable.

comme je suis surtout hors ligne les 4 prochains jours, je verrai la semaine prochaine combien sont encore en vie

Oh, et salutations au roi ! J'espère qu'il aime aussi l'IoT 😀

clumsy-stefan le 27 avr. 2018

@clumsy-stefan cette version ? https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability
et quel noyau ?
As-tu essayé de redémarrer le routeur ?

melwinek le 27 avr. 2018

@melwinek git commit: d582cab938f041f622f2d4d8016b3d4bada55580 de la branche master esp8266 (donc le dernier commit sur la branche master du développement principal).

clumsy-stefan le 27 avr. 2018

@clumsy-stefan core 2.3.0, 2.4.0 ou 2.4.1 ?

melwinek le 27 avr. 2018

dernier commit GIT ! (donc je suppose que c'est le noyau 2.4.1+)

clumsy-stefan le 27 avr. 2018

Je ne trouve pas ce commit.
Le dernier est : https://github.com/letscontrolit/ESPEasy/commit/d780f1a07fdcd4eec394a0677866c2a9778eb696
Pouvez-vous fournir un lien?

melwinek le 27 avr. 2018

@clumsy-stefan Je comprends, vous avez écrit git au cœur.
Quel commit ESPEasy compilez-vous ?

melwinek le 27 avr. 2018

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

clumsy-stefan le 27 avr. 2018

@TD-er :

@giig1967g
Vous pouvez rechercher la fonction pour démarrer/arrêter le serveur Web et ajouter un retour ; sur la première ligne de cette fonction.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585
Je suppose qu'il y a un problème avec l'appel de la fonction 'gotIP' lors de l'utilisation d'une adresse IP statique.
C'est aussi la raison de l'instabilité lors de l'exécution de MQTT + IP statique.

Salut, le problème n'est pas le serveur Web, c'est l'unité qui semble connectée au Wifi mais ce n'est pas le cas. Impossible de ping, impossible d'envoyer MQTT, etc.

giig1967g le 27 avr. 2018

Le dernier github fonctionne parfaitement ici sur le noyau 2.4.1. Pas de problèmes de connexion, pas de fuites de membres

ghost le 27 avr. 2018

@mvdbro Utilisez-vous un périphérique esp32 ou esp8266 ?

weisskopfjens le 27 avr. 2018

J'utilise à la fois ESP8266 et ESP32. Les deux fonctionnent bien.

Note latérale :
Toujours utiliser une IP statique
Utiliser uniquement les plugins dont j'ai besoin (maintient la RAM à un minimum sûr. Je pense que l'ensemble par défaut a de nombreux plugins chargés)

ghost le 27 avr. 2018

👍1

Super! :le sourire:
J'essaye aussi le core 2.4.1 sur mon esp8266.
Statique et DHCP fonctionne.
DNSserver et portail captif fonctionne.
ntp fonctionne !

weisskopfjens le 27 avr. 2018

@Feuerreiter : avez-vous essayé d'éteindre et de rallumer le routeur pour voir si l'appareil se reconnecte ?
Dans mon cas, le journal dit qu'il s'est reconnecté mais ce n'est pas le cas.

giig1967g le 27 avr. 2018

@ giig1967g Je l'essayerais plus tard à la maison. J'ai fait le test dans ma voiture avec mon téléphone portable comme point d'accès. ;-)

weisskopfjens le 27 avr. 2018

@mvdbro

Je pense que l'ensemble par défaut a de nombreux plugins chargés

Je suis d'accord. Il devrait y avoir une présélection sur les plugins, ou peut-être une meilleure vérification sur chacun d'eux pour ne pas utiliser plus de mémoire que nécessaire lorsqu'il n'est pas utilisé.
Et il y a beaucoup de mémoire à gagner en regardant de près les grandes structures contenant des informations sur les plugins disponibles.

TD-er le 27 avr. 2018

[PlatformIO] Core mis à jour vers 2.4.1
1+

Je pense que c'est une bonne décision.
Je n'ai aucun problème depuis hier après-midi.

micropet le 27 avr. 2018

Comme je l'ai posté dans un autre fil :
Pour ceux qui ont besoin d'un peu d'aide pour construire, je viens de construire une version du patch que j'ai écrit il y a 2 jours, mais maintenant avec le core 2.4.1 :
TD-er_wifi_stability_core-2.4.1

TD-er le 27 avr. 2018

La mémoire reste assez constante.
Il coule un peu dans les 15 premières minutes.
(Ils ne doivent pas être vus ici)
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 le 27 avr. 2018

Pendant ce temps, 8 appareils fonctionnent depuis hier midi.
Aucun d'eux n'est resté coincé.

L'un d'eux n'a pas été accessible pendant environ 15 minutes - tout à coup, il est revenu sur le réseau.
Dans l'ensemble, un résultat satisfaisant.

micropet le 27 avr. 2018

Très bon à entendre.
Espérons que @Oxyandy puisse également partager des résultats positifs similaires avec la dernière version que j'ai partagée.
Ses nœuds étaient les plus critiques lors de l'utilisation de 2.4.x

TD-er le 27 avr. 2018

@TD-er Morning, a finalement trouvé ce post après avoir fait un rattrapage
0403 en utilisant la 2.4.1 s'est bien passé toute la nuit.
Clignotant maintenant à partir de votre dernier rar normal 1024 8266
se connecte du premier coup, met à jour l'heure immédiatement, pas d'erreurs wifi (pour l'instant) et reste connecté (pour l'instant),
le serveur web répond à chaque fois...
Besoin d'un peu plus de temps pour tester, mais ça a l'air bien

Oxyandy le 27 avr. 2018

Ça fait plaisir à entendre :)

Je vais jeter un œil au problème NTP signalé par @ giig1967g , puis
Esperons le meilleur.

Ce serait vraiment génial si nous pouvions laisser le wifi pour ce qu'il est et continuer avec le reste.

TD-er le 27 avr. 2018

❤1 👍1

J'espère que vous pourrez affiner certaines choses sur lesquelles je fournirai des commentaires, une fois que les choses seront à nouveau stables.
Je vais essayer quelques tests spécifiques avec votre source wifi_stability_core-2.4.1 de Github
& peut-être corrige mes problèmes de longue date, si la source n'a pas changé radicalement

Oxyandy le 27 avr. 2018

Si vous avez des correctifs, merci de les partager.

TD-er le 28 avr. 2018

@ giig1967g J'ai fait les tests. Les déconnexions très courtes ne posent aucun problème. AP éteint et immédiatement allumé. Mon mcunode se connecte si AP est de retour. Mon PC s'est déjà connecté à un autre point d'accès.

weisskopfjens le 28 avr. 2018

Je viens également de commencer les tests avec D1-Mini et BME280

ESPEasy : commit 2abec2b0bb74018ea76203886f683761796091a2
Fusionner : 16d3a9f 29f89b6
Auteur : Susis Strolch [email protected]
Date : 28 avr. 10:26:14 2018 +0200

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

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

Noyau : commettre 41a64707f149d01ace37c903f448d5e3f1cee5d8
Auteur : Marcel Stör [email protected]
Date : jeu. 26 avr. 01:46:17 2018 +0200

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

Personnalisé.h :
`#warning " ** Utilisation des paramètres du fichier Custom.h * "

si défini (ESP8266)

// activer la mise à jour Arduino OTA.
//Remarque : Cela ajoute environ 10 ko à la taille du micrologiciel et 1 ko de RAM supplémentaire.
// #définir FEATURE_ARDUINO_OTA

//activer le mode mDNS (ajoute environ 6 Ko de RAM et quelques octets IRAM)
// #définir FEATURE_MDNS

fin si

undef PLUGIN_BUILD_NORMAL

undef PLUGIN_BUILD_TESTING

undef PLUGIN_BUILD_DEV

définir PLUGIN_BUILD_CUSTOM

undef BUILD_UPLOADER

si défini (BUILD_UPLOADER)

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

autre

// définir nos propres plugins
#define USES_P001 // Commutateur
#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 // Factice

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

fin si

undef BUILD_GIT

définir BUILD_GIT "2abec2b"`

susisstrolch le 28 avr. 2018

Il semble qu'il y ait des problèmes avec NTP :
`
INIT : version de démarrage : 2abec2b (ESP82xx Core 41a64707)

80 : INIT : Amorçage chaud #2

81 : FS : Montage...

106 : FS : Montage réussi, utilisé 76053 octets sur 957314

115 : CRC : Aucune somme de contrôle de la mémoire du programme trouvée. Vérifier la sortie de crc2.py

144 : CRC : Paramètres de sécurité CRC ...OK

227 : INIT : RAM libre

227 : INIT : I2C

227 : INIT : SPI non activé

232 : INFO : Plugins : 8 (ESP82xx Core 41a64707)

233 : ÉVÉNEMENT : System#Wake

241 : WIFI : Réglez le WiFi sur STA
242 : WIFI : Connexion SusiconStrolch tentative #0
355 : ÉVÉNEMENT : System#Boot
364 : WD : Disponibilité 0 Échecs de connexion 0 FreeMem 31504
3987 : BMx280 : BME280 détecté
5575 : BME280 : point de rosée 8.03C
5576 : BME280 : Adresse : 0x76
5576 : BME280 : Température : 18,49
5576 : BME280 : Humidité : 50,75
5576 : BME280 : Pression barométrique : 1010,58
5583 : ÉVÉNEMENT : BMx280#Température=18.49
5592 : ÉVÉNEMENT : BMx280#Humidité=50.75
5597 : ÉVÉNEMENT : BMx280#Pression=1010.58
5853 : Fuseau horaire actuel : Début de l'heure DST : 25/03/2018 02:00:00 décalage : 120 min Début de l'heure STD : 28-10-2018 03:00:00 décalage : 60 min
5853 : ÉVÉNEMENT : Heure#Initialisée
5862 : ÉVÉNEMENT : Horloge#Heure=Sam,10:52
5866 : ACT : jeu de valeurs de tâche 12,1,0
5872 : ACT : jeu de valeurs de tâche 12,2,-58
5877 : ACT : jeu de valeurs de tâche 12,3,29912
5883 : ACT : jeu de valeurs de tâche 12,4,39164
5888 : WIFI : Connecté ! AP : SusiconStrolch (38:10:D5:B2:22:1E) Canal : 13 Durée : 3783 ms
5888 : ÉVÉNEMENT : WiFi#ChangedAccesspoint
5894 : WIFI : DHCP IP : 192.168.254.71 (D1pro-01-11) GW : 192.168.254.1 SN : 255.255.255.0 durée : 17 ms
5913 : Fuseau horaire actuel : Début de l'heure DST : 2036-03-30 02:00:00 décalage : 120 min Début de l'heure STD : 2036-10-26 03:00:00 décalage : 60 min
5914 : ÉVÉNEMENT : Heure#Définir
5921 : ÉVÉNEMENT : WiFi#Connecté
5928 : Serveur Web : démarrer
5935 : ÉVÉNEMENT : Horloge#Heure=Jeu,07:28
`
5853 : Fuseau horaire actuel : heure de début de l'heure d'été : 2018-03-25 02:00:00
5913 : Fuseau horaire actuel : Heure DST début : 2036-03-30 02:00:00 décalage : 120 min Heure STD début :

susisstrolch le 28 avr. 2018

C'est un code d'erreur -1 connu et toujours converti en bogue temporel.

s0170071 le 28 avr. 2018

Hmm, je me demande encore comment l'appel à NTP peut entraîner un -1.

@susisstrolch
C'est quelle version ? ESPeasy a utilisé la valeur BUILD_GIT pour déterminer ce qui doit être corrigé dans les fichiers de paramètres et peut-être aussi dans d'autres fichiers. C'est une sorte de version interne utilisée pour déterminer les correctifs nécessaires. (si seulement)
lorsque vous modifiez cette valeur, cela peut entraîner des choses étranges.

TD-er le 28 avr. 2018

Je suppose que c'est lié à UDP. Je ne vois aucun de mes autres appareils. Et vice versa.

susisstrolch le 28 avr. 2018

@susisstrolch C'est avec IP statique, ou avec DHCP ?

TD-er le 28 avr. 2018

Le correctif @TD-er basé sur BUILD_GIT est une mauvaise idée, car il change sur les forks, les branches et les commits locaux.
Il devrait y avoir un type/variable différent - peut-être BUILD_FEATURE - qui contrôle un tel comportement.

susisstrolch le 28 avr. 2018

Comme je ne redémarre presque jamais mon AP, il est passé inaperçu qu'une reconnexion échoue avec la dernière source github (20180428). J'ai essayé d'obtenir un état interne pour voir ce qui se passe :

Après le démarrage :
appel à Wifi.status() : 3 signifie WL_CONNECTED
variable wifiStatus : 3 signifie ESPEASY_WIFI_SERVICES_INITIALIZED

Après redémarrage AP
appel à Wifi.status() : 3 signifie WL_CONNECTED
variable wifiStatus : 0 signifie ESPEASY_WIFI_DISCONNECTED

cela ne change pas avec le temps et l'ESP ne se reconnecte jamais

Je me demandais juste pourquoi l'appel Wifi.status() au noyau signale toujours un statut 3 (WL_CONNECTED)
Est-ce parce que le wifi basé sur les événements interfère avec l'état du noyau interne ?

Le comportement est le même sur le core 2_3_0 et 2_4_1

ghost le 28 avr. 2018

C'est avec DHCP

susisstrolch le 28 avr. 2018

Et je m'attendrais à ce qu'après un redémarrage normal :

appel à Wifi.status() : 3 signifie WL_CONNECTED
variable wifiStatus : 1 signifie ESPEASY_WIFI_CONNECTED

à la place de:
appel à Wifi.status() : 3 signifie WL_CONNECTED
variable wifiStatus : 3 signifie ESPEASY_WIFI_SERVICES_INITIALIZED

ghost le 28 avr. 2018

Hmm, c'est une bonne question @mvdbro
Peut-être que le statut WL_CONNECTED n'est jamais mis à jour car il n'appelle pas la fonction pour mettre à jour ce statut.
De mémoire, je dirais que cette fonction est appelée dans la bibliothèque principale lorsque l'événement "get IP" est géré.
Je vais examiner cette zone du code de la bibliothèque de base.
Merci d'avoir remarqué.

@susisstrolch OK, je vais aussi essayer avec DHCP ici.
Mes unités de test peuvent se voir via la communication interne ESPeasy UDP, mais elles fonctionnent actuellement sur une adresse IP statique, car cela a causé la plupart des problèmes ces derniers temps.

TD-er le 28 avr. 2018

@TD-er hold on - vérifiera s'il s'agit d'un problème lié au cœur.

susisstrolch le 28 avr. 2018

@mvdbro
Voici le code :
https://github.com/esp8266/Arduino/blob/836c7da8cc1ad11a66e0be1f30d35a92b5317bcc/libraries/ESP8266WiFi/src/ESP8266WiFiSTA.cpp#L497 -L513

En effet, tant que le statut interne n'est pas défini sur 'got IP', il ne retournera pas WL_CONNECTED.

À propos de la différence de noms de variables entre enum/defines dans ESPeasy et la bibliothèque principale.
Les états de la bibliothèque principale ne reflètent pas vraiment l'état réel, car vous pouvez être connecté et ne pas avoir d'adresse IP.

TD-er le 28 avr. 2018

Je ferais peut-être mieux de garder ce fil pour les problèmes de connexion/reconnexion Wifi uniquement afin que cela puisse être résolu en premier lieu.

ghost le 28 avr. 2018

Je suppose que ce sont les codes efficaces utilisés:

Codes Wifi.status() :
WL_IDLE_STATUS 0
WL_NO_SSID_AVAIL 1
WL_SCAN_COMPLETED 2
WL_CONNECTÉ 3
WL_CONNECT_FAILED 4
WL_CONNECTION_LOST 5
WL_DÉCONNECTÉ 6

wifiCodes d'état :
ESPEASY_WIFI_DISCONNECTED 0
ESPEASY_WIFI_CONNECTED 1
ESPEASY_WIFI_GOT_IP 2
ESPEASY_WIFI_SERVICES_INITIALISE 3

ghost le 28 avr. 2018

Je suppose que cela peut très bien être lié au problème de connexion/reconnexion wifi.
Avec une adresse IP statique, il n'y a tout simplement pas d'événement pour " got IP ", donc sa gestion actuelle peut être incomplète, ce qui est à l'origine de certains de ces problèmes.

TD-er le 28 avr. 2018

Donc après redémarrage AP
appel à Wifi.status() : 3 signifie WL_CONNECTED
Ce n'est pas correct.

Si le Wifi.status() ne fonctionne pas comme prévu, il s'agirait d'un grave bug du noyau arduino. Cela ne devrait-il pas être signalé sur leur outil de suivi des problèmes github ?

ghost le 28 avr. 2018

@susisstrolch Je

Solution : vérifiez l'entrée du port UDP. (65500) Le mien venait de disparaître. Un autre redémarrage et cela fonctionnait.
Nous devrions vraiment opter pour la config basée sur JSON !!!

s0170071 le 28 avr. 2018

@mvdbro Je viens de trouver ceci, voir en haut de la page 39 :
https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf
Je vais donc maintenant tester pour voir si nous devons (re)définir la configuration IP après avoir traité l'événement de connexion.

TD-er le 28 avr. 2018

Quelqu'un peut-il tester le code dans ce PR : https://github.com/letscontrolit/ESPEasy/pull/1328

TD-er le 28 avr. 2018

@s0170071 - confirmé - le réglage du port UDP a changé.

susisstrolch le 28 avr. 2018

@TD-er à propos de #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

Comme vous pouvez le voir, DHCP est démarré même lorsqu'il est défini sur IP statique...

Et voici mon 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 le 28 avr. 2018

99 : CRC : Aucune somme de contrôle de la mémoire du programme trouvée. Vérifier la sortie de crc2.py
130 : CRC : Paramètres de sécurité CRC ...OK
211 : INIT : RAM libre
211 : INIT : I2C
211 : INIT : SPI non activé
1042 : INFO : Plugins : 71 [Normal] [Test] (ESP82xx Core 2_4_1)
1042 : ÉVÉNEMENT : System#Wake
1089 : WIFI : Réglez le WiFi sur STA
1091 : WIFI : Tentative de connexion SMC #0
1103 : EVENEMENT : System#Boot
1111 : ACT : Publier ESP-201/IP,0.0.0.0
1124 : ACT : timerSet,1,60
1152 : WD : Disponibilité 0 Échecs de connexion 0 FreeMem 20160
1183 : DS : Température : 20,37 (28-ff-b8-ea-b4-16-3-ed)
1184 : ÉVÉNEMENT : DS18b20#Température=20.37
4887 : WIFI : Connecté ! AP : SMC (78:8A:20:D1:9B:D9) Canal : 1 Durée : 3795 ms
4888 : ÉVÉNEMENT : WiFi#ChangedAccesspoint
4910 : IP : IP statique : 192.168.0.201 GW : 192.168.0.3 SN : 255.255.255.0 DNS : 192.168.0.3
4911 : WIFI : IP statique : 192.168.0.201 (ESP-201-1) GW : 192.168.0.3 SN : 255.255.255.0 durée : 25 ms
5009 : Fuseau horaire actuel : Début de l'heure DST : 25/03/2018 02:00:00 décalage : 120 min Début de l'heure STD : 28-10-2018 03:00:00 décalage : 60 min
5010 : ÉVÉNEMENT : Heure#Initialisée
5027 : ÉVÉNEMENT : WiFi#Connecté
5044 : Serveur Web : démarrer
5127 : MQTT : Reconnexion intentionnelle
5182 : MQTT : Connecté au courtier avec l'ID client : ESPClient_5C:CF:7F:0B:68:52
5184 : Abonné à : ESP-201/#
5185 : ÉVÉNEMENT : MQTT#Connecté
5846 : ÉVÉNEMENT : Horloge#Heure=Sam,16:19

micropet le 28 avr. 2018

@susisstrolch C'est étrange de démarrer DHCP, car j'ai récemment écrit un correctif pour cela.
Peut-être que quelque chose a changé dans la 2.4.1 ?

Qu'avez-vous fait pour obtenir les informations de débogage supplémentaires ?

TD-er le 28 avr. 2018

J'ai simplement défini le niveau de débogage sur "Déboguer plus"...

susisstrolch le 28 avr. 2018

@susisstrolch Vous semblez également avoir d'autres sorties de débogage générées par la bibliothèque principale.
Je ne vois pas cela dans mon log sur le port série.

Éditer:
Trouvé, Serial.setDebugOutput est appelé à partir de Setup(). Donc un simple redémarrage suffisait :)

TD-er le 28 avr. 2018

Voici une interaction entre SYSHEAP et Uptime.

sysheap

micropet le 28 avr. 2018

Je suis curieux de savoir à quoi ressemblera ce graphique sysheap après un jour ou deux.

TD-er le 28 avr. 2018

S'il n'échoue pas, nous le verrons. :)

micropet le 28 avr. 2018

Les graphiques sont tous différents : il s'agit de l'appareil avec votre dernière modification et une adresse IP statique.

esp-201 sysheap

micropet le 28 avr. 2018

De quelle version était le graphique précédent ?

TD-er le 28 avr. 2018

Le premier graphique, la version spéciale de vous d'hier soir. Avec DHCP

micropet le 29 avr. 2018

Intéressant.
J'ajouterai également une journalisation sysheap à mes nœuds.

TD-er le 29 avr. 2018

Je me connecte avec openHAB. C'est aussi super avec Grafana.

micropet le 29 avr. 2018

Dois-je flasher vos commits actuels ? Ensuite, ma carte est perdue sur l'ESP-201.

micropet le 29 avr. 2018

Je suppose que les tests de stabilité du wifi sont plus importants pour le moment.

TD-er le 29 avr. 2018

Ok je vais faire.

micropet le 29 avr. 2018

OK, est en ligne.

INIT : version de démarrage : (ESP82xx Core 2_4_1)
92 : INIT : botte chaude #2
94 : FS : Montage...
118 : FS : Montage réussi, utilisé 76806 octets sur 957314
131 : CRC : Aucune somme de contrôle de la mémoire du programme trouvée. Vérifier la sortie de crc2.py
162 : CRC : Paramètres de sécurité CRC ...OK
243 : INIT : RAM libre
243 : INIT : I2C
243 : INIT : SPI non activé
1073 : INFO : Plugins : 71 [Normal] [Test] (ESP82xx Core 2_4_1)
1073 : EVENEMENT : System#Wake
1120 : WIFI : Réglez le WiFi sur STA
1152 : WIFI : Tentative de connexion SMC #0
1153 : IP : IP statique : 192.168.0.201 GW : 192.168.0.3 SN : 255.255.255.0 DNS : 192.168.0.3
1155 : WIFI : L'état de la station SDK diffère de l'état Arduino. État du SDK : 1 État de l'Arduino : 6
1172 : EVENEMENT : System#Boot
1178 : ACT : NeoPixelAll,0,0,0,0
1189 : ACT : Publier ESP-201/IP, 192.168.0.201
1201 : ACT : timerSet,1,60
1226 : WD : Temps de disponibilité 0 Échecs de connexion 0 FreeMem 20088
1257 : DS : Température : 20,25 (28-ff-b8-ea-b4-16-3-ed)
1259 : EVENEMENT : DS18b20#Température=20.25
4952 : WIFI : Connecté ! AP : SMC (78:8A:20:D1:9B:D9) Canaux : 1 Durée : 3798 ms
4953 : ÉVÉNEMENT : WiFi#ChangedAccesspoint
4974 : IP : IP statique : 192.168.0.201 GW : 192.168.0.3 SN : 255.255.255.0 DNS : 192.168.0.3
4975 : WIFI : L'état de la station SDK diffère de l'état Arduino. Statut SDK : 5 Statut Arduino : 3
4980 : WIFI : IP statique : 192.168.0.201 (ESP-201-1) GW : 192.168.0.3 SN : 255.255.255.0 durée : 24 ms
5102 : Fuseau horaire actuel : Début de l'heure DST : 25/03/2018 02:00:00 décalage : 120 min Début de l'heure STD : 28-10-2018 03:00:00 décalage : 60 min
5103 : EVENEMENT : Heure#Initialisé
5123 : ÉVÉNEMENT : WiFi#Connecté
5140 : Serveur Web : démarrer
5141 : WIFI : L'état de la station SDK diffère de l'état Arduino. Statut SDK : 5 Statut Arduino : 3
5223 : MQTT : Reconnexion intentionnelle
5261 : MQTT : Connecté au courtier avec l'ID client : ESPClient_5C:CF:7F:0B:68:52
5264 : Abonné à : ESP-201/#
5265 : ÉVÉNEMENT : MQTT#Connecté
5912 : ÉVÉNEMENT : Horloge#Heure=Dim,00:14
31226 : WD : Temps de disponibilité 1 Échecs de connexion 0 FreeMem 15968

micropet le 29 avr. 2018

J'ai également étendu les informations sur la page sysinfo.
Ajout d'un compteur de reconnexion et utilisation du paramètre Static/DHCP (et de la version SDK)

Inclut également une vérification de reconnexion forcée, qui se reconnectera lorsqu'elle n'est pas connectée pendant un certain temps.

TD-er le 29 avr. 2018

Dois-je interrompre le WIFI pendant 0,2 seconde ?

micropet le 29 avr. 2018

S'il vous plaît essayez de le planter :)

TD-er le 29 avr. 2018

d'accord

micropet le 29 avr. 2018

244302 : ACT : Publier ESP-201/IP, 192.168.0.201
244318 : ACT : Publier ESP-201/MAC,5C:CF:7F:0B:68:52
244331 : ACT : Publier ESP-201/Heure,00:18:18
244343 : ACT : Publier ESP-201/Uptime,4
244355 : ACT : Publier ESP-201/RSSI,-62
244367 : ACT : Publier ESP-201/SSID,SMC
244379 : ACT : Publier ESP-201/BSSID,78:8A:20:D1:9B:D9
244391 : ACT : Publier ESP-201/CH,1
244406 : ACT : publier ESP-201/SYSHEAP,12616
244422 : ACT : timerSet,1,60
255542 : ÉVÉNEMENT : WiFi#Déconnecté
255560 : WIFI : Déconnecté ! Raison : '(1) Non spécifié' Connecté pendant 4 m 10 s
255560 : WIFI : l'état de la station SDK diffère de l'état Arduino. Statut SDK : 5 Statut Arduino : 3
255571 : MQTT : Connexion perdue
255572 : ÉVÉNEMENT : MQTT#Déconnecté
255610 : MQTT : Échec de la connexion au courtier
256110 : MQTT : Échec de la connexion au courtier
256860 : MQTT : Échec de la connexion au courtier
257860 : MQTT : Échec de la connexion au courtier
259110 : MQTT : Échec de la connexion au courtier
260610 : MQTT : Échec de la connexion au courtier
262360 : MQTT : Échec de la connexion au courtier
264360 : MQTT : Échec de la connexion au courtier
266360 : MQTT : Échec de la connexion au courtier
268360 : MQTT : Échec de la connexion au courtier
270360 : MQTT : Échec de la connexion au courtier
271226 : WD : Temps de disponibilité 5 Échecs de connexion 22 FreeMem 17224
271247 : MQTT : Échec de la connexion au courtier
272360 : MQTT : Échec de la connexion au courtier
274360 : MQTT : Échec de la connexion au courtier
276360 : MQTT : Échec de la connexion au courtier
278360 : MQTT : Échec de la connexion au courtier
280360 : MQTT : Échec de la connexion au courtier
282360 : MQTT : Échec de la connexion au courtier
284360 : MQTT : Échec de la connexion au courtier
286291 : ÉVÉNEMENT : Horloge#Heure=Dim,00:19
286359 : MQTT : Échec de la connexion au courtier
288360 : MQTT : Échec de la connexion au courtier
290360 : MQTT : Échec de la connexion au courtier

micropet le 29 avr. 2018

Juste pour ce contrôle, pourriez-vous le laisser dans cet état pendant 4 minutes ?
Je vais réduire l'intervalle de ticker pour ce contrôle (est actuellement de 240 sec)

TD-er le 29 avr. 2018

D'accord, je le fais.

micropet le 29 avr. 2018

240 secondes c'est très long

micropet le 29 avr. 2018

Oui je sais, je vais le changer.
Je viens de reprendre l'idée de ce numéro : https://github.com/esp8266/Arduino/issues/4445

TD-er le 29 avr. 2018

rien....

432148 : MQTT : Échec de la connexion au courtier
434148 : MQTT : Échec de la connexion au courtier
436148 : MQTT : Échec de la connexion au courtier
438147 : MQTT : Échec de la connexion au courtier
440148 : MQTT : Échec de la connexion au courtier
442147 : MQTT : Échec de la connexion au courtier
444148 : MQTT : Échec de la connexion au courtier
446148 : MQTT : Échec de la connexion au courtier
448148 : MQTT : Échec de la connexion au courtier
450147 : MQTT : Échec de la connexion au courtier
451222 : WD : Uptime 8 ConnectFailures 446 FreeMem 17384
451243 : MQTT : Échec de la connexion au courtier
452148 : MQTT : Échec de la connexion au courtier
453907 : ÉVÉNEMENT : Horloge#Heure=Dim,00:29
454148 : MQTT : Échec de la connexion au courtier
456148 : MQTT : Échec de la connexion au courtier
458148 : MQTT : Échec de la connexion au courtier

micropet le 29 avr. 2018

Je vais dormir, à demain.

micropet le 29 avr. 2018

je viens de trouver un autre problème, peut-être lié à UDP :
sur une nouvelle unité de réinitialisation d'usine, utilisez les commandes série
clé wifi
wifissid
sauver

redémarrez, puis accédez aux paramètres avancés et vérifiez ssdp. Redémarrez.
Il entre dans une boucle de démarrage puis :

 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 le 29 avr. 2018

Bonjour à tous.
Pour moi, la reconnexion ne fonctionne pas encore.

INIT : version de démarrage : (ESP82xx Core 2_4_1)
92 : INIT : Démarrage à chaud #8
94 : FS : Montage...
118 : FS : Montage réussi, utilisé 76806 octets sur 957314
131 : CRC : Aucune somme de contrôle de la mémoire du programme trouvée. Vérifier la sortie de crc2.py
162 : CRC : Paramètres de sécurité CRC ...OK
243 : INIT : RAM libre
243 : INIT : I2C
243 : INIT : SPI non activé
1073 : INFO : Plugins : 71 [Normal] [Test] (ESP82xx Core 2_4_1)
1074 : EVENEMENT : System#Wake
1121 : WIFI : Réglez le WiFi sur STA
1153 : WIFI : Tentative de connexion SMC #0
1154 : IP : IP statique : 192.168.0.201 GW : 192.168.0.3 SN : 255.255.255.0 DNS : 192.168.0.3
1155 : WIFI : L'état de la station SDK diffère de l'état Arduino. État du SDK : 1 État de l'Arduino : 6
1173 : EVENEMENT : System#Boot
1179 : ACT : NeoPixelAll,0,0,0,0
1190 : ACT : Publier ESP-201/IP, 192.168.0.201
1201 : ACT : timerSet,1,60
1226 : WD : Disponibilité 0 Échecs de connexion 0 FreeMem 20072
1258 : DS : Température : 19,75 (28-ff-b8-ea-b4-16-3-ed)
1259 : EVENEMENT : DS18b20#Temperature=19.75
4925 : WIFI : Connecté ! AP : SMC (78:8A:20:D1:9B:D9) Canal : 1 Durée : 3770 ms
4926 : ÉVÉNEMENT : WiFi#ChangedAccesspoint
4947 : IP : IP statique : 192.168.0.201 GW : 192.168.0.3 SN : 255.255.255.0 DNS : 192.168.0.3
4947 : WIFI : L'état de la station SDK diffère de l'état Arduino. Statut SDK : 5 Statut Arduino : 3
4953 : WIFI : IP statique : 192.168.0.201 (ESP-201-1) GW : 192.168.0.3 SN : 255.255.255.0 durée : 23 ms
5066 : Fuseau horaire actuel : Début de l'heure DST : 25/03/2018 02:00:00 décalage : 120 min Début de l'heure STD : 28-10-2018 03:00:00 décalage : 60 min
5066 : ÉVÉNEMENT : Heure#Initialisé
5087 : ÉVÉNEMENT : WiFi#Connecté
5104 : Serveur Web : démarrer
5104 : WIFI : L'état de la station SDK diffère de l'état Arduino. Statut SDK : 5 Statut Arduino : 3
5186 : MQTT : Reconnexion intentionnelle
5222 : MQTT : Connecté au courtier avec l'ID client : ESPClient_5C:CF:7F:0B:68:52
5225 : Abonné à : ESP-201/#
5226 : ÉVÉNEMENT : MQTT#Connecté
5906 : ÉVÉNEMENT : Horloge#Heure=Dim,10:01
31227 : WD : Temps de disponibilité 1 Échecs de connexion 0 FreeMem 16336
47905 : ÉVÉNEMENT : Horloge#Heure=Dim,10:02
61229 : WD : Temps de disponibilité 1 Échecs de connexion 0 FreeMem 16336
61926 : DS : Température : 19,75 (28-ff-b8-ea-b4-16-3-ed)
61928 : ÉVÉNEMENT : DS18b20#Température=19.75
61972 : ÉVÉNEMENT : Règles#Timer=1
61983 : ACT : Publier ESP-201/IP, 192.168.0.201
61999 : ACT : Publier ESP-201/MAC,5C:CF:7F:0B:68:52
62015 : ACT : publier ESP-201/Heure,10:02:14
62030 : ACT : Publier ESP-201/Uptime,1
62044 : ACT : Publier ESP-201/RSSI,-62
62060 : ACT : Publier ESP-201/SSID,SMC
62076 : ACT : Publier ESP-201/BSSID,78:8A:20:D1:9B:D9
62091 : ACT : Publier ESP-201/CH,1
62107 : ACT : publier ESP-201/SYSHEAP,13536
62120 : ACT : timerSet,1,60
67292 : ÉVÉNEMENT : WiFi#Déconnecté
67310 : WIFI : Déconnecté ! Raison : '(1) Non spécifié' Connecté pendant 1 m 2 s
67310 : WIFI : L'état de la station SDK diffère de l'état Arduino. Statut SDK : 5 Statut Arduino : 3
67316 : MQTT : Connexion perdue
67317 : ÉVÉNEMENT : MQTT#Déconnecté
67357 : MQTT : Échec de la connexion au courtier
67856 : MQTT : Échec de la connexion au courtier
68606 : MQTT : Échec de la connexion au courtier
69607 : MQTT : Échec de la connexion au courtier
70857 : MQTT : Échec de la connexion au courtier
72357 : MQTT : Échec de la connexion au courtier
74107 : MQTT : Échec de la connexion au courtier
76106 : MQTT : Échec de la connexion au courtier
78107 : MQTT : Échec de la connexion au courtier
80107 : MQTT : Échec de la connexion au courtier
82106 : MQTT : Échec de la connexion au courtier
84106 : MQTT : Échec de la connexion au courtier
86107 : MQTT : Échec de la connexion au courtier
88106 : MQTT : Échec de la connexion au courtier
90107 : MQTT : Échec de la connexion au courtier
91228 : WD : Uptime 2 ConnectFailures 30 FreeMem 17368
91250 : MQTT : Échec de la connexion au courtier
92107 : MQTT : Échec de la connexion au courtier
94107 : MQTT : Échec de la connexion au courtier
96106 : MQTT : Échec de la connexion au courtier
98107 : MQTT : Échec de la connexion au courtier
100107 : MQTT : Échec de la connexion au courtier
102107 : MQTT : Échec de la connexion au courtier
104106 : MQTT : Échec de la connexion au courtier
106107 : MQTT : Échec de la connexion au courtier
107905 : ÉVÉNEMENT : Horloge#Heure=Dim,10:03
108107 : MQTT : Échec de la connexion au courtier
110107 : MQTT : Échec de la connexion au courtier
112107 : MQTT : Échec de la connexion au courtier
114107 : MQTT : Échec de la connexion au courtier
116107 : MQTT : Échec de la connexion au courtier
118107 : MQTT : Échec de la connexion au courtier
120107 : MQTT : Échec de la connexion au courtier
121228 : WD : Uptime 2 ConnectFailures 62 FreeMem 17368
121249 : MQTT : Échec de la connexion au courtier
121926 : DS : Température : 19,75 (28-ff-b8-ea-b4-16-3-ed)
121927 : ÉVÉNEMENT : DS18b20#Température=19.75
122107 : MQTT : Échec de la connexion au courtier
122905 : ÉVÉNEMENT : Règles#Timer=1
122915 : ACT : Publier ESP-201/IP,0.0.0.0
122927 : ACT : Publier ESP-201/MAC,5C:CF:7F:0B:68:52
122939 : ACT : Publier ESP-201/Heure,10:03:15
122950 : ACT : Publier ESP-201/Uptime,2
122961 : ACT : Publier ESP-201/RSSI,0
122972 : ACT : Publier ESP-201/SSID,--
122983 : ACT : Publier ESP-201/BSSID,00:00:00:00:00:00
122994 : ACT : Publier ESP-201/CH,0
123005 : ACT : Publier ESP-201/SYSHEAP,16992
123015 : ACT : timerSet,1,60
124107 : MQTT : Échec de la connexion au courtier
126106 : MQTT : Échec de la connexion au courtier
128107 : MQTT : Échec de la connexion au courtier
130107 : MQTT : Échec de la connexion au courtier
132107 : MQTT : Échec de la connexion au courtier
134107 : MQTT : Échec de la connexion au courtier
136107 : MQTT : Échec de la connexion au courtier
138107 : MQTT : Échec de la connexion au courtier
140107 : MQTT : Échec de la connexion au courtier
142107 : MQTT : Échec de la connexion au courtier
144107 : MQTT : Échec de la connexion au courtier
146107 : MQTT : Échec de la connexion au courtier
148107 : MQTT : Échec de la connexion au courtier
150107 : MQTT : Échec de la connexion au courtier
151228 : WD : Uptime 3 ConnectFailures 94 FreeMem 17368
151249 : MQTT : Échec de la connexion au courtier
152107 : MQTT : Échec de la connexion au courtier
154107 : MQTT : Échec de la connexion au courtier
156107 : MQTT : Échec de la connexion au courtier
158107 : MQTT : Échec de la connexion au courtier
160107 : MQTT : Échec de la connexion au courtier
162107 : MQTT : Échec de la connexion au courtier
164107 : MQTT : Échec de la connexion au courtier
166107 : MQTT : Échec de la connexion au courtier
167905 : ÉVÉNEMENT : Horloge#Heure=Dim,10:04
168107 : MQTT : Échec de la connexion au courtier
170107 : MQTT : Échec de la connexion au courtier
172107 : MQTT : Échec de la connexion au courtier
174106 : MQTT : Échec de la connexion au courtier
176106 : MQTT : Échec de la connexion au courtier
178107 : MQTT : Échec de la connexion au courtier
180107 : MQTT : Échec de la connexion au courtier
181228 : WD : Uptime 3 ConnectFailures 126 FreeMem 17368
181250 : MQTT : Échec de la connexion au courtier
181926 : DS : Température : 19,75 (28-ff-b8-ea-b4-16-3-ed)
181927 : ÉVÉNEMENT : DS18b20#Temperature=19.75
182107 : MQTT : Échec de la connexion au courtier
183905 : ÉVÉNEMENT : Règles#Timer=1
183915 : ACT : Publier ESP-201/IP,0.0.0.0
183927 : ACT : Publier ESP-201/MAC,5C:CF:7F:0B:68:52
183938 : ACT : Publier ESP-201/Heure,10:04:16
183950 : ACT : Publier ESP-201/Uptime,3
183961 : ACT : Publier ESP-201/RSSI,0
183972 : ACT : Publier ESP-201/SSID,--
183983 : ACT : Publier ESP-201/BSSID,00:00:00:00:00:00
183994 : ACT : Publier ESP-201/CH,0
184005 : ACT : Publier ESP-201/SYSHEAP,16992
184015 : ACT : timerSet,1,60
184107 : MQTT : Échec de la connexion au courtier
186106 : MQTT : Échec de la connexion au courtier
188107 : MQTT : Échec de la connexion au courtier
190106 : MQTT : Échec de la connexion au courtier
192107 : MQTT : Échec de la connexion au courtier
194106 : MQTT : Échec de la connexion au courtier
196106 : MQTT : Échec de la connexion au courtier
198106 : MQTT : Échec de la connexion au courtier
200106 : MQTT : Échec de la connexion au courtier
202106 : MQTT : Échec de la connexion au courtier
204106 : MQTT : Échec de la connexion au courtier
206106 : MQTT : Échec de la connexion au courtier
208106 : MQTT : Échec de la connexion au courtier
210106 : MQTT : Échec de la connexion au courtier
211228 : WD : Uptime 4 ConnectFailures 158 FreeMem 17368
211249 : MQTT : Échec de la connexion au courtier
212106 : MQTT : Échec de la connexion au courtier
214106 : MQTT : Échec de la connexion au courtier
216106 : MQTT : Échec de la connexion au courtier
218106 : MQTT : Échec de la connexion au courtier
220106 : MQTT : Échec de la connexion au courtier
222106 : MQTT : Échec de la connexion au courtier
224106 : MQTT : Échec de la connexion au courtier
226106 : MQTT : Échec de la connexion au courtier
227905 : ÉVÉNEMENT : Horloge#Heure=Dim,10:05
228107 : MQTT : Échec de la connexion au courtier
230107 : MQTT : Échec de la connexion au courtier
232107 : MQTT : Échec de la connexion au courtier
234107 : MQTT : Échec de la connexion au courtier
236106 : MQTT : Échec de la connexion au courtier
238106 : MQTT : Échec de la connexion au courtier
240106 : MQTT : Échec de la connexion au courtier
241228 : WD : Uptime 4 ConnectFailures 190 FreeMem 17368
241249 : MQTT : Échec de la connexion au courtier
241925 : DS : Température : 19,75 (28-ff-b8-ea-b4-16-3-ed)
241927 : ÉVÉNEMENT : DS18b20#Température=19.75
242107 : MQTT : Échec de la connexion au courtier
244106 : MQTT : Échec de la connexion au courtier
244908 : ÉVÉNEMENT : Règles#Timer=1
244918 : ACT : Publier ESP-201/IP,0.0.0.0
244930 : ACT : Publier ESP-201/MAC,5C:CF:7F:0B:68:52
244942 : ACT : Publier ESP-201/Heure,10:05:17
244953 : ACT : Publier ESP-201/Uptime,4
244964 : ACT : Publier ESP-201/RSSI,0
244975 : ACT : Publier ESP-201/SSID,--
244986 : ACT : Publier ESP-201/BSSID,00:00:00:00:00:00
244997 : ACT : Publier ESP-201/CH,0
245008 : ACT : Publier ESP-201/SYSHEAP,16992
245018 : ACT : timerSet,1,60
246107 : MQTT : Échec de la connexion au courtier
248106 : MQTT : Échec de la connexion au courtier
250106 : MQTT : Échec de la connexion au courtier
252106 : MQTT : Échec de la connexion au courtier
254106 : MQTT : Échec de la connexion au courtier
256106 : MQTT : Échec de la connexion au courtier
258106 : MQTT : Échec de la connexion au courtier
260106 : MQTT : Échec de la connexion au courtier
262106 : MQTT : Échec de la connexion au courtier
264106 : MQTT : Échec de la connexion au courtier
266107 : MQTT : Échec de la connexion au courtier

micropet le 29 avr. 2018

ESP32 - derniers changements (28-04-2018) MQTT arrêter le travail, NTP arrêter le travail
(I.P statique)

flexiti le 29 avr. 2018

@flexiti
MQTT perd la connexion chaque seconde si vous ne vous abonnez pas et essayez simplement de publier.

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

Essayez d'entrer quelque chose dans la ligne d'abonnement même si vous ne l'utilisez pas. A travaillé pour moi.

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 le 29 avr. 2018

@TD-er
ce fil est un peu surchargé et il semble qu'il y ait plusieurs problèmes de wifi / stabilité. Je suggère de déplacer tous les problèmes vers un problème github séparé et de les marquer avec un mot clé, par exemple
[WIFICORE] ssdp
[WIFICORE] MQTT subscription needed
[WIFICORE] Unit not found - port setting vanished
[WIFICORE] ticker interval

s0170071 le 29 avr. 2018

Juste pour signaler, je viens de passer de méga-20180428 à méga-20180429.

Dans mega-20180428, le wifi était globalement stable, mais ne se reconnectait pas après une déconnexion.
dans mega-20180429, le wifi est très instable et je ne peux pas le ping sans avoir beaucoup de délais de lecture.

J'utilise un sonoff basic, en auto-compilant les versions avec #define PLUGIN_SET_SONOFF_BASIC pour rendre le bac suffisamment petit pour l'OTA.
Je ne sais pas si cela aide, je reviens à mega-20180428 en attendant.

louis-lau le 29 avr. 2018

@louis-lau Pourriez-vous re-tester avec le dernier commit+merge que je viens de faire ?

TD-er le 29 avr. 2018

C'est sur le dernier commit
screenshot

louis-lau le 29 avr. 2018

@louis-lau Et le log du nœud lui-même ?
S'il essaie de se reconnecter à un courtier MQTT, la réponse est plus lente et il y a actuellement un gestionnaire de reconnexion en arrière-plan pour se reconnecter lorsqu'il y a beaucoup d'échecs de reconnexion MQTT.
Oh et parfois, après une tentative de flash, il est préférable de réinitialiser le nœud (pas de réinitialiser les paramètres, tout comme d'appuyer sur le bouton de réinitialisation). Parfois, il reste une configuration restante sur le nœud après le flashage, ce qui peut conduire à des résultats étranges.

TD-er le 29 avr. 2018

@louis-lau un basique sonoff ?
moi aussi j'aime 0429, 0428 était terrible
Puis-je en savoir plus sur vos paramètres « globaux », s'il vous plaît ?
Et comme auto-compilé, est-il compilé avec 2.4.1 Core ?
Je viens de tester 0429 Fresh Flash sur un nœud vierge et il fonctionne parfaitement.
Mon essai précédent avec 0429 était une mise à jour d'un nœud d'ensemble statique préconfiguré. parfait aussi
Mes planches sont datées du 5-5-2017

Oxyandy le 29 avr. 2018

@Oxyandy
2.4.2 noyau ????

TD-er le 29 avr. 2018

C'est tout ce que j'ai qui me semble pertinent :

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 Je vais essayer une réinitialisation d'usine. Je n'ai apporté aucune modification avant la compilation, à l'exception du drapeau du plugin de base sonoff et des paramètres réseau dans Custom.h.

louis-lau le 29 avr. 2018

Vous avez raison, fonctionne très bien avec les paramètres d'usine 😄 .

Je vais essayer de restaurer, voir si ça casse à nouveau.

louis-lau le 29 avr. 2018

Cela ressemble à un redémarrage?

Dans le journal Web, vous obtiendrez un peu plus de lignes, car celui-ci a un tampon de 15 lignes.
Également sur la page sysinfo, vous pouvez obtenir plus d'informations.

Les journaux enregistrés sur le serveur syslog peuvent ne pas être complets, car celui-ci ne reçoit pas de données lorsque le wifi est déconnecté.

TD-er le 29 avr. 2018

D'accord, cela a recommencé à se produire lorsque j'ai activé le contrôleur mqtt.
Et arrêté quand je l'ai désactivé.

Je vais essayer d'avoir un meilleur log, c'est un peu dur quand on ne peut pas s'y connecter la moitié du temps.
Quel niveau de log ? déboguer?

louis-lau le 29 avr. 2018

Les connexions MQTT sont également affichées au niveau des informations.
Les informations montrent l'erreur + les informations.
De cette façon, vous ne remplissez pas trop rapidement la mémoire tampon du journal du blog pour l'afficher.

TD-er le 29 avr. 2018

D'accord, lorsque j'arrête le serveur mqtt fonctionne également normalement, ce n'est que lorsque le serveur est en cours d'exécution que la connexion expire.

C'est tout ce que j'ai pu obtenir du journal :
screenshot

louis-lau le 29 avr. 2018

De quel type de contrôleur MQTT s'agit-il ? Domotique ? OpenHAB ?

Ou essayez-vous de faire importMQTT?

Il existe également un bouton de copie sur la page Web affichant le journal.
Cette page s'actualise toutes les N secondes, ce qui vous permet de coller le texte entre les actualisations dans un éditeur de texte.
Ce n'est pas parfait, je sais, mais c'est mieux que rien :)

Éditer:
Veuillez également consulter les règles, si elles sont complètes.
Il y a toujours un problème pour sauvegarder les règles. Cette sauvegarde peut ne pas correspondre à l'ensemble des règles saisies.

TD-er le 29 avr. 2018

En utilisant le dernier githib (07bfec42347d13ad49dda907654a36bf747df3bc), le Wifi se connecte sans problème sur tous mes nœuds. Désormais, il se reconnecte également correctement après le redémarrage du point d'accès. Utilisation du noyau 2.4.1.

ghost le 29 avr. 2018

Héhé, une fois qu'il est chargé, j'ai très peu de temps, alors j'ai juste pris une capture d'écran. J'utilise le contrôleur openhab mqtt, le serveur est mosquitto.

EDIT : je n'utilise pas les règles pour le moment. Juste pour être sûr que ce n'est pas le problème.

louis-lau le 29 avr. 2018

Pareil ici. Essayez de vous abonner à n'importe quel sujet. Cela a résolu mon problème.

-------- Ursprüngliche Nachricht --------
Von: Louis Laureys [email protected]
Gesendet: 29. avril 2018 16:23:54 MESZ
An : letscontrolit/ESPEasy [email protected]
CC : s0170071 [email protected] , Mentionner [email protected]
Betreff : Re : [letscontrolit/ESPEasy] Problèmes de wifi - histoire sans fin - revenir au wifi non basé sur des événements ? (#1302)

Héhé, une fois qu'il est chargé, j'ai très peu de temps, alors j'ai juste pris une capture d'écran. J'utilise le contrôleur openhab mqtt, le serveur est mosquitto.

--
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/letscontrolit/ESPEasy/issues/1302#issuecomment-385255207

s0170071 le 29 avr. 2018

@s0170071 Où cet abonnement doit-il être effectué ?
Si c'est dans une sorte de paramètre par défaut, alors peut-être devrions-nous l'ajouter.

Le temps entre les reconnexions MQTT est-il d'environ 15 à 16 secondes ? Ensuite, il se pourrait que Mosquito vous expulse et que je sache où corriger cela.

TD-er le 29 avr. 2018

Dans les paramètres du contrôleur openhab. Il y a le champ d'abonnement.

s0170071 le 29 avr. 2018

En utilisant le dernier githib (07bfec4), MQTT fonctionne également sans problème ici en utilisant le contrôleur openhab et en se connectant à Mosquitto. Utilisation du noyau 2.4.1.

ghost le 29 avr. 2018

@td-er voir quelques messages ci-dessus.

s0170071 le 29 avr. 2018

Je suis déjà abonné à /sonoff_lavalamp/# comme vous pouvez le voir dans les logs.

J'ai remarqué quand je m'abonne à # (donc, tous les sujets). Le wifi est stable, mais cela rend mqtt inutilisable ;)

Mosquitto ne devrait pas expulser l'utilisateur, l'utilisateur que j'utilise a des autorisations sur tous les sujets.

louis-lau le 29 avr. 2018

Voici le journal des moustiques :

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.

Il semble se reconnecter et Mosquitto ferme l'ancienne connexion.

louis-lau le 29 avr. 2018

J'ai recherché la source de PubSubClient.
Il semble qu'il doit y avoir une activité entrante et sortante dans le délai d'attente.
Si l'un d'eux échoue, PubSubClient se déconnectera et donc ESPeasy se reconnectera.

Je vais essayer d'ajouter une sorte de ping automatique. Il y en a déjà, mais il se peut que le contrôle soit effectué avant le retour du ping.

TD-er le 29 avr. 2018

@louis-lau Pouvez-vous trouver le réglage de l'heure de maintien en vie utilisé dans votre Mosquito?

Il semble que le paramètre de délai d'attente MQTT que nous utilisons est de 15 secondes.
Il est défini comme : #define MQTT_KEEPALIVE 15

Voir aussi https://github.com/knolleary/pubsubclient/issues/239

TD-er le 29 avr. 2018

Wow, tu l'as fait @TD-er !!!!!

467279 : ÉVÉNEMENT : Horloge#Heure=Dim,17:24
467588 : WD : Uptime 8 ConnectFailures 0 FreeMem 16304
481935 : MQTT : Connexion perdue
481935 : ÉVÉNEMENT : MQTT#Déconnecté
481953 : ÉVÉNEMENT : WiFi#Déconnecté
481969 : WIFI : Déconnecté ! Raison : '(1) Non spécifié' Connecté pendant 7 m 40 s
482278 : WIFI : Tentative de connexion SMC #0
482278 : IP : IP statique : 192.168.0.201 GW : 192.168.0.3 SN : 255.255.255.0 DNS : 192.168.0.3
483304 : ÉVÉNEMENT : WiFi#Déconnecté
483322 : WIFI : Déconnecté ! Raison : '(202) Auth fail' Connecté pendant 1018 ms
484291 : WIFI : Tentative de connexion SMC #1
484292 : IP : IP statique : 192.168.0.201 GW : 192.168.0.3 SN : 255.255.255.0 DNS : 192.168.0.3
488073 : WIFI : Connecté ! AP : SMC (78:8A:20:D1:9B:D9) Canal : 1 Durée : 3780 ms
488074 : IP : IP statique : 192.168.0.201 GW : 192.168.0.3 SN : 255.255.255.0 DNS : 192.168.0.3
488078 : WIFI : IP statique : 192.168.0.201 (ESP-201-1) GW : 192.168.0.3 SN : 255.255.255.0 durée : 6 ms
488099 : ÉVÉNEMENT : WiFi#Connecté
488245 : MQTT : Connecté au courtier avec l'ID client : ESPClient_5C:CF:7F:0B:68:52
488247 : Abonné à : ESP-201/#
488248 : ÉVÉNEMENT : MQTT#Connecté
489111 : ÉVÉNEMENT : Heure#Définir

micropet le 29 avr. 2018

@TD-er Êtes-vous sûr que le pubsubclient rencontre des problèmes ? Mon appareil ne reçoit rien, n'envoie une valeur analogique que toutes les 30 secondes. Aucun problème de connexion MQTT. S'il y avait un problème avec la bibliothèque, n'aurions-nous pas beaucoup plus d'utilisateurs à se plaindre ?

ghost le 29 avr. 2018

C'est peut-être une condition de course...

s0170071 le 29 avr. 2018

Le courtier MQTT doit considérer un client comme déconnecté à 1,5 fois le délai d'expiration.
Pubsubclient envoie un ping lorsque la dernière activité remonte à plus de 15 secondes.
Donc, si le délai d'expiration par défaut de Mosquito (10 s) est utilisé, alors le timing devient assez critique.

Lors de ma configuration, je vois beaucoup de trafic MQTT de tous les nœuds ici en train de discuter sur le même canal (domoticz).
Ainsi, le délai d'attente n'est jamais un problème ici.
Mais s'il n'y a qu'un seul nœud, il y a beaucoup moins de trafic et avec le délai d'attente ESPeasy par défaut défini à exactement 1,5 fois le délai d'attente par défaut de Mosquito, cela peut être un peu critique.

TD-er le 29 avr. 2018

Ensuite, il pourrait essayer d'envoyer une valeur analogique factice toutes les 5 secondes pour vérifier si le problème disparaît...

ghost le 29 avr. 2018

Ou utilisez mon dernier commit ;)

TD-er le 29 avr. 2018

Mes reconnexions étaient très rapides, toutes les secondes environ

s0170071 le 29 avr. 2018

Le développeur MQTT ne semble pas aimer ça :
Je ne suis pas enclin à changer la valeur par défaut. Cela faisait 15 secondes depuis plus de 7 ans. Si quoi que ce soit, nous faciliterons la personnalisation et ne dépendrons pas de la modification du fichier d'en-tête.

ghost le 29 avr. 2018

La définition est enveloppée avec #ifdef
Il existe donc une option pour le définir dans d'autres parties du code.

Sur la page github de PubSubclient, il y a aussi un problème pour le rendre configurable.

TD-er le 29 avr. 2018

Autre commentaire de son auteur :
Dans le protocole MQTT, le client détermine la valeur keepalive utilisée sur une connexion. Le courtier n'a pas son mot à dire.

La seule option de configuration keepalive sur mosquitto est son bridge keepalive - où il agit en tant que client se connectant à un autre courtier - https://mosquitto.org/man/mosquitto-conf-5.html

ghost le 29 avr. 2018

J'ai vérifié ma configuration de moustique. Impossible de trouver une option de délai d'attente pour les connexions

ghost le 29 avr. 2018

Ce document traite du comportement du délai d'attente.

TD-er le 29 avr. 2018

Et le document dit la même chose :

Le client MQTT est responsable de la définition de la bonne valeur keep alive. Par exemple, il peut adapter l'intervalle à la force de son signal actuel.

Alors d'où vient le temps Mosquitto de 10 secondes ? C'est codé en dur ?

ghost le 29 avr. 2018

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

keepalive_interval secondes
Définissez le nombre de secondes après lesquelles le pont doit envoyer un ping si aucun autre trafic ne s'est produit. La valeur par défaut est 60. Une valeur minimale de 5 secondes est autorisée.

Grovkillen le 29 avr. 2018

Ce paramètre est uniquement pour le pontage

ghost le 29 avr. 2018

Gardez à l'esprit que ce n'était pas un problème en 20180428 :)

EDIT : J'essaierai votre dernier commit quand je rentrerai à la maison.

louis-lau le 29 avr. 2018

Vous pouvez essayer de désactiver le connectionCheckHandler .

Pour voir ce qui a changé le dernier jour : https://github.com/letscontrolit/ESPEasy/compare/mega@%7B1day%7D...mega

TD-er le 29 avr. 2018

Je viens de mettre à jour vers https://github.com/letscontrolit/ESPEasy/commit/4e6e31fdae11476a2f3dfce00e01ed77d1858c00 et le wifi est maintenant stable. Il se reconnecte également maintenant lorsque je redémarre mon AP ! Merci

louis-lau le 29 avr. 2018

(Au fait, existe-t-il un moyen de basculer le paramètre du voyant d'état Wifi à l'aide de règles ? Par exemple, je voudrais l'activer uniquement si mqtt est déconnecté et l'utiliser pour l'état du relais lorsqu'il est connecté.)

louis-lau le 29 avr. 2018

Je ne suis pas sûr de la LED d'état. Il est appelé depuis la fonction MQTTconnect et depuis quelques autres endroits.
Mais peut-être pourriez-vous ajouter un problème pour rendre sélectionnable ce qui est affiché via cette LED ?

Et c'est bien d'entendre que les problèmes MQTT semblent être résolus par le délai d'attente réduit.
Nous devrons peut-être le rendre sélectionnable.

TD-er le 29 avr. 2018

👍2

Pourriez-vous allonger un peu la fenêtre LOG ?
Je veux dire, augmenter le nombre de lignes.

Sinon ça se passe très bien maintenant.

micropet le 29 avr. 2018

Je viens de les réduire.
C'était 20 lignes, mais avec la 2.4.0, il devait y avoir un peu plus de mémoire libre, donc je l'ai réduit à 10 lignes pour dev/test et 15 pour normal.

Je vais examiner la consommation de mémoire cette semaine et @Grovkillen cherche un moyen d'obtenir une fenêtre de journal appropriée.

TD-er le 29 avr. 2018

OK, je vais dormir.
Merci beaucoup pour votre travail acharné !!

micropet le 29 avr. 2018

À propos de cette fenêtre. Selon moi, il y a trois options.

Utilisez autant de RAM que disponible pour conserver les informations jusqu'à ce qu'elles soient demandées. Peut être dynamique, selon le nombre de plugins actifs.
Diffusez-le sur le navigateur Web.
Compressez-le temporairement et restaurez-le à la demande. Par exemple, utilisez plus de codes numériques. C'est moins lisible bien sûr.

J'aime 2. Donne également un affichage Web fluide. Ce n'est pourtant pas si simple.

s0170071 le 29 avr. 2018

L'idée est d'obtenir une sorte de JavaScript pour collecter le journal et le stocker dans le navigateur.
Il existe plusieurs options pour fournir les données au navigateur, comme le maintien d'une connexion ouverte ou d'autres techniques.
Cela ne laisse que quelques lignes de journal à conserver en mémoire.
Et ce tampon peut également être utilisé pour transférer le journal vers syslog.

L'objet de cache de journal n'est actuellement pas très efficace avec la mémoire. Beaucoup de place pour l'amélioration.

TD-er le 29 avr. 2018

👍1

Je me demande aussi maintenant si différentes versions de moustique
fonctionnant sur différents systèmes d'exploitation ont un comportement différent ?
Je sais qu'ESPeasy devrait être flexible, mais une mise à jour de moustique résoudrait-elle les problèmes pour certains.

Oxyandy le 30 avr. 2018

Seulement pour comprendre...
Pourquoi je reçois directement après avoir démarré mon ESP ceci:

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

Dans syslog, je vois deux messages IP STATIC et 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 le 30 avr. 2018

Peut-être que le terme "reconnecter" n'est pas bien choisi.
C'est plutôt "(re)connecter", ou "tentatives de connexion"
Le compteur commence à 0 et à chaque tentative de connexion c'est un compteur++.

TD-er le 30 avr. 2018

J'ai changé le compteur en l'initialisant à '-1'. Ainsi, la première tentative de connexion le mettra à 0, donc l'étiquette "Number reconnects" a à nouveau un sens :)
Je ne pouvais pas penser à un meilleur nom, alors j'ai changé la valeur signalée ;)

Nommer correctement est toujours la partie la plus difficile de la programmation.

TD-er le 2 mai 2018

Ça sonne bien !

DittelHome le 2 mai 2018

connexion essayer x

uzi18 le 2 mai 2018

Malheureusement, la dernière version 20180503 (4096 dev) ne fonctionne pas pour moi - le Web ESP ne s'ouvre pas, mais il cesse de répondre dans la console série (après la tentative d'ouverture Web). Les paramètres sont réinitialisés aux valeurs par défaut et ne définissent que le WifiSSID et la clé via la console série. PING fonctionne, pas de redémarrage, pas de message d'erreur.

ghtester le 3 mai 2018

👍1

Avez-vous effectué un redémarrage à froid après flash ?
J'ai eu quelque chose de similaire juste après avoir flashé.
Un cycle d'alimentation l'a alors résolu.

TD-er le 3 mai 2018

Oui, j'ai essayé plusieurs fois de redémarrer à froid, c'est toujours pareil. Testé depuis MSIE et Firefox sur Win7. Je vais tester l'appareil à un autre endroit quelques minutes plus tard (PC/OS différent, AP différent).
Juste après le flash, il a redémarré et s'est bloqué.

ghtester le 3 mai 2018

Je l'ai essayé en ce moment, avec la version normale. De mon côté, aucun problème. Aucune remise sous tension n'a été nécessaire.

DittelHome le 3 mai 2018

C'est étrange à un autre endroit, le site Web ESP du même appareil fonctionne (Win10 + Firefox / MS Edge, AP différent) mais la console série a l'air "en lecture seule"... :-/
Mise à jour - essayé une autre application de terminal - la même console série en lecture seule. Ensuite, exécutez à nouveau putty (qui est mon application de terminal par défaut) et voyez l'appareil redémarrer dès que je me suis connecté avec putty au port COM approprié. Maintenant la console série accepte les commandes et le web fonctionne aussi... Je ne comprends rien...

ghtester le 3 mai 2018

Peut-être essayez-vous d'effacer complètement le flash et de programmer à nouveau ?
Il semble y avoir une relation avec la connexion wifi et si le port série est en cours de lecture. J'ai vu quelqu'un en parler dans un fil. Je ne sais pas si c'était sur le problème PlatformIO ou sur LWIP.
J'ai beaucoup lu ces derniers temps ;)

TD-er le 3 mai 2018

Oui, je vais essayer avec une prochaine version, celle-ci que je souhaite tester à nouveau à un autre endroit pour voir si c'est toujours le même problème (configuration de l'appareil mise à jour un peu entre-temps).
D'AILLEURS. lorsque j'ai réinitialisé les paramètres pour la première fois (après ce flash de build, en émettant la commande Reset à partir de la console série), en fait, il n'a PAS réinitialisé les paramètres malgré la mention "formatage flash", etc. L'appareil a redémarré et au moins les paramètres WiFi étaient toujours là comme j'ai vu des tentatives de connexion à AP dans la console série... La deuxième tentative de réinitialisation de la console série a effacé les paramètres...

ghtester le 3 mai 2018

Oui, la bibliothèque principale stocke les paramètres wifi dans une zone en dehors du SPIFF.
Cela peut affecter les tentatives de connexion wifi.

J'ai déjà lu dans le code (de base) qu'il existe désormais un support pour jusqu'à 5 paramètres wifi, que vous pouvez sélectionner.
Alors peut-être que j'utiliserai activement cette zone de stockage également, pour m'assurer qu'elle n'entrera pas en conflit avec nos propres paramètres.
La seule chose dont j'ai peur, c'est que ces paramètres soient écrits trop souvent. Je dois vérifier quand c'est écrit.
Mais cela peut rendre la connexion wifi un peu plus prévisible lorsque cette zone est également prise en compte avec ESPeasy.

TD-er le 3 mai 2018

👍1

@Oxyandy Je vais maintenant pousser le changement PlatformIO.ini pour utiliser LWIP2_LOW_MEMORY.
Pourriez-vous s'il vous plaît tester cela?
Et aussi la question de savoir si vous utilisiez la tâche/l'appareil 12 ?
Je viens de le tester sur mon nœud et presque immédiatement, il s'est déconnecté + a refusé de se reconnecter.
C'était avec LWIP1.4

TD-er le 4 mai 2018

👍1

Et aussi la question de savoir si vous utilisiez la tâche/l'appareil 12 ?

Dans les tests, pas seulement le premier, un seul interrupteur
Oui, il y a 15 fichiers modifiés dans GitHub Desktop qui tirent maintenant

Oxyandy le 4 mai 2018

Compilé très bien, serveur Web génial, utilisant LWIP2_LOW_MEMORY, le test F5, tout simplement génial ..
aucun signe de LmacRxBlk:1 dans les journaux
J'avais effacé tous les paramètres du nœud, mais je vais le "réinitialiser" et suivre le processus, signaler toute bizarrerie.
Wifi connecté instantanément d'abord.

Oxyandy le 4 mai 2018

soyez juste prudent avec la faible mémoire lwIP2, j'ai dû utiliser la bande passante élevée lwIP2, sinon les gros paquets étaient tronqués (par exemple, les capteurs avec plusieurs valeurs), au moins lors de l'utilisation de fhem comme serveur/contrôleur...

J'utilise actuellement la méga branche avec le noyau esp de GIT et la bande passante élevée lwIP2 qui fonctionne bien, sauf qu'après un certain temps, certaines unités ne peuvent plus lire les valeurs des capteurs et ne les enverront donc plus au contrôleur. l'unité elle-même ainsi que l'interface Web fonctionnent bien... Je suis toujours en train d'enquêter là-dessus, je n'ai jamais eu cela dans les commits avant Mai...

clumsy-stefan le 4 mai 2018

Nous avons essayé la bande passante élevée LwIP2 et ces messages POST ont foiré.
Par exemple, les règles de sauvegarde > 1520 octets ont été tronquées.

TD-er le 4 mai 2018

ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Est-ce qu'il s'agit d'une attaque DoS sur les serveurs de temps ?
Après avoir flashé, j'ai été appelé, j'ai des pages et des pages de cette boucle

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 le 4 mai 2018

Avec le noyau actuel (Master, ESP82xx Core 41a64707, NONOS SDK 2.2.1(cfd48f3)) les problèmes de MTU n'apparaissent plus.
Avoir 10 ESP (Sonoff, NodeMcu, W1pro) en cours d'exécution depuis le 1er mai sans aucun problème.

susisstrolch le 4 mai 2018

Pour info... Flashez la dernière version officielle, réinitialisez les paramètres via la série aux valeurs par défaut, entrez le WiFiSSID et les clés. Impossible de se connecter au point d'accès principal alors qu'il était visible (mais un signal faible d'environ -82). Puis s'est écrasé comme vous pouvez le voir ci-dessous.
Dans un autre emplacement, un appareil connecté à un point d'accès secondaire rapidement sans aucun problème et jusqu'à présent, cela fonctionne (mais aucun plugin configuré, aucune règle active).
....
....
458745 : WIFI : Connexion IOTAP1 tentative #57
458749 : Mode AP : Client déconnecté : xx:xx:xx:xx:xx:xx Appareils connectés : 0
458810 : WIFI : Déconnecté ! Raison : " (201) Aucun point d'accès trouvé " Connecté pendant 64 ms
459360 : Mode AP : Client connecté : xx:xx:xx:xx:xx:xx Appareils connectés : 1
471739 : WIFI : L'identifiant du mode AP sera ESP_Easy_0 avec l'adresse 192.168.4.1
471739 : WIFI : Tentative de connexion IOTAP2 #58

Exception (29) :
epc1=0x4000e1c3 epc2=0x00000000 epc3=0x40000f68 excvaddr=0x00000018 depc=0x00000000

ctx : sys
sp : 3ffffc50 fin : 3fffffb0 décalage : 01a0

pile>>>
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 : 3ffff0a 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 7ffffffff 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 : 3ffff10 3fff752c 00000040 3ffeb710
3fffff80 : 00000040 3ffef160 00000002 00000000
3fffff90: 4027de7f 3fffdab0 00000000 40283f5f
3fffffa0: 3ffeb710 40000f49 3fffdab0 40000f49
<<

ets 8 janvier 2013, première cause:2 , mode de démarrage:(3,7)

charge 0x4010f000, len 1384, salle 16
queue 8
somme de chks 0x2d
somme 0x2d
v614f7c32
~ld
-U88 :

INIT : version de démarrage : mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP : 2.0.3)
89 : INIT : Démarrage à chaud #6
90 : FS : Montage...
116 : FS : Montage réussi, utilisé 75802 octets de 957314
436 : CRC : somme de contrôle du programme ...OK
442 : CRC : Paramètres de sécurité CRC ...OK
548 : INIT : RAM libre
549 : INIT : I2C
549 : INIT : SPI non activé
565 : INFO : Plugins : 72 [Normal] [Test] [Développement] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP : 2.0.3)
566 : WIFI : Réglez le WiFi sur STA
599 : WIFI : Connexion IOTAP1 tentative #0
607 : WD : Disponibilité 0 Échecs de connexion 0 FreeMem 20616
3461 : WIFI : Déconnecté ! Raison : " (201) Aucun point d'accès trouvé " Connecté pendant 2861 ms
3604 : WIFI : Connexion IOTAP1 tentative #1
6466 : WIFI : Déconnecté ! Raison : '(201) Aucun AP trouvé' Connecté pendant 2862 ms
6604 : WIFI : Connexion IOTAP2 tentative #2
9467 : WIFI : Déconnecté ! Raison : '(201) Aucun AP trouvé' Connecté pendant 2862 ms
9604 : WIFI : Connexion IOTAP2 tentative #3
12467 : WIFI : Déconnecté ! Raison : '(201) Aucun AP trouvé' Connecté pendant 2862 ms
12604 : WIFI : Connexion IOTAP1 tentative #4
15466 : WIFI : Déconnecté ! Raison : '(201) Aucun AP trouvé' Connecté pendant 2862 ms
15604 : WIFI : Tentative de connexion IOTAP1 #5
18466 : WIFI : Déconnecté ! Raison : '(201) Aucun AP trouvé' Connecté pendant 2862 ms
18604 : WIFI : Réglez le WiFi sur AP+STA
19524 : WIFI : AP Mode ssid sera ESP_Easy_0 avec l'adresse 192.168.4.1
19524 : WIFI : Connexion IOTAP2 tentative #6
22388 : WIFI : Déconnecté ! Raison : " (201) Aucun point d'accès trouvé " Connecté pendant 2863 ms
22603 : WIFI : AP Mode ssid sera ESP_Easy_0 avec l'adresse 192.168.4.1
22603 : WIFI : Connexion IOTAP2 tentative #7
25463 : WIFI : Déconnecté ! Raison : " (201) Aucun point d'accès trouvé " Connecté pendant 2860 ms
25602 : WIFI : le ssid du mode AP sera ESP_Easy_0 avec l'adresse 192.168.4.1
25603 : WIFI : Connexion IOTAP1 tentative #8
28464 : WIFI : Déconnecté ! Raison : " (201) Aucun point d'accès trouvé " Connecté pendant 2860 ms
28602 : WIFI : L'identifiant du mode AP sera ESP_Easy_0 avec l'adresse 192.168.4.1
28603 : WIFI : Connexion IOTAP1 tentative #9
30606 : WD : Temps de disponibilité 1 Échecs de connexion 0 FreeMem 18176
...
...

ghtester le 4 mai 2018

J'ai vu cette erreur "Aucun AP trouvé" également hier.
Cela semble être lié à des paramètres incorrects ou corrompus. Pas seulement les paramètres que nous stockons, mais peut-être aussi les paramètres stockés dans une autre partie du flash, par la bibliothèque principale.

Les mises à jour

@susisstrolch Pourriez-vous tester pour écrire un fichier de règles contenant > 1800 octets ?
La version à bande passante élevée LWIP2 corrompt les requêtes HTTP POST lorsqu'elles dépassent une taille MTU.

TD-er le 4 mai 2018

Salut Gijs,
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Si vous avez vu le journal, c'est un modèle, se connecte toujours, MQTT se connecte, met à jour l'heure

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

toutes les 10 à 12 secondes, en boucle comme ça pendant des heures, oups

Oxyandy le 4 mai 2018

Taille de la règle de mon appareil pondctrl : Taille actuelle : 1859 caractères (Max 2048)
MTU : 534 (faible mémoire lwip 2.x)
Aucun problème - changé plusieurs fois cette semaine.

susisstrolch le 4 mai 2018

Nous utilisons actuellement LwIP 2.x à faible mémoire, car la version à bande passante élevée posait ces problèmes.
@Oxyandy Je vais examiner le code concernant la mise à jour de l'heure et bien sûr la boucle de reconnexion.
Ce sujet devient de plus en plus d'actualité :(

TD-er le 4 mai 2018

Je ne comprends pas, celui que j'ai compilé homebrew (ce matin) selon votre demande a très bien fonctionné..
puis quand la version officielle était disponible, j'ai pensé que je ferais mieux de l'utiliser, j'ai été choqué par la différence.
Maintenant, concernant votre dernière réponse.. la mise à jour de l'heure est bonne..
la version officielle d'aujourd'hui se connecte au wifi sans problème, se connecte à MQTT, obtient l'heure, puis abandonne la connexion avec "(200) Beacon timeout" puis boucle toutes les 11 secondes
Connecter - wifi, MQTT, heure, déconnecter, répéter
Alors ne regardez pas "mise à jour de l'heure", s'il restait connecté, ce serait bien...

Oxyandy le 4 mai 2018

C'est étrange. Il y a quelque chose de vraiment génial dans le processus de construction de PlatformIO.
J'ai remarqué moi-même à quelques reprises que le construire pour la deuxième fois fait une différence.
C'est comme s'il y avait quelque chose qui ne va pas au niveau de l'éditeur de liens dans PlatformIO.
C'est vraiment étrange ce qui se passe ici.

TD-er le 4 mai 2018

c'est probablement dans les drapeaux du compilateur ou de l'éditeur de liens. L'optimisation peut être une garce.
L'IDE Arduino a ce fichier de configuration (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 le 4 mai 2018

👍1

Pour éviter tout problème avec platformIO, j'ai supprimé le dossier .pioenvs et j'ai quand même exécuté 'Clean'
Depuis le build de ce matin - 2 fichiers ont changé
ESPEasy-Globals.h & Misc.ino (Correction de la corruption des paramètres de tâche)

Oxyandy le 4 mai 2018

Commencer à faire ceci : ma structure de dossiers actuelle est GitHub/ESpeasy
Je copie le dossier ESpeasy et le renomme pour inclure la date avant de faire une recherche, cela m'aidera à comparer les modifications localement.

Oxyandy le 4 mai 2018

FritzBox a fait une mise à jour automatique du firmware. Tous les ESP ont basculé vers l'autre point d'accès maillé sans aucun problème.

susisstrolch le 4 mai 2018

@TD-er vous avez dit "Avez-vous ce délai d'attente de balise avec 0504 sur n'importe quel nœud, ou juste quelques-uns?"
Ok, pour être juste, je vais prendre un nouveau module et flasher cela et à l'avenir flasher 2 nœuds pour chaque nouveau firmware.
J'ai du temps à perdre car il n'y a que 16h dans ta partie du monde

Oxyandy le 4 mai 2018

Ok, un tout nouveau Node, effacé.
Flashé avec ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Le journal ci-dessous a un comportement identique à l'autre nœud.
Pouvez-vous voir le modèle dans le journal ?

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 le 4 mai 2018

Ah je suppose qu'il est temps que je configure un point d'accès spécial exécutant wireshark

Oxyandy le 4 mai 2018

En utilisant GitHub Desktop, j'ai récupéré la dernière source 'live' qui comprend seulement 2 fichiers modifiés de https://github.com/letscontrolit/ESPEasy/commit/92680c5542b76a15db16af198a3a07ed17618c4e depuis ma compilation de travail de ce matin, fait une version du soir et cela fonctionne parfaitement ..
Pourquoi les builds nocturnes sont-ils différents si c'est la même source, que se passe-t-il différemment sur GitHub ?

Oxyandy le 4 mai 2018

Quelqu'un utilise Arduino IDE ?
Êtes-vous capable de construire un "ESP8266 normal 1024" à partir du src actuel et de le déposer ici ?
Merci

Oxyandy le 4 mai 2018

Je ne sais pas si cela est lié à certains des problèmes aléatoires que nous rencontrons, mais j'ai remarqué qu'après un certain temps, mes unités arrêtent d'envoyer des données au contrôleur. Cependant, l'interface Web est toujours opérationnelle, mais elle affiche une adresse IP de 0.0.0.0. (voir capture d'écran). Quelqu'un d'autre voit ça ?

untitled

clumsy-stefan le 4 mai 2018

De quelle version de build s'agit-il ?

TD-er le 4 mai 2018

@Oxyandy

Pourquoi les builds nocturnes sont-ils différents si c'est la même source, que se passe-t-il différemment sur GitHub ?

C'est ce que je me demande aussi.
Je suppose que cela a quelque chose à voir avec le fait que nous devons aussi parfois le construire deux fois lorsque nous le construisons nous-mêmes.
Il semble y avoir quelque chose qui ne va pas avec la façon dont nous compilons les choses, ou avec le compilateur.
Cela explique peut-être aussi pourquoi nous voyons tant de choses très difficiles, voire impossibles, à reproduire ces dernières semaines.

J'en ai également discuté avec @arendst de Tasmota, et il a confirmé qu'il devait également reconstruire de temps en temps pour obtenir une bonne version fonctionnelle.
Je demanderai à @psy0rz s'il est possible de construire les versions nocturnes deux fois à titre de test.

TD-er le 4 mai 2018

auto-compilé à partir de mega-20180503
Construire | 20102 - Méga
Bibliothèques | ESP82xx Core 76a14b1f, SDK NONOS 2.2.1 (cfd48f3), LWIP : 2.0.3

clumsy-stefan le 4 mai 2018

Pourriez-vous essayer de le construire deux fois, avant de l'écrire dans le nœud ?
Pas de nettoyage entre les versions, il suffit de le construire et de le reconstruire.

TD-er le 4 mai 2018

bien sûr, mais j'utilise Arduino SDK sur un mac, pas platformIO... ça vaut toujours le coup d'essayer ?

clumsy-stefan le 4 mai 2018

Oui, s'il vous plaît, car nous n'avons pas encore la moindre idée de ce qui en est la cause.
Assurez-vous simplement que vous utilisez les mêmes bibliothèques de base que nous, car Arduino IDE ne regarde pas les versions fixes définies dans PlatformIO.
Les versions actuelles que nous utilisons sont :
ESP82xx Core 2_4_1, SDK NONOS 2.2.1 (cfd48f3), LWIP : 2.0.3

TD-er le 4 mai 2018

ok, je vais essayer ça maintenant et flasher quelques unités. Je signalerai dès qu'il se passera quelque chose... ou rien du tout ;)

clumsy-stefan le 4 mai 2018

D'AILLEURS. la version actuelle peut être bloquée à tout moment en maintenant la touche F5 enfoncée dans le navigateur Web au moins sur les pages Appareil ou Notifications (probablement sur n'importe quelle page Web ESP) pendant quelques secondes. Je peux le répéter à tout moment depuis Firefox sur Win10 :
...
...
39543696 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39551825 : LoadFromFile : index config.dat : 27648 taille des données : 320
39557599 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39566681 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39566879 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39567105 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39567490 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39567690 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39567883 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39568086 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39568287 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39568495 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39568701 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39568910 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39569112 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39569324 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39569530 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39569739 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39569948 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39570158 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39570366 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39570582 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
39570742 : page Web ignorée : mémoire insuffisante : 1784
39570832 : page Web ignorée : mémoire insuffisante : 1784
39570906 : page Web ignorée : mémoire insuffisante : 1784
39570992 : page Web ignorée : mémoire insuffisante : 1784
39571074 : page Web ignorée : mémoire insuffisante : 1784
39571161 : page Web ignorée : mémoire insuffisante : 1784
39571240 : page Web ignorée : mémoire insuffisante : 1784
39571322 : page Web ignorée : mémoire insuffisante : 1784
39571401 : page Web ignorée : mémoire insuffisante : 1784

Exception (28) :
epc1=0x4025cb66 epc2=0x00000000 epc3=0x401003f2 excvaddr=0x00000000 depc=0x00000000

ctx : suite
sp : 3fff4690 fin : 3fff4b20 décalage : 01a0

pile>>>
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 : 0000001 3fff16d4 3fff6294 40227cb4
3fff48f0 : 3fffb414 0000000f 00000007 4010053d
3fff4900 : 3fff4d6c 00000855 00000855 3fff4d6c
3fff4910 : 00000010 000000010 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 0000001 3fff1868 40253308
3fff49a0 : 3fff4d6c 00000c35 00000c35 4010020c
3fff49b0 : 0000001 0000001 3fff49e0 40107b70
3fff49c0: ffffffff 40107b70 00000000 40257a14
3fff49d0 : 4020a8ca 0000001 3fff6294 4022fd96
3fff49e0 : 00000000 00000000 00000000 40253308
3fff49f0 : 0000001 0000001 3fff6294 4022fe80
3fff4a00 : 0000001 0000001 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 0000001 00000000 4024d200
3fff4a80 : 0000001 00000000 40251b18 0000000d
3fff4a90 : 00000000 3fff7b4c 3fff3628 3fff3af4
3fff4aa0 : 0000001 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 0000001 40258a31
3fff4b00 : 3fffdad0 00000000 3fff3aee 40258a5c
3fff4b10 : fefeffe fefeffe 3fff3b00 40100700
<<

ets 8 janvier 2013, première cause:2 , mode de démarrage:(3,7)

charge 0x4010f000, len 1384, salle 16
queue 8
somme de chks 0x2d
somme 0x2d
v614f7c32
~ld
U88 :

INIT : version de démarrage : mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP : 2.0.3)
89 : INIT : Démarrage à chaud #3
90 : FS : Montage...
115 : FS : Montage réussi, utilisé 75802 octets de 957314
437 : CRC : somme de contrôle du programme ...OK
469 : CRC : Paramètres de sécurité CRC ...OK
575 : INIT : RAM libre
575 : INIT : I2C
575 : INIT : SPI non activé
1677 : INFO : Plugins : 72 [Normal] [Test] [Développement] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP : 2.0.3)
1678 : EVENEMENT : System#Wake
1682 : WIFI : Réglez le WiFi sur STA
...
...

L'appareil s'est ensuite connecté avec succès au point d'accès. Encore une panne :

973 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
279178 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
279387 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
279590 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
279798 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
280321 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
280558 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
280785 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
Exception fatale 28 (LoadProhibitedCause) :
epc1=0x4025cb66, epc2=0x00000000, epc3=0x40100408, excvaddr=0x00000000, depc=0x00000000

Exception (28) :
epc1=0x4025cb66 epc2=0x00000000 epc3=0x40100408 excvaddr=0x00000000 depc=0x00000000

ctx : suite
sp : 3fff4690 fin : 3fff4b20 décalage : 01a0

pile>>>
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 : 0000001 3fff16d4 3fff773c 40227cb4
3fff48f0 : 3fff83ac 0000000f 00000007 4010053d
3fff4900 : 3fff4d6c 00000a67 00000a67 3fff4d6c
3fff4910 : 00000010 000000010 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 0000001 3fff185c 40253308
3fff49a0 : 3fff4d6c 00000628 00000628 4010020c
3fff49b0 : 0000001 0000001 3fff49e0 40107b70
3fff49c0: ffffffff 40107b70 00000000 40257a14
3fff49d0 : 4020a8ca 0000001 3fff773c 4022fd96
3fff49e0 : 00000000 00000000 00000000 40253308
3fff49f0 : 0000001 0000001 3fff773c 4022fe80
3fff4a00 : 0000001 0000001 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 0000001 00000000 4024d200
3fff4a80 : 0000001 00000000 40251b18 0000000d
3fff4a90 : 00000000 3fff9b0c 3fff3628 3fff3af4
3fff4aa0 : 0000001 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 0000001 40258a31
3fff4b00 : 3fffdad0 00000000 3fff3aee 40258a5c
3fff4b10 : fefeffe fefeffe 3fff3b00 40100700
<<

ets 8 janvier 2013, première cause:2 , mode de démarrage:(3,7)

charge 0x4010f000, len 1384, salle 16
queue 8
somme de chks 0x2d
somme 0x2d
v614f7c32
~ld
U89 :

INIT : version de démarrage : mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP : 2.0.3)
89 : INIT : Démarrage à chaud #8
91 : FS : Montage...
116 : FS : Montage réussi, utilisé 75802 octets de 957314
438 : CRC : somme de contrôle du programme ...OK
469 : CRC : Paramètres de sécurité CRC ...OK
575 : INIT : RAM libre
576 : INIT : I2C
576 : INIT : SPI non activé
1678 : INFO : Plugins : 72 [Normal] [Test] [Développement] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP : 2.0.3)
1678 : EVENEMENT : System#Wake
1683 : WIFI : Réglez le WiFi sur STA
...

ghtester le 4 mai 2018

Eh bien, c'est avec 72 plugins, qu'en est-il de la normale qui se comporte de la même manière ;)

Oxyandy le 4 mai 2018

C'est normal si vous inondez la pile IP de requêtes. La seule chose qui aide est de servir le serveur Web plus souvent afin que le tampon entrant soit à nouveau libéré.

s0170071 le 4 mai 2018

Au moins, c'est bien qui est récupérable - un blocage complet serait pire que le redémarrage ... Mais il est étrange que la cause du démarrage n'ait pas été la même à chaque fois - j'ai également vu la cause 4.

ghtester le 4 mai 2018

ESP_Easy_mega-20180504_test_ESP8266_1024.bin
Je peux me connecter au wifi (premier essai) et rester connecté
F5 (page Périphériques) ne provoque aucune erreur ni plantage
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Se connecte et échoue dans un cycle de 11 secondes de plus en plus - (200) Délai d'expiration de la balise
ESP_Easy_mega-20180504_normal_ESP8266_1024_(Self_Compiled).bin
Parfait

Oxyandy le 4 mai 2018

😕1

@Oxyandy Répétition automatique du clavier lent ? ;-)
Le mien plante sur toutes les pages Web que j'ai essayées.

ghtester le 4 mai 2018

@ghtester Je vais construire un set sur mon PC, avec tout le code actuel. La construction prendra environ 30 minutes.

TD-er le 4 mai 2018

@TD-er Merci beaucoup pour vos efforts, je le testerai lorsque la nouvelle version sera prête.

ghtester le 4 mai 2018

@TD-er a flashé mes unités (16) maintenant avec ESP82xx Core 2_4_1, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 construit deux fois avant de flasher... Je verrai demain s'ils sont toujours en vie et s'ils envoient data... J'ai dû prendre la bande passante élevée lwIP2 sinon les données envoyées via le contrôleur FHEM sont tronquées !
mais besoin de dormir maintenant.... n8

clumsy-stefan le 5 mai 2018

Soyez conscient des problèmes HTTP POST avec la version à bande passante élevée.

Ma version est maintenant en cours d'exécution pour la 3ème fois (il y avait un problème ESP32 qui devait être corrigé et je voulais m'assurer que seule la liaison est effectuée dans la dernière version)
Il y aura donc un fichier zip dans quelques minutes.
Ensuite, je vais me coucher aussi.

TD-er le 5 mai 2018

Voir la version : https://github.com/letscontrolit/ESPEasy/releases/tag/mega-20180505_TD-er

TD-er le 5 mai 2018

TD-er, votre build, mon matériel, pas de problème avec le (normal 1024 8266)
En attendant que la version quotidienne s'affiche, nous essaierons ensuite ;)

Oxyandy le 5 mai 2018

@TD-er Merci beaucoup, rapidement testé la version 4096 dev (à suivre), le problème de redémarrage "F5" est toujours là (la première tentative a complètement bloqué l'appareil) et les informations du micrologiciel indiquent que la vérification MD5 échoue (je suppose que c'est dû à test de construction). Néanmoins, tout le reste va bien jusqu'à présent et il se connecte parfaitement et rapidement à AP.

Build 20102 - Méga
Bibliothèques ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP : 2.0.3
Version GIT
Plugins 72 [Normal] [Test] [Développement]
Construire Md5 4d44355f4d44355f4d44355f4d44355f
Échec du contrôle Md5 !
Temps de construction 5 mai 2018 00:33:21
Nom de fichier binaire ThisIsTheDummyPlaceHolderForTheBinaryFilename...

ghtester le 5 mai 2018

Tels que construits et publiés sur GitHub, ces deux BIN, à 1 jour (1 Build) d'intervalle.
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Confirmé "défectueux" de nombreuses manières différentes, réinitialisation, différents nœuds, etc.
les problèmes cohérents (201 Beacon Timeout) dans une boucle de 11 secondes
Homebrew fonctionnant parfaitement à partir de la même source.
à
ESP_Easy_mega-20180505_normal_ESP8266_1024.bin
Fonctionne parfaitement, les changements de source étant minimes
me dit que les versions de GitHub ont un échec "quelque part" dans la compilation.
Connecté au Wi-Fi pour un premier essai, mise à jour instantanée de l'heure, pas de suppression du Wi-Fi une fois,
MQTT maintenant la connexion
etc -
rien à redire ;)

Oxyandy le 5 mai 2018

Cela signifie donc que beaucoup de temps passé ces dernières semaines (???) peut être dû à des problèmes de compilation ?
C'est malheureux, mais cela me donne au moins confiance que je ne perds pas la tête en voyant toutes sortes de problèmes signalés que je ne pouvais ni reproduire ni expliquer.

TD-er le 5 mai 2018

😕1

En ce qui concerne le problème f5 : essayez lwip à bande passante élevée car il avait des tampons plus grands. Il peut planter un peu plus tard.

s0170071 le 5 mai 2018

Problèmes de compilation : vous tournez à 80 MHz, n'est-ce pas ?

s0170071 le 5 mai 2018

80 MHz est la valeur par défaut, je suppose.

TD-er le 5 mai 2018

Je sais. Mais le régler sur 160 peut provoquer un comportement étrange.

s0170071 le 5 mai 2018

Oui, le problème "F5" est le seul problème sérieux que je vois jusqu'à présent dans cette version spéciale. En fait, si j'appuie simplement plusieurs fois dessus pour actualiser la page Web ESP, cela crée des problèmes :

18084332 : EVENT : Clock#Time=Sat,08:47 Temps de traitement
18091174 : WD : Uptime 302 ConnectFailures 0 FreeMem 14504
bcn_timout, ap_probe_send_start
18112119 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18115167 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18116976 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18119084 : LoadFromFile : index notification.dat : 0 taille des données : 996
18119089 : LoadFromFile : notification.dat index : 1024 datasize : 996
18119092 : LoadFromFile : index notification.dat : 2048 taille des données : 996
18119129 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18121330 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18121337 : WD : Temps de disponibilité 302 Échecs de connexion 0 FreeMem 13584
18128862 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18130833 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18135120 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18136605 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18138356 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18140067 : LoadFromFile : notification.dat index : 0 taille des données : 996
18140076 : LoadFromFile : notification.dat index : 1024 datasize : 996
18140078 : LoadFromFile : notification.dat index : 2048 datasize : 996
18140152 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18144694 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18144700 : ÉVÉNEMENT : Horloge#Heure=Sam,08:48
18144702 : EVENT : Clock#Time=Sat,08:48 Temps de traitement
18148558 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18151336 : WD : Temps de disponibilité 303 Échecs de connexion 0 FreeMem 12568
18153230 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18153763 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18155000 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18155592 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18156416 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18156838 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18164949 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18165234 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18165587 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18170770 : Utilisation de la RAM : Serveur Web uniquement : 0 y compris Core : 0
18170947 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18171120 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18171300 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18171733 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18177686 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
bcn_timout, ap_probe_send_start
18181336 : WD : Temps de disponibilité 303 Échecs de connexion 0 FreeMem 10832
18182865 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18183367 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18188878 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18190025 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18203237 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18203809 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18203817 : ÉVÉNEMENT : Horloge#Heure=Sam,08:49
18203819 : EVENT : Clock#Time=Sat,08:49 Temps de traitement
bcn_timout, ap_probe_send_start
bcn_timout, ap_probe_send_start
bcn_timout, ap_probe_send_start
18496844 : Utilisation de la RAM : Serveur Web uniquement : 0, y compris Core : 0
18496850 : WD : Temps de disponibilité 304 Échecs de connexion 0 FreeMem 8736
18496856 : ÉVÉNEMENT : Horloge#Heure=Sam,08:53
18496858 : EVENT : Clock#Time=Sat,08:53 Temps de traitement

Après les trois derniers messages bcn_timout,ap_probe_send_start, l'appareil a été gelé pendant environ 60 secondes, même dans la console série, puis il a continué à fonctionner sans redémarrage.

Oui, il fonctionne à 80 MHz - Les informations système indiquent : ESP Chip Freq : 80 MHz

Les réponses Web ESP sont très rapides jusqu'à ce que j'essaye de rafraîchir trop rapidement...

ghtester le 5 mai 2018

matin tout... mes unités fonctionnent de manière stable depuis environ 10 heures maintenant. Cependant, les problèmes n'ont parfois augmenté qu'après un jour ou deux, alors je les laisse fonctionner comme ça. une unité a redémarré deux fois pendant la nuit (sur 16 D1), ce qui pourrait être lié au plugin ou à un autre... les bases de sonoff fonctionnent également sans problème.

clumsy-stefan le 5 mai 2018

Je sais que vous ne pouviez pas voir ou expliquer TD-er, mais avez-vous utilisé les versions GitHub comme test ?
Je pourrais revenir sur la source des versions du mois dernier et comparer avec l'homebrew
J'en ai eu plein que j'ai jugé inutile, un de mes onglets dans Notepad++ a la liste

Oxyandy le 5 mai 2018

A propos de F5, ce n'est pas vraiment un problème - je l'utilise comme référence, je n'ai pas de rafraîchissement automatique pour la touche F5,
donc je le frappe manuellement, en surveillant l'utilisation de la RAM et la sortie du journal série en même temps.
"lwip haute bande passante" de la mémoire avait presque instantanément
LmacRxBlk:1 erreurs et elles n'étaient pas récupérables.
Ce qui me rappelle que je suis censé écrire quelque chose sur la liste des choses à faire.
Et je vais réessayer différents paramètres de compilation comme mesure

Oxyandy le 5 mai 2018

Hmm, je ne sais pas si la raison est que j'ai configuré un écran LCD à la position 12 mais peu de temps après, j'ai perdu la connexion à AP et je ne peux plus me reconnecter (Aucun AP trouvé malgré qu'il soit visible par wifiscan). Après redémarrage, même problème. Ensuite, l'appareil est entré en mode AP, mais peut-être en raison de soulignements dans le nom du SSID, il a dit :

1127917 : WIFI : Erreur lors du démarrage du mode AP avec SSID : ESP_01_1 IP : 192.168.4.1

Mais l'appareil était visible sous le nom AI-THINKER_XXXXXXX, j'ai pu le connecter mais lorsque j'ai essayé de changer le nom de l'appareil, etc.

Mise à jour - après plusieurs tentatives, j'ai renommé l'appareil pour supprimer le soulignement, mais il y a toujours avant le numéro d'appareil :
599417 : WIFI : Erreur lors du démarrage du mode AP avec SSID : ESP-001_1 IP : 192.168.4.1
Et l'appareil est toujours visible sous le nom AI-THINKER_XXXXXXX
Je ne peux plus me connecter à mon AP en tant que client... Je vais essayer de réinitialiser les paramètres d'usine...

Update2 OK... Réinitialisation d'usine, appareil visible en tant qu'AP ESP_Easy_0... Définissez le WifiSSID et la WifiKey via la console série, l'appareil est immédiatement connecté à l'AP...

ghtester le 5 mai 2018

la plupart de mes unités fonctionnent toujours bien... mais je ne pense pas vraiment qu'il s'agisse de compiler deux fois... la seule différence est que certaines bibliothèques ne sont compilées que la première fois, puis après cela, lorsque le SDK voit qu'elles n'a pas changé, il ne sera pas recompilé...

une autre chose que je vais essayer maintenant est qu'au lieu de spécifier la carte "D1 Mini" dans arduino, je définis tous les paramètres moi-même et j'utilise le module "generic 8266"... nous verrons si cela fait une différence...

actuellement, la seule chose que je vois, ce sont des redémarrages spontanés de certaines unités... mais cela pourrait être lié à d'autres choses...

une question de ma part: sonoff basic n'a que 1M de mémoire... une chance de mettre ces choses à jour OTA? il prétend évidemment toujours "pas assez de mémoire"... des idées ?

PS : à propos des problèmes de compilation, j'ai toujours utilisé des binaires auto-compilés (autres plugins) depuis le début, et j'ai eu les "mêmes" problèmes de stabilité... donc certains d'entre eux pourraient vraiment être liés à platformIO, d'autres je pense étaient de "vrais" problèmes. ..

clumsy-stefan le 5 mai 2018

Vous pouvez utiliser moins de plugins lors de la compilation. Regardez https://github.com/letscontrolit/ESPEasy/blob/mega/src/define_plugin_sets.h

Vous ne pourrez jamais utiliser l'OTA directement, mais de cette façon, il est au moins assez petit pour l'OTA en deux étapes. Regardez le wiki pour celui-là :)

louis-lau le 5 mai 2018

c'est exactement ce que j'ai fait... c'est pourquoi je compile toujours moi-même... mais même avec seulement 2 plugins activés, le sketch utilise 500k...
c'est pourquoi je recherche une solution différente (par exemple, pas d'interface Web... etc.).

clumsy-stefan le 5 mai 2018

500k est assez petit. Comme je l'ai dit, OTA en deux parties. Vous ne pouvez pas mettre à jour directement. Regarde le wiki :)

louis-lau le 5 mai 2018

thx.. recherche.... ;)

ajouter : d'une manière ou d'une autre, j'ai raté la partie en deux étapes...

clumsy-stefan le 5 mai 2018

Avec 1M Sonoffs, vous devrez utiliser un téléchargeur initial qui a le drapeau DOUT dans l'en-tête,
de mémoire celui sur le Wiki ne l'est pas, mais peut avoir été mis à jour récemment.

Oxyandy le 6 mai 2018

Je me souviens de quelque chose comme ça, je viens de chercher et j'utilise celui-ci pour OTA: https://github.com/soif/EspBuddy/blob/master/firmwares/ESPEasyUploader.OTA.1m128.esp8266.bin

louis-lau le 6 mai 2018

Oui, vérifié c'est DOUT
En voici un que j'ai mis en place, il est plus petit
Initial_Firmware_Uploader_Sonoff_1M_DOUT.zip

Oxyandy le 6 mai 2018

J'ai dit que je le ferais parce que j'étais très curieux........
En comparaison avec Self_Compiled mega-20180422 sur GitHub publié, jusqu'à présent - j'en ai essayé un seul
ESP_Easy_mega-20180422_normal_ESP8266_1024.bin
J'ai laissé un commentaire et je me connecte à son comportement ici https://github.com/letscontrolit/ESPEasy/issues/1301#issuecomment -383433822 (GitHub publié)
Même source auto-compilée, pas de surprise, je vois un comportement différent du Nightly.
Il est resté connecté, choc horreur !
GitHub a publié mega-20180422, flashé par-dessus, exactement le même comportement que j'ai signalé lorsque je l'ai essayé pour la première fois.
Ne resterait pas connecté, WIFI : Disconnected! Reason: '(200) Beacon timeout' vélo encore et encore
La cause doit être étudiée... soupir
GitHub publié = à ne pas faire confiance ?

Oxyandy le 6 mai 2018

J'ai posté les drapeaux du compilateur Arduino hier environ. Quels drapeaux Travis utilise-t-il ?

s0170071 le 6 mai 2018

👍1

J'ai 16 D1 et 3 basics fonctionnant sur f69e476 auto-compilés, Core 2.4.1, lwIP2 High bandwith.
Presque tous avec une disponibilité de > 900 min. maintenant et fonctionne toujours bien. 2 d'entre eux sont passés en mode AP il y a environ une heure et ne se sont pas reconnectés jusqu'à maintenant. Je vais attendre ce soir et voir s'ils récupèrent.

malheureusement, le comportement n'est pas vraiment reproductible, et je ne peux pas vraiment fournir de preuves d'où viennent les problèmes, mais je continuerai à rechercher les défauts et à le signaler si je trouve quelque chose...

@Oxyandy : J'ai aussi recompilé un téléchargement pour mes travaux de base très bien ! merci encore de m'avoir indiqué la bonne direction .. ;)

clumsy-stefan le 6 mai 2018

@s0170071
Ils sont stockés dans .travis.yml & platformio.ini
J'ai accéléré la lecture, tada, regarde ce que j'ai trouvé
skip_cleanup: true
Edit : Pour en savoir plus, je ne sais pas si cela fait référence à la création d'une version propre ?
J'avoue que c'est tout nouveau pour moi... ??? Désactiver la mise en cache ?

Oxyandy le 6 mai 2018

Travis effectue une construction propre à chaque fois, car il télécharge même l'environnement python, etc.

Les builds nocturnes sont effectués par @psy0rz , pas par Travis

TD-er le 6 mai 2018

👍1

Okee dokee, alors sont-ils des builds propres ?
Essayer de comprendre pourquoi ils se comportent différemment ?

Oxyandy le 6 mai 2018

Pourquoi comparer MD5 de bin1 et bin2 ?
Il indiquera s'il s'agit d'un problème de compilation ou d'exécution...

susisstrolch le 6 mai 2018

@susisstrolch tu veux dire quand tu te
https://github.com/s0170071/CRC4ESP

-edit: @susisstrolch je vous ai peut-être mal compris :-)
oui, vous pouvez comparer les md5, ils doivent être identiques. Si vous le faites hors ligne, vous pouvez également comparer les binaires au niveau du bit. De cette façon, vous pouvez même dire où se trouve la déviation. Si vous êtes avancé, vous pouvez même revenir en arrière sur le code. Le fichier .elf doit contenir toutes les informations.

De toute façon, je ne me soucie pas tellement de ce qui diffère exactement. Je pense qu'il est plus important de s'assurer qu'ils sont tous sur le même binaire, peu importe qui l'a compilé.

Encore une fois, quels sont les drapeaux de compilation pour Arduino, platformio, nightly et travis ? Win/Linux,.

s0170071 le 6 mai 2018

Non - Je veux dire au lieu de spéculer sur les différences de sortie du compilateur dans les versions automatisées, comparez simplement le MD5 des deux versions. Ainsi, vous pouvez dire exactement s'ils diffèrent.

susisstrolch le 6 mai 2018

Les drapeaux pour Arduino IDE sur Linux sont :

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 le 6 mai 2018

@ s0170071 J'ai essayé de demander à Edwin, mais il n'a pas encore répondu.
Donc, pour l'instant, nous ne savons pas exactement ce qui est fait pour les versions nocturnes.
Et le comportement étrange persiste (que j'ai également rencontré sur ma configuration) selon lequel le compiler deux fois donne des résultats différents.
Les binaires entre les versions ne peuvent pas être comparés via une somme de contrôle. Il y a un horodatage de build inclus, qui sera différent pour chaque build. Donc, compiler la même source 100 fois donnera 100 sommes de contrôle différentes.
Mais au moins, cela devrait donner la même fonctionnalité et cela ne semble pas se produire (parfois) entre la première et la deuxième version. Et ce n'est pas comme ça que ça devrait être.

TD-er le 6 mai 2018

Donc, à des fins de test et pour le comprendre, je sauterais de définir toutes les modifications de précompilation entre ces compilations consécutives pour obtenir un src comparable.

susisstrolch le 6 mai 2018

@ s0170071 donc nous obtenons beaucoup d'informations de débogage en raison de l'option -g lors de la construction avec Arduino IDE.
Peut-être un point pour réduire la taille...

susisstrolch le 6 mai 2018

La réduction de la taille est quelque chose que nous devons examiner à l'avenir, mais vous devez faire attention lorsque vous changez d'indicateur d'optimisation. Certains peuvent conduire à des problèmes encore plus difficiles à reproduire.

TD-er le 6 mai 2018

les deux untis ont récupéré quelques heures plus tard dans la journée, mais d'autres échouent au hasard... deux choses que j'ai trouvées jusqu'à maintenant :
J'obtiens des entrées dans le journal disant :
96493069 : IP bloqué : 0.0.0.0 Autorisé : 10.0.0.0 - 10.0.255.255
96517068 : WD : Disponibilité 1608 Échecs de connexion 0 FreeMem 11544
la première ligne me semble étrange, qu'est-ce qui essaie de se connecter avec IP 0.0.0.0 ? cela pourrait être lié aux problèmes que j'ai vus il y a quelques jours, à savoir que l'unité est accessible, mais cela me dit qu'elle a l'IP 0.0.0.0.

deuxième chose, même si rien n'a été fait au cours des dernières 24 heures, je constate des sauts soudains de charge CPU, même dans les "petites" unités, qui utilisent simplement la fonctionnalité de commutation (par exemple, le numéro 7 dans le graphique ci-joint).

Avez-vous une chance de savoir pourquoi ces changements soudains de la charge du processeur se produisent ? le journal ne dit rien de spécifique.. (Charge CPU d'aujourd'hui et d'hier)...

clumsy-stefan le 6 mai 2018

La charge CPU saute-t-elle au moment d'un redémarrage ?
La façon dont la charge CPU est calculée est juste un peu étrange.
Cela prend le nombre de fois que la fonction de boucle principale est exécutée en 30 secondes.
Ceci est comparé au nombre maximum observé.
Cela signifie qu'en fonctionnement le nombre maximum observé peut augmenter, mais aussi qu'il peut diminuer brutalement après un redémarrage.

TD-er le 6 mai 2018

non, pas lors d'un redémarrage... juste "au hasard" à un moment donné... il est intéressant de noter que cela arrive à plusieurs unités à la fois... Je n'ai aucune idée de ce qui s'est passé là-bas (je n'étais pas à la maison à ce moment-là)... 14 sont des cartes vraiment simples sans tâches à part rssi, load, uptime et mem... les graphiques de mémoire ne montrent également aucun signe de changements significatifs...
encore maintenant, la charge sur certaines unités affiche ~ 50% mais l'interface Web est rapide.

J'ai aussi sur une unité une montre pilotée par nfx qui change chaque seconde la position des aiguilles. Il est intéressant de noter que l'horloge s'est arrêtée à un moment donné, mais l'unité a continué à fonctionner sans problème... comme si cette tâche n'était plus exécutée... signaler probablement des problèmes...

mais comme je l'ai dit, je n'ai actuellement absolument aucune idée d'où peuvent provenir tous ces problèmes.

en tout cas, merci beaucoup pour vos efforts et votre aide... si je trouve quelque chose de raisonnable, je le signalerai...

clumsy-stefan le 6 mai 2018

Cela pourrait également signifier que la disponibilité de certains services a changé à un moment donné.
Soit il est devenu disponible, ce qui a amené les nœuds à faire plus de travail.
Ou il n'était plus disponible. ESPeasy essaie de faire un ping à un hôte pour détecter sa disponibilité. Si ce ping échoue, il arrêtera le nœud pendant la période de temporisation.

TD-er le 6 mai 2018

comment se fait ce "ping" ? parce que je vois de temps en temps des "hôtes inconnus"... se pourrait-il que ce délai d'attente soit assez important ? ou la recherche DNS ping ord doit-elle avoir de courts délais d'attente ? En fait, je n'utilise plus de FQDN, juste des IP, donc le DNS est moins susceptible d'être un problème...

Je suis juste en train de mettre à jour avec le dernier commit... certaines unités sont faciles à mettre à jour et assez rapides, d'autres très lentes...

J'ai 4 points d'accès fonctionnant sur le même SSID, il se pourrait aussi qu'il en sélectionne parfois un pire et ait ensuite des problèmes de vitesse ?

clumsy-stefan le 6 mai 2018

J'avais l'intention de changer la façon dont un ping est effectué en ping asynchrone.
Lorsque vous essayez d'établir une connexion, une vérification est effectuée pour voir si l'hôte est disponible. Cela se fait par ping.

TD-er le 6 mai 2018

et c'est un appel bloquant ?

clumsy-stefan le 6 mai 2018

C'est en effet, c'est pourquoi je veux le changer en une variante asynchrone.

TD-er le 6 mai 2018

hmm.. cela pourrait expliquer, lorsque la connectivité réseau est faible, que les choses ne sont pas vraiment "fluides"... surtout lorsqu'on essaie de télécharger un nouveau sketch... est-il possible d'augmenter le ping-timeout si le net en a beaucoup de latence ?

clumsy-stefan le 6 mai 2018

Cela n'est fait que lors de l'établissement d'une connexion.
La charge expérimentée d'une nouvelle tentative de connexion MQTT qui échouera est beaucoup plus perceptible.
Il n'y a pas vraiment beaucoup d'hôtes avec lesquels nous nous connectons, alors peut-être qu'il devrait y avoir une vérification de disponibilité asynchrone en arrière-plan pour aider à décider de se reconnecter ou non.
NB une recherche DNS peut également être assez bloquante lorsqu'elle finira par échouer.

TD-er le 6 mai 2018

se pourrait-il que 0.0.0.0 soit le DNS secondaire ?

giig1967g le 6 mai 2018

Je m'en suis rendu compte avec DNS, c'est pourquoi je n'utilise plus que des adresses IP maintenant... Je n'utilise pas du tout MQTT, uniquement le plugin de contrôleur fhme ainsi que des requêtes json régulières (de fhem avec le plugin HTTPMOD).

une chose que je vais probablement essayer est de désactiver la mise en réseau UDP inter-ESPEasy... Je ne peux pas me débarrasser du sentiment que cela a une certaine influence sur les unités, en particulier lors de l'exécution de 15 unités ou plus qui envoient des mises à jour régulières. ..

clumsy-stefan le 6 mai 2018

après avoir mis à jour toutes les unités vers le dernier méga commit, toutes les charges du processeur sont revenues à la "normale"... ce matin vers 8h, j'ai redémarré Nr. 4 et 9, et voyez ce qui est arrivé à la charge du processeur, presque toutes les unités ont eu un pic d'environ 30 minutes. et est revenu à la normale après ça...

juste une petite idée : est-il possible que les événements UDP inter-ESPEasy reçus soient "redistribués" à d'autres unités et puissent donc générer une boucle et remplir la pile réseau ?

clumsy-stefan le 7 mai 2018

Je n'ai jamais regardé dans le code de cette 'communication inter ESPeasy', donc je ne peux rien en dire.
Je m'attendrais à ce que ce protocole envoie seulement ses propres données et ne fasse pas écho au reste.
Ce protocole se compose de 2 parties :

Affirmer sa propre présence.
Envoi des valeurs de paramètres des plugins via ce qui était auparavant une "synchronisation globale".

Ce dernier est maintenant remplacé par "controller c_013".

Mais je ne sais pas s'il n'y a pas de boucle possible. Par exemple avec des appareils factices, l'importation MQTT, etc.
Il peut également y avoir un comportement différent entre les anciennes versions et les nouvelles versions qui utilisent le "contrôleur 13".

TD-er le 7 mai 2018

ok, merci pour la réponse rapide... Je vais l'éteindre maintenant, resp. régler le port UDP sur 0 et voir si quelque chose change...

Ajout : après l'avoir modifié, je vois environ 50% des unités redémarrer (sans qu'on leur dise de le faire)... et des "HTTP : échec de la connexion" dans le journal....

clumsy-stefan le 7 mai 2018

J'ai remarqué un problème similaire avec la charge du processeur. Le wemos exécute un FW auto-compilé avec 13 plugins. J'utilise Rest API avec Pimatic. Comme vous pouvez le voir, pour une raison quelconque, la charge monte jusqu'à 90% et plus.

jopiekr le 7 mai 2018

pour info : depuis que j'ai désactivé la mise en réseau Inter-ESPEasy en réglant le port sur 0 dans les paramètres avancés, il semble que (la plupart) mes problèmes aient disparu ! les 20 unités ont des temps de disponibilité >20min. et continuent de rapporter régulièrement des valeurs. web-if opérationnel. également CPU-graph ne montre plus ces sauts soudains. Une seule unité est passée en mode AP, je vais voir si elle récupère..
probablement ce besoin d'enquêter (dans la source)... avec beaucoup d'unités, le truc UDP surcharge probablement la pile réseau...
J'espère que cela aidera d'autres personnes confrontées à des problèmes similaires...

clumsy-stefan le 8 mai 2018

Voici mon expérience :
6 unités toutes avec IP statique et réseau Inter-ESPeasy actif.
Le dernier firmware chargé était "Mega 20180505 Manuel construit deux fois". (mais les firmwares précédents fonctionnaient très bien aussi).
Ils ont fonctionné pendant presque 3 jours sans aucun problème.

immagine

giig1967g le 8 mai 2018

C'est l'une des raisons pour lesquelles je veux attendre quelques jours avant de faire des correctifs wifi/réseau. Laissez-le simplement fonctionner pendant un certain temps pour voir ce qui ne va pas et essayez de lire certains problèmes sur la liste des problèmes Arduino.
J'ai déjà remarqué qu'un certain nombre de problèmes suggèrent de désactiver la gestion de l'alimentation pour certaines configurations wifi. Apparemment, certaines combinaisons de point d'accès ESP8266 + ne fonctionnent pas bien avec les fonctionnalités de gestion de l'alimentation activées (qui sont activées par défaut)
C'est donc une option à ajouter à ESPeasy.

Je cherche plus d'idées les prochains jours et vendredi/samedi j'ai plus de temps pour coder.

TD-er le 8 mai 2018

Pour référence, mon point d'accès est ASUS RT-AC68U avec le firmware Merlin

giig1967g le 8 mai 2018

Je suppose que la plupart des problèmes sont liés au micrologiciel par défaut d'usine pour les modèles plus économiques et peut-être aux points d'accès un peu plus anciens qui n'étaient pas au courant des options d'économie d'énergie des appareils wifi modernes.
La question demeure s'il est possible de négocier de telles fonctionnalités pour détecter automatiquement ces fonctionnalités.

TD-er le 8 mai 2018

Qu'en est-il de laisser désactivé par défaut et de ne l'activer que si cela est demandé dans la page des paramètres ?
Les options d'économie d'énergie n'ont de sens que pour les appareils fonctionnant sur batterie, je suppose.

giig1967g le 8 mai 2018

Ils ont également du sens à d'autres fins.
Plus de puissance signifie plus de chaleur et certains sont enfermés avec des capteurs.... ;)

TD-er le 8 mai 2018

En plus de la charge élevée du processeur. Je suis revenu sur un FW du 16/03 avec Core 2.3.0 et tout est redevenu normal. Charge maintenant max. 25%. De plus, le temps de réponse des wemos est encore bien meilleur. Avec le 08/05 et le 16/03, je n'ai pas du tout de déconnexion WiFi. Toujours aucune idée de ce qui a causé la charge élevée. De plus, dans les deux cas, je n'ai pas utilisé udp.

jopiekr le 10 mai 2018

depuis la désactivation de l'UDP, les unités fonctionnent sans problème, à l'exception de celles qui ont un écran LCD connecté. Je pense que si vous avez beaucoup d'unités qui parlent (> 20), elles sont soit trop occupées à décoder tous les messages UDP, soit ont une fuite de mémoire ou similaire. Cela expliquerait aussi les redémarrages instantanés des unités après le démarrage d'une autre. juste MHO... besoin de déboguer plus pour être sûr...

clumsy-stefan le 11 mai 2018

Cela peut également être lié à l'exécution de tâches plus longues sans temps pour certains appels à yield() , ce qui est également fait lors de l'appel de delay() .
Je peux imaginer que le plugin LCD (et peut-être d'autres aussi) effectue des tâches qui prennent > 10 ms.

TD-er le 11 mai 2018

les unités avec écran LCD semblent devenir de plus en plus occupées avec le temps... lorsque j'essaie de reflasher, je dois d'abord les redémarrer, car après quelques heures, le téléchargement ne fonctionne plus (ou prend du temps... )

toutes les autres unités fonctionnent bien maintenant, mais comme dit, l'annonce inter ESP doit être désactivée...

au moins le WiFi est stable comme ça, pas d'autres problèmes de connectivité jusqu'à présent... (fonctionne maintenant avec plus de 20 unités)

clumsy-stefan le 11 mai 2018

La journalisation est-elle activée sur le port série ?
Pourriez-vous peut-être régler cela sur "Aucun" ?

TD-er le 11 mai 2018

hmm.. point intéressant, j'ai les "informations" par défaut sur la journalisation du port série, mais j'ai complètement désactivé le port série... cela pourrait-il entraîner des problèmes?

Je vais le changer en "aucun" sur les unités, je vais voir si cela fait une différence..

clumsy-stefan le 11 mai 2018

J'ai déjà entendu des rapports selon lesquels les données non récupérées à partir des tampons série s'accumuleront.
Et je viens de remarquer moi-même que sur un nœud en cours d'exécution, lorsque j'ai connecté le moniteur série, j'ai reçu des données au moment où il a démarré, comme une minute auparavant.

TD-er le 11 mai 2018

Avec la différence entre le noyau 2.3.0 et 2.4.1, le 10 mai, j'ai changé le FW de 2.4 à 2.3. Les paramètres et les règles pour les deux sont exactement les mêmes.

jopiekr le 11 mai 2018

@jopiekr : quel est le logiciel que tu utilises pour imprimer la charge CPU ?

giig1967g le 11 mai 2018

@gii1967g c'est pimatique. Faites-le fonctionner sur un OrangePi One pendant plus d'un an sans aucun problème. En sauvegarde également sur un Raspberry Pi. pimatic.org

jopiekr le 11 mai 2018

changé tous les journaux de série en aucun maintenant... Je vais voir ce qui se passe...

ce qui est également remarquable, c'est le wifi RSSI.. si les unités ont un signal faible, elles peuvent être assez insensibles. un....

clumsy-stefan le 11 mai 2018

J'ai remarqué qu'au-dessus de -77 dB, ils peuvent devenir insensibles. De plus, lorsqu'ils ne fonctionnent pas sur batterie, vérifiez le renouvellement de la durée de location de votre routeur. J'ai fait une règle pour les redémarrer après 12000 minutes.

jopiekr le 11 mai 2018

Ils devraient se reconnecter au dernier. La première tentative de reconnexion concerne le BSSID de la dernière connexion active.
Mais je suppose que nous devrions ajouter le BSSID aux paramètres.

Ces derniers jours, j'ai beaucoup réfléchi aux problèmes de wifi et j'ai trouvé une sorte de solution de contournement pour les bogues probablement présents dans la bibliothèque principale ou en combinaison avec les versions du micrologiciel AP autour
Actuellement, la bibliothèque principale effectue une analyse lorsqu'elle essaie de se connecter en utilisant uniquement un SSID + pwd.
De cette façon, c'est tellement plus rapide lorsque vous fournissez le canal BSSID + lors de la connexion.
Parce qu'alors il n'a pas besoin de scanner.
Alors pourquoi ne pas faire le scan nous-mêmes, trouver le SSID connu, stocker tous les BSSID + canal pour les réseaux correspondants, puis essayer de se connecter uniquement en utilisant le canal BSSID +.
Ensuite, vous disposez également du basculement automatique et avez un contrôle total sur le moment d'envisager le renouvellement d'une connexion. (et donc redémarrer les services)

Vous connaissez également le RSSI le plus fort, alors connectez-vous d'abord au plus fort et essayez toujours de réutiliser le dernier utilisé en premier
Et lorsque la connexion est instable, essayez de désactiver la fonction d'économie d'énergie qui est activée par défaut dans le noyau 2.4.x.
Cette fonction d'économie d'énergie peut provoquer des reconnexions wifi, des blocages lors de la navigation sur les pages Web ou même des rejets lors de la connexion.

Lorsque la fonction d'économie d'énergie est activée, le wifi est désactivé pendant un moment, puis réactivé juste à temps pour recevoir le signal de balise du point d'accès.
Si ceux-ci ne sont pas synchronisés, certains paquets peuvent ne pas arriver à l'ESP et ne seront retransmis que lorsque le prochain signal de balise sera reçu. (ce qui peut prendre du temps)

Je ne connais pas grand-chose aux spécificités de ces problèmes d'économie d'énergie, mais j'en connais suffisamment sur le développement de micrologiciels pour savoir que les normes peuvent ne pas être mises en œuvre de la même manière chez les fournisseurs. Il est donc très probable que certaines combinaisons de matériel fonctionneront de manière moins optimale avec les fonctions d'économie d'énergie activées. Il peut même s'agir d'un autre appareil Wi-Fi qui retarde l'intervalle de balise Wi-Fi du point d'accès. Il y a juste trop de variables.

Une telle déconnexion temporaire peut également affecter les recherches DNS et d'autres interruptions de connexion qui peuvent bloquer l'ESP pendant un certain temps. Cela pourrait également affecter la charge du processeur, car cette valeur (mal définie) est basée sur le nombre de fois que la fonction loop() est exécutée en 30 secondes. Si un appel à une demande de résolution DNS bloque l'ESP, le nombre de boucles sera alors assez faible et donc une charge CPU élevée signalée.

TD-er le 11 mai 2018

@jopiekr Vous pouvez également effectuer un redémarrage, je suppose, à partir des règles.
Je vais d'abord chercher à désactiver les options d'économie d'énergie (et les rendre sélectionnables bien sûr)

TD-er le 11 mai 2018

@TD-er à propos de la gestion du WiFi : je suis tout à fait d'accord avec la fonction de gestion de l'alimentation. On devrait pouvoir l'éteindre, car cela peut causer des problèmes vraiment étranges et des appareils à la traîne...

Pour la reconnexion à l'AP, je vois les choses différemment, j'essaierais toujours de me connecter à l'AP le plus puissant pour assurer une bonne connexion. seulement après cela, je prendrais probablement le dernier. Simplement parce que si le point d'accès "principal" plante/redémarre/ne répond pas, etc., l'unité se connectera à une autre. À partir de ce moment-là, il faudra toujours ce (pire) jusqu'à ce que celui-ci échoue également... il ne reviendra jamais au plus fort, même si celui-ci revient... même si vous déplacez les appareils. , il se peut qu'il sélectionne le point d'accès précédent même si celui-ci est beaucoup plus éloigné/a un signal plus faible...

J'accepte cependant de scanner dans votre code, puis je décide lequel prendre en fonction du RSSI et du BSSID connu...

clumsy-stefan le 11 mai 2018

Il ne s'agit que de la première tentative de reconnexion au dernier BSSID connu.
Cela se traduira par une connexion plus stable lors de l'utilisation de répéteurs.
Ces répéteurs peuvent parfois interrompre les connexions lorsqu'ils sont trop occupés à gérer d'autres tâches et ils peuvent sembler moins puissants lors de la numérisation. Les moins chers n'ont qu'une seule radio pour la réception et la transmission, donc lorsqu'ils reçoivent des données, il se peut qu'ils ne diffusent pas leur signal de balise au moment où un balayage est effectué. Ainsi, le RSSI d'un autre AP peut apparaître plus fort à ce moment-là.

TD-er le 11 mai 2018

ok, que diriez-vous d'un scan « régulier » qui garde une trace de la force ? ou au moins après un redémarrage, il devrait réévaluer le point d'accès qu'il choisit ...

clumsy-stefan le 11 mai 2018

Au redémarrage et si la première tentative de reconnexion échoue, il effectuera une analyse et choisira la correspondance la plus forte pour le SSID défini.

Je vais changer cela en stockant le BSSID de l'AP préféré dans les paramètres, pour que ce BSSID soit toujours le préféré.
Les reconnexions sont vraiment rapides si le canal est également connu. (inférieur à 200 ms est possible, selon l'AP utilisé)
La définition d'une adresse IP statique prend également environ 20 à 25 ms, par rapport à DHCP qui prend 2,5 à 10 secondes.
Ce serait idéal pour les appareils alimentés par batterie.

Il y a donc place à amélioration :)

TD-er le 11 mai 2018

Cela semble très prometteur. Jusqu'à présent, j'ai eu 2 mois d'autonomie avec 2 piles AA jusqu'à 3,3 V et un capteur DHT envoyant toutes les 900 s. Il s'agit d'une carte RobotDyn ESP Pro avec régulateur de tension retiré.

jopiekr le 11 mai 2018

@TD-er Je viens d'essayer la version d'hier. Je ne vois aucune différence dans les temps de connexion si j'utilise une adresse IP statique ou DHCP. Les deux connexions prennent environ 3 secondes après la réinitialisation.

s0170071 le 11 mai 2018

Ensuite, vous avez un serveur DHCP rapide.
Ma Fritzbox prend environ 2,5 secondes pour le DHCP, après les 2,5 secondes de connexion au wifi.
Ainsi, la configuration de l'heure de connexion MQTT + NTP prend environ 6 à 6,5 secondes à partir du démarrage.

TD-er le 12 mai 2018

Boîte Fritz 7490.

s0170071 le 12 mai 2018

mise à jour rapide : après avoir désactivé InterESP UDP (et supprimé C13 des unités 1M) et réglé le journal série sur « non » (également en désactivant le port série), presque toutes mes unités fonctionnent de manière stable depuis plus de 30 heures... un mélange entre D1 Mini, D1 pro, Sonoff Basic, Dual et 4ch... Plus de 20 unités... fonctionnant sur commit de mega-20180511, auto-compilé avec Arduino IDE...

clumsy-stefan le 12 mai 2018

🎉1

J'ai le 7581 comme modem et 3* 1750E comme points d'accès.

TD-er le 12 mai 2018

BTW : Je fonctionne sur Mikrotik AP (et un très vieil USR). Je vais mettre à jour les unités maintenant avec le dernier commit de ce soir...

clumsy-stefan le 12 mai 2018

Les derniers commits ne traitent actuellement que le code lié à JSON (visualiseur de journaux + mise à jour des valeurs du capteur).
Pas encore avec le code wifi.

TD-er le 12 mai 2018

bien sûr, mais le wifi semble être "assez stable" avec les derniers commits, donc je veux être à jour avec mes unités ;)

clumsy-stefan le 12 mai 2018

désolé de soulever à nouveau cela, mais j'éprouve toujours le problème selon lequel l'ESP pense qu'il a une adresse IP de 0.0.0.0 et arrête de parler au serveur, peu au niveau du réseau et du Web, tout va bien ! voir la capture d'écran ci-jointe, essayé avec différentes combinaisons de versions d'ESPEasy et d'esp8266...
Est-ce que quelqu'un d'autre a vécu ça ?
untitled

clumsy-stefan le 31 mai 2018

Très étrange en effet, car je me demande comment vous pouvez voir la page Web avec une telle configuration IP.
Ou vous connectez-vous à l'ESP via sa fonction point d'accès ?

TD-er le 31 mai 2018

non, connecté via le réseau directement. ping et http fonctionnent sans problème, rapidement (voir l'adresse IP du client est 10.0.0.10 qui est mon ordinateur portable, le réseau interne est 10.0.0.0/16)... oui, assez étrange cependant...
peut-être lié à DHCP ou à peu près .. après un redémarrage, tout va bien à nouveau ..

Cela pourrait-il être lié au fait que je n'ai activé qu'un seul contrôleur (FHEM) et aucun contrôleur compatible MQTT ? J'ai vu beaucoup de code mqtt dans les sources, en dehors du plugin du contrôleur... juste une supposition... mais je pense que ce n'est pas vraiment lié...

clumsy-stefan le 31 mai 2018

Peut-être que DHCP a expiré et n'a pas été renouvelé ?

uzi18 le 3 juin 2018

pourrait très bien l'être... probablement la pile réseau a toujours une adresse IP active, mais si le renouvellement échoue, la configuration correspondante est remise à zéro... je ne sais pas comment fonctionne le code DHCP, mais cela pourrait expliquer l'état que I0m voit.

J'ai également constaté que lorsque le serveur (dans mon cas, fhem) ne répondait pas assez rapidement un certain nombre de fois, les unités commençaient à redémarrer après un certain temps. cela pourrait être un problème dans le code du plugin ou dans la pile tcp sous-jacente... J'ai fait quelques ajustements de performances sur le serveur, depuis lors, les unités fonctionnent beaucoup plus stables (certaines ont des temps de disponibilité de plus de 48h maintenant)..

clumsy-stefan le 4 juin 2018

J'ai déjà vu plus de 10 jours de disponibilité de connexion (temps de disponibilité sans aucune reconnexion) avec les dernières versions.
Il est possible de faire en sorte que les unités remplissent leur bélier avec de nombreuses demandes.
Et j'ai vu le LWIP faire des choses étranges en faisant beaucoup de requêtes. (lecture de la mémoire ne contenant pas de données liées à cette demande.)

TD-er le 4 juin 2018

Aujourd'hui, un nœud cesse de répondre à nouveau. Il s'est déconnecté du wifi. Je n'ai pas pu me connecter au réseau "esp". Il a cessé d'envoyer des données au contrôleur. J'ai dû le redémarrer. Peut-être qu'un chien de garde serait une bonne solution. Si, par exemple, une heure est déconnectée du wifi, il redémarre. Ou peut-être que cela peut être fait avec des règles, mais je ne sais pas comment :)

melwinek le 9 juin 2018

Aujourd'hui, j'ai expérimenté de nombreuses actions Watchdog lors du débogage d'un plugin.
Et je sais maintenant que parfois lorsque le chien de garde intervient, un nœud peut rester stoppé.
Un chien de garde n'est donc pas la solution parfaite.

Est-il possible que votre nœud suspendu n'ait jamais été redémarré après avoir clignoté ? (appuyez sur reset ou sur power cycle)

TD-er le 9 juin 2018

Il est possible qu'il n'y ait pas eu de redémarrage après le flashage. Mais c'était un flash via www, pas une série.

melwinek le 10 juin 2018

D'accord, cela ne devrait pas avoir d'importance si vous avez flashé OTA.
Tant qu'il y a eu une réinitialisation/redémarrage approprié après le flash série.

TD-er le 10 juin 2018

Eh bien, après avoir rencontré de nombreux problèmes de stabilité et d'étranges problèmes de wifi avec les dernières versions du firmware, j'ai finalement dû revenir aux versions antérieures. Par exemple, jusqu'à ce qu'une panne de courant se produise récemment, un ancien nœud ESP12E avec mega-20180311dev fonctionnait pendant 70 jours, envoyant des données de température à ThingSpeak.
Sur un autre nœud après la mise à niveau vers mega-20180522dev, je subissais un redémarrage en raison d'une exception toutes les 24 heures environ malgré la réinitialisation des paramètres par défaut, fonctionnant simplement sans aucun périphérique configuré, aucun NTP configuré, aucun contrôleur... Jamais survécu 48 heures. Après la rétrogradation à méga-20180324 il y a deux jours et demi, j'ai conservé la configuration, j'ai réactivé NTP et jusqu'à présent, il fonctionne. Bien qu'il y ait quelques bugs et fonctionnalités manquantes dans ces anciennes versions, pour moi c'est actuellement le meilleur choix.

ghtester le 4 juil. 2018

Personne ne peut faire grand-chose si les problèmes ne sont pas reproductibles de manière fiable.
Ce qui aide un peu, c'est de planifier un redémarrage tous les soirs. Vous pouvez utiliser les règles pour cela.

s0170071 le 4 juil. 2018

Je sais mais je préfère un nœud stable sans redémarrage programmé. Je ne sais pas si la stabilité a été considérablement diminuée en raison du passage au noyau 2.4.1 (peut-être qui n'est pas encore assez mature) ou si c'est lié à la refonte d'ESP Easy mais cela s'est produit malgré l'effort maximal de tous les contributeurs d'ESP Easy. J'apprécie vraiment le travail acharné de vous tous, mais actuellement, je ne peux plus utiliser les dernières versions d'ESP Easy.

ghtester le 4 juil. 2018

Je pense que cela est également lié au plugin utilisé ou peut-être à une combinaison de plugins.

La semaine dernière, j'ai travaillé sur les effets des timings et je suis sûr que cela aura un effet significatif sur les tâches critiques.

Je viens de regarder certains de mes nœuds, tous exécutant des versions officielles :

Nom de fichier binaire ESP_Easy_mega-20180513_normal_ESP8266_4096.bin

Unité 3

Temps de disponibilité 16 jours 18 heures 26 minutes
Connecté 5j23h07m
Raison de la dernière déconnexion (201) Aucun point d'accès trouvé
Numéro reconnecte 2

Unité 5

Temps de disponibilité 11 jours 5 heures 22 minutes
Connecté 5j22h57m
Raison de la dernière déconnexion (201) Aucun point d'accès trouvé
Numéro reconnecte 4

Unité 6

Temps de disponibilité 11 jours 5 heures 23 minutes
Connecté 45 m 1 s
Raison de la dernière déconnexion (201) Aucun point d'accès trouvé
Numéro reconnecte 58

Nom de fichier binaire ESP_Easy_mega-20180619_test_ESP8266_4096.bin

Unité 7

Temps de disponibilité 13 jours 20 heures 51 minutes
Connecté 5j23h05m
Raison de la dernière déconnexion (202) Échec de l'authentification
Numéro reconnecte 2

Il y a environ 6 jours, j'ai eu quelques problèmes avec l'un de mes points d'accès WiFi, que j'ai dû redémarrer.

L'unité 6 est connectée de la même manière que les unités 3 et 7, mais elle a beaucoup plus de reconnexions.
Ces 3 unités sont côte à côte, à moins d'un mètre l'une de l'autre pour comparer différents capteurs de CO2 (MH-Z19 A, B et SenseAir S8) et tous alimentés par la même alimentation (chargeur USB 3 ports IKEA).

La seule différence entre eux est que celui avec le plus de reconnexions a le capteur Senseair.
Il se pourrait donc que la mise en œuvre de ce capteur exerce plus de pression sur la routine Wi-Fi (moins d'appels retardés), ce qui pourrait entraîner une instabilité du Wi-Fi.

Pouvez-vous donner une liste des plugins utilisés ?
J'ai également fait une pull request hier qui enregistre de nombreuses statistiques de synchronisation. Vous pourriez peut-être créer une version basée sur celle-ci et l'exécuter pendant quelques minutes pour vous faire une idée des plugins qui prennent beaucoup trop de temps.

TD-er le 4 juil. 2018

J'utilise toujours les versions officielles car je ne suis pas en mesure de préparer et de maintenir l'environnement de développement pour ces appareils.
La version mentionnée mega-20180522dev, comme je l'ai décrit ci-dessus, était une configuration complètement vide, donc absolument aucun plugin utilisé, aucune règle, j'ai même supprimé le contrôleur par défaut Nr1 à la fin. Rien ne pouvait empêcher le redémarrage du nœud en raison d'une exception à des intervalles d'environ 24 à 40 heures.

ghtester le 4 juil. 2018

Je ne sais pas s'il s'agit d'un problème de wifi - ça n'y ressemble pas, j'ai réussi à définir des adresses IP statiques pour le wifi, mais espeasy les récupère toujours par DHCP et les définit différemment.

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 le 4 juil. 2018

@uzi18 Avez-vous défini tous les champs pour la configuration IP statique ?

Si tel est le cas, je crains qu'il s'agisse d'un problème connu (pour moi), où une session précédente est stockée dans une région où nous n'effaçons pas (encore) les données lors d'une réinitialisation d'usine.
Cela signifie qu'en ce moment, il n'y a pas d'autre moyen que d'effacer tout le flash et de recommencer avec une version récente d'ESPeasy.
Les versions ultérieures définissent une valeur pour ne pas rendre les paramètres wifi persistants.

TD-er le 5 juil. 2018

@TD-er Oui, toutes les données sont remplies - comme vous le voyez dans le journal.
J'ai flashé NOUVEAU module, avec
INFO : Plugins : 71 [Normal] [Test] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP : 2.0.3)
et ça marche comme ça.
Le module n'a été extrait que du sac d'origine et a flashé, espeasy n'a jamais été ici auparavant.

uzi18 le 5 juil. 2018

@TD-er : Deux réflexions à ce sujet :

Mon chauffage non ESPEasy vers le diffuseur MQTT fonctionne parfaitement en utilisant le dernier client pubsub. Se reconnecte et ainsi de suite. Peut-être que la surveillance de la connectivité ESPEasy interfère avec ce qui a déjà été fait par la bibliothèque principale. Devrions-nous avoir un moyen de désactiver tous ces éléments supplémentaires de ping-reconnect-wifistate ? Juste pour tester ?
Êtes-vous au courant de la mise hors tension automatique du wifi ? https://blog.creations.de/?p=149

s0170071 le 5 juil. 2018

Ce serait bien si quelqu'un avec un wifi plutôt instable pouvait tester ce PR : https://github.com/letscontrolit/ESPEasy/pull/1562

TD-er le 12 juil. 2018

@TD-er vient de tomber sur https://github.com/esp8266/Arduino/pull/4718
traite les problèmes de reconnexion lwip. Est réparé en attendant. Peut-être que vous voulez sauter à travers elle...

s0170071 le 13 juil. 2018

J'utilise toujours la dernière version GIT de l'esp8266.. c'est pourquoi je ne vois probablement plus le problème 0.0.0.0...

clumsy-stefan le 13 juil. 2018

Hier encore, un nœud après le redémarrage du routeur a perdu le contact avec le réseau.
Les règles fonctionnaient correctement.
Il s'agit de mon propre interrupteur mural, il est difficile de le démonter pour le réinitialiser.

Pour faciliter cela à l'avenir, j'ai modifié les règles :

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

Maintenant la vie sera plus simple :))

melwinek le 18 juil. 2018

Je redémarre toutes les 24h. Cela fait revivre un nœud avec un firmware d'il y a 4 semaines deux fois par semaine.
Peut-être que cela devrait être une fonctionnalité permanente ....

s0170071 le 18 juil. 2018

Est-ce toujours un problème ? Si oui, veuillez rouvrir.

Grovkillen le 25 oct. 2018

Notre fil le plus long sur la liste des problèmes....

TD-er le 25 oct. 2018

Espeasy: Problèmes de Wi-Fi - histoire sans fin - revenir au Wi-Fi non basé sur des événements ?

Commentaire le plus utile

Tous les 388 commentaires

si défini (ESP8266)

fin si

undef PLUGIN_BUILD_NORMAL

undef PLUGIN_BUILD_TESTING

undef PLUGIN_BUILD_DEV

définir PLUGIN_BUILD_CUSTOM

undef BUILD_UPLOADER

si défini (BUILD_UPLOADER)

autre

fin si

undef BUILD_GIT

définir BUILD_GIT "2abec2b"`

Questions connexes