Guide de l'automatisation IoT : automatiser maisons, bâtiments, exploitations agricoles et énergie avec MQTT

L'automatisation IoT consiste à laisser des capteurs, des règles et des actionneurs prendre en charge les décisions courantes dans un espace physique, qu'il s'agisse d'éteindre les lumières d'un bureau vide ou d'ouvrir une vanne d'irrigation quand le sol est sec. Ce guide vous propose une architecture unique qui fonctionne pour les maisons, les bâtiments, les exploitations agricoles et les systèmes énergétiques, présente des automatisations Home Assistant et Python fonctionnelles via MQTT, et explique comment garder l'ensemble fiable et sécurisé.

Ce qu'est l'automatisation IoT et pourquoi MQTT en est le centre

Toute automatisation, aussi complexe soit-elle, suit la même boucle : mesurer, décider, agir, confirmer. Un capteur mesure quelque chose, une règle décide si une action est nécessaire, un actionneur fait le travail, et un rapport d'état confirme que c'est fait.

Les systèmes d'automatisation traditionnels construisaient cette boucle à l'intérieur du contrôleur d'un seul fournisseur. Cela fonctionne jusqu'au jour où vous voulez qu'un détecteur de mouvement Zigbee commande un relais Wi-Fi, ou que la production d'un onduleur solaire décide du moment où un chauffe-eau se met en marche. L'automatisation IoT découpe la boucle en éléments indépendants qui communiquent via une couche de messagerie commune, et cette couche est presque toujours MQTT.

MQTT convient parce que :

• Le publish/subscribe découple les équipements de la logique. Un capteur publie une fois ; un nombre quelconque de règles, de tableaux de bord et d'enregistreurs peuvent s'abonner.
• Il est assez léger pour les microcontrôleurs comme l'ESP32 et l'ESP8266, et pris en charge nativement par Tasmota, ESPHome, Zigbee2MQTT, les appareils Shelly et Home Assistant.
• Les retained messages permettent à un moteur de règles qui redémarre de connaître immédiatement l'état courant de chaque équipement.
• Les messages Last Will annoncent qu'un équipement s'est déconnecté, afin que les automatisations puissent se mettre en sécurité.

Si la notion de broker est nouvelle pour vous, commencez par ce que fait un broker MQTT, puis revenez ici.

L'architecture d'automatisation IoT en quatre couches

La même structure s'applique, que vous automatisiez un appartement, un immeuble de bureaux de 20 étages ou une serre.

C'est la séparation de ces couches qui rend le système maintenable. Vous pouvez remplacer un capteur Zigbee par un capteur Wi-Fi, ou déplacer des règles de Home Assistant vers Node-RED, sans recâbler le reste, tant que les topics restent les mêmes.

Broker local, broker cloud ou les deux ?

Un broker sur un Raspberry Pi local permet aux automatisations de continuer à fonctionner quand Internet est coupé, ce qui compte pour l'éclairage et le chauffage. Un broker cloud rend les équipements accessibles de partout, relie des sites qui ne partagent pas le même réseau (une exploitation agricole avec plusieurs parcelles, une entreprise avec plusieurs bâtiments) et vous épargne la mise à jour et la sauvegarde d'un broker. De nombreuses installations combinent les deux : les règles critiques en temps s'exécutent en local, tandis que la supervision, le contrôle à distance et la coordination multisite passent par un broker MQTT cloud. Le tutoriel Home Assistant avec un broker MQTT externe détaille cette configuration.

Concevoir les topics pour l'automatisation

Des noms de topics clairs rendent les règles lisibles et évitent les interférences accidentelles entre équipements. Une organisation pratique :

<site>/<area>/<device>/<channel>
<site>/<area>/<device>/<channel>/set      (commands)

home/livingroom/thermostat/temperature
home/livingroom/thermostat/setpoint/set
office/floor3/zone-b/occupancy
farm/greenhouse1/soil/moisture
farm/greenhouse1/valve/state
energy/house/solar/power

Des règles empiriques qui font gagner des heures de débogage :

1. Séparez les topics d'état (ce que l'équipement rapporte) des topics de commande (ce que vous lui demandez de faire), généralement avec un suffixe /set.
2. Publiez l'état en mode retained pour que tableaux de bord et moteurs de règles le voient instantanément après un redémarrage.
3. Utilisez des payloads JSON avec unités et horodatages lorsqu'un équipement rapporte plusieurs valeurs.
4. Donnez à chaque équipement un topic status avec un Last Will valant offline.

Le guide sur la structure des topics MQTT pour la maison connectée va plus loin, notamment sur la gestion des groupes et des scènes.

L'automatisation IoT selon l'environnement

L'architecture reste constante, mais chaque environnement a ses propres priorités.

Maisons

La domotique est le domaine le plus mature. Home Assistant est la couche logique habituelle, MQTT servant de passerelle avec des équipements de nombreux écosystèmes : capteurs Zigbee via Zigbee2MQTT, prises Wi-Fi flashées avec Tasmota et cartes ESP32 personnalisées construites avec ESPHome. Les automatisations typiques sont l'éclairage selon la présence, les plannings de chauffage, les alertes de fuite et les notifications. Jeedom et Domoticz savent aussi communiquer en MQTT et peuvent tenir ce même rôle de couche logique. Un piège courant consiste à dépendre du cloud pour des choses qui doivent fonctionner hors ligne, comme un interrupteur ; gardez-les en local.

Bâtiments tertiaires

L'automatisation des bâtiments se concentre sur le CVC, l'éclairage, l'occupation et la qualité de l'air, généralement sur de nombreuses zones. Les systèmes existants parlent BACnet, KNX ou Modbus, et des passerelles les traduisent en MQTT afin que les applications plus récentes puissent exploiter les données sans toucher à la GTB. Lisez l'automatisation des bâtiments avec MQTT pour l'architecture et BACnet vers MQTT pour l'étape de passerelle. Le CVC et l'éclairage pilotés par l'occupation sont les gains rapides classiques, car les pièces vides sont faciles à détecter.

Exploitations agricoles et serres

L'automatisation agricole doit composer avec de longues distances, des conditions difficiles et des capteurs sur batterie. L'humidité du sol, la température de l'air, l'hygrométrie et les niveaux d'eau pilotent l'irrigation, la ventilation et l'ombrage. LoRaWAN est courant dans les champs, avec des serveurs réseau comme The Things Network qui transmettent les uplinks via MQTT, comme expliqué dans The Things Network et MQTT. Un broker cloud est particulièrement utile ici, car les parcelles et les serres partagent rarement un réseau local. Le guide de l'IoT pour l'agriculture intelligente et le tutoriel d'automatisation de serre couvrent les détails.

Énergie

L'automatisation énergétique équilibre production, stockage et consommation : faire fonctionner un chauffe-eau quand la production solaire est élevée, recharger un véhicule électrique en heures creuses ou délester les charges non critiques. Onduleurs, batteries et compteurs intelligents exposent souvent du Modbus ou des API locales que de petites passerelles publient vers MQTT. Voir le suivi énergétique domestique avec MQTT et la supervision d'onduleur solaire pour des réalisations concrètes.

En pratique : une automatisation d'irrigation selon l'humidité du sol

Construisons une boucle complète mesurer-décider-agir. Un équipement publie l'humidité du sol, Home Assistant décide quand arroser, et une vanne rapporte son état. Vous pouvez tout tester sur le serveur MQTT public gratuit broker.connectmq.com avant de connecter du vrai matériel. Choisissez un préfixe unique comme connectmq/demo/k7x2p9 et utilisez-le partout ci-dessous ; ce serveur public est lisible par tous, seules des données de test y ont donc leur place, jamais des données de production.

Étape 1 : simuler le capteur et la vanne en ligne de commande

Publiez une mesure d'humidité retenue :

mosquitto_pub -h broker.connectmq.com -p 1883 -i soil-k7x2p9 \
  -t "connectmq/demo/k7x2p9/greenhouse1/soil" -r \
  -m '{"moisture": 42.5, "tempC": 19.8}'

Observez tout ce qui passe sous le préfixe dans un second terminal :

mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-k7x2p9 \
  -t "connectmq/demo/k7x2p9/#" -v

Étape 2 : définir les entités dans Home Assistant

Ajoutez l'intégration MQTT dans Home Assistant (Paramètres, Appareils et services, Ajouter une intégration, MQTT) avec le broker broker.connectmq.com, le port 1883 et un client ID unique pour les tests. Déclarez ensuite le capteur et la vanne dans configuration.yaml :

mqtt:
  sensor:
    - name: "Greenhouse Soil Moisture"
      unique_id: greenhouse1_soil_moisture
      state_topic: "connectmq/demo/k7x2p9/greenhouse1/soil"
      unit_of_measurement: "%"
      value_template: "{{ value_json.moisture }}"
  switch:
    - name: "Greenhouse Valve"
      unique_id: greenhouse1_valve
      command_topic: "connectmq/demo/k7x2p9/greenhouse1/valve/set"
      state_topic: "connectmq/demo/k7x2p9/greenhouse1/valve/state"
      payload_on: "ON"
      payload_off: "OFF"
      retain: false

Étape 3 : écrire la règle d'automatisation

automation:
  - alias: "Irrigate greenhouse when soil is dry"
    mode: single
    triggers:
      - trigger: numeric_state
        entity_id: sensor.greenhouse_soil_moisture
        below: 30
        for: "00:05:00"
    conditions:
      - condition: time
        after: "06:00:00"
        before: "20:00:00"
    actions:
      - action: switch.turn_on
        target:
          entity_id: switch.greenhouse_valve
      - delay: "00:10:00"
      - action: switch.turn_off
        target:
          entity_id: switch.greenhouse_valve

La clause for ignore les baisses brèves dues au bruit du capteur, la condition horaire évite d'arroser la nuit, et le délai fixe garantit la fermeture de la vanne même si la mesure d'humidité cesse d'arriver. Publiez une valeur d'humidité de 25 et maintenez-la pendant cinq minutes ; vous verrez ON apparaître sur le topic valve/set dans votre fenêtre mosquitto_sub, suivi de OFF dix minutes plus tard. Un vrai contrôleur de vanne s'abonnerait à valve/set et publierait sa position réelle sur valve/state.

La même règle sans Home Assistant

Tous les sites n'utilisent pas Home Assistant. Node-RED (voir le tutoriel Node-RED MQTT) ou un petit service Python peuvent héberger la même logique. Cette version utilise paho-mqtt 2.x et ajoute une hystérésis pour que la vanne ne bascule pas sans cesse autour du seuil :

import json
import threading
import uuid

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/k7x2p9/greenhouse1"
DRY, WET, MAX_RUN_S = 30.0, 45.0, 600
valve_on = False
timer = None


def set_valve(client, on):
    global valve_on, timer
    valve_on = on
    client.publish(f"{PREFIX}/valve/set", "ON" if on else "OFF", qos=1)
    if timer:
        timer.cancel()
    if on:  # sécurité : ne jamais fonctionner plus de MAX_RUN_S
        timer = threading.Timer(MAX_RUN_S, set_valve, args=(client, False))
        timer.start()
    print("valve", "ON" if on else "OFF")


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/soil", qos=1)


def on_message(client, userdata, msg):
    moisture = json.loads(msg.payload)["moisture"]
    if not valve_on and moisture < DRY:
        set_valve(client, True)
    elif valve_on and moisture > WET:
        set_valve(client, False)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"irrigation-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Checklist de conception d'une automatisation IoT

Parcourez cette liste avant de confier à une automatisation quoi que ce soit d'important :

1. Sécurité en cas de défaillance. Décidez de ce que doit faire chaque actionneur si le moteur de règles, le broker ou le capteur disparaît. Les vannes se ferment, les radiateurs s'éteignent, les portes restent verrouillées.
2. Anti-rebond et hystérésis. Utilisez des fenêtres temporelles ou des seuils de marche et d'arrêt distincts pour que le bruit ne provoque pas de commutations rapides.
3. Confirmer l'état. Commandez un équipement sur /set, mais pilotez les tableaux de bord et les règles suivantes à partir de son state rapporté.
4. Gérer les équipements hors ligne. Abonnez-vous aux topics status à Last Will et déclenchez une alerte lorsqu'un capteur critique se tait.
5. Conserver les commandes manuelles. Les personnes doivent pouvoir reprendre la main localement sur l'automatisation, et les règles doivent le respecter.
6. Choisir la QoS délibérément. QoS 1 pour les commandes et les alarmes, QoS 0 pour les mesures fréquentes. L'article sur les niveaux de QoS MQTT explique pourquoi.
7. Sécuriser. Utilisez TLS, des identifiants uniques par équipement ou par passerelle, et n'exposez jamais un broker sans authentification. La checklist des bonnes pratiques de sécurité MQTT s'applique directement.
8. Journaliser les décisions. Publiez ce que la règle a fait et pourquoi sur un topic de journal, afin de pouvoir déboguer « pourquoi le chauffage s'est-il allumé à 3 heures du matin ? ».

Tester et maintenir les automatisations dans la durée

Une automatisation qui fonctionne le premier jour peut se dégrader en silence des mois plus tard : la pile d'un capteur s'épuise, une mise à jour de firmware renomme une entité, ou un équipement obtient une nouvelle adresse IP et ne se reconnecte jamais. Traitez les automatisations comme n'importe quel autre logiciel dont vous dépendez.

Commencez par tester les règles avec des messages simulés avant qu'elles ne touchent de vrais actionneurs. Publier une fausse valeur d'humidité basse ou un faux événement d'occupation depuis la ligne de commande est le moyen le plus rapide de voir si une règle se déclenche, et cela ne coûte rien. Conservez une courte liste de ces messages de test pour chaque règle importante afin de pouvoir les rejouer après les mises à jour.

Ensuite, surveillez la santé des entrées, pas seulement des sorties. Une règle de chauffage qui s'appuie sur un capteur de température ne vaut que par le dernier relevé de ce capteur. Suivez le temps écoulé depuis la dernière publication de chaque équipement critique et déclenchez une alerte lorsqu'il dépasse quelques intervalles de rapport. Les topics status retenus avec un Last Will facilitent la tâche, car un équipement planté se signale lui-même.

Enfin, passez en revue les automatisations quelques fois par an. Supprimez les règles dont personne ne se souvient, vérifiez que les seuils correspondent toujours à la saison ou à la culture, et confirmez que les commandes manuelles fonctionnent encore. Un petit ensemble de règles bien comprises vaut mieux qu'un grand ensemble auquel personne ne fait confiance.

Les pièges courants

• Des règles éparpillées entre de nombreux outils. Si une partie de la logique vit dans le firmware d'une prise, une autre dans Home Assistant et une autre dans Node-RED, personne ne peut prédire le comportement. Choisissez un moteur de règles principal.
• Les commandes retenues. Un ON retenu sur un topic de commande rallumera l'équipement à chaque reconnexion. Retenez l'état, pas les commandes.
• Les client ID partagés. Deux clients avec le même ID s'éjectent mutuellement du broker en boucle. Rendez chaque ID unique.
• Des chemins critiques uniquement dans le cloud. Gardez en local les règles liées à la sécurité et au confort essentiel, et utilisez le cloud pour la supervision et l'accès à distance.
• Négliger le choix du protocole. Matter, Zigbee et Wi-Fi présentent chacun des compromis ; Matter vs MQTT explique comment ils peuvent coexister.

Étendre l'automatisation IoT à plusieurs sites avec ConnectMQ

Dès que vous avez plus d'un site, ou que vous avez besoin d'un accès à distance sans ouvrir de ports sur votre routeur, un broker MQTT managé devient le hub le plus simple. ConnectMQ offre à chaque site le même endpoint via TLS sur le port 8883, ou via WebSocket sécurisé sur le port 8084 pour les tableaux de bord dans le navigateur ; les instances Home Assistant, les flows Node-RED, les passerelles et les équipements situés en différents lieux se retrouvent ainsi sur un même broker. L'explorateur de topics en direct du portail vous aide à vérifier ce que publient réellement les équipements, et des règles d'alerte à seuil avec un journal des alertes peuvent vous prévenir lorsqu'une mesure franchit une limite. La logique d'automatisation elle-même reste dans Home Assistant, Node-RED ou votre propre service, connectés comme de simples clients MQTT.

Le plan Serverless gratuit prend en charge jusqu'à 25 connexions, ce qui couvre largement une maison type ou une petite serre. Les bâtiments plus grands et les déploiements multisites peuvent passer au plan Serverless payant avec jusqu'à 1 000 connexions, ou à un cluster dédié. Comparez les options dans la présentation du broker MQTT managé.

Démarrer avec ConnectMQ

Prototypez vos automatisations sur le serveur MQTT public gratuit, puis passez à un broker privé lorsque les vrais équipements entrent en service. Inscrivez-vous sur app.connectmq.com avec le plan Serverless gratuit, sans carte bancaire, créez un broker et copiez le nom d'utilisateur, le mot de passe et le client ID générés dans Home Assistant, Node-RED ou vos équipements. Passez au port 8883 avec TLS et vos règles continuent de fonctionner sans modification.

Questions fréquentes

Faut-il Home Assistant pour faire de l'automatisation IoT ?

Non. Home Assistant est la couche logique la plus courante pour les maisons, mais Node-RED, openHAB ou un petit service Python ou Node.js connecté au même broker MQTT peuvent exécuter des règles identiques. Le broker et les topics restent les mêmes, quel que soit votre choix.

Le broker d'automatisation doit-il être local ou dans le cloud ?

Exécutez en local les règles critiques en temps et liées à la sécurité afin qu'elles fonctionnent pendant les coupures Internet. Utilisez un broker cloud pour l'accès à distance, les configurations multisites et la supervision, ou combinez les deux avec des règles locales et une visibilité dans le cloud.

ConnectMQ exécute-t-il mes règles d'automatisation ?

Non. ConnectMQ est le hub de messagerie et propose des règles d'alerte à seuil pour la supervision, mais la logique d'automatisation s'exécute dans des outils comme Home Assistant, Node-RED ou vos propres services, qui se connectent au broker en tant que clients MQTT.

Pourquoi mon équipement s'allume-t-il à chaque reconnexion ?

Vous avez probablement publié la commande avec le flag retain. Le broker stocke les retained messages et les livre à chaque nouvel abonné : retenez donc les topics d'état, mais jamais les topics de commande.

Peut-on tester l'automatisation IoT sans matériel ?

Oui. Simulez des capteurs avec mosquitto_pub sur broker.connectmq.com, en utilisant un client ID et un préfixe de topic uniques, et observez les commandes qui en résultent avec mosquitto_sub avant de connecter de vrais équipements.