Comment stopper l’auto-déclenchement MQTT : guide complet 2024

Bienvenue chers makers et passionnés de domotique ! Au Laboratoire SolarLogik, nous comprenons parfaitement la frustration lorsque votre système ne se comporte pas comme prévu. Vous avez simplement associé un bouton via MQTT, et voilà qu’un autre appareil se met à réagir de manière autonome, sans que vous n’ayez configuré d’automatisation explicite. Ce scénario, plus courant qu’on ne le pense, pointe souvent du doigt une fonctionnalité puissante mais parfois mal comprise de MQTT : les messages « retain ».

Dans ce tutoriel détaillé, nous allons vous guider pas à pas pour diagnostiquer la cause de ce déclenchement inattendu, nettoyer les messages persistants qui en sont responsables, et configurer vos appareils pour éviter que cela ne se reproduise. Préparez-vous à reprendre le contrôle total de votre installation domotique !

Matériel requis

Pour suivre ce guide et diagnostiquer efficacement votre problème, vous aurez besoin des éléments suivants :

• Un broker MQTT fonctionnel (ex: Mosquitto installé sur un Raspberry Pi ou un serveur dédié).
• L’appareil « bouton » qui émet le message MQTT (ex: un Sonoff MINIR4, un Shelly Button1, ou un module ESP32/ESP8266 flashé avec Tasmota ou ESPHome).
• L’appareil « récepteur » ou « actionneur » qui se déclenche de manière inattendue (ex: un Shelly Plus 1PM, un Sonoff Basic R2, ou tout autre module relais intelligent).
• Un ordinateur avec un client MQTT installé (recommandation : MQTT Explorer pour son interface graphique intuitive, ou les outils en ligne de commande mosquitto_pub / mosquitto_sub).
• Un accès au réseau local (Wi-Fi ou Ethernet) et aux interfaces d’administration web de vos appareils (si disponibles).

Etape 1 : Comprendre le mécanisme des messages « Retain » MQTT

Le cœur du problème réside très probablement dans la notion de message « retain » (persistant) en MQTT. Lorsqu’un message est publié sur un topic avec le flag « retain » activé, le broker MQTT (comme Mosquitto) ne se contente pas de le transmettre aux abonnés actuels ; il stocke le dernier message « retain » pour ce topic. Ainsi, tout nouvel abonné à ce topic recevra immédiatement ce message stocké dès sa connexion au broker.

Pourquoi est-ce utile ? C’est idéal pour les états permanents. Par exemple, si vous avez un capteur de température qui publie sa valeur avec « retain », tout appareil qui se connecte au réseau recevra immédiatement la dernière température connue sans avoir à attendre la prochaine publication du capteur.

Pourquoi cela pose problème ? Dans votre cas, il est fort probable que votre bouton ait publié un message (par exemple « ON » ou « TOGGLE ») avec le flag « retain » sur un topic auquel votre appareil récepteur est abonné. Chaque fois que l’appareil récepteur se connecte (ou redémarre), il reçoit cet ancien message « ON » et s’active automatiquement, créant l’illusion d’une automatisation fantôme.

Etape 2 : Identifier le topic problématique et le message « retain »

La première étape cruciale est de savoir quel topic est en cause. Nous allons utiliser un client MQTT pour espionner le trafic.

Avec MQTT Explorer (recommandé) :

1. Ouvrez MQTT Explorer et connectez-vous à votre broker MQTT. Entrez l’adresse IP de votre Raspberry Pi (ou serveur), le port (généralement 1883) et vos identifiants si nécessaires.
2. Dans la barre de recherche des topics (en haut), saisissez # pour vous abonner à tous les topics.
3. Observez attentivement la liste des topics. Cherchez le topic qui est publié par votre bouton lorsque vous l’activez. Identifiez également le topic auquel votre appareil récepteur est censé être abonné pour recevoir des commandes.
4. Pour le topic suspect, vous verrez probablement un petit symbole à côté du message (souvent un cercle plein ou une icône spécifique) indiquant qu’il s’agit d’un message « retained ». Le contenu du message (le payload) sera « ON », « 1 », « TOGGLE », ou similaire.

Avec mosquitto_sub (ligne de commande) :

