Hello everyone,
I installed the n8n add-on for Home Assistant and the initial access worked perfectly. However, when setting up a simple workflow using the Chat Trigger node connected to an AI Agent (with the Google Gemini Chat Model), I encounter the following error in the chat interface after sending a message: “Error: Failed to receive response”.
I’ve already run some isolation tests to try to debug this:
-
The Gemini API credential is validated and connected.
-
If I change the trigger to manual (When clicking ‘Execute workflow’) and pass the prompt directly into the node, the workflow runs successfully and the model processes the response.
-
The problem happens only when the input comes from the Chat Trigger. The execution seems to pause/stall at the trigger. The agent node shows no failure (doesn’t turn red) and no error logs are generated in the console.
I’ve already tried removing the memory node to avoid RAM overflow in the container, but the timeout behavior in the chat window persists.
Hey @Ricardo_Mendonca Welcome!
Have you tried manually defining the chat trigger’s output into the AI agent? Like this:
I think this should work, let me know how this goes.
Hi @Ricardo_Mendonca
The problem isn’t that your AI or your workflow is broken—it’s that the “middleman” (the Home Assistant network layer) is getting impatient. When you send a message, the AI takes a few seconds to think and generate a response. During this silence, Home Assistant thinks the connection has stalled and cuts it off to save resources, which results in the “Failed to receive response” error.
To fix this, you need to change how n8n sends the answer back. Instead of letting the Chat Trigger handle the response automatically, change the trigger’s settings to “Use response nodes” and add a “Respond to Chat” node at the very end of your workflow. This changes the communication method and typically prevents Home Assistant from killing the connection prematurely.
If that doesn’t work, the issue is likely a configuration mistake regarding your web address. n8n might be trying to send the response to an internal address that the browser can’t reach. You can fix this by ensuring the “Webhook URL” in your add-on settings is set to your full, external Home Assistant address.
If your environment is set to "N8N_HOST=0.0.0.0" , you may need to replace it to localhost or your custom domain
Check to see if any of these apply
hi @Ricardo_Mendonca, welcome to the n8n community!
I’d first check if the execution is created when the message is sent and if the Agent produces output normally. If the execution completes successfully, open the browser console (F12) and check for any websocket/SSE errors. It would also be helpful to know the exact version of the n8n Add-on and Home Assistant, as that would help determine if the issue is in the chat UI layer or in the integration via Ingress.
Hey, I ran into the exact same issue (self-hosted via Docker Compose, not the HA add-on, but same symptoms: manual trigger works fine, chat trigger just stalls with “Failed to receive response”, no execution logged, agent node never turns red).
In my case the issue was how I had N8N_HOST configured in my docker-compose.yml. I had it set to 0.0.0.0 (needed so the container listens on all interfaces), but n8n was apparently also using that same value to build the URL it sends back to the browser for the chat/webhook endpoint. So the frontend was literally trying to fetch http://0.0.0.0:5678/``…, which the browser correctly refuses (ERR_ADDRESS_INVALID). You can actually see this in DevTools > Network tab if you filter for failed requests while sending a chat message.
Fix was adding two explicit env vars:
N8N_EDITOR_BASE_URL=http://localhost:5678
WEBHOOK_URL=http://localhost:5678/
(swap localhost:5678 for whatever your actual reachable address/port is)
After restarting the stack, the chat trigger worked immediately.
Might be worth checking your HA add-on’s config for something similar - if it’s binding to 0.0.0.0 or an internal container hostname without a separate public-facing URL set, you’d hit the same thing. Worth checking your browser’s Network tab first to confirm it’s actually the same root cause before changing anything.
Thank you, kind person! This worked perfectly, I spent a good half hour trying everything I could think of but this is the only thing that worked!
It worked great by adding N8N_EDITOR_BASE_URL
I’m incredibly grateful for your help.
