Bonjour à tous,
J’ai installé l’extension n8n sur Home Assistant et l’accès initial a fonctionné parfaitement. Cependant, lors de la création d’un flux simple utilisant le nœud Chat Trigger connecté à un AI Agent (avec le Google Gemini Chat Model), je rencontre l’erreur suivante dans l’interface de chat après l’envoi d’un message : « Error: Failed to receive response ».
J’ai déjà effectué quelques tests d’isolement pour essayer de déboguer :
-
Les identifiants de l’API Gemini sont validés et connectés.
-
Si je change le déclencheur pour le manuel (When clicking ‘Execute workflow’) et que je passe l’invite directement dans le nœud, le flux s’exécute avec succès et le modèle traite la réponse.
-
Le problème se produit uniquement quand l’entrée provient du Chat Trigger. L’exécution semble s’arrêter/tomber en panne au niveau du déclencheur. Le nœud agent ne signale pas d’erreur (ne devient pas rouge) et aucun journal d’erreur n’est généré dans la console.
J’ai déjà essayé de supprimer le nœud de mémoire pour éviter un débordement de RAM dans le conteneur, mais le comportement de timeout dans la fenêtre de chat persiste.
Hé @Ricardo_Mendonca Bienvenue !
As-tu essayé de définir manuellement la sortie du déclencheur de chat dans l’agent IA ? Comme ceci :
Je pense que ça devrait fonctionner, fais-moi savoir comment ça se passe.
Bonjour @Ricardo_Mendonca
Le problème ne vient pas de votre IA ou de votre flux de travail qui seraient cassés — c’est l’« intermédiaire » (la couche réseau de Home Assistant) qui devient impatient. Quand vous envoyez un message, l’IA met quelques secondes à réfléchir et générer une réponse. Pendant ce silence, Home Assistant pense que la connexion s’est bloquée et la coupe pour économiser les ressources, ce qui provoque l’erreur « Failed to receive response ».
Pour corriger cela, vous devez changer la façon dont n8n renvoie la réponse. Au lieu de laisser le Chat Trigger gérer la réponse automatiquement, changez les paramètres du déclencheur pour « Use response nodes » et ajoutez un nœud « Respond to Chat » à la toute fin de votre flux de travail. Cela change la méthode de communication et empêche généralement Home Assistant de terminer la connexion prématurément.
Si ça ne fonctionne pas, le problème vient probablement d’une erreur de configuration concernant votre adresse web. n8n essaie peut-être d’envoyer la réponse à une adresse interne que le navigateur ne peut pas atteindre. Vous pouvez corriger cela en vous assurant que l’« URL du webhook » dans les paramètres de votre add-on est définie sur votre adresse Home Assistant externe complète.
Salut @Ricardo_Mendonca, bienvenue dans la communauté n8n !
Je vérifierais d’abord si l’exécution est créée quand le message est envoyé et si l’Agent produit une sortie normalement. Si l’exécution se termine correctement, ouvre la console du navigateur (F12) et vérifie les erreurs possibles de websocket/SSE. Il serait aussi utile de connaître la version exacte de l’Add-on n8n et de Home Assistant, car cela aiderait à déterminer si le problème se situe au niveau de l’interface utilisateur du chat ou de l’intégration via Ingress.
Hé, je suis tombé sur exactement le même problème (auto-hébergé via Docker Compose, pas le module complémentaire HA, mais mêmes symptômes : le déclenchement manuel fonctionne bien, le déclenchement par chat se fige simplement avec « Impossible de recevoir une réponse », aucune exécution enregistrée, le nœud agent ne devient jamais rouge).
Dans mon cas, le problème venait de la façon dont j’avais configuré N8N_HOST dans mon docker-compose.yml. Je l’avais défini sur 0.0.0.0 (nécessaire pour que le conteneur écoute sur toutes les interfaces), mais n8n utilisait apparemment cette même valeur pour construire l’URL qu’il renvoie au navigateur pour le point de terminaison du chat/webhook. Donc l’interface frontale tentait littéralement de récupérer http://0.0.0.0:5678/``…, ce que le navigateur refuse correctement (ERR_ADDRESS_INVALID). Vous pouvez réellement voir cela dans DevTools > onglet Réseau si vous filtrez les requêtes échouées lors de l’envoi d’un message de chat.
La solution était d’ajouter deux variables d’environnement explicites :
N8N_EDITOR_BASE_URL=http://localhost:5678
WEBHOOK_URL=http://localhost:5678/
(remplacez localhost:5678 par votre adresse/port réellement accessible)
Après le redémarrage de la pile, le déclenchement du chat a fonctionné immédiatement.
Cela vaudrait peut-être la peine de vérifier la configuration de votre module complémentaire HA pour quelque chose de similaire — si elle se lie à 0.0.0.0 ou à un nom d’hôte interne du conteneur sans une URL publique séparée définie, vous rencontreriez le même problème. Cela vaudrait la peine de vérifier d’abord l’onglet Réseau de votre navigateur pour confirmer que c’est réellement la même cause racine avant de modifier quoi que ce soit.
Merci, personne bienveillante ! Ça a marché parfaitement, j’ai passé une bonne demi-heure à essayer tout ce que je pouvais imaginer mais c’est la seule chose qui a fonctionné !
Ça a très bien fonctionné en ajoutant N8N_EDITOR_BASE_URL
Je te remercie énormément de ton aide.