1. Ouvrez un terminal sur votre Raspberry Pi ou un autre ordinateur disposant des outils Mosquitto.
2. Abonnez-vous à tous les topics en mode verbeux pour voir les détails :
   

   mosquitto_sub -h <ADRESSE_IP_BROKER> -p 1883 -t "#" -v

   
   Remplacez <ADRESSE_IP_BROKER> par l’IP de votre broker. Ajoutez -u <UTILISATEUR> -P <MOT_DE_PASSE> si votre broker nécessite une authentification.

3. Activez votre bouton. Observez le terminal. Les messages retained sont généralement indiqués lors de la connexion initiale du client ou dans les logs du broker, mais la commande mosquitto_sub elle-même ne montre pas explicitement le flag. Le comportement d’auto-déclenchement de l’appareil récepteur à chaque redémarrage sera le meilleur indicateur.

Notez précisément le topic identifié (ex: cmnd/lumiere_salon/POWER ou stat/mon_bouton/RESULT) et le payload qu’il contient.

Etape 3 : Supprimer les messages Retain indésirables

Une fois le topic et le payload indésirable identifiés, l’étape suivante consiste à « nettoyer » le broker de ce message « retain » persistant.

Méthode 1 : Avec MQTT Explorer (la plus simple)

1. Dans MQTT Explorer, naviguez jusqu’au topic que vous avez identifié.
2. Dans le panneau de « Publish » (publier) en bas de l’interface :
   • Assurez-vous que le champ « Topic » contient le topic exact à nettoyer.
   • Laissez le champ « Payload » vide (ou saisissez un espace si un champ vide n’est pas permis, mais un vrai champ vide est préférable).
   • Cochez la case « Retain » (très important !).
   • Cliquez sur « Publish ».
3. Le broker va enregistrer ce message vide avec le flag « retain ». Comme un message vide « écrase » le précédent message retenu, l’ancien message indésirable sera supprimé.
4. Pour vérifier, redémarrez votre appareil récepteur. Il ne devrait plus se déclencher automatiquement. Le topic ne devrait plus afficher le symbole « retained » dans MQTT Explorer (ou le message vide remplacera l’ancien).

Méthode 2 : Avec mosquitto_pub (ligne de commande)

1. Ouvrez un terminal.
2. Utilisez la commande suivante pour publier un message vide avec le flag retain :
   

   mosquitto_pub -h <ADRESSE_IP_BROKER> -p 1883 -t "cmnd/lumiere_salon/POWER" -r -n

   • -h <ADRESSE_IP_BROKER> : Adresse IP de votre broker.
   • -p 1883 : Port de votre broker.
   • -t "cmnd/lumiere_salon/POWER" : Remplacez par le topic exact que vous voulez nettoyer.
   • -r : Active le flag « retain ».
   • -n : Publie un payload nul (vide).

   N’oubliez pas les options -u <UTILISATEUR> -P <MOT_DE_PASSE> si votre broker est sécurisé.

3. Après avoir exécuté la commande, redémarrez votre appareil récepteur pour confirmer que le problème est résolu.

Etape 4 : Configurer le bouton/émetteur pour éviter le Retain

Le nettoyage ponctuel est une solution, mais il est crucial d’empêcher le bouton de publier des messages « retain » à l’avenir. La méthode varie selon le firmware de votre bouton.

Pour les appareils Tasmota (très courant) :

Les appareils Tasmota peuvent retenir le statut de leur alimentation (POWER) par défaut. Si votre bouton est configuré pour publier sur un topic POWER et que l’appareil récepteur y est abonné, cela peut être la cause.

1. Accédez à l’interface web de votre appareil Tasmota (bouton).
2. Allez dans la console (Console).
3. Tapez la commande suivante et appuyez sur Entrée :
   

   PowerRetain 0

   
   Cette commande désactive la persistance de l’état POWER sur le broker. Si le bouton est configuré pour publier sur un topic lié à POWER, cela devrait empêcher la rétention.

4. Si votre bouton utilise des Rules spécifiques pour publier sur un topic, examinez ces règles. Assurez-vous qu’aucune commande PUBLISH dans vos règles n’utilise le flag de rétention. Une commande PUBLISH basique dans une règle Tasmota ne retient pas par défaut, sauf si vous utilisez une syntaxe avancée. Si votre bouton envoie des commandes comme cmnd/lumiere/POWER TOGGLE, l’action du retain est généralement gérée par le PowerRetain global.

