I Gave an AI Access to My Smart Home — Here’s Exactly How Far I Let It Go

ByRyan

;toc

For about a week, my front yard camera alerts quietly stopped working. Someone would pull into the driveway and my phone said nothing.

I didn’t catch it. My house did.

The AI agent I built — I call him Alfred — reads my Home Assistant logs on a schedule. He found that the automation behind those alerts was throwing the same error every single time a car pulled up. It was trying to send a notification to a phone that, as far as Home Assistant was concerned, no longer existed. So every alert failed. Silently.

Then Alfred did the part I actually care about. He didn’t just report the problem — he showed me the exact one-line fix and asked whether I wanted to apply it. I said yes, he made the change, and the alerts came back. Later that day when Amazon dropped off a package, my phone lit up again.

I never opened a config file. I never touched a line of YAML.

But that only works because I gave it something first: real access to my house. The ability to read what’s wrong, and — if I’m not careful — change things while I’m not looking.

This post is the written companion to the video. It covers what an MCP server actually is, the honest risks, the full setup for both Claude and ChatGPT, the security scoping I use, and the exact prompts behind Alfred’s self-healing loop.

First, let’s be precise about what “self-healing” means

I said my Home Assistant healed itself. What actually happened was narrower than that, and the distinction matters.

An AI detected a problem, diagnosed it, and proposed a fix. Then it waited for me to approve the change.

That approval step isn’t something I forgot to remove. It’s the line I choose to keep. By the end of this post you’ll understand why — and hopefully you’ll be able to decide where your own line goes.

What an MCP server actually is

Normally, an AI like Claude or ChatGPT can do exactly one thing: talk. You type, it types back. It can describe how to fix a Home Assistant automation, but it can’t reach into your house and do it. It’s looking through glass.

MCP — Model Context Protocol — is what breaks the glass. It’s an open standard released by Anthropic in late 2024, and it’s been adopted just about everywhere since. It’s the thing that lets an AI connect to an outside system and both read from it and take action on it.

People call it “USB-C for AI,” and that’s a fair analogy. One standard plug between the model and all your stuff.

Mechanically, an MCP server exposes a set of tools and describes to the AI how and when to use them. The server is the adapter that sits on the thing you want the AI to reach. There are MCP servers for n8n, for After Effects, for basically anything you can think of.

Put one on Home Assistant, and the AI isn’t talking about your house anymore. It’s in it.

The two Home Assistant MCP servers (this tripped me up)

Search “Home Assistant MCP” and you’ll find two very different things. Picking the wrong one is why people get confused about what’s possible.

1. The official one — built into Home Assistant

It’s called Model Context Protocol Server, and it ships with Home Assistant. It’s solid, safe, and limited on purpose. It can only see and control entities you’ve deliberately exposed to it — it rides on the same exposure system as Assist, Home Assistant’s voice feature.

It can flip on a light you’ve allowed. It cannot read your logs or rewrite an automation.

https://www.home-assistant.io/integrations/mcp_server

2. The community one — HA-MCP

The one I use is a community project called HA-MCP (homeassistant-ai/ha-mcp). It goes much further: reading logs, editing automations, managing add-ons, driving HACS. It exposes 80+ tools.

That extra reach is the only reason Alfred could catch that broken automation at all. The official server couldn’t have done it.

And that’s the entire tradeoff of this video. More capability means more keys you hand over. The safe, limited one can’t fix your house. The powerful one can — which means it can also break it.

https://github.com/homeassistant-ai/ha-mcp

The four risks, stated honestly

Risk 1: It acts. It doesn’t just answer.

The moment you connect a write-capable MCP server, the AI can change things — toggle devices, edit configuration. A wrong move isn’t a wrong answer anymore. It’s a damaging action in your actual home.

Risk 2: Prompt injection

This is the one most people miss. Your AI reads text that comes from your house: device names, notification messages, log entries. If any of that text contains instructions — say, a device somebody named something sneaky — a naive agent can be tricked into following them.

The AI can’t reliably tell your data apart from a command hidden inside your data. That’s not science fiction. It’s the central unsolved security problem of every AI tool right now.

Risk 3: Attack surface

Every entity you expose and every tool you grant is one more thing that can go wrong if the AI gets confused or manipulated. Eighty tools is a lot of surface.

The rule I follow: expose the least you need. My door locks, garage doors, and alarm are walled off. The AI that fixes a broken notification has no ability to unlock my front door. That’s deliberate.

Risk 4: You’re opening a door into your network

For a cloud AI to reach Home Assistant, your instance has to be reachable from the outside world. Do that carelessly and you’ve published your entire home to the internet.

That’s why I route this through Nabu Casa rather than poking a hole in my firewall. If you don’t have Nabu Casa, a Cloudflare Tunnel is a reasonable alternative — I don’t cover it here, but the concept is the same: outbound, authenticated, no open ports.

The two rules everything below follows

  1. Give it as few keys as possible.
  2. Make it ask before it acts.

Part 1: Installing HA-MCP

How to Set up Home Assistant Community Store: https://youtu.be/FDqZ1DxOigE

Prerequisites: HACS installed, and Home Assistant 2026.6.0 or newer for the in-process server.

  1. In Home Assistant, open HACS → three-dot menu (top right) → Custom repositories.
  2. Paste in https://github.com/homeassistant-ai/ha-mcp-integration and set Type to Integration. Click Add.
  3. Search HACS for MCP, find HA-MCP Custom Component at the bottom of the list, and click Download.
  4. Restart Home Assistant. New integrations always need this.
  5. Go to Settings → Devices & Services → Integrations → Add Integration and search for HA-MCP.
  6. You’ll get two options. Choose HA-MCP Server — that’s the full in-process server.

That last part is worth calling out, because it used to be a lot worse. The component now runs the entire MCP server inside Home Assistant and handles external exposure through Home Assistant webhooks. Previously you had to install an add-on (a Docker container), configure it separately, then add another component just to make it work through Nabu Casa. Now it’s one install.

  1. Click Submit, name the entry (I put mine in my Systems area), and Finish.

Part 2: Getting your connect URL

This next step isn’t obvious, so don’t skip it.

  1. Go back to your integrations list and find HA-MCP Custom Component.
  2. Click the entry, then the gear icon → Configure.
  3. At the top you’ll see several connect URLs. The one with your Nabu Casa domain in it is the one you want — that’s the externally accessible one.
  4. Below that are authentication options. I use the secret webhook URL, which uses the random string in the URL as the credential. You can also use Sign in with Home Assistant (OAuth). There’s a legacy OAuth option too — skip it.
  5. Right-click the URL and Copy link address. You’ll need it in a minute. Then Submit.

⚠️ Security landmine #1

That webhook string is randomly generated, but it is a credential, not an obscurity trick. Anyone who gets hold of that URL can reach into and modify your Home Assistant instance. Treat it exactly like a password: don’t paste it in Discord, don’t leave it on screen during a stream, don’t email it to yourself.

On Nabu Casa: it’s Home Assistant’s official remote access service, routed through their servers. One of the features you get is webhooks — the ability to send a command through their infrastructure that reaches into your instance. HA-MCP piggybacks on that, which is how you get external access without opening a single port in your firewall.

https://nabucasa.com

Part 3: Connecting Claude

Claude is my daily driver. I’m on the Max plan, but you don’t need that for this — any paid tier that supports custom connectors works.

  1. Open the Claude desktop app → Settings → Connectors.
  2. Click Add → Add custom connector.
  3. Name it Home Assistant, paste your connect URL into the MCP server URL field, and click Add.
  4. Claude will prompt you to connect and authorize. Since you pre-authorized with the webhook URL, there’s nothing else to enter. Click Open Claude.

You’ll now see the connector listed with its full tool set, split into read-only tools and write/delete tools.

How to scope it

This screen is the most important one in the whole setup.

  • Start with everything set to “Needs approval.” This is the safe default and I’d leave it there for a long time.
  • Want read-only? Set the entire write/delete group to Blocked. Nothing in that group can be used until you change it back — no exceptions, no “the AI thought it was important.”
  • “Always allow” exists. I don’t recommend it. It means any time the AI decides it needs Home Assistant, it can use whatever tool it wants.
  • You have per-tool control. Read down the list and block individual tools you’re not comfortable with.

If you’re just getting started: block the write/delete tools entirely. You still get full read access, so the AI can analyze your system and tell you exactly what’s wrong. You just make the changes yourself. That’s a genuinely useful setup and it carries almost none of the risk.

⚠️ Security landmine #2

Claude shows that connector URL in plain text on this screen. If you’re screen sharing or recording, blur it.

One nice detail: the connector shows as a web connection, which means it isn’t tied to the desktop app. The same connector works in the Claude mobile app and on the web.

Quick test: ask it something read-only, like “How many Z-Wave devices do I have in my smart home?” The first time it reaches for a tool it’ll ask permission — you can pick Allow once or Always allow. Mine came back with 28 Z-Wave devices, the controller model, and a full device list. Accurate, and fast.

Part 4: Connecting ChatGPT

A few things to know up front:

  • You need Plus or Pro — that’s what unlocks the developer tools you need to add a connector.
  • As of end of July 2026, this lives in Developer Mode. OpenAI moves this stuff around constantly. If the path below doesn’t match what you see, ask ChatGPT where connectors live now.
  • Do this on the web version, not desktop. It’s more stable.
  1. Click your username → Settings → Plugins → scroll to the bottom → Developer Mode. Activate it.
  2. Back to Settings → Plugins → scroll down → Browse Plugins.
  3. Top right, click the + button.
  4. Name it Home Assistant, paste your connect URL under Connection, set Authentication to None, check the “I understand” box, and click Create.
  5. Click Sign in with Home Assistant.

Quick test: “How many Zigbee devices do I have in Home Assistant?” Mine returned 68 active devices out of 69 associated — meaning one was dead, which was correct.

Part 5: Scoping what the AI can never see

Blocking tools in Claude or ChatGPT is one layer. But that’s client-side — it protects you in that client. The stronger control is at the server, in HA-MCP itself, because it applies to every client that connects.

Once HA-MCP is running, an HA-MCP panel appears in your Home Assistant sidebar. Click it.

There are a lot of options in here. The big ones:

  • Read-only mode — disables every write tool globally. Great way to start.
  • Disable individual tools — no LLM can access them, regardless of client settings.
  • Entity visibility — this is where the real scoping happens.

Entity visibility

Check the entity visibility box and you get a few filtering options:

Enforce mode is the one you want to understand. By default, filtered entities are hidden from search — the AI won’t find them when it looks. But if it already knows the entity ID (from earlier in the conversation, or from memory), it can still reach it. Check enforce mode and those entities become hidden and unreachable across every tool.

From there you can filter by:

  • Area
  • Label ← this is the one to use
  • Individual entity IDs — precise, but painful. My Tesla alone has something like 70 entities, and you’d have to add each one.
  • Inverted / allow-list mode — flip it so the AI can only see specific areas, labels, or entities. The most locked-down option.
  • Follow Assist exposure — match visibility to whatever you’ve already exposed to Assist. Handy if you’ve already done that work.

The label workflow I use

Labels are the practical answer, because you can apply one to a whole device and cover all its entities at once.

  1. Go to Settings → Devices & Services → Entities and filter for lock.
  2. Click each lock → gear icon → Add Label → create a new label called no MCP.
  3. Important: to block every entity belonging to a device, apply the label at the device level — open Device info → Settings → Add label → no MCP.
  4. Repeat for garage doors, alarm, and anything else that should be off-limits.
  5. Back in the HA-MCP panel → Entity visibility → under Labels, add no MCP → Save.

Restarting the integration (required)

Changes don’t take effect until you reload the integration:

Settings → Devices & Services → HA-MCP → three-dot menu → Disable → wait ~10 seconds → Enable.

Verify it worked. I had ChatGPT locate my front door lock before the restart, so it had the entity ID cached in the conversation. After the restart, I asked it for details on that same lock — and it got blocked by the integration. That’s the behavior you want: it doesn’t matter what the AI already knows, the server refuses.

Part 6: Actually using it — building an automation with Claude

Here’s a real example: I asked Claude to build a Z-Wave offline notification automation from scratch.

Hey, can you create an automation that sends a notification to my
phone — the Samsung S24 Ultra, using the Home Assistant app — anytime
one of my Z-Wave devices goes offline.

What happened next is worth describing, because it sets expectations correctly.

This is not a one-shot process. It’s a back-and-forth. Claude asked permission for each new tool as it needed it — the Home Assistant best-practices guide, the search tool, then the create/update automation tool. You sit there and approve each one, deciding as you go whether you’re comfortable with that specific access. That friction is the feature.

It built an automation called Notification Z-Wave device offline, and the trigger covered every single Z-Wave device in my house with its associated status entity. Looking at the list, you can see devices in different states — some asleep, some awake with a heartbeat, a couple showing dead. (One of those was my outdoor keypad, which had actually just run out of batteries.)

Then it did something I want to highlight: it flagged its own mistake. The notify service resolution got confusing, so instead of silently guessing, it created the automation, told me it couldn’t confirm the correct entity ID, said it had searched and thought it found the right one, and asked what I wanted to do — apply its suggested fix, or leave it and fix it myself.

I picked the fix. It called the update tool again, and validation came back clean. Refreshed the page and the action was there with the right target, message, and title. It even wrote a sensible description for the automation, which is a nice touch six months later when you’re wondering what the thing does.

Part 7: The self-healing loop (Alfred)

Everything above is reactive — you ask, it answers. The loop from the top of the video is different: nobody asks. It runs on a schedule and comes to me.

What Alfred actually is

Alfred is a sub-agent running in Hermes Agent, an agent framework I run on a server in my basement. It uses an LLM underneath — in my case ChatGPT, signed in with my own account and using my token allotment — and layers persistent context and memory on top, so it stays useful across sessions instead of starting fresh every time.

https://hermes-agent.nousresearch.com

Two things to be clear about:

  • The agent’s processes and knowledge run locally on my basement server.
  • The thinking still happens in OpenAI’s cloud.

I asked my main Hermes agent to generate a sub-agent named Alfred whose job is Home Assistant.

Connecting Alfred to HA-MCP

Example Prompt

Hey Alfred, I want to give you access to my Home Assistant instance
via the HA-MCP server integration (https://github.com/homeassistant-ai/ha-mcp). Here is the URL for that server: [URL]
Please get connected and let me know what information you need.

Because the agent runs on my own network, I gave it the local connect URL rather than the Nabu Casa one — no reason to round-trip through the internet to reach a box in my basement.

⚠️ Security landmine #3

Pasting the connect URL into a chat with your agent means that URL goes to the LLM provider. The correct way is to have the agent scaffold the connection, then drop the URL into a config file yourself so it never enters the conversation. I took the shortcut for the demo and rotated the keys afterward. If you’re setting this up for real, do it properly the first time.

After connecting, Alfred reported back: connection verified, tool list updated, no changes made to Home Assistant. I ran reload MCP to refresh its server list, re-approved the tools, and tested with “turn off the neon light in my office.” It worked.

It’s slower than saying it to a Google speaker — but it has vastly more at its disposal. Anything you can do in Home Assistant, you can do through text chat.

The cron job

A cron job is just a task that runs on a schedule. The nice part about doing this through an agent is you don’t write cron syntax — you say “do this every day at 9 AM” or “every weekday” in plain English and it builds the scheduled job for you.

📋 PROMPT EXAMPLE — “Daily self-healing cron job”

Mine runs daily at 9 AM. Here’s what it does:

HOME ASSISTANT — AUTOMATION SELF-HEALING LOOP

You are [AGENT], [USER's] home-admin operator. This is a scheduled Home Assistant automation-monitoring job. Run once per tick, daily at 9am. Do NOT create or modify cron jobs from this job.

A deterministic pre-run script fetches current Home Assistant ERROR logs through the configured HA-MCP endpoint before this prompt runs. Treat the injected script output as the ground truth for initial log retrieval.

ROLE
Monitor Home Assistant automations for failures, diagnose them, and — only with [USER]'s explicit approval — propose/apply fixes. This scheduled tick normally SCANS and PROPOSES only. No automation/device/service changes without explicit per-change approval from [USER].

CRITICAL FIRST-STEP RULES
- If the injected script output has `prefetch_success: true`, HA-MCP access worked for log retrieval. Do NOT report that Home Assistant MCP tools are missing.
- If `prefetch_success: false`, report the exact script error as a real HA-MCP connectivity/config blocker and make no changes.
- Home Assistant native MCP tools are expected as `mcp_home_assistant_*`, including `mcp_home_assistant_ha_config_get_automation`, `mcp_home_assistant_ha_get_automation_traces`, `mcp_home_assistant_ha_list_services`, `mcp_home_assistant_ha_search`, `mcp_home_assistant_ha_get_state`, `mcp_home_assistant_ha_get_system_health`, `mcp_home_assistant_ha_get_skill_guide`, and — only after explicit approval — `mcp_home_assistant_ha_config_set_automation`.
- Do NOT claim a tool is missing unless an actual tool call returns a missing/unavailable/not-connected error. If a tool call fails, quote the exact tool and exact error.

SCAN
1. Use the injected script JSON. It contains `automation_error_entries`, pre-filtered to logger names beginning with `homeassistant.components.automation.`.
2. If `automation_error_entries` is empty, send a concise all-clear: log retrieval succeeded, number of ERROR entries checked, no relevant automation errors found, and no changes made.
3. If entries exist, classify each:
   - IN SCOPE: a config edit would likely fix it, such as missing service/entity/device, typo, stale target.
   - OUT OF SCOPE: transient/runtime device/integration errors, Z-Wave command timeouts, template errors requiring design judgment, or anything intermittent. Notify but propose no change unless high-confidence after inspection.

HARD EXCLUSION — NEVER VIOLATE
Never propose/apply a change to automations whose actions control/reference: locks, garage doors, alarm/security, or Tesla-related entities/devices/areas. If such an automation is failing, notify only and stop; no diff, no write.

DIAGNOSE — NO GUESSING
For a high-confidence in-scope candidate, inspect the live system first using the native MCP tools. Fetch the full automation config and config_hash with `mcp_home_assistant_ha_config_get_automation`. Use `mcp_home_assistant_ha_list_services`, `mcp_home_assistant_ha_search`, `mcp_home_assistant_ha_get_state`, etc. as needed. Never fabricate replacement values.

PROPOSE, THEN STOP
If a single safe high-confidence fix is found, message [USER] with: automation name/id, root cause, exact before → after diff, impact, and ask for explicit approval. Include rollback snapshot/config_hash in the session context if available. Then STOP. Change nothing.

APPLY — ONLY ON EXPLICIT APPROVAL
If [USER] has explicitly approved a specific pending change in this continuable job session, apply only that change with
  1. Scan Home Assistant for automation failures — pull ERROR-level logs, filter for automation issues, ignore everything else.
  2. Classify by scope. Is this a one-off (a battery died) or has it been erroring repeatedly?
  3. Take the highest-confidence, highest-priority issue and do a deep dive on it.
  4. Send me a proposal over Telegram.
  5. Stop. Under this ruleset it has no ability to make any change at all.

The safety rules (this is the part that matters)

The task description is the easy half. The guardrails are where you actually decide how much of your house you’re handing over. Mine:

  • Explicitly prohibited from making changes on its own.
  • Must not modify anything without my explicit approval.
  • Hard exclusions: no locks. No garage or cover targets. No alarm or security automation changes. Nothing related to my Tesla.
  • No guessed values. If it doesn’t know, it says so.
  • One proposed change at a time.
  • Create a snapshot before any write.
  • Everything must match — same hash, no errors or drift — before it proceeds.

📋 PROMPT EXAMPLE FROM ABOVE — “Agent guardrails / custom instructions”

HARD EXCLUSION — NEVER VIOLATE
Never propose/apply a change to automations whose actions control/reference: locks, garage doors, alarm/security, or Tesla-related entities/devices/areas. If such an automation is failing, notify only and stop; no diff, no write.

What it caught

The last successful run is the one from the top of this post. It found that my front yard camera alert automation was targeting an old mobile app entity ID — notify.mobile_app_s24 pointing at a device that no longer existed. Same class of problem Claude hit earlier, and the same root cause: I renamed something and never went back to fix what depended on it.

The proposal was a single swap to the correct entity. I replied “go ahead and apply that change,” it made the fix in the background, reported exactly what it did, and the automation started working on its next trigger.

It also surfaces two or three secondary fixes most days alongside the main one. After a few weeks of that, a surprising amount of accumulated cruft gets cleaned up.

And you can point this at anything. Offline devices. Low batteries. Entities that haven’t reported in a week. Whatever pattern you can describe, you can schedule.

📋 PROMPT PLACEHOLDER — “Variant jobs” (optional)

COMING SOON

So — would I give an AI the keys to my smart home?

Yes. I already have. But only some of the keys, and with my hand on the brake.

Alfred can read my logs and diagnose a broken automation while I’m asleep. He cannot do anything about it until I say so. He can’t touch my locks, my garage, or anything connected to my car — not because I trust him not to, but because those entities don’t exist as far as he’s concerned.

Follow those two rules — fewest keys possible, and it asks before it acts — and an AI in your home is a genuinely useful tool instead of a liability. Ignore them and you’ve handed a confident stranger the run of the place.

And if you read all of this and decide the tradeoff isn’t worth it, that’s a completely valid outcome. There’s no wrong answer here, only an informed one.

The caveat I’m not going to gloss over

Everything above runs through a cloud AI. Alfred included.

Every log he reads and every fix he proposes takes a round trip through OpenAI’s servers. If you’re not comfortable with somebody else’s cloud reading your house — that’s a reasonable position, and the answer is to run the whole thing on a local model so nothing leaves your network.

The problem is that a local model capable enough to reliably diagnose automations needs a large context window and real hardware. We’re talking a serious GPU investment, not a spare Raspberry Pi. Today, I’m not willing to make that spend.

I’d like to do a full breakdown of what a self-hosted smart home AI actually takes — the hardware, the models, the real cost, and whether it beats just accepting the cloud tradeoff. Let me know in the comments on the video if that’s one you want.

Where to start (if you take one thing from this)

You don’t need any of the agent stuff to get value out of this today.

Connect it read-only. Block every write and delete tool. Then the next time something breaks, open the chat and ask your house: “Why isn’t this working?”

It’ll walk you through the diagnosis, and you stay in control of every change that gets made. Less convenient. Considerably more secure. That’s how I operated before I found out about MCP servers, and it’s still where I’d tell anybody to start.

📋 PROMPT EXAMPLE — “Read-only diagnostic starter”

Look at my ERROR-level logs from the last 24 hours. Find anything
related to automations, and for each one tell me what's failing and
why. Do not make any changes — diagnosis only.

Next: If you’re just getting started with Home Assistant, my beginner playlist is the right place to go from here.

Links

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *