Espeasy: MQTT cesse de fonctionner depuis 20181008

En 20181004, ce qui suit a changé:

• [sendHttp] # 1830 Définir le délai d'expiration et la sortie anticipée lorsque le délai d'expiration est atteint
• [WiFiClient] Définissez le délai d'expiration et rendez-le configurable pour les contrôleurs
• [Core 2.4.1] Revenir au noyau 2.4.1 à partir de 2.4.2

Et en 20181006:

• [WiFi] Ajouter un délai aux tentatives de connexion dans ControllerSettings

Pourriez-vous peut-être tester la version 20181003 et peut-être ces 2 autres également pour affiner le problème?

J'essaierai, mais j'ai peur de ne pas pouvoir le faire avant samedi. ;-)

Avez-vous une idée du temps qu'il faut avant que la connexion MQTT ne soit perdue?
Et est-ce que cela coïncide d'une manière ou d'une autre avec une reconnexion wifi?

Pour autant que je puisse voir, il n'y a pas eu de perte de Wifi.
que la connexion MQTT a été perdue a été assez rapide ce matin (10 min) mais j'ai aussi eu des heures selon la dernière entrée de l'IOBroker ...
J'essaierai de démarrer au moins une des 3 versions ce soir.

Juste comme un chèque; Le construisez-vous vous-même ou utilisez-vous des versions nocturnes?

autre chose à vérifier:

êtes-vous sûr que MQTT cesse de fonctionner?
Mon un ici montre après un certain temps "Connection LOST" mais tout fonctionne toujours avec MQTT.

Le seul bug que je vois est le message "Connexion perdue" alors que tout fonctionne toujours.
Par exemple, je reçois des minutes de disponibilité par le contrôleur MQTT.
Après un certain temps (entre 10 minutes et 10 heures), je vois "Connexion perdue" mais les minutes comptent toujours pour envoyer sur MQTT.

Greetz
Sascha

MQTT doit effectuer une reconnexion dès qu'il a détecté qu'il n'était plus connecté.
Voir aussi @ Sasch600xt autre problème connexe:
https://github.com/letscontrolit/ESPEasy/issues/1873#issuecomment -431170001

Quelques builds avant 20180927, celui que vous signalez fonctionner très bien, j'ai ajouté un correctif pour les contrôleurs MQTT dans lequel le client MQTT sur l'ESP se donnera un nouvel ID client, juste pour empêcher le courtier de refuser une nouvelle connexion lorsque le courtier suppose toujours une connexion existante de ce client et le client pense qu'il est déconnecté.

Pouvez-vous augmenter le paramètre de délai d'expiration du contrôleur? La valeur par défaut était de 1000 ms, avant d'introduire ce paramètre et la première version avait 100 ms par défaut. Plus tard, j'ai changé la valeur par défaut (pour les nouveaux paramètres) à 300 msec.
Alors peut-être que vous pouvez essayer de le régler à 300 ou plus (pas plus de 1000 msec) juste à titre de test. (peu importe la version, au moins une qui échouait)

J'ai rencontré le même problème avec 1 (sur 5) unités. J'ai joué un peu avec les paramètres du contrôleur MQTT (intervalle d'envoi minimum, profondeur maximale de la file d'attente, tentatives maximales et action de file d'attente complète); paramètres qui fonctionnent maintenant pour moi avec cet appareil: 1000ms, 5/5 et "Supprimer le plus ancien".

Ok nouvelles ...
On dirait que c'est le même problème dont parle blb4github il y a 12 heures. A pris une NOUVELLE unité et cela fonctionne jusqu'à présent sans problèmes !!!! On dirait que l '«ancien» a des problèmes de mémoire ou de synchronisation. Je vais essayer d'augmenter le timeout dans celui-ci ... vous tenir informé ;-)
Btw .. (Désolé .. Selfbuild avec Atom .. parce que je ne veux pas de tous les plugins ... Mais jusqu'à présent, ça s'est toujours bien passé ..) Vous faites tous un excellent travail sur ce point ... et pour autant que je sache ce n'est que cela (et donc celui avec le plus récent SW) qui pose ce problème. Je vais augmenter les paramètres et vous le faire savoir.

Cordialement Peter

@fraeggle est-il possible pour vous de coller ici une capture d'écran des pages systeminfo de bons et de mauvais modules? (sections d'esp et de stockage)

Et une description du matériel.
Par exemple, j'ai le sentiment qu'il y a eu des changements récemment dans les modules sonoff.
Sonoff basic et le S20

@fraeggle Pourriez-vous peut-être également effectuer un nettoyage complet du nœud problématique et commencer à nettoyer?
Les fichiers bin vides sont inclus dans les fichiers ZIP de la version.

Salut TD-er
J'avais effacé le mauvais nœud avant ... Depuis que j'ai changé les paramètres de délai d'expiration à 800 ms
c'est stable. La tension est mise à jour toutes les 120 secondes.

Matériel rien de spécial .... parce que j'attends toujours l'arrivée d'INA219 .. ;-)

Cordialement Peter

ups je l'ai malheureusement fermé ..

Mais je pense qu'avec ce "workaroud", il peut être fermé ... Je pense vraiment que c'est un problème d'unité maintenant ..
Que pensez-vous de ça TD-er?

Pourtant, il est étrange que les unités diffèrent sur cet aspect.
Cela suggérerait que la stabilité du wifi est pire dans une unité

Je suis d'accord mais je pense que cette unité a simplement une plage de tolérance trop large. Comme je vous l'ai dit, depuis que je suis passé à 800 ms, cela fonctionne très bien ...
donc si vous êtes d'accord, je fermerai celui-ci, car il est possible de modifier le délai d'expiration.

Merci pour ton aide..

salutations Peter

J'ai trouvé "depuis 20181007 MQTT Open Hab montre" Connexion perdue "# 1873.
Peut-être le même problème?
TD-euh, dites-moi si je peux vous aider en créant des journaux ou quelque chose comme ça ...
Utilisation d'Openhab (avec IOBroker). mais jusqu'à présent aucune erreur après avoir réglé Timeout à 800ms

Le courtier MQTT pour OpenHAB que vous exécutez est-il installé sur un ordinateur de votre propre réseau ou externe?
Et s'il est local, est-il peut-être installé sur un ordinateur qui manque de ressources?

J'ai aussi un test en cours depuis 394 minutes à 20181020.
Timeout à 800ms.
Parfois, il apparaît comme déconnecté après 24 heures ou même plus. Mais je n'ai jamais atteint 2 jours.
Et encore une fois, pour moi tout fonctionne toujours après avoir montré "Connection Lost". C'est donc juste le message qui me déroute. Je vous tiendrai au courant

Connexion perdue n'est qu'un message d'information indiquant ... la connexion a été perdue.
Mais il devrait redémarrer une nouvelle connexion.
Dans la page sysinfo, vous pouvez voir à quelle fréquence la connexion WiFi a été perdue et reconstruite et aussi combien de temps elle est connectée au WiFi depuis la dernière (re) connexion au point d'accès.

Dès que la connexion WiFi est interrompue, il supposera également que la connexion MQTT doit être reconstruite, il considérera donc que la connexion au courtier MQTT est perdue.
Jusqu'à il y a 4 semaines, il était possible que le courtier MQTT n'accepte pas la nouvelle tentative de connexion, car le courtier considérait toujours que le client était connecté.
Cela peut entraîner des tentatives de reconnexion indéfinies, lorsque le client continue d'essayer de se connecter et que le courtier n'accepte pas la connexion.
J'ai changé l'ID client MQTT à chaque reconnexion (en ajoutant le nombre de reconnexions à l'ID client) afin que le courtier le considère comme un nouveau client.
Il en résulte une reconnexion rapide, avec comme seul inconvénient, le courtier enverrait le LWT (dernier testament et testament) puisqu'il suppose que le client est déconnecté.

Si cela entraîne un comportement indésirable, je peux le changer en une nouvelle stratégie.
Par exemple, lors d'une tentative de reconnexion qui échoue, je peux essayer d'envoyer d'abord un message de déconnexion approprié.

En bref, il existe de nombreuses options sur lesquelles la connexion au courtier peut se perdre et je ne sais pas pourquoi dans votre cas, elle est perdue.
Cela peut être un délai d'attente, une déconnexion WiFi, une réponse inconnue du courtier ou toute autre raison.

ok ..... je l'ai.
Très bonne déclaration, merci.
Je suis à la minute 507 en ce moment / Open HAB controller / 800ms timeout.
Jusqu'à présent, tout va bien :)

Dois-je remettre le délai d'expiration par défaut pour les nouvelles instances d'un contrôleur à 1000 ms?

bien ...... donne-moi 36 heures de plus ..... alors je sais mieux que le bogue arrive aussi avec 800ms ou pas.

Minute 629 maintenant sans problèmes ...

bizarre ... découvert après le passage à 800ms.
Raison de la dernière déconnexion | (200) Délai d'expiration de la balise
Nombre de reconnexions | 3
Que signifie das Beacon Timeout?
MQTT est toujours en cours d'exécution mais pour le moment le même que Sasch600txt. Mais différent qu'avant ... MQTT fonctionne toujours
seul le courtier dit que celui-ci n'est pas connecté.

Pour plus d'informations sur le cadre Beacon, voir Wikipedia
En bref, le point d'accès envoie périodiquement un paquet contenant des informations sur le réseau.
Cet intervalle est généralement de 100 TU (102,4 ms).
Le module ESP essaie d'écouter cette balise à chaque fois, mais pour un certain nombre de raisons, il peut manquer une trame de balise. Le délai d'expiration est supérieur à 100 TU, il doit donc manquer un certain nombre de ces trames de balise pour signaler un délai d'expiration de balise.
Les raisons de manquer un tel cadre de balise sont:

• trop occupé à traiter d'autres tâches de blocage (très probablement)
• le point d'accès n'envoie pas de balise en raison de la forte demande de trafic des autres (selon la marque / le modèle / les paramètres)
• Perturbations RF (peu probables compte tenu de la fréquence à laquelle cela se produit)
• dérive de l'horloge (pas vraiment probable)

Ainsi, le "délai d'expiration de la balise" se produit de temps en temps sur les nœuds ESP.
Je travaille dur pour que chaque plugin / contrôleur utilise des tranches de temps courtes pour rendre les tâches aussi peu bloquantes que possible.

Je peux confirmer tout ce que Fraeggle a dit.
Quelque part ce soir j'ai "Connection Lost"

Bon week-end :)
Sascha

@fraeggle :
s'il apparaît comme "Connexion perdue", essayez d'aller dans les paramètres du contrôleur d'ESPEasy, désactivez simplement le contrôleur -> enregistrez, activez-le à nouveau -> enregistrez. Ensuite, au moins pour moi, il apparaît à nouveau comme connecté. Pas une solution, mais au moins intéressante :) est cette IPSymcon que vous utilisez?

@ TD-er:
tâches trop chargées? eh bien ...... au "TEST UNIT" que j'ai en cours d'exécution ici, je n'envoie que les minutes de disponibilité toutes les 60 secondes ...... rien de plus ne fonctionne sur cette unité ..... donc probablement le plus petit système possible

@ Sasch600xt les termes "trop ​​occupé" n'est peut-être pas le meilleur pour décrire le vrai problème.
La façon Arduino de faire les choses est:

• appeler setup()
• appelez loop() encore et encore.

En plus de cela, la version Arduino pour ESP8266 (et ESP32 Arduino) exécute des tâches en dehors des loop() pour la partie Arduino.
Ces tâches concernent les processus d'arrière-plan, comme la gestion de la connexion réseau et du trafic entrant, etc.
Les tâches d'arrière-plan sont exécutées uniquement à:

• fin d'un loop()
• lors de l'appel delay() ou yield() depuis l'espace Arduino.

Si une boucle dure plus de 102,4 ms et qu'aucun appel à yield () ou delay () n'est effectué, le nœud ESP aura manqué un intervalle de balise.
De plus, s'il exécute plusieurs tâches de blocage qui sont toujours occupées au moment où le point d'accès WiFi envoie la balise, un certain nombre de balises seront manquées.

Lorsque vous regardez le journal série (avec le niveau de débogage activé), vous verrez les statistiques de synchronisation.
Certains d'entre eux peuvent faire plusieurs dizaines de msec et sont donc candidats pour provoquer ces raisons de «déconnexion».

Je pourrais ajouter une tâche au planificateur pour essayer d'écouter la balise toutes les 102,4 msec. La seule chose est que je ne sais pas comment voir quand une telle balise a été vue.

À propos de ce problème, je pourrais examiner la déconnexion / reconnexion de MQTT lorsqu'une connexion a été perdue.
Quel courtier utilisez-vous? J'utilise Mosquito ici et cela fonctionne bien avec le comportement actuel.

ok, "trop ​​occupé" était un peu facile à dire de moi :)

J'utilise un script en cours d'exécution dans mon ipsymcon housecontrol eviroment pour le courtier MQTT

Greetz
Sascha

Salut Sascha .. Utilisation d'IOBroker.
@ TD-er est retourné à la version 27092018. Le courtier me dit toujours connecté ...
Vraiment déroutant .. AUCUNE erreur dans les 14 heures (nombre de reconnexions | 0)

J'installe IObroker maintenant sur mon ordinateur, juste pour voir ce qui se passe.

Éditer:
45 minutes plus tard et je ne parviens toujours pas à faire fonctionner IObroker sur mes ordinateurs.
Je ne sais pas ce qui se passe ici, mais le programme d'installation de Windows ne fonctionne tout simplement pas (le fichier de service bat est introuvable) et l'installation sur Linux ne se termine tout simplement pas. Il continue d'essayer de faire la même installation npm encore et encore.
Testé sur Ubuntu 18.04 sur un hôte CPU Intel et Bash sur Windows (Ubuntu 18.04)

pas sûr avec Windows .. je pense qu'il y a des dépendances logicielles. Exécuter sur Raspberry.
pour Windows ioBroker verwendet Node.js als Plattform und setzt diese voraus. (Téléchargement: http://nodejs.org/download/) Le premier node.js doit être installé.

J'ai également un problème avec un module avec 4 capteurs DS18B20 connectés.
Je pensais que c'était mon RasPi mais j'ai pris une image Raspbian Streth propre et y ai installé mosquitto et node-red. Même problème, la connexion est interrompue après 6 à 12 heures.

Tableau de bord: https://emoncms.org/Edegem/scrtmp2e
Les 4 courbes de l'ESP sont CV_aanvoer, CV_retour et Sanitair_warm, Sanitair_koud

@fluppie si vous utilisez des versions officielles?

Non, je me construis avec PlatformIO / Atom
EDIT: Ha, je n'ai pas bien lu, je vais essayer une version officielle.

Regardons ça!

salut

J'ai / j'ai eu le même problème, j'utilise HomeAssistant mais après ESPEasy_mega-20181111 fw, le problème me semble résolu.

Merci
T

Le mien perdait toujours la connexion après 2-3 jours. Je vais mettre à jour vers: ESP_Easy_mega-20181112_normal_ESP8266_4096.bin

Voyons voir!

Le mien était de perdre le conn. après 1 à 10 heures. J'ai ~ 10h30min de disponibilité et tous (5pcs) les modules associés connectés. :-)

semble qu'il vaudrait la peine d'essayer ... toujours sur 2709 car besoin d'une connexion stable. Veuillez me tenir informé. :-))

Vous pouvez également suivre via: https://emoncms.org/Edegem/scrtmp2e et vérifier si les graphiques CV_ et Sanitair_ sont là :).

1 jour de disponibilité et toujours ok. :-)

Vous pouvez également suivre via: https://emoncms.org/Edegem/scrtmp2e et vérifier si les graphiques CV_ et Sanitair_ sont là :).

:-D Sanitair_warm près de 60 C? petit feu de camp? ;-)
Je vais essayer la firme .. Merci ...

Je me douchais ;-)

1 jour ... toujours connecté :-D
en utilisant 12112018

Après ~ 3 jours 3 heures, l'un de mes appareils a perdu la connexion MQTT. :-( (méga-20181112 4096 VCC fw)

@redskinhu :
juste pour être sûr, est-ce que cela fonctionne toujours bien après que l'unité ait perdu la connexion MQTT?
parce que de mon côté, il n'apparaît que comme "connexion perdue" mais fonctionne toujours très bien avec toutes les actions MQTT.

Greetz
Sascha

En effet, une connexion perdue n'est pas rare de temps en temps.
Tant que la connexion est reconstruite sans intervention humaine, il n'y a pas de problème.
Les connexions WiFi seront réinitialisées de temps en temps et vous ne pouvez rien faire pour l'empêcher.
Dès qu'une telle connexion est perdue, il notifie aux clients MQTT sur le même nœud de se reconnecter.

Cela ressemble à une sorte de problème lié au LWT. MQTT n'est pas totalement déconnecté, ESPEasy envoie / reçoit des messages MQTT mais le LWT n'est pas renouvelé, donc le HomeAssistant n'a pas reçu le message LWT connecté, il indique donc que le capteur / commutateur concerné est indisponible. C'est ma théorie ...

Le mien Toujours connecté et contrairement à mon premier message, même MQTT LWT me dit connecté. Cela semble bon.

En effet, une connexion perdue n'est pas rare de temps en temps.
Tant que la connexion est reconstruite sans intervention humaine, il n'y a pas de problème.
Les connexions WiFi seront réinitialisées de temps en temps et vous ne pouvez rien faire pour l'empêcher.
Dès qu'une telle connexion est perdue, il notifie aux clients MQTT sur le même nœud de se reconnecter.

OK y a-t-il une possibilité de renouveler LWT connecté dans ce cas?

Il est censé envoyer le LWT au moment où il renouvelle la connexion.

J'ai un nœud en ce moment qui est montré déconnecté dans le LWT et il envoie des mesures très bien. Une version un peu plus ancienne ... peut-être que cela vous dit quelque chose

Version GIT: | méga-20181008
Disponibilité: | 3 jours 17 heures 36 minutes

J'ai vu des choses étranges lorsque le nœud ESP pense qu'il était déconnecté et doit se reconnecter, mais le courtier n'est pas d'accord.

salut

J'ai fait une petite enquête. Il semble que le LWT soit le problème. Un de mes ESP a de nouveau produit cette chose "déconnectée" de MQTT.

Tout fonctionne bien, capteurs / interrupteurs. Mais l'assistant domestique ne pouvait pas les voir car dans la configuration, j'ai fourni les détails de LWT.

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

J'ai vérifié le trafic MQTT: j'ai obtenu les données du capteur et j'ai pu activer / désactiver le GPIO. Tout va bien ex. le LWT.

Et après avoir publié un message LWT "Connected" et tout est revenu à la normale.

J'espère que cela aide.

T

PS:
Je pense à une règle qui peut publier un message LWT Connected si le message LWT est déconnecté, mais malheureusement je ne peux pas importer les chaînes MQTT ;-)

Quoi qu'il en soit, j'attendais avec impatience la nouvelle version de fw. 4 longues journées ...

Je suis parti lundi / mardi et les jours suivants ont été très occupés;)

Je vais jeter un œil au LWT pour voir si je peux trouver pourquoi il n'est pas publié lors de la reconnexion.

Quel est le paramètre de délai d'expiration du courtier MQTT?
Je pense à la possibilité que le courtier suppose une connexion perdue, mais le nœud ESP agit toujours comme s'il était actif et toujours connecté.

J'ai essayé 100-1000 ms. Maintenant 300. Peu importe.

Pas dans le contrôleur, dans le courtier.
Ces durées sont de l'ordre de 10 à 15 secondes.
Veuillez donc vérifier dans la configuration du courtier quel délai est utilisé.

Je n'ai rien changé à propos du délai d'expiration LWT et je n'ai trouvé aucun paramètre pertinent dans ma configuration Mosquitto. Il doit s'agir par défaut. Je n'ai pas trouvé de paramètre de délai d'expiration LWT dans les documents.

Non, pas le timeout LWT, le timeout du courtier.
Si un client n'envoie pas de message dans le délai d'expiration, le courtier le considérera comme déconnecté.
Donc, si le client utilise un autre paramètre de délai d'expiration, il se peut que le courtier considère que le client est déconnecté et que le client n'essaye pas de se reconnecter.

Ce que je comprends de la spécification mqtt, le courtier envoie LWT lorsqu'il n'a pas reçu de message du client pendant la période de maintien en vie qui est définie par le client. Rien à configurer du côté du courtier.

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

Et

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

C'est vrai, mais ce que je veux savoir, c'est ce qu'est cette «période de maintien en vie» du côté des courtiers.
Je sais qu'il est fixé du côté d'ESPeasy.
Mais si ceux-ci ne sont pas synchronisés les uns avec les autres, vous verrez des choses étranges se produire.

hm je n'ai aucune possibilité de définir quelque chose comme ça

Mais dit toujours "Connecté". 4 jours :-D

juste eu un méga-20181006 faire la même chose. LWT n'est pas mis à jour en ligne mais fonctionne normalement avec MQTT

@ jimmys01 Pouvez-vous voir dans votre courtier s'il fonde la décision sur l'ID client? (cela change lorsque la connexion est perdue)
Ce changement d'ID client est quelque chose que j'ai ajouté dans les versions fin septembre.

@ TD-euh, j'ai trouvé un moyen de reproduire ça! Je désauthentifie les wemos du routeur mikrotik et il se connecte de nouveau, mais le LWT reste hors ligne tant que le mqtt fonctionne toujours. Envoyez-moi des builds à tester à volonté

Pouvez-vous également voir l'ID client dans le courtier MQTT?
S'il a un "-1" ou quelque chose derrière l'ID client, cela signifie qu'il accepte le nouvel ID client.
Sinon, cela peut avoir quelque chose à voir avec le changement d'identifiant client que j'ai effectué il y a quelque temps.

Je ne sais pas où se trouve l'identifiant du client dans Mosquitto, mais les journaux indiquent qu'aucun client n'est déconnecté et qu'un nouveau est connecté, probablement parce que le processus de désauthentification et d'authentification wifi est plus rapide que le rythme cardiaque du protocole MQTT.

Nouvelle connexion après le redémarrage de l'esp et du courtier

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

Désauthentifiez le client et le client se reconnecte. Le courtier cette fois a laissé le client LWT en ligne pour une raison quelconque ...

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

Deuxième désautorisation

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

À partir de cette reconnexion et sur le LWT reste hors ligne, les messages MQTT fonctionnent correctement. Notez le _1_1 supplémentaire sur le nom du client.

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

OK, alors je vais annuler le changement d'ID client.
Peut-être est-il également possible de vérifier à distance si le client est considéré comme connecté?
J'ai vu la connexion refuser lorsque le courtier considère que le client est toujours connecté et que le client tente de se reconnecter.
Une nouvelle tentative à de courts intervalles conservera cet état et donc un client ne pourra jamais se reconnecter.

Une mise à jour de statut à ce sujet?

Non, pas encore.
Mais puisque nous faisons (enfin) des progrès sur d'autres problèmes de stabilité, je suppose que ce sera le prochain sur ma liste.
Merci pour le ping;)

J'ai rendu facultatif la modification de l'ID client lors de la reconnexion. (Outils => Avancé, à côté des autres paramètres MQTT)

Veuillez fermer le problème s'il fonctionne maintenant.
Je vais le régler sur fixe.

Pourquoi changer l'ID client de toute façon?

Il y avait des rapports du courtier rejetant les tentatives de connexion tant que le courtier supposait que le client était toujours connecté.
Le client a donc été rejeté et réessayé.
Mais d'une manière ou d'une autre, ces reconnexions ont déclenché quelque chose du côté du courtier pour considérer les tentatives de connexion comme une activité récente de ce client et il ne considérerait donc jamais le client comme déconnecté.

Ok, cela l'a résolu, mais la solution n'est pas explicite pour les autres qui voient cette case à cocher.
Peut-être ajouter une fenêtre contextuelle qui expliquera de la cocher s'il y a des problèmes de reconnexion après une perte de wifi
Une recherche sur les problèmes de tasmota vous montrera qu'ils avaient des problèmes similaires, liés à la conservation MQTT, ressemblaient à un problème de courtier.
J'ai également eu un client qui ne se reconnectait pas du tout au wifi après l'avoir désauthentifié ... j'ai besoin d'enquêter là-dessus.

Nous ajouterons ceci à la documentation .
Nous travaillons très dur pour mettre à jour la documentation et également déplacer une grande partie de la documentation du wiki vers le ReadTheDocs. Cela permet d'avoir une documentation par version.
Les fichiers de documentation sont également inclus dans le référentiel GitHub.

Idéalement, un commit pour un correctif dans le code contiendra également une mise à jour dans la documentation.
Je vais maintenant clore ce numéro.
Si vous avez plus d'informations sur l'autre problème que vous avez mentionné, veuillez en ouvrir un nouveau.

salut

J'ai récemment installé la version 20190110. Cela semble prometteur. Aucun problème de LWT après 5 jours de test. :-)
J'ai quelques nœuds avec l'option "MQTT changer ClientId à la reconnexion" activée et certains désactivées.

Bonnes nouvelles!

T