Should Home Assistant Let a Local AI Control Your House?

Bryan D. Lawrence — skeptical home-automation caretaker

The Coco

• Home Assistant can use a local Ollama model, but its control feature is explicitly experimental.
• Home Assistant limits the model to entities you expose, and recommends starting with fewer than 25.
• Ollama binds to 127.0.0.1:11434 by default, and its local API does not require authentication.
• Remote access should use a narrowly scoped LAN or Tailscale path, not public port forwarding.
• A local model should earn additional control gradually instead of receiving the keys to the house on its first day.

Local is a privacy boundary, not a permission model

Yes, this is a sensible experiment—as long as the model begins as a conversation partner rather than the household executive.

The current Home Assistant Ollama integration connects Home Assistant to an Ollama server and can optionally give the model access to the Assist API. Home Assistant calls that control feature experimental. The model can only access devices and entities you deliberately expose, and the documentation recommends exposing fewer than 25 entities while experimenting.

That is a useful boundary. It is not a safety case.

The word “local” does a lot of work in artificial-intelligence conversations. It tells you something about where processing happens. It does not tell you who can reach the service, what requests they can make, or whether the model understands the difference between “turn on the porch light” and “turn on every light in the house.”

Ollama says prompts and data are not seen by Ollama when running local models. Cloud-hosted models are different. If you want a stricter local-only configuration, Ollama documents the OLLAMANOCLOUD=1 setting, with the obvious tradeoff that cloud models and web search stop working.

That improves privacy. It does not create authorization.

Ollama’s friendly local API

Ollama binds to 127.0.0.1:11434 by default. Its documentation also states that no authentication is required when accessing the local API through http://localhost:11434.

That is perfectly reasonable when the only client is the same computer running Ollama. It becomes a design decision when Home Assistant lives somewhere else.

To connect from another machine, Ollama can be configured with the OLLAMA_HOST environment variable. The moment the service listens beyond loopback, the network path becomes part of the security model. “It’s only on my LAN” may be an acceptable decision in a small, controlled network. It should still be a conscious decision.

The API is also more than a text-generation button. Ollama documents endpoints for generating responses, pulling models, and deleting models. If an unauthenticated local API is made reachable by other machines, the result is an operational control surface: somebody may be able to consume compute, download large models, or remove models. That conclusion is an inference from the documented API and authentication behavior, not a claim that Ollama currently has a remote exploit.

The practical answer is to put access control somewhere. That may be a host firewall, a narrowly bound interface, a reverse proxy with authentication, or a combination of those. Ollama’s own documentation supports running behind a proxy and forwarding requests with required headers.

The entity list is the real leash

Home Assistant provides a more important control than the system prompt: the exposed-entity list.

The documentation says only models that support tools can control Home Assistant. It also warns that smaller models are more likely to make mistakes and may not reliably maintain a conversation when control is enabled.

That should change the rollout.

Home Assistant even documents using multiple Ollama configurations with the same model: one without control enabled for ordinary conversation, and another with control enabled. That is the arrangement I would use.

The first agent can answer questions or discuss the state of the house. The second can operate a small collection of deliberately selected devices. Start with lights, media players, or non-critical switches. Leave locks, garage doors, alarm systems, water valves, and whole-house climate control outside the experiment.

A prompt can say “always ask for confirmation.” That is useful guidance. It is not a mechanical safety interlock. If an action matters, keep a human in the loop through the surrounding workflow instead of expecting the model to honor a paragraph of instructions forever.

The network trap is usually one line

If Ollama and Home Assistant run on the same machine, leaving Ollama on loopback is the cleanest arrangement.

If they run on separate machines, expose only the interface Home Assistant actually needs. This is where Docker deployments frequently widen the boundary by accident. Docker’s documentation says published ports listen on all host interfaces by default unless a specific host IP is supplied.

Deployment path	What it means	Sensible baseline
Same machine	Ollama stays on loopback	Use 127.0.0.1:11434; publish no external port
Separate machines on a tailnet	Home Assistant reaches Ollama over a private network	Bind to the required Tailscale address, restrict the source host, and consider proxy authentication
Public internet	Anyone who can reach the endpoint can attempt requests	Do not expose the Ollama API this way

Tailscale’s access-control documentation supports rules that define which sources may reach which destinations and ports. Tailscale Serve is intended to share local services inside the tailnet. Tailscale Funnel, by contrast, exposes services to the public internet.

That difference matters. A private tailnet route and a public tunnel are not interchangeable because they happen to use the same vendor.

Home Assistant includes an API Key field for an Ollama server that requires authentication. If a reverse proxy sits in front of Ollama, that is where I would add authentication, TLS, rate limits, and request logging. Tailscale can narrow who reaches the service, but it does not eliminate the value of application-level controls.

A rollout that deserves trust

A reasonable rollout looks boring:

1. Start with an Ollama conversation agent that cannot control Home Assistant.

1. If local-only processing is required, disable Ollama cloud features and understand that cloud models and web search will no longer be available.

1. Keep Ollama on loopback when possible. For cross-host access, use a specific LAN or Tailscale address and restrict the firewall to the Home Assistant host.

1. Create a separate control-enabled Home Assistant configuration. Expose fewer than 25 low-consequence entities and use a model that supports tools.

1. Test ambiguous requests, incorrect entity names, repeated commands, and model failures before adding anything important.

1. Expand the entity list one device at a time. Review what the model actually did, not merely whether its explanation sounded confident.

Local AI is worth experimenting with. It can reduce cloud dependence and keep ordinary model processing on hardware you control. But privacy, network reachability, and device authority are three different problems.

Give the model a room, a few lamps, and time to prove itself. It can earn more authority later. It should not receive the house keys simply because it answered a question about the weather.