Local AI Voice Assistant Stack 2026: Whisper + Piper + Ollama Wired Together

Originally published at , and spoken back through a neural TTS engine, all without a single cloud API call.

Piper TTS got archived in October 2025. Ollama shipped MLX support with up to 90% faster inference on as a conversation agent. Models like llama3.2:3b handle voice queries in real time on consumer hardware.

Piper TTS — Text-to-speech. A fast neural TTS system that converts response text back into spoken audio. Archived in October 2025 but still functional.

The Whisper, Piper, and Wyoming Protocol integrations are each used by 8.9% of all active Home Assistant installations as of 2026.7, according to .

How Does the Full Offline Pipeline Work?

The audio flow from mouth to speaker, with zero packets leaving your LAN:

Microphone → openWakeWord (wake-word detection) → Wyoming STT (Whisper or Speech-to-Phrase) → Home Assistant Assist (intent parsing) → Ollama conversation agent (LLM response) → Wyoming TTS (Piper) → Speaker

Say "Hey Jarvis, what's the weather forecast and turn off the porch lights." openWakeWord catches the wake phrase and activates the pipeline. The audio stream goes via Wyoming to Whisper, which transcribes it to text. Home Assistant Assist receives the transcription and splits the work. The entity command ("turn off the porch lights") gets handled directly through Assist's intent system. The conversational query ("what's the weather forecast") routes to the Ollama conversation agent, which generates a natural-language response using whatever model you've configured. The response text goes via Wyoming to Piper, which synthesises speech and plays it through your speaker.

The entire round trip stays on your network. No audio recordings sitting in someone else's cloud. No transcription logs feeding an ad model. No subscription fee.

As , Whisper takes approximately 8 seconds to process a voice command on a Raspberry Pi 4. On an Intel NUC or equivalent x86 hardware, under 1 second.

Speech-to-Phrase is Home Assistant's newer close-ended model. It only recognises a predefined subset of voice commands — "turn on the lights," "set temperature to 22 degrees," that kind of thing. But it runs in under 1 second even on a Raspberry Pi 4 or Home Assistant Green. If all you need is home control without freeform queries, this is the practical choice for constrained hardware.

Feature	Whisper	Speech-to-Phrase
Transcription type	Open-ended (anything)	Close-ended (known commands)
Pi 4 latency	~8 seconds	< 1 second
NUC/x86 latency	< 1 second	< 1 second
Freeform queries	Yes	No
Shopping lists, timers	Yes	No
Language support	Broad multilingual	Growing (community-translated)
Best for	Powerful hardware + LLM pipeline	Raspberry Pi home control

For the full Ollama-powered conversational pipeline, you need Whisper. Speech-to-Phrase won't pass freeform text to an LLM because it doesn't generate freeform text. But if you're on a Pi 4 and just want fast light switches, Speech-to-Phrase is the right call.

Latency optimisation tip: Use faster-whisper (a CTranslate2 reimplementation) instead of the stock OpenAI Whisper for 2-4x speed improvement. Choose the tiny or base model for speed-critical setups, accepting slightly lower accuracy. The small model hits the sweet spot for most English-language voice assistants. Tune beam size down to 1 for single-command use cases.

From maintaining the benchmark data at , creator of Piper and the Rhasspy voice assistant project, archived Piper's GitHub repository on October 6, 2025. The repo has 11,200+ stars, 1,000+ forks, and 396 open issues that will never be fixed.

What this means in practice:

• 
  Piper still works. The Home Assistant Wyoming add-on functions fine. You can install it today, pick a voice model, and it will synthesise speech without issues.


• 
  No new features. No new voice models, no bug fixes, no security patches. The codebase is frozen.


• 
  No new language support. The community had translated Home Assistant voice commands into 45+ languages, but Piper's voice model library won't grow from here.


• 
  Building on archived software is technical debt from day one. That's just the reality.

When to still use Piper: You're running the Home Assistant add-on path and want the simplest possible setup. For English and major European languages, the existing voice models are good enough for home assistant responses.

When to look elsewhere: You need voice cloning, new languages, active development, or you're building a Docker-based pipeline outside Home Assistant OS.

Alternatives worth evaluating:

• 
  Kokoro TTS — Emerging open-source neural TTS with active development and a growing community. Lighter weight than some alternatives.


• 
  Coqui XTTS — Supports voice cloning, broader language coverage. Heavier compute requirements but significantly more capable. Coqui the company shut down, but the XTTS model lives on as open source.


• 
  OpenVoice — MIT-licensed, supports cross-lingual voice cloning. Worth a look if multilingual matters to you.

For the Home Assistant pipeline specifically, any TTS that implements the Wyoming protocol can drop in as a Piper replacement. The Wyoming abstraction layer means the rest of your pipeline doesn't care which TTS engine sits behind it.

If you're thinking about the adds a conversation agent powered by a local Ollama server. When you ask something conversational — "What should I cook for dinner given what's in my fridge?" — the query routes to a real language model instead of hitting a dead end at Assist's intent parser.

Setup is pretty simple. You need an Ollama server running on a machine accessible to your Home Assistant instance. Doesn't have to be the same machine. For performance, you'll often want Ollama on a beefier box while Home Assistant runs on a Pi or Green.

The configuration options that matter in the .

For hygiene.

Choosing the Right Ollama Model for Voice Use Cases

Not every model works for voice. Speed is everything here. Nobody wants to wait 15 seconds for an answer to "what time is sunset today?"

For voice assistant pipelines, models in the 1B–7B parameter range hit the best latency-quality trade-off on consumer hardware. My recommendations by hardware tier:

16GB RAM machine (Mac Mini, NUC, mini-PC):

• 
  llama3.2:3b — Best latency. Fast enough and conversational enough for home assistant tasks. This is my default recommendation.


• 
  qwen3:4b — Slightly larger, better at structured responses. Good pick if you want the LLM to control Home Assistant entities via the experimental API.


• 
  gemma3:4b — Google's small model. Strong instruction following, 38.3 million pulls on Ollama.

32GB+ RAM or dedicated GPU:

• 
  qwen3:8b — Better reasoning, still fast enough for voice on decent hardware.


• 
  llama3.1:8b — The workhorse. Good quality, well-tested, from the most-pulled model family on Ollama.

Raspberry Pi 5 (8GB):

• Don't run Ollama on a Pi 5 for voice. The latency will drive you crazy. Offload the LLM to a separate machine and keep the Pi for Home Assistant + Wyoming services.

Ollama 0.31, shipped in June 2026, brings multi-token prediction via MLX on Apple Silicon — , it's a lightweight JSON-over-TCP protocol that lets voice services register with Home Assistant as pluggable components.

It supports 4 service types:

• 
  Speech-to-text (Whisper, Speech-to-Phrase)


• 
  Text-to-speech (Piper, or any TTS implementing the protocol)


• 
  Wake-word detection (openWakeWord)


• 
  Intent handling (via Assist pipeline routing)

The reason Wyoming matters: substitutability. Want to swap Piper for Kokoro TTS? Implement the Wyoming protocol and Home Assistant doesn't know the difference. Want to run Whisper on a GPU server in your closet while Home Assistant lives on a Pi in your living room? Wyoming handles it over TCP.

Same architectural principle behind and the complete . For voice assistant workloads specifically, Apple wins on power efficiency and noise. Fanless operation matters when the device sits in your living room.

Wake Word Detection With openWakeWord

Without a wake word, your voice assistant requires a button press to activate. openWakeWord is the open-source solution that plugs into Wyoming for always-on listening.

openWakeWord runs a small neural network that continuously monitors audio for a trigger phrase. It supports custom wake words — you're not locked into "Hey Google" or "Alexa." Common choices: "Hey Jarvis," "Hey Mycroft," or any custom phrase you train.

The important design decision: openWakeWord runs on the satellite device (the ESP32 or Pi with the microphone), not your central server. Wake-word detection happens at the edge with minimal latency. Only activated audio streams get forwarded to Whisper.

For ESP32-based satellite devices using ESPHome, openWakeWord integrates directly. The Home Assistant community has built from scratch. Wyoming handles the complexity of routing audio between wake-word detection, STT, and TTS. You don't build that plumbing yourself.

Running the Stack Without Home Assistant OS

Not everyone runs Home Assistant OS. If you're on Home Assistant Container, Home Assistant Core, or you want this pipeline without Home Assistant at all, the Docker Compose path works.

The Wyoming services (Whisper, Piper, openWakeWord) are all available as standalone Docker containers. You can wire them together with Home Assistant Container or build your own orchestration.

The architecture for a Docker-based deployment:

• 
  Container 1: wyoming-whisper — runs the Whisper STT service, exposes a Wyoming TCP port (default 10300)


• 
  Container 2: wyoming-piper — runs Piper TTS, exposes Wyoming TCP port (default 10200)


• 
  Container 3: wyoming-openwakeword — runs wake-word detection, exposes Wyoming TCP port (default 10400)


• 
  Container 4: ollama — runs the LLM server, exposes HTTP API on port 11434


• 
  Container 5: homeassistant — the core instance, connects to all Wyoming services and Ollama via their TCP/HTTP ports

Key configuration: tell Home Assistant where each Wyoming service lives. In the Wyoming integration setup, you point to each container's hostname and port. For Ollama, add the integration and point the URL to http://ollama:11434.

If you want to skip Home Assistant entirely and build a pure Python pipeline, you'll need to implement the intent-parsing layer yourself. Projects like OpenJarvis v1.0 — which launched in May 2026 with built-in Ollama support — are emerging as alternatives for developers who want an serving outside the Home Assistant ecosystem, Ollama remains the easiest path. It handles model management, for the full trade-off analysis.

Privacy: What Stays Local vs. What Leaks

The privacy argument for this stack isn't hand-waving. Here's exactly what goes where:

Data Point	Cloud Assistant (Alexa/Google)	This Local Stack
Audio recordings	Stored on vendor servers	Never leaves your LAN
Transcription text	Processed and stored in cloud	Processed locally, discarded
Command history	Full log retained by vendor	Only in your HA instance
Device state data	Sent to vendor cloud	Stays on your network
Voice profiles	Stored for speaker recognition	Not applicable
Third-party sharing	Shared with skills/actions providers	Zero third parties
Internet requirement	Required for every command	Not required at all

The entire pipeline works with no internet connection. Once you've downloaded the Whisper model, Piper voice files, and your Ollama model, you can unplug your router and the voice assistant keeps working. That's not true of any commercial voice assistant on the market today.

Amazon's move toward users need additional container configuration.

Piper producing garbled audio: Almost always a sample rate mismatch. Piper outputs 22050 Hz by default. If your audio pipeline expects 16000 Hz or 48000 Hz, you get distorted playback. Match the output sample rate to your speaker setup.

High Whisper latency on good hardware: Check that you're running faster-whisper, not stock Whisper. Verify the model size — accidentally loading large-v3 instead of small on a 16GB machine will crush performance. Monitor RAM usage. If the system is swapping, everything slows to a crawl.

Ollama model not responding to Home Assistant queries: Make sure the model actually downloaded. Run ollama list on the server to confirm. Also verify the Ollama server is listening on 0.0.0.0 rather than localhost if Home Assistant is on a different machine. This one catches people constantly.

What's Next for the Local Voice Stack

A few things are becoming clear about where this is heading:

Piper's archival leaves a TTS gap. Someone will fill it. Kokoro TTS and the community forks around Coqui XTTS are the leading candidates. Whichever project ships a clean Wyoming protocol implementation first will likely become the default. If you're looking at

Vollständiger Original-Bericht

Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

↗ Original-Artikel auf dev.to lesen