Pour les appareils ESPHome :

Dans ESPHome, la rétention MQTT est généralement explicitement configurée dans le fichier YAML de votre appareil. Pour un switch ou binary_sensor (représentant le bouton) configuré pour publier sur MQTT, recherchez l’option retain :

1. Ouvrez le fichier YAML de votre configuration ESPHome pour le bouton.
2. Recherchez la section mqtt_json ou mqtt pour votre capteur ou switch.
3. Assurez-vous que l’option retain est définie sur false pour le topic de publication de l’état du bouton ou de la commande :
   

           mqtt:
             ...
             broker: ...
             ...
           binary_sensor:
             - platform: gpio
               pin: GPIOXX
               name: "Mon Bouton Physique"
               on_press:
                 - mqtt.publish:
                     topic: "cmnd/lumiere_salon/POWER"
                     payload: "TOGGLE"
                     retain: false  # Assurez-vous que ceci est à false ou absent (false par défaut)
           

   
   Si l’option retain est absente, la valeur par défaut est false pour la plupart des composants ESPHome, ce qui est généralement le comportement souhaité pour un bouton. Vérifiez attentivement toutes les sections mqtt.publish.

4. Enregistrez et recompilez/téléchargez la configuration sur votre ESPHome.

Pour les appareils Shelly (firmware d’origine) :

Les appareils Shelly ont généralement une section MQTT dans leurs paramètres. Vous devrez vérifier si une option « Retain » est activée pour les messages qu’il publie. Cependant, les boutons Shelly (comme le Button1) publient des événements spécifiques qui sont généralement non retenus par défaut, sauf si vous les configurez via des actions HTTP ou des scripts pour publier des messages MQTT avec retain.

1. Accédez à l’interface web de votre appareil Shelly.
2. Allez dans Internet & Security > Advanced - Developer Settings > MQTT.
3. Vérifiez les paramètres relatifs aux messages publiés. Il est rare qu’un Shelly retienne par défaut ses actions de bouton, mais assurez-vous qu’aucune configuration avancée (par exemple via des actions) ne force la rétention.

Etape 5 : Configurer l’appareil récepteur/actionneur pour des écoutes précises

Bien que le problème vienne principalement de l’émetteur (le bouton) qui retient un message, il est toujours une bonne pratique de s’assurer que l’appareil récepteur n’écoute que les topics qu’il est censé écouter et ne réagit pas à des commandes « génériques » ou des topics d’état.

Pour les appareils Tasmota/ESPHome (sur le récepteur) :

1. Accédez à l’interface web de votre appareil Tasmota ou au fichier YAML de votre ESPHome (appareil récepteur).
2. Pour Tasmota :
   • Vérifiez la Console pour les Rules (règles) que vous auriez pu configurer. Assurez-vous qu’elles ne réagissent qu’aux topics de commande spécifiques et non à des topics d’état génériques de votre bouton.
   • Le topic par défaut pour contrôler une prise Tasmota est généralement cmnd/NOM_DE_L_APPAREIL/POWER. Votre bouton doit publier sur ce topic exact.
3. Pour ESPHome :
   • Examinez la section mqtt_subscribe ou on_message dans votre fichier YAML. Confirmez que l’appareil ne s’abonne qu’aux topics pertinents pour ses fonctions de commande (ex: cmnd/lumiere_salon/POWER) et non à des topics d’état générés par votre bouton (ex: stat/mon_bouton/POWER).
   • Assurez-vous que votre configuration n’a pas de logiques implicites qui pourraient lier des entrées à des sorties de manière inattendue.

Pour les appareils Shelly (firmware d’origine) :

Un Shelly en mode MQTT s’attend à des commandes sur des topics spécifiques (ex: shellies/DEVICEID/relay/0/command). Assurez-vous que votre bouton publie *exactement* sur ce topic si vous utilisez un Shelly comme récepteur. Si le bouton publie sur un topic plus générique, c’est l’intégration dans votre système domotique (si vous en avez un, comme Home Assistant) qui fera le lien, mais ce n’est pas le cas pour un « déclenchement sans automatisation ».

Dépannage

L’appareil se déclenche toujours après suppression du retain

• Vérifiez la suppression : Utilisez MQTT Explorer et abonnez-vous à nouveau au topic suspect. Le message devrait être vide ou absent de la liste des messages retenus. Si ce n’est pas le cas, le message n’a pas été supprimé correctement. Reprenez l’étape 3.
• Redémarrage de l’appareil : Assurez-vous d’avoir redémarré physiquement l’appareil récepteur après avoir nettoyé le message « retain ». Il doit se reconnecter au broker pour recevoir le nouvel état du topic (l’absence de message retenu).
• Bon topic ? : Êtes-vous certain d’avoir ciblé le topic exact qui contenait le message « retain » indésirable ? Il peut y avoir des variations mineures.

Le bouton continue de publier des messages retain

• Configuration du bouton : Retournez à l’étape 4 et revérifiez méticuleusement la configuration de votre bouton (interface web Tasmota/Shelly, fichier YAML ESPHome). Les options de rétention peuvent parfois être cachées ou mal comprises.
• Mise à jour du firmware : Dans de rares cas, un bug dans un ancien firmware pourrait causer ce comportement. Une mise à jour vers la dernière version stable pourrait résoudre le problème.
• Automatisation intermédiaire : Si vous utilisez un système domotique comme Home Assistant, vous pourriez créer une automatisation qui s’abonne au topic de votre bouton, puis republie le message sur le topic de l’appareil récepteur, mais SANS le flag « retain ». C’est un contournement si vous ne parvenez pas à configurer le bouton directement.

Problèmes avec les outils CLI (mosquitto_pub / mosquitto_sub)

• IP / Port incorrects : Vérifiez l’adresse IP et le port de votre broker MQTT.
• Authentification : N’oubliez pas les options -u <UTILISATEUR> -P <MOT_DE_PASSE> si votre broker est sécurisé.
• Firewall : Assurez-vous qu’aucun pare-feu sur le serveur MQTT ou votre machine ne bloque la communication sur le port 1883.

Le problème est dû à une automatisation implicite du système domotique

• Si vous utilisez Home Assistant, vérifiez vos fichiers de configuration automations.yaml, scripts.yaml, ou même des intégrations spécifiques qui pourraient lier des entités sans que vous ayez créé une automatisation graphique. Par exemple, des intégrations MQTT par défaut peuvent lier un state_topic à un command_topic. Examinez les attributs des entités MQTT dans l’interface de développement de Home Assistant.

Conclusion

Félicitations ! Vous avez maintenant une compréhension approfondie des messages « retain » MQTT et des outils nécessaires pour gérer ce comportement. En suivant ces étapes, vous avez diagnostiqué la cause de l’auto-déclenchement, purgé les messages persistants indésirables, et configuré vos appareils pour une meilleure maîtrise de votre système domotique.

Le protocole MQTT, avec sa simplicité et sa légèreté, est incroyablement puissant pour la domotique. Cependant, des concepts comme le « retain » ou la Qualité de Service (QoS) nécessitent une attention particulière pour éviter des comportements inattendus. N’hésitez pas à explorer davantage les outils comme MQTT Explorer ; ils sont de véritables couteaux suisses pour tout maker et expert en domotique.

Au Laboratoire SolarLogik, nous sommes convaincus qu’une bonne compréhension des fondamentaux est la clé pour construire des systèmes fiables et performants. Continuez d’expérimenter, d’apprendre, et de bâtir la maison intelligente de demain !

---

Ce tutoriel a ete redige en reponse a un besoin technique identifie sur les forums communautaires. La solution d’ingenierie a ete developpee par le Laboratoire SolarLogik.

Pour aller plus loin, découvrez notre comparatif des les meilleurs panneaux solaires portables pour camping-car et aventure : Comparatif : Les Meilleurs Panneaux Solaires Portables pour Camping-Car et Aventure.

Pour une analyse approfondie et un comparatif détaillé, consultez notre guide sur : Comparatif des meilleurs kits solaires autoconsommation en 2024.

Demandez un devis gratuit pour votre installation solaire !