Pour confirmer avant d’allez plus loin, est ce que l’un de vous deux peux executer cette commande:
grep -qF -- "listener 1883" /var/lib/gladysassistant/mosquitto/mosquitto.conf || sudo echo "listener 1883" >> /var/lib/gladysassistant/mosquitto/mosquitto.conf
Puis redémarrer
@GBoulvin dans ton cas il faudra stopper ton mosquitto installé manuellement
Alors…
La commande me renvoie systématiquement un “Permission non accordée”. Je l’ai donc ajouté manuellement.
Mais en plus, je n’arrive plus à désactiver le mosquitto installé 
Toujours est-il que ça fonctionne, mais je ne sais pas comment (c’est la philosophie de Gladys, non ? 
)
Bon, finalement, j’ai réussi à désactiver mon “second” broker et exécuter la commande proposée.
Voici ce que le log issu de docker dit :
1612709888: mosquitto version 2.0.7 starting
1612709888: Config loaded from /mosquitto/config/mosquitto.conf.
1612709888: Opening ipv4 listen socket on port 1883.
1612709888: Opening ipv6 listen socket on port 1883.
1612709888: mosquitto version 2.0.7 running
1612710037: mosquitto version 2.0.7 terminating
1612710038: mosquitto version 2.0.7 starting
1612710038: Config loaded from /mosquitto/config/mosquitto.conf.
1612710038: Opening ipv4 listen socket on port 1883.
1612710038: Opening ipv6 listen socket on port 1883.
1612710038: mosquitto version 2.0.7 running
1612710090: mosquitto version 2.0.7 terminating
1612710157: mosquitto version 2.0.7 starting
1612710157: Config loaded from /mosquitto/config/mosquitto.conf.
1612710157: Opening ipv4 listen socket on port 1883.
1612710157: Opening ipv6 listen socket on port 1883.
1612710157: mosquitto version 2.0.7 running
Super !
Mais en fait, ça ne fonctionne pas. Malgré plusieurs reboot, aucun accès à mes périphériques mqtt 
Et pourtant :
Salut, ça aurait été bien de faire un nouveau sujet sur ton soucis, parce que là depuis hier ça dénature un peu le [tutoriel]…
Ton mosquitto crash en boucle.
Peux tu me donner le contenu du fichier suivant ?
/var/lib/gladysassistant/mosquitto/mosquitto.conf
Voici :
allow_anonymous false
connection_messages false
password_file /mosquitto/config/mosquitto.passwd
listener 1883
Est-ce qu’à terme, cela pose un problème que j’utilise eclipse-mosquitto en tant que service hors de Docker ou je peux sans souci laisser ça comme ça?
Est-ce possible que j’aie une latence qui n’existait pas avant ou suis-je parano?
Bonjour à tous, j’ai les mêmes symptômes: aucune config ou paramètre supplémentaire sur une installation qui marchait bien et plus de comm mqtt sur les radiateurs sonoff. Je suis en Gladys 4.0.8 sur une rasp installée via l’image Gladys Assistant.
Suivant les conseils ci-dessus.
Je me suis connecté en ssh sur la rasp
En utilisant vi, j’ai ajouté “listener 1883” au fichier /var/lib/gladysassistant/mosquitto/mosquitto.conf
J’ai ensuite redémarré ma rasp
Dans Gladys Assistant, j’ai dû reconfigurer mon service mqtt.
Tout refonctionne comme avant. 
merci
Pour information, le problème a été réglé avec Gladys v4.1.0.
@AlexTrovato a codé une routine qui met à jour automatiquement le fichier de conf + bloque la version du container a mosquitto 2.0 pour éviter tout problème à l’avenir.
Juste pour info, après avoir recommencé une énième fois, je suis arrivé à remettre le bon mosquitto en route et je vais vous expliquer comment…
Le mot de passe du serveur via Docker avait été remis à zéro, dans doute que aux nombreuses manipulations !
A aucun moment je n’ai été vérifié ce qu’il y avait derrière les petits points du mot de passe et ça avait été remplacé par ******.
Donc en effet, ça ne pouvait pas marcher…
Je suis un génie…
Enfin…
En fait…
Non.
Mince, c’est peut être un bug du service MQTT ça non @AlexTrovato ?
le front remplace le contenu du mot de passe par des **** a un moment non ?
Le front reçoit le vrai mot de passe uniquement si MQTT embarqué est utilisé (sinon c’est un faux mot de passe *********). Et la possibilité de l’afficher est également disponible uniquement pour un broker embarqué.
Le mot de passe est généré aléatoirement à partir du moment où on passe en mode “broker embarqué”, mais il est possible de le modifier depuis la page de configuration, ce qui le modifie également sur mosquitto.
J’ai pris le choix de cacher le mot de passe s’il n’est pas géré par Gladys (connexion à un serveur externe).
J’ai peut-être loupé un truc, mais s’il faut fixer, mon PC est tout chaud !
Je me doute que normalement il n’y a pas de bug, mais là ça y ressemble fortement Si il n’a pas mis “****” dans le champs et que ça se retrouve dans le mot de passe, c’est que forcément le frontend a du se mélanger les pinceaux à un moment. Peut-être lors d’un clique supplémentaire sur “connexion” plus tard dans l’UI ?
Après c’est peut-être un bug legacy qui a été fixé dans une release récente, mais bon il faut en être sur parce que ça craint comme bug 
Je ne me prendrais pas trop la tête avec ça car, pour rappel, j’ai installé éclipse mosquitto en dehors de Docker, activé et désactivé les deux plusieurs fois, modifié le .conf manuellement…
Un conflit à un moment donné n’est pas impossible…
Maintenant, dans un monde parfait, ça n’aurait jamais dû arriver (Mais qu’est-ce qu’on se ferait Ch… 
)
Salutations!
Je déterre ce sujet pour vous faire part d’un petit souci si semble être récurrent.
Lorsque le container éclipse-mosquitto est mis à jour (via Watchtower je suppose, la dernière fois il y a deux heures), je dois systématiquement re-sauvegarder le login et mot de passe du serveur MQTT dans Gladys pour que ça refonctionne…
Suis-je le seul?
Salut @GBoulvin ,
Non tu n’es pas seul dans ce cas, j’ai le même problème avec mosquitto, mais ça m’arrive égalementsur coupure EDF à chaque orage, visiblement Gladys ne sait pas se reconnecter automatiquement (certainement après plusieurs essais infructueux). Également, l appui sur le bouton ne suffit pas, il faut retaper le mot de passe (lorsque je bossais sur l’integration Netatmo, j’avais remarqué que le mot de passe devenait ********** en base au lieu du mot de passe d’origine).
En effet! Pour éviter ça, ‹ démasquer › le mot de passe avant de cliquer sur ‹ sauvegarder la configuration › suffit chez moi…
Est-ce qu’on a une issue GitHub pour ce bug?
ça permettrait de ne pas le perdre de vue.
@pierre-gilles , si c’est lors de la mise à jour du container que les credentials sont ‘oubliés’, ne serait-ce pas un bug du côté d’eclipse-mosquitto ? Ou c’est à Gladys de vérifier que les infos sont transmises au container MQTT après une mise à jour ?
A enquêter Dans tous les cas peut-importe si ça vient de eclipse-mosquitto ou Gladys, côté Gladys il faut que ça marche!