n8n avec Home Assistant et ioBroker : automatiser la technique du bâtiment en exploitation

n8n peut être connecté à Home Assistant et ioBroker, mais pas via un déclencheur intégré unique pour les changements d'état. Le nœud natif Home Assistant dans n8n ne propose actuellement aucun déclencheur réagissant à un changement d'état, c'est pourquoi la direction push s'est imposée en pratique : Home Assistant déclenche un workflow n8n via une automatisation et un appel webhook, et n8n écrit en retour si nécessaire via l'intégration REST Command ou un appel API direct. Pour ioBroker, la connexion fonctionne via l'adaptateur REST API officiel avec authentification Basic ou Bearer token dans les deux sens. Pour le contrôle d'accès, la régulation du chauffage ou la transmission d'alarmes dans un bâtiment d'entreprise, ce modèle push/pull suffit généralement. À jour : août 2026.

Comment Home Assistant déclenche-t-il un workflow n8n via webhook ?

Home Assistant configure automatiquement le point de terminaison webhook dès que vous créez une automatisation avec le type de déclencheur « Webhook » et lui attribuez un ID de webhook. L'appel se fait à l'adresse /api/webhook/<webhook_id>, la documentation recommandant explicitement les requêtes PUT ; les requêtes GET et HEAD ne sont autorisées que si vous les activez explicitement via l'option allowed_methods. Par défaut, l'option local_only limite l'accès au réseau local ou au cloud Nabu Casa, ce que vous devriez généralement laisser inchangé pour une automatisation purement interne. Selon le type de contenu, les données envoyées dans l'automatisation sont disponibles soit sous forme de trigger.data (données de formulaire), soit de trigger.json (JSON, lorsque le content-type application/json est défini). Côté n8n, un nœud webhook classique avec la méthode HTTP appropriée capte cette requête, y compris la distinction habituelle entre URL de test et de production. Vous trouverez les détails sur la configuration du déclencheur dans la documentation Home Assistant sur les déclencheurs d'automatisation.

Pourquoi le nœud natif Home Assistant dans n8n ne suffit-il pas à lui seul ?

Le nœud natif ne couvre aucun déclencheur pour les changements d'état, ce qui est décrit à plusieurs reprises dans la communauté n8n comme une lacune centrale lors du passage depuis Node-RED. Les utilisateurs y signalent l'absence de sélection d'entité par menu déroulant, ce qui oblige à transférer manuellement les ID d'entité entre les deux systèmes, et citent l'interrogation par intervalles de l'API REST comme seule solution de contournement, peu adaptée en pratique aux événements critiques du bâtiment. Un nœud WebSocket générique a été évoqué, mais n'a pas été mis en œuvre comme solution intégrée. Pour l'exploitation, cela signifie : misez sur la direction push via webhooks plutôt que sur le polling, et appelez les services Home Assistant appropriés pour commander les appareils plutôt que de définir directement les états, ce dernier ne parvenant pas de manière fiable à tous les appareils selon les retours de la communauté.

Comment n8n reçoit-il les événements et comment écrit-il en retour ?

Le nœud webhook de n8n prend en charge les méthodes HTTP DELETE, GET, HEAD, PATCH, POST et PUT avec une charge utile maximale de 16 Mo, ce qui suffit pour les données de capteurs et d'événements issues de la technique du bâtiment. Pour le chemin retour, n8n appelle l'intégration rest_command de Home Assistant via un nœud HTTP Request, qui met à disposition les appels REST classiques comme actions appelables et rend configurables l'URL, la méthode HTTP, les en-têtes et la charge utile ; la réponse fournit le code de statut, le texte de retour et les en-têtes pour un traitement ultérieur. Pour l'authentification auprès de systèmes externes, la documentation n8n recommande d'utiliser les types d'identifiants prédéfinis lorsqu'ils sont disponibles, et sinon de recourir à des méthodes génériques comme l'authentification par en-tête ou OAuth2. Vous trouverez les détails sur les méthodes et les limites de charge utile dans la documentation n8n sur le nœud webhook.

Comment connecter ioBroker via l'API REST ?

L'adaptateur officiel ioBroker.rest-api propose une interface Swagger et prend en charge trois méthodes d'authentification : identifiants en paramètres de requête, authentification Basic via l'en-tête Authorization, ou un jeton bearer OAuth2 provenant d'un point de terminaison dédié. Les états peuvent être définis de manière classique via GET avec un paramètre value, ce que l'adaptateur prend en charge pour des raisons de compatibilité avec l'ancienne Simple API, mais qui est marqué comme méthode obsolète (legacy) dans la documentation actuelle. Pour les accès en écriture structurés, POST et PUT sont disponibles, POST créant une ressource indépendamment des doublons et PUT vérifiant au préalable son existence. Dans n8n, vous représentez cela via un nœud HTTP Request qui lit les états ou les écrit via setState avec les champs val et ack. Les détails se trouvent dans le README de l'adaptateur ioBroker.rest-api.

Pour quels scénarios en exploitation la combinaison est-elle intéressante ?

Pour le contrôle d'accès, un modèle adapté consiste à faire déclencher une automatisation webhook par un capteur de porte ou un lecteur de carte via Home Assistant, n8n consignant l'événement et, si nécessaire, en informant l'administration. Pour la régulation du chauffage, le chemin inverse convient : un workflow n8n programmé appelle l'intégration rest_command ou l'adaptateur ioBroker pour définir des valeurs de consigne pour des zones individuelles. Pour la transmission d'alarmes, une combinaison des deux est recommandée, Home Assistant signalant à n8n les événements liés à la sécurité via webhook, n8n prenant en charge l'escalade par e-mail, Microsoft Teams ou un système de tickets. Il est important, dans les trois cas, que les actions liées à la sécurité comme le déverrouillage de portes ne soient pas déclenchées directement via webhook, comme le souligne également explicitement la documentation Home Assistant. Si vous souhaitez ancrer durablement une telle automatisation dans votre exploitation et la maintenir, NordFlux vous accompagne dans la mise en place de workflows n8n.

Questions fréquentes sur n8n avec Home Assistant et ioBroker

n8n peut-il réagir directement à un changement d'état dans Home Assistant ?

Non, le nœud natif Home Assistant dans n8n n'offre actuellement aucun déclencheur intégré pour cela. En pratique, la connexion fonctionne donc dans le sens inverse : Home Assistant signale activement les événements à n8n via webhook, plutôt que n8n n'interroge en permanence l'état.

Quelle méthode HTTP le webhook Home Assistant doit-il utiliser ?

La documentation Home Assistant recommande explicitement les requêtes PUT pour les déclencheurs webhook. Les requêtes GET et HEAD ne fonctionnent que si vous les activez en plus via l'option allowed_methods.

L'API REST d'ioBroker est-elle suffisamment sécurisée pour un usage en production ?

Elle l'est, à condition d'activer l'authentification Basic ou un jeton bearer OAuth2, plutôt que de transmettre les identifiants en clair comme paramètres de requête. Pour l'exploitation sur le réseau de l'entreprise, vous devriez également faire fonctionner l'adaptateur derrière un reverse proxy avec HTTPS.

Ai-je besoin d'un workflow n8n distinct pour chaque appareil ?

Non, il est courant d'utiliser un workflow webhook central qui redirige les événements entrants vers la logique de traitement appropriée via un nœud Switch ou IF, en fonction du contenu de la charge utile. Cela permet de garder la maintenance simple, même lorsque plusieurs dizaines de capteurs et d'actionneurs sont connectés dans le bâtiment.