Home Assistant + Ollama: Local AI Smart Home Setup

Published April 11, 2026 · Updated August 2026 — 18 min read

Home Assistant ships a first-class Ollama integration, so adding local AI is a config step, not a project: point the integration at http://your-ollama-host:11434, pick a tool-capable model, choose which entities the AI is allowed to see, and you have natural language device control with nothing leaving your LAN. From there the interesting part begins — automations that reason about conditions instead of matching rules, and a voice pipeline (wake word → speech-to-text → model → speech) that works during an internet outage.

A smart home logs when the house wakes up, when it empties, which rooms get used, what temperature the occupants prefer, and when the lights go out. That is an intimate behavioural profile, and every cloud assistant uploads it for processing. Home Assistant keeps the sensor data local by default; adding Ollama keeps the AI processing local too.

This guide covers the complete integration: installing Ollama alongside Home Assistant, configuring the built-in integration, writing natural language automations, sizing the hardware with arithmetic instead of guesswork, and building a fully offline voice pipeline.

---

Why should smart home AI stay on your own hardware? {#why-local}

Smart home data is uniquely sensitive. Unlike browsing history or email (which you consciously create), smart home sensors passively record your physical life:

• Occupancy patterns: Motion sensors reveal when your home is empty — useful for burglars.
• Sleep schedule: Bedroom lights and motion expose when you wake and sleep.
• Health indicators: Bathroom sensor frequency, medication cabinet openings, activity levels.
• Financial patterns: Energy usage correlates with income and lifestyle.
• Relationship data: Who visits, how often, when they leave.

Every cloud-connected smart home assistant (Alexa, Google Home, Apple HomePod) uploads this data for processing. Home Assistant keeps it local by default. Adding Ollama keeps the AI processing local too. For a broader perspective on AI privacy, see our local AI privacy guide.

---

What does the Home Assistant + Ollama stack look like? {#architecture}

The stack is straightforward:

1. Home Assistant — Runs your smart home (devices, automations, dashboards)
2. Ollama — Runs AI models for natural language understanding
3. The Ollama integration — Home Assistant's own built-in integration. It registers Ollama as a conversation agent and hands the model the entities you have chosen to expose, as callable tools

The built-in integration talks to Ollama's native API on port 11434 — you give it a host, it does the rest. (Ollama also serves an OpenAI-compatible endpoint at http://localhost:11434/v1 if you would rather drive it from a custom or community integration.) Either way the traffic stays on your LAN.

The name to watch out for: Extended OpenAI Conversation is a different, community-installed HACS integration that some older tutorials use. You do not need it for this setup, and mixing the two is the most common reason a config copied off a forum does not match what you see in the UI.

How much hardware do you actually need?

You can size this with arithmetic rather than shopping around. Two formulas do all the work.

Will the model fit? At Q4_K_M quantization, weights come out to roughly 0.6 GB per billion parameters. Use the tag's real parameter count rather than its rounded name — "Qwen 2.5 14B" is actually 14.8B, so 8.9 GB, not 8.4. Add 1-2 GB for the KV cache, then add whatever Home Assistant and the OS are already using on that box — check with free -h rather than trusting anyone's estimate, because a HA install with 40 integrations looks nothing like a bare one.

Will it be fast enough? Generating one token means reading every weight once, so:

tokens/sec ceiling  =  memory bandwidth (GB/s)  ÷  model size (GB)

That is an arithmetic upper bound — real throughput lands below it — but it is enough to rule options in or out before you buy anything.

Every cell in that table is arithmetic you can redo yourself, so here is the working. The RTX 3060 12GB figure is NVIDIA's published spec. The other rows are computed from each platform's published memory configuration: the Pi 5 runs LPDDR4X-4267 on a 32-bit bus, so 4267 × 4 bytes ≈ 17 GB/s, and DDR5-5600 in dual channel is 5600 × 8 bytes × 2 = 89.6 GB/s. Weights are 0.6 × the tag's parameter count. The ceiling column is the first number divided by the fourth. It is all arithmetic, not a benchmark run.

The shape of the answer: a Pi 5 with 8 GB will run a 3B model alongside Home Assistant, and that is genuinely enough for "turn on the kitchen lights." It is not enough for an automation that reasons over a dozen sensor values, because the ceiling is single digits and those prompts are long. If you want that, move Ollama onto a separate machine — the Pi keeps doing what it is good at, and the model gets an order of magnitude more bandwidth.

Note that these ceilings assume the weights are resident in RAM. The moment a model spills to the Pi's SD card or SSD, throughput falls off a cliff and no tuning brings it back.

For detailed hardware requirements, check our Ollama system requirements guide. If you are considering a Raspberry Pi setup, our LLM on Raspberry Pi 5 guide covers installation and optimization, and best local AI models for 8GB RAM covers what fits in that budget.

---

How do you install Ollama for Home Assistant? {#install-ollama}

On Raspberry Pi 5 (Same Machine as HA)

# SSH into your Home Assistant OS
# If running HA OS, use the Terminal & SSH add-on

# Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Pull a tool-capable model that fits in 8GB RAM
ollama pull llama3.2:3b

# For a 4GB Pi, drop to the 1B — still tool-capable, 1.24B params -> ~0.75GB of weights
ollama pull llama3.2:1b

# Verify it's running, and that it reports the tools capability
ollama list
ollama show llama3.2:3b | grep -i capabilities

Do not substitute phi3:mini or gemma2 here just because they are small. Neither base tag ships a tool-calling template, and Home Assistant drives devices through tool calls — the model would answer in prose and never touch a light switch.

On a Separate Machine (Recommended for Better Performance)

If you run Home Assistant on a Pi and have a mini PC or desktop with more RAM:

# On the separate machine, install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Pull a larger model for better natural language understanding
ollama pull llama3.1:8b    # 8.0B params -> ~4.8GB of weights at Q4_K_M
ollama pull qwen2.5:7b     # 7.6B params -> ~4.6GB, good for complex automations

# Allow network access from other machines
# Edit Ollama's systemd service
sudo systemctl edit ollama.service

Add this to the override file:

[Service]
Environment="OLLAMA_HOST=0.0.0.0"

sudo systemctl daemon-reload
sudo systemctl restart ollama

# Verify it's accessible from your network
curl http://YOUR_OLLAMA_IP:11434/api/tags

---

How do you connect Home Assistant to Ollama? {#configure-ha}

Home Assistant includes a built-in integration called "Ollama" that connects directly to your local Ollama instance. It ships with Home Assistant — no HACS, no custom component, nothing to add to configuration.yaml first. The integration's documentation page is the authority on the minimum Home Assistant version and which features (conversation agent, entity control, vision) are available in the release you are on; check it rather than a forum post, because this integration has gained capabilities steadily.

Setup via UI

1. Go to Settings → Devices & Services → Add Integration
2. Search for "Ollama"
3. Enter the Ollama URL:
   • Same machine: http://localhost:11434
   • Separate machine: http://192.168.1.X:11434 (use your Ollama machine's IP)
4. Select your model (e.g., llama3.2:3b)
5. Click Submit

Setup via configuration.yaml

If you prefer YAML configuration:

# configuration.yaml
conversation:
  # This tells HA to use Ollama for the conversation agent

# The Ollama integration is configured via UI,
# but you can set defaults here:
ollama:

Verify the Connection

After adding the integration, go to Developer Tools → Services and call:

• Service: conversation.process
• Data: { "text": "What time is it?" }

If Ollama responds, the integration is working.

---

How do you control devices with natural language? {#voice-control}

With the Ollama conversation agent active, you can control devices using natural language from the Home Assistant Assist dialog.

Basic Commands

Open Assist (the microphone icon in the HA header) and try:

• "Turn on the living room lights"
• "Set the thermostat to 72 degrees"
• "Lock the front door"
• "What is the temperature in the bedroom?"
• "Is the garage door open?"
• "Turn off all lights"

The point of putting a model in front of Assist is that phrasing stops having to be exact — "kill the lights" resolves to the same intent as "turn off the lights", and "make it warmer" becomes a thermostat call rather than a parse error. How reliably it does that is a function of the model you picked and how many entities you exposed, not something a guide can promise. Test the phrasings you actually use.

Exposing Entities to the AI

By default, Home Assistant does not expose every entity to the conversation agent. You need to explicitly choose which devices the AI can see and control:

1. Go to Settings → Voice assistants
2. Click on your Ollama agent
3. Under Exposed entities, select which entities the AI can access

Be selective. Exposing 200 entities makes the AI slower and less accurate. Start with the entities you actually want to control by voice — lights, thermostats, locks, and media players. Add more as needed.

Custom Sentences and Intents

For complex commands, define custom intents:

# custom_sentences/en/movie_night.yaml
language: "en"
intents:
  MovieNight:
    data:
      - sentences:
          - "movie night"
          - "start movie mode"
          - "cinema mode"
          - "time for a movie"

# automations.yaml
- alias: "Movie Night Scene"
  trigger:
    - platform: conversation
      command: "MovieNight"
  action:
    - service: light.turn_on
      target:
        entity_id: light.living_room
      data:
        brightness: 30
        color_temp_kelvin: 2700
    - service: cover.close_cover
      target:
        entity_id: cover.living_room_blinds
    - service: media_player.turn_on
      target:
        entity_id: media_player.tv
    - service: media_player.select_source
      target:
        entity_id: media_player.tv
      data:
        source: "HDMI 1"
    - service: climate.set_temperature
      target:
        entity_id: climate.living_room
      data:
        temperature: 72

Now saying "movie night" triggers a complete scene: lights dim to 30% warm white, blinds close, TV turns on to the right input, and the thermostat adjusts.

---

What can AI automations do that rules cannot? {#ai-automations}

Beyond simple voice commands, Ollama enables automations that require reasoning — something traditional rule-based automations cannot do.

Energy Optimization

Use AI to analyze your energy usage and make recommendations:

# automations.yaml
- alias: "AI Energy Analysis"
  trigger:
    - platform: time
      at: "06:00:00"  # Run every morning
  action:
    - service: conversation.process
      data:
        agent_id: conversation.ollama
        text: >
          Analyze today's energy plan. Current weather forecast shows
          {{ states('weather.home') }} with high of
          {{ state_attr('weather.home', 'forecast')[0].temperature }}F.
          Current electricity rate is {{ states('sensor.electricity_rate') }}/kWh.
          Yesterday's total consumption was {{ states('sensor.daily_energy') }} kWh.
          Suggest optimal thermostat schedule to minimize cost while
          maintaining comfort. Should I pre-cool or pre-heat?
      response_variable: energy_advice
    - service: notify.mobile_app
      data:
        title: "Daily Energy Plan"
        message: "{{ energy_advice.response.speech.plain.speech }}"

Presence-Based Scene Management

- alias: "AI Welcome Home"
  trigger:
    - platform: state
      entity_id: person.john
      from: "not_home"
      to: "home"
  condition:
    - condition: time
      after: "17:00:00"
      before: "23:00:00"
  action:
    - service: conversation.process
      data:
        agent_id: conversation.ollama
        text: >
          John just arrived home. It's {{ now().strftime('%I:%M %p') }}.
          Outside temperature is {{ states('sensor.outdoor_temperature') }}F.
          Inside temperature is {{ states('sensor.indoor_temperature') }}F.
          The following lights are on: {{ states.light | selectattr('state','eq','on') | map(attribute='entity_id') | list }}.
          Based on the time and conditions, what lights should I turn on
          and what should the thermostat be set to?
          Reply with ONLY a JSON object like:
          {"lights": ["light.living_room", "light.kitchen"], "brightness": 80, "thermostat": 71}
      response_variable: ai_response
    # Parse and execute the AI's suggestion
    - service: script.execute_welcome_scene
      data:
        config: "{{ ai_response.response.speech.plain.speech }}"

Anomaly Detection

- alias: "AI Security Check"
  trigger:
    - platform: time_pattern
      hours: "/1"  # Every hour
  condition:
    - condition: state
      entity_id: group.family
      state: "not_home"
  action:
    - service: conversation.process
      data:
        agent_id: conversation.ollama
        text: >
          Nobody is home. Check these sensor states for anomalies:
          Front door: {{ states('binary_sensor.front_door') }}
          Back door: {{ states('binary_sensor.back_door') }}
          Garage: {{ states('binary_sensor.garage_door') }}
          Living room motion: {{ states('binary_sensor.living_room_motion') }}
          Kitchen motion: {{ states('binary_sensor.kitchen_motion') }}
          Basement motion: {{ states('binary_sensor.basement_motion') }}
          Doorbell last ring: {{ states('sensor.doorbell_last_ring') }}

          Is anything unusual? If motion is detected while nobody is home,
          respond with "ALERT" followed by the concern. Otherwise respond "OK".
      response_variable: security_check
    - choose:
        - conditions:
            - condition: template
              value_template: "{{ 'ALERT' in security_check.response.speech.plain.speech }}"
          sequence:
            - service: notify.mobile_app
              data:
                title: "Security Alert"
                message: "{{ security_check.response.speech.plain.speech }}"
                data:
                  push:
                    sound: "alarm.caf"

---

Which model should you use with Home Assistant? {#model-selection}

There is one hard requirement and one budget decision.

The hard requirement: the model must support tool calling. Home Assistant's Ollama integration exposes your entities to the model as callable tools. A model whose Ollama tag lacks the tools capability will hold a pleasant conversation about your lights and never actually turn them on — no error, just nothing happening. Check before you configure anything:

ollama show llama3.2:3b | grep -i capabilities

The llama3.1, llama3.2, qwen2.5 and mistral-small families carry it. Base gemma2 and phi3:mini tags do not, which is why Phi-3 Mini is a poor fit here despite being the obvious choice on size alone.

The budget decision: model size against the ceiling you calculated above.

On a Pi 5 with 8 GB, Llama 3.2 3B is the practical ceiling — it is tool-capable, it fits, and short commands keep prompts short. Anything that stuffs a dozen sensor values into the prompt will feel slow on that hardware regardless of which 3B you pick, because prompt processing scales with prompt length and the Pi's bandwidth is fixed at about 17 GB/s.

If you move Ollama to a separate machine with 16 GB or more, Qwen 2.5 7B buys you noticeably more room for conditional reasoning without leaving consumer hardware.

Measure it rather than trusting a table. Ollama returns timing fields with every response, so you can get the real number for your own hardware and prompt in one command:

curl -s http://localhost:11434/api/generate -d '{
  "model": "llama3.2:3b",
  "prompt": "Turn on the living room lights",
  "stream": false
}' | grep -o '"eval_count":[0-9]*\|"eval_duration":[0-9]*'

Divide eval_count by eval_duration (nanoseconds) and multiply by 1e9 for your actual tokens per second. That is the only response-time figure worth acting on, because it is measured on the machine you own with the prompt you actually send.

Switching Models Per Automation

You can configure multiple Ollama integrations in Home Assistant with different models:

1. Add a second Ollama integration (Settings → Devices & Services → Add Integration → Ollama)
2. Point it to the same Ollama URL but select a different model
3. Use the specific agent_id in each automation

# Fast model for voice commands
- service: conversation.process
  data:
    agent_id: conversation.ollama_fast   # llama3.2:3b
    text: "{{ trigger.sentence }}"

# Smart model for energy analysis
- service: conversation.process
  data:
    agent_id: conversation.ollama_smart  # qwen2.5:7b
    text: "Analyze energy usage..."

---

Which automations are worth building first? {#practical-automations}

Morning Briefing

- alias: "AI Morning Briefing"
  trigger:
    - platform: state
      entity_id: binary_sensor.bedroom_motion
      to: "on"
  condition:
    - condition: time
      after: "05:30:00"
      before: "09:00:00"
    - condition: state
      entity_id: input_boolean.morning_briefing_done
      state: "off"
  action:
    - service: input_boolean.turn_on
      entity_id: input_boolean.morning_briefing_done
    - service: conversation.process
      data:
        agent_id: conversation.ollama
        text: >
          Create a brief morning summary:
          - Weather: {{ states('weather.home') }}, {{ state_attr('weather.home', 'temperature') }}F
          - Calendar: {{ states('sensor.next_calendar_event') }}
          - Commute: {{ states('sensor.commute_time') }} minutes
          - Energy yesterday: {{ states('sensor.daily_energy') }} kWh
          Keep it under 4 sentences.
      response_variable: briefing
    - service: tts.speak
      target:
        entity_id: media_player.kitchen_speaker
      data:
        message: "{{ briefing.response.speech.plain.speech }}"
    - service: input_boolean.turn_off
      entity_id: input_boolean.morning_briefing_done
      # Reset at midnight via another automation

Smart Thermostat Logic

Instead of static schedules, let AI adapt to conditions:

- alias: "AI Thermostat Adjustment"
  trigger:
    - platform: time_pattern
      minutes: "/30"  # Every 30 minutes
  action:
    - service: conversation.process
      data:
        agent_id: conversation.ollama
        text: >
          Current conditions:
          - Indoor temp: {{ states('sensor.indoor_temperature') }}F
          - Outdoor temp: {{ states('sensor.outdoor_temperature') }}F
          - Humidity: {{ states('sensor.indoor_humidity') }}%
          - People home: {{ states('sensor.people_count') }}
          - Time: {{ now().strftime('%I:%M %p') }}
          - Current setpoint: {{ state_attr('climate.thermostat', 'temperature') }}F
          - Electricity rate: {{ states('sensor.electricity_rate') }}/kWh

          Based on these conditions, recommend a thermostat setpoint.
          Consider: energy cost, comfort, and time of day.
          Respond with ONLY a number (the temperature in F).
      response_variable: temp_suggestion
    - service: climate.set_temperature
      target:
        entity_id: climate.thermostat
      data:
        temperature: "{{ temp_suggestion.response.speech.plain.speech | float }}"

Goodnight Routine

- alias: "AI Goodnight Check"
  trigger:
    - platform: conversation
      command:
        - "goodnight"
        - "going to bed"
        - "bedtime"
  action:
    - service: conversation.process
      data:
        agent_id: conversation.ollama
        text: >
          Running bedtime checklist:
          - Front door locked: {{ states('lock.front_door') }}
          - Back door locked: {{ states('lock.back_door') }}
          - Garage closed: {{ states('cover.garage_door') }}
          - Stove off: {{ states('switch.stove_monitor') }}
          - Windows: {{ states('binary_sensor.windows') }}
          - Lights still on: {{ states.light | selectattr('state','eq','on') | map(attribute='name') | list }}

          Report any issues. If everything looks good, confirm all clear.
      response_variable: checklist
    # Turn off all lights except bedroom
    - service: light.turn_off
      target:
        entity_id: all
    - service: light.turn_on
      target:
        entity_id: light.bedroom
      data:
        brightness: 10
        color_temp_kelvin: 2200
    # Lock any unlocked doors
    - service: lock.lock
      target:
        entity_id:
          - lock.front_door
          - lock.back_door
    # Report status
    - service: tts.speak
      target:
        entity_id: media_player.bedroom_speaker
      data:
        message: "{{ checklist.response.speech.plain.speech }}"

---

How do you tune a Raspberry Pi 5 to run both? {#raspberry-pi}

The Pi 5 is the most common Home Assistant hardware. Running Ollama alongside it requires some tuning.

Memory Management

Do the budget in the order that matters: start from what free -h reports as available after Home Assistant is already running, then subtract the model. Llama 3.2 3B at Q4_K_M is roughly 0.6 × 3.2 = 1.9 GB of weights, plus 1-2 GB for the KV cache at a short context. If available memory minus that number is not comfortably positive, the model will page to storage and the ceiling maths stops applying entirely.

The exact Home Assistant footprint depends on how many integrations you run — a bare install and a forty-integration install are not the same machine — so measure yours rather than assuming a figure.

# Check available memory (run this AFTER Home Assistant is up)
free -h

# Monitor Ollama memory usage
watch -n 5 'ollama ps'

# Set Ollama to unload models after 5 minutes of inactivity
# This frees RAM when AI is not needed
export OLLAMA_KEEP_ALIVE=5m

Performance Optimization

# Ensure the Pi 5 runs at maximum clock speed during AI inference
echo "performance" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# Increase swap to handle occasional spikes
sudo dphys-swapfile swapoff
sudo sed -i 's/CONF_SWAPSIZE=.*/CONF_SWAPSIZE=2048/' /etc/dphys-swapfile
sudo dphys-swapfile setup
sudo dphys-swapfile swapon

What determines response time on a Pi

End-to-end latency for an Assist command is three costs stacked, and it is worth knowing which one you are paying:

1. Model load — only on the first request after an idle period. Set OLLAMA_KEEP_ALIVE long enough that an interactive session never pays this twice.
2. Prompt processing — scales with prompt length. This is why "turn on the lights" is fast and a six-sensor security check is not: the sensor values are prompt tokens, and the Pi has to read them before it generates anything.
3. Generation — bounded by the ceiling from the arithmetic earlier: bandwidth ÷ model size, so roughly ≤9 tok/s for a 3B on a Pi 5. Keep the model's replies short and this barely registers.

Two design consequences follow. Keep automation prompts terse — every extra sensor line is prompt-processing time you pay on every run. And instruct the model to answer with a single value or a small JSON object rather than prose, because generated tokens are the slowest part.

To get real numbers for your own Pi, use the eval_count / eval_duration method shown in the model selection section above. For a complete guide to running models on Pi hardware, see our Raspberry Pi 5 LLM guide.

---

How do you build a fully local voice pipeline? {#voice-setup}

Home Assistant has built-in voice pipeline support. Combined with Ollama, you get a fully local voice assistant.

Option 1: Phone App (Easiest)

The Home Assistant mobile app includes a microphone button for Assist. Tap it, speak your command, and the AI processes it through Ollama. No additional hardware needed.

Option 2: Satellite Speakers

For room-by-room voice control, set up voice satellites:

# ESPHome voice satellite configuration
# Flash this to an ESP32-S3 with a microphone
esphome:
  name: kitchen-voice
  platform: esp32
  board: esp32-s3-devkitc-1

microphone:
  - platform: i2s_audio
    id: mic
    i2s_din_pin: GPIO16
    channel: left
    pdm: true

voice_assistant:
  microphone: mic
  use_wake_word: true
  on_wake_word_detected:
    - light.turn_on:
        id: led
  on_stt_end:
    - light.turn_off:
        id: led

Option 3: Wyoming + Whisper (Complete Local Pipeline)

For a fully private voice pipeline (wake word + speech-to-text + AI + text-to-speech):

# Install Wyoming Whisper (speech-to-text)
docker run -d \
  --name wyoming-whisper \
  -p 10300:10300 \
  -v whisper-data:/data \
  rhasspy/wyoming-whisper \
  --model small-int8 \
  --language en

# Install Wyoming Piper (text-to-speech)
docker run -d \
  --name wyoming-piper \
  -p 10200:10200 \
  -v piper-data:/data \
  rhasspy/wyoming-piper \
  --voice en_US-lessac-medium

# Install openWakeWord
docker run -d \
  --name wyoming-openwakeword \
  -p 10400:10400 \
  rhasspy/wyoming-openwakeword

Configure in HA: Settings → Voice assistants → Add assistant → Select Wyoming services as STT, TTS, and wake word providers. Set Ollama as the conversation agent.

Now you have a complete local voice pipeline: wake word detection → Whisper speech-to-text → Ollama reasoning → Piper text-to-speech. No cloud involved at any stage.

Budget for it the same way you budgeted for the model: Whisper and Piper are additional processes holding their own weights resident. On a Pi 5 running Home Assistant and a 3B model, adding both is usually a step too far — run the Wyoming services on a second machine, or accept a smaller Whisper model.

If you want to try different Piper voices or run it outside Docker, the Piper TTS setup guide covers installation on Windows, Linux and Raspberry Pi, and our Whisper + Ollama + Piper voice assistant guide builds the same pipeline standalone.

---

How do you secure an AI that can unlock your doors? {#security}

Network Isolation

If Ollama runs on a separate machine, restrict access:

# Only allow Home Assistant's IP to access Ollama
sudo iptables -A INPUT -p tcp --dport 11434 -s 192.168.1.100 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 11434 -j DROP

# Or use OLLAMA_ORIGINS to restrict CORS
export OLLAMA_ORIGINS="http://192.168.1.100:8123"

Prompt Injection Prevention

When passing sensor data to the AI, sanitize the values:

# BAD — sensor value could contain injection
text: "The doorbell name is {{ states('sensor.doorbell_name') }}"

# BETTER — validate expected format
text: >
  The temperature is {{ states('sensor.temperature') | float(0) }}F.
  Only respond with a temperature number.

For automations that control locks, doors, or security systems, always add a confirmation step rather than blindly executing AI suggestions.

Settings for Security Tasks

Set temperature: 0 for any automation that touches physical access. Sampling temperature controls how much randomness is injected when picking the next token — non-zero means the same sensor state can produce different decisions on different runs, which is exactly the property you do not want from something wired to a deadbolt.

If you are pointing AI at cameras or intrusion detection, our Frigate + Ollama camera guide and local AI home security go deeper on that specific stack.

---

How do you monitor and debug the integration? {#monitoring}

Check AI Response Quality

# Log all AI interactions for review
- alias: "Log AI Conversations"
  trigger:
    - platform: event
      event_type: conversation_agent_response
  action:
    - service: logbook.log
      data:
        name: "AI Response"
        message: >
          Input: {{ trigger.event.data.user_input }}
          Response: {{ trigger.event.data.response }}
          Agent: {{ trigger.event.data.agent_id }}

Ollama Health Check

# Alert if Ollama goes down
- alias: "Ollama Health Monitor"
  trigger:
    - platform: time_pattern
      minutes: "/5"
  action:
    - service: rest_command.check_ollama
  # rest_command in configuration.yaml:
  # check_ollama:
  #   url: "http://localhost:11434/api/tags"
  #   method: GET

---

Frequently asked questions

Can Home Assistant talk to Ollama without any cloud service?

Yes. Home Assistant's built-in Ollama integration connects directly to your local Ollama instance over your LAN, with no API key and no internet connection required. Voice processing can be fully local too, using Wyoming + Whisper + Piper for speech-to-text and text-to-speech.

Will a Raspberry Pi 5 handle both Home Assistant and Ollama?

An 8 GB Pi 5 can run Home Assistant alongside a 3B model. Do the arithmetic before committing: Llama 3.2 3B at Q4_K_M is roughly 1.9 GB of weights plus 1-2 GB of KV cache, and it has to fit in whatever free -h reports as available after Home Assistant is running. Expect single-digit tokens per second — the Pi's ~17 GB/s of memory bandwidth divided by the model size is a hard ceiling. That is fine for short commands and poor for long multi-sensor prompts.

Is the AI reliable enough to control my home?

Simple, unambiguous commands against a small exposed-entity list are the reliable case; ambiguous multi-step reasoning over many sensors is not. Two things move the needle more than model choice: expose only the entities you actually want controlled (a shorter list means fewer wrong matches), and constrain the output format so automations parse a value instead of prose. Test each automation before you trust it with anything that matters.

Can I use this for security automations?

Yes, with caution. Use AI for monitoring and alerting, not for direct control of locks or alarms. Add a confirmation step for any security-critical action, set temperature: 0 so the same inputs produce the same decision, and log every AI-triggered action so there is an audit trail when something misfires.

What determines latency for voice commands?

Three things, in this order: whether the model is already loaded (set OLLAMA_KEEP_ALIVE so it stays resident), how long your prompt is (prompt processing dominates on multi-sensor automations), and the generation ceiling — memory bandwidth divided by model size. For a real figure on your own hardware, read eval_count and eval_duration from an Ollama API response rather than trusting any published number.

Which models work with Home Assistant's Ollama integration?

Any model whose Ollama tag carries the tools capability, since the integration exposes entities as callable tools. ollama show <model> tells you. The llama3.1, llama3.2, qwen2.5 and mistral-small families have it; base gemma2 and phi3:mini tags do not, and will chat about your lights without ever switching them.

Does this work with all Home Assistant devices?

The AI can control any device exposed through Home Assistant — Zigbee, Z-Wave, Wi-Fi, Matter and Thread all included, because the model talks to Home Assistant's entity layer rather than to the devices. You decide which entities it can reach through the exposed-entities setting.

Can AI automations actually reduce my electricity bill?

You can build automations that pass weather forecasts, tariff rates and historical consumption to Ollama and act on the recommendation. Whether that saves money depends entirely on your tariff structure — the savings come from shifting load into cheap hours, which is a property of your rate plan, not of the model. On a flat tariff there is nothing to optimize. Run it as a scheduled background job either way, since latency does not matter for a daily plan.