Building an AI Smart Home That Understands Natural Language with n8n + MCP + ESP8266

With a single sentence, you can turn on all the lights in a room, and a simple complaint like "it's too dark" is enough for it to know which light to turn off — this isn't science fiction, but a real project a college student built using n8n, the MCP protocol, and a single ESP8266 board.

Project Overview: What Is the AI Agent "Bob"?

Developer Mohamad Faisal Putra showcased his smart home course project on YouTube — an AI voice assistant named Bob. Users speak to a web page, and Bob can read temperature, humidity, and distance data from the environment, as well as control 6 electrical devices (simulated by 6 LEDs representing an air conditioner, washing machine, refrigerator, etc.).

The core idea behind the entire system is: let a large language model call real hardware tools through the MCP protocol, rather than merely generating text responses. This means when you ask "what's the room temperature right now," Bob won't make up a number — it will actually read data from the DHT22 sensor before answering.

Breaking Down the Four-Layer Architecture

Layer 1: Voice Input and Frontend

Users speak through a browser page, the Web Speech API converts speech to text, and the text is sent to the n8n workflow via Webhook. The Agent's text responses are ultimately read aloud by the browser, forming a complete voice interaction loop.

The Web Speech API is a JavaScript interface natively provided by browsers, in which SpeechRecognition handles transcribing audio captured from the microphone into text, and SpeechSynthesis handles reading text aloud. Developers can implement basic voice interaction without introducing third-party voice services. It's worth noting that the recognition quality of the Web Speech API depends on the browser implementation — mainstream browsers like Chrome typically call cloud-based voice services behind the scenes, so it's not fully offline; at the same time, its robustness for non-English languages and noisy environments is still limited. In the Bob project, the browser plays the role of "ears" and "mouth," while the Gemini model connected on the backend is what truly determines the quality of semantic understanding. This division of labor — light on the frontend, heavy on the backend — is also a common structure for many web-based AI applications.

Layer 2: The AI Agent in n8n

The n8n workflow is the brain of the entire system. The core node is an AI Agent connected to the Gemini model, equipped with conversation memory and tool-calling capabilities.

There's a notable design choice here: the developer integrated Wikipedia as a general knowledge source. The reason is that this is the easiest way to handle common-sense questions — no additional model training is needed, and when the Agent encounters encyclopedic questions, it simply queries Wikipedia, avoiding "hallucinated" answers while staying lightweight.

n8n is an open-source low-code workflow automation platform where users can drag and drop nodes to chain together triggers (such as Webhooks or timers), data processing, API calls, and conditional branches into an automated flow — much like a visual scripting language. Its value lies in turning "orchestration" from writing code into connecting wires, while still retaining the ability to embed custom JavaScript within nodes or call arbitrary HTTP endpoints. In this article, the n8n workflow serves as the system bus: the Webhook receives text from the frontend, the AI Agent node handles interaction with the Gemini model and decides whether to call tools, and the MCP Client node connects downward to the hardware. Compared to writing scheduling logic from scratch in Python, n8n lets developers focus their energy on prompt design and tool definitions — which is one reason this project could be completed independently by a single student.

Layer 3: The MCP Protocol Connecting Software and Hardware

MCP (Model Context Protocol) plays a key role here. The MCP Client node in n8n connects to two MCP Servers, exposing two tools externally:

• Read sensors: Retrieve real-time data from the DHT22 and ultrasonic sensors
• Control devices: Turn specified appliances on/off

The Agent autonomously decides whether to call tools based on user intent. This "tool calling" mechanism grounds the AI's responses in real data rather than guesswork.

MCP (Model Context Protocol) is a standard open-sourced by Anthropic in late 2024 to standardize how large language models communicate with external tools and data sources. Before MCP emerged, integrating a new tool often required writing a custom set of interface code for that model — a "point-to-point" private integration between tool and model with poor reusability. MCP's approach is to abstract the tool provider as an MCP Server and the tool consumer as an MCP Client, with both sides describing the tool's capabilities (name, parameters, return format) through a unified protocol. This way, any MCP-compatible model or Agent framework can plug and play with the same Server without caring whether the underlying transport is HTTP, serial, or a local process. In this project, sensor reading and device control are encapsulated into two tools, exposed by independent MCP Servers to the MCP Client node in n8n. The Agent merely needs to call them as declared by the protocol, without knowing the specific implementation details of the ESP8266. This is precisely the key to making "tool calling" standardized and portable.

Layer 4: The ESP8266 Hardware Side

The hardware portion is led by an ESP8266 board, connected to 2 ultrasonic sensors, 1 DHT22 temperature and humidity sensor, and 6 LEDs. The ESP8266 communicates with n8n over Wi-Fi: it reports sensor data every 3 seconds and checks for device state changes every 1 second. When the Agent modifies device state through an MCP tool, the ESP8266 reads the command on its next poll and lights up the corresponding LED.

ESP8266 is a low-cost Wi-Fi microcontroller chip from Espressif Systems, with a complete built-in TCP/IP protocol stack — a single chip can connect to the network, and common modules (such as NodeMCU and ESP-01) cost only around ten yuan RMB. It's typically used as the main controller for IoT devices, connecting various sensors and actuators through GPIO pins and communicating with cloud or local servers over Wi-Fi. The DHT22 used here is a commonly used digital temperature and humidity sensor with measurement accuracy of about ±0.5°C and ±2% relative humidity; ultrasonic sensors (such as the HC-SR04) measure distance by calculating the time difference between transmitting and receiving sound waves, often used for obstacle avoidance or liquid level detection. This combination of "cheap MCU + common sensors" is the standard configuration for entry-level AIoT projects — cost-controlled and with a mature ecosystem, which is also an important reason why the overall cost of this solution is extremely low.

Highlights from the Live Demonstration

During the demonstration, several interaction scenarios are worth noting:

Direct commands: "Bob, turn on all the devices at home" — the Agent calls the control tool and all 6 devices turn on.

Indirect reasoning: "The room is too cold, turn off the air conditioner" — the Agent understands that "cold" corresponds to "air conditioner/cooling device," without the user explicitly naming the device.

Vague requests: "It's too glaring, turn off some lights" — the Agent decides on its own and turns off some of the lighting devices.

These interactions showcase the unique value of LLMs in smart home scenarios: users don't need to memorize every device name or issue commands in fixed sentence patterns — the Agent will understand intent by combining context and common sense.

What This Approach Means

Traditional smart home control relies on preset rules: if the temperature is above 28°C, turn on the air conditioner. This approach is rigid and requires enumerating all conditions. The AI Agent + MCP approach, in essence, replaces rule matching with semantic understanding.

n8n's low-code workflow dramatically lowers the barrier to entry, and the MCP protocol provides a standardized tool-calling interface. Combined with cheap hardware like the ESP8266, these form a prototype with extremely low cost but complete capabilities. Of course, currently using LEDs to simulate real appliances still leaves a gap before mass production — after connecting relay modules, real circuits can be controlled.

For developers wanting to get started with AIoT, the reference value of this project lies in: it proves that the technical path of "large model + tool calling + microcontroller" works, and the implementation cost is much lower than one might imagine.

One-line Summary

A college student built an AI smart home assistant Bob that understands vague commands using n8n, MCP, and ESP8266.

Paragraph Summary

This article introduces the AI voice assistant Bob, built by developer Mohamad Faisal Putra using n8n, the MCP protocol, and an ESP8266. The system is divided into four layers: the browser handles voice input/output through the Web Speech API; the Gemini Agent in the n8n workflow handles conversation and tool decisions, integrating Wikipedia to avoid hallucinations in general Q&A; the MCP protocol encapsulates sensor reading and device control as standardized tools for the Agent to call; and the ESP8266 connects the DHT22, ultrasonic sensors, and 6 LEDs, communicating with n8n via polling. In the demo, Bob can execute direct commands and also understand vague expressions like "too cold" or "too glaring," inferring the target device. This approach replaces traditional preset rules with semantic understanding, at extremely low cost, validating the feasibility of the "large model + tool calling + microcontroller" AIoT path.