MQTT sert de bus de messages entre vos équipements domotiques et Home Assistant. Un capteur publie une valeur, un broker la reçoit, Home Assistant s’y abonne, puis une automatisation réagit. Rien de magique : c’est juste une mécanique publish/subscribe très efficace quand elle est bien tenue, et très pénible quand les topics partent dans tous les sens.
Dans une installation Home Assistant, MQTT devient utile dès que vous utilisez Zigbee2MQTT, certains modules DIY, des capteurs ESP, des passerelles locales ou des intégrations qui parlent mieux en messages qu’en API propriétaire. Si vous n’avez que des intégrations natives très simples, MQTT n’est pas obligatoire. Si vous voulez comprendre ce qui circule dans la maison, il devient vite indispensable, parce qu’il expose les états avant qu’ils soient digérés par les dashboards et les automatisations.
- ✓MQTT est un protocole publish/subscribe : les appareils publient des messages, Home Assistant les lit via un broker.
- ✓Le broker, souvent Mosquitto, est le point central : sans lui, les messages MQTT ne circulent pas.
- ✓Zigbee2MQTT utilise MQTT pour exposer les états, commandes et événements des appareils Zigbee.
- ✓MQTT est utile pour le local, le debug et les intégrations techniques, mais il demande une bonne discipline sur les topics, les identifiants et les sauvegardes.
- ✓Ne l’installez pas “par principe” : installez-le quand un vrai flux MQTT existe dans votre maison.
01 / 10
Le rôle exact de MQTT
MQTT ne pilote pas directement votre ampoule. Il transporte un message.
Exemple simple : un capteur de température publie une valeur sur un topic MQTT, puis Home Assistant lit ce topic et met à jour l’entité correspondante. Si la température dépasse un seuil, une automatisation peut déclencher le chauffage, une alerte ou un scénario, sans que le capteur connaisse la logique complète de votre maison.
La différence avec une API classique est importante. L’appareil ne parle pas forcément à Home Assistant en direct. Il parle au broker. Home Assistant s’abonne ensuite aux topics qui l’intéressent. Cette séparation rend le système très lisible quand on debugge, parce qu’on peut inspecter le message brut sans passer par l’interface graphique, puis vérifier où la chaîne se casse.
Le réflexe à garder : MQTT est un transport, pas une interface utilisateur. Il ne remplace pas vos dashboards, vos automatisations ou vos intégrations. Il donne simplement une couche stable pour faire circuler des états et des commandes.
02 / 10
Broker, topic, payload : les trois mots à connaître
Le broker MQTT est le serveur qui reçoit et redistribue les messages. Dans Home Assistant, on croise souvent Mosquitto parce qu’il est simple à installer en add-on et largement documenté. Mais le principe reste le même avec un autre broker : il doit être stable, joignable et correctement protégé.
Le topic est l’adresse logique du message. Par exemple, un capteur peut publier sur une arborescence du type maison/salon/temperature. Le payload est le contenu : valeur brute, JSON, état ON/OFF, niveau de batterie ou commande. Quand un problème apparaît, je commence toujours par lire topic et payload avant de soupçonner l’automatisation.
| Élément | Rôle | Erreur fréquente |
|---|---|---|
| Broker | Reçoit et redistribue les messages | Identifiants faibles, broker non sauvegardé, service instable |
| Topic | Adresse logique du message | Nommage incohérent, doublons, casse différente |
| Payload | Contenu transmis | JSON mal formé, valeur inattendue, unité absente |
| Abonnement | Ce que Home Assistant écoute | Wildcard trop large ou topic oublié |
Commencez toujours par là. Broker, topic, payload : si ces trois points sont flous, le reste du debug sera flou aussi.
03 / 10
Pourquoi Zigbee2MQTT s’appuie dessus
Zigbee2MQTT est le cas d’usage le plus connu : il fait le pont entre votre réseau Zigbee et MQTT. Les capteurs, prises et interrupteurs Zigbee ne parlent pas MQTT eux-mêmes. Zigbee2MQTT traduit les états et commandes en messages que Home Assistant peut consommer.
C’est puissant, parce que vous pouvez inspecter ce qui sort du réseau Zigbee sans attendre que Home Assistant interprète tout proprement. Quand un capteur remonte une batterie étrange, une disponibilité incohérente ou un état non reconnu, le message MQTT brut donne souvent la réponse plus vite que l’interface.
Mais il ne faut pas confondre les deux sujets. Zigbee2MQTT est une passerelle Zigbee. MQTT est la couche de transport. Le post que vous lisez ici explique MQTT ; il ne remplace pas un tutoriel d’installation Zigbee2MQTT, qui doit traiter le coordinateur, le canal radio, les appareils routeurs, les mises à jour de firmware et le maillage. Mélanger les deux rend le diagnostic beaucoup moins propre.
04 / 10
Faut-il installer MQTT avec Home Assistant ?
Non, pas systématiquement. Si vos intégrations fonctionnent déjà en local via Home Assistant, Matter, ZHA, une API officielle ou une intégration cloud assumée, installer MQTT “au cas où” ajoute une pièce de plus à maintenir, à sauvegarder et à sécuriser. Le bon critère est simple : avez-vous un besoin réel de broker ou seulement l’envie d’ajouter un composant avancé ?
Je l’installe quand un flux en dépend : Zigbee2MQTT, Tasmota, ESPHome en mode MQTT, passerelle RF ou vieux module bavard. Là, MQTT n’est pas un luxe technique.
MQTT utile ou inutile ?
Le bon choix dépend de vos flux réels, pas de la mode Home Assistant.
Utile
Zigbee2MQTT, Tasmota, capteurs DIY
Le broker devient le passage central des états et commandes.
Optionnel
Intégrations natives solides
Si Home Assistant lit déjà tout proprement, MQTT peut être une complexité inutile.
À éviter
Installation sans plan
Un broker sans topics clairs finit en dette technique.
05 / 10
Le piège des topics mal rangés
Un mauvais plan de topics se paie plus tard. Au début, tout marche avec trois capteurs. Six mois après, vous avez des topics salon_temp, salon/temperature, zigbee2mqtt/salon/temp et test/capteur1. La maison fonctionne, mais le debug devient sale.
La cohérence bat le nom parfait.
Gardez une convention simple. Préférez une arborescence lisible, des noms stables, et évitez de renommer les topics à chaque changement d’humeur. Si vous utilisez Zigbee2MQTT, respectez sa logique au lieu de bricoler une traduction partout, parce qu’un plan “plus joli” mais isolé rendra les logs, les scripts et les sauvegardes plus difficiles à relire.
- Un préfixe clair pour les équipements ou passerelles.
- Des noms d’appareils stables, sans accents ni espaces si vous les exploitez dans des scripts.
- Un format de payload lisible, idéalement documenté quand il est custom.
- Une séparation nette entre états, commandes et topics de test.
06 / 10
Retained, QoS et discovery : les options qui changent le comportement
MQTT paraît simple jusqu’au moment où un état ancien réapparaît après redémarrage. C’est souvent lié aux messages retained : le broker garde le dernier message sur un topic et le renvoie aux nouveaux abonnés. C’est pratique pour un état de capteur, dangereux pour une commande si vous ne comprenez pas ce que vous faites.
Exemple concret : conserver la dernière température du salon a du sens. Conserver une commande “ON” envoyée à une prise peut être une mauvaise idée si un client se reconnecte et relit cette commande comme si elle était fraîche. La règle de terrain est simple : retained pour les états stables, prudence maximale pour les commandes et les scénarios qui déclenchent une action physique.
Le QoS mérite aussi une lecture sobre. Dans une maison, on cherche surtout un système prévisible, pas une usine à gaz. Monter le QoS sans raison ne transforme pas un réseau instable en réseau fiable. Commencez avec les réglages documentés par l’intégration ou la passerelle utilisée, puis changez seulement si vous avez un symptôme précis : message perdu, doublon, client fragile ou broker qui redémarre mal.
La découverte MQTT de Home Assistant ajoute une autre couche. Elle permet à des appareils de se déclarer automatiquement, avec les bons topics d’état, de commande et de disponibilité. C’est confortable, mais cela suppose que les messages de configuration soient propres. Si une entité fantôme apparaît, si un capteur garde un ancien nom ou si un appareil ne disparaît pas, cherchez d’abord du côté des topics de discovery et des messages retained, avant de supprimer des entités au hasard dans l’interface.
Options MQTT à vérifier avant de debug
Ces trois réglages expliquent beaucoup de comportements étranges.
- ✓Un message retained est-il encore stocké sur le topic ?
- ✓Le topic sert-il à un état ou à une commande ?
- ✓Le QoS a-t-il été changé pour une vraie raison ?
- ✓La discovery Home Assistant publie-t-elle une configuration cohérente ?
- ✓Le broker a-t-il été redémarré après nettoyage des vieux topics ?
07 / 10
Sécurité : ne laissez pas le broker ouvert
MQTT est souvent local, mais “local” ne veut pas dire sans risque. Un broker sans authentification, exposé par erreur, ou partagé avec des appareils peu fiables peut devenir un point faible. Même dans une maison, mettez des identifiants solides, limitez l’accès réseau et évitez les ports ouverts sur Internet.
Sur une installation sérieuse, je préfère un broker local, non exposé, avec des utilisateurs dédiés selon les besoins. Home Assistant n’a pas besoin du même compte qu’un script de test. Et si vous manipulez des commandes sensibles, comme chauffage, alarme ou ouverture, les ACL MQTT deviennent un sujet concret, pas une coquetterie d’admin réseau. Un compte trop large peut publier partout ; un compte limité réduit les dégâts d’une erreur de script.
Checklist broker propre
Avant de brancher trop d’appareils, verrouillez la base.
- ✓Un broker stable, local et sauvegardé.
- ✓Un compte dédié pour Home Assistant.
- ✓Pas de port MQTT exposé directement sur Internet.
- ✓Des topics nommés de façon cohérente.
- ✓Un outil de debug pour lire topic + payload sans deviner.
08 / 10
Debug : MQTT rend les pannes plus visibles
C’est là que MQTT devient franchement utile. Quand une automatisation ne se déclenche pas, vous pouvez vérifier si le message arrive au broker, si Home Assistant le voit, puis si l’automatisation réagit. Vous coupez le problème en trois morceaux au lieu de chercher au hasard dans toute la stack, ce qui change tout quand une panne arrive tard le soir et que vous devez isoler vite le vrai coupable.
Dans mon ordre de diagnostic : broker en ligne, client connecté, topic publié, payload correct, entité mise à jour, automatisation déclenchée. Si le message n’arrive pas au broker, inutile d’accuser Home Assistant. S’il arrive mais que l’entité ne bouge pas, regardez la configuration MQTT ou la découverte automatique. Cette méthode évite beaucoup de faux coupables.
Deux scènes où MQTT fait gagner du temps
Le protocole devient intéressant quand il rend le diagnostic observable.
Lire le message brut
Topic, payload et timestamp disent souvent plus que l’état final affiché dans Home Assistant.
Fiabiliser le réseau local
Broker, routeur et alimentation doivent rester stables si des automatisations dépendent de MQTT.
09 / 10
Ce que MQTT ne règle pas
MQTT ne rend pas un capteur radio plus fiable. Il ne corrige pas un mauvais maillage Zigbee, une alimentation instable, un Wi-Fi saturé ou un broker qui redémarre tous les deux jours. Il donne de la visibilité et une couche de transport, mais il ne remplace pas une installation propre.
Il ne faut pas non plus transformer chaque problème Home Assistant en problème MQTT. Une automatisation mal écrite reste mal écrite. Une entité mal nommée reste pénible. Un historique trop lourd reste un problème de base de données. MQTT aide à isoler les flux, pas à faire disparaître la dette de configuration.
10 / 10
Le verdict de terrain
Installez MQTT quand un équipement ou une passerelle en a besoin. Pas pour décorer une installation déjà claire.
Mon verdict est tranché : MQTT est excellent quand il transporte des messages locaux utiles et inspectables. Il est inutile quand il sert seulement à complexifier une installation qui fonctionnait déjà. Dans Home Assistant, la bonne architecture n’est pas celle qui utilise le plus de protocoles ; c’est celle qu’on peut debugger à 23 h sans tout casser.
