Wie ich Alexa mit Home Assistant, Voice Satellite, einem LLM und eigener Websuche ersetze
Ich möchte hier meinen aktuellen Stand mit Home Assistant Voice teilen, weil daraus inzwischen etwas geworden ist, das für mich erstmals wirklich das Potenzial hat, Alexa komplett zu ersetzen.
Nicht nur als Sprachschalter für Lampen.
Sondern als richtiger Assistent, der mein Haus kennt, natürliche Sprache versteht, aktuelle Informationen aus dem Internet recherchieren kann und bei Bedarf mehrere Werkzeuge miteinander kombiniert.
Der Kern besteht bei mir aus:
- Home Assistant
- Assist beziehungsweise Voice Satellites
- einem LLM als Conversation Agent
- Big Pickle als Modell
- MCP als Werkzeug-Schnittstelle
- einer selbst gehosteten SearXNG-Suche
- MetaMCP als MCP-Gateway
Die wichtigste Erkenntnis dabei war: Ein gutes LLM allein reicht nicht. Erst Werkzeuge machen daraus einen wirklich brauchbaren Assistenten.
Wo die Idee herkam: OpenCode für Home Assistant
Der eigentliche Auslöser für dieses Projekt war die Home-Assistant-App beziehungsweise das Add-on OpenCode von Magnus Øverli.
OpenCode für Home Assistant auf GitHub
Das Projekt bringt den OpenCode-AI-Coding-Agent direkt in Home Assistant. Es ist speziell auf Home-Assistant-Konfiguration zugeschnitten und besitzt eine sehr tiefe MCP-Integration. Laut Projektbeschreibung stellt das Add-on aktuell unter anderem zahlreiche Tools, Ressourcen und Prompts zur Verfügung und kann dadurch sehr viel mehr, als nur Text an ein LLM zu schicken. GitHub
OpenCode kann außerdem über sehr viele verschiedene LLM-Provider arbeiten. Für den schnellen Einstieg gibt es OpenCode Zen als kostenlosen Zugang zu ausgewählten Modellen. GitHub
Genau dort bin ich auf Big Pickle gestoßen.
Was mir beim Benutzen von OpenCode auffiel: Der Agent konnte Dinge erledigen und Fragen beantworten, für die das eigentliche Modell allein gar nicht ausreichend aktuelles Wissen besitzen musste.
Und damit kam mir der entscheidende Gedanke:
Wenn OpenCode ein LLM mit Werkzeugen versorgen kann, warum sollte ich nicht dasselbe Prinzip auf meinen Sprachassistenten übertragen?
Mein Voice-Setup funktionierte bereits. Das LLM konnte mein Smart Home bedienen und deutlich natürlicher mit mir kommunizieren als Alexa.
Was ihm fehlte, war der Zugriff auf die Gegenwart.
Voice Satellite statt Echo-Geräte
Home Assistant hat mit Assist Satellite inzwischen eine ziemlich gute Grundlage für eigene Sprachgeräte.
Ein Assist Satellite repräsentiert einen entfernten Sprachendpunkt, der die Assist-Pipeline von Home Assistant nutzt. Home Assistant kennt dabei Zustände wie Listening, Processing und Responding und unterstützt inzwischen auch Aktionen wie Durchsagen, Fragen und das Starten von Gesprächen. Home Assistant
Home Assistant: Assist Satellite
Das Grundprinzip sieht für mich so aus:
Mikrofon / Voice Satellite
↓
Wake Word
↓
Speech-to-Text
↓
Home Assistant Assist
↓
Conversation Agent / LLM
↓
Text-to-Speech
↓
Lautsprecher
Damit kann man im Prinzip genau das ersetzen, was bei mir bisher die Echo-Geräte erledigt haben.
Der Unterschied liegt in der Intelligenz hinter der Sprachpipeline.
Warum ein LLM so viel interessanter ist als Alexa
Bei einem klassischen Sprachassistenten arbeitet man im Wesentlichen mit festen Intents, Skills und vorgegebenen Funktionsbereichen.
Ein LLM kann dagegen aus normaler Sprache eine Absicht ableiten.
Statt:
„Schalte Wohnzimmerlampe 1 und Wohnzimmerlampe 2 auf 35 Prozent.“
kann ich eher sagen:
„Mach es im Wohnzimmer etwas gemütlicher, aber nicht zu dunkel.“
Das Modell kann den Kontext verstehen und die entsprechenden Home-Assistant-Werkzeuge auswählen.
Das ist der Punkt, an dem Sprachsteuerung für mich zum ersten Mal wirklich natürlich wird.
Aber dabei entsteht sofort ein neues Problem.
Das große Problem: Das LLM lebt in der Vergangenheit
Ein Sprachmodell hat einen Wissensstand.
Ohne weitere Werkzeuge kann es zwar enorm viel wissen, aber es kann nicht wissen, was heute Morgen passiert ist.
Fragen wie:
„Was ist heute bei Home Assistant erschienen?“
„Wer ist momentan Fußball-Weltmeister?“
„Welche Version dieser Software ist aktuell?“
„Wie ist das Spiel gestern ausgegangen?“
können deshalb mit altem Modellwissen beantwortet werden.
Und genau das wollte ich nicht.
Ein Assistent, der mein Haus im Jahr 2026 steuert, aber bei Wissensfragen in seinem Trainingsjahr hängen bleibt, ist nur die halbe Lösung.
MCP: Die Verbindung zwischen LLM und Werkzeugen
Hier kommt Model Context Protocol, kurz MCP, ins Spiel.
Home Assistant besitzt inzwischen selbst eine MCP-Integration und kann dabei als MCP-Client arbeiten. Externe MCP-Server können dem Conversation Agent zusätzliche Tools bereitstellen.
Home Assistant nennt eine Websuche sogar ausdrücklich als Beispiel für genau diesen Anwendungsfall. Home Assistant
Home Assistant: Model Context Protocol
Das ist konzeptionell sehr mächtig.
Das LLM muss die Websuche nicht selbst besitzen.
Es bekommt einfach ein Werkzeug:
web_search(query)
und kann selbst entscheiden, wann es dieses Werkzeug braucht.
Damit wird aus:
LLM
ein:
LLM + Werkzeuge
Und genau das hatte ich bei OpenCode gesehen.
Meine aktuelle Architektur
Der Aufbau sieht bei mir inzwischen so aus:
┌─────────────────────┐
│ Voice Satellite │
└─────────┬───────────┘
│
▼
┌─────────────────────┐
│ Home Assistant │
│ Assist │
└─────────┬───────────┘
│
▼
┌─────────────────────┐
│ Local OpenAI LLM │
│ Big Pickle │
└─────────┬───────────┘
│
┌─────────────┴─────────────┐
│ │
▼ ▼
Home-Assistant-Tools MCP Tools
Licht / Heizung / │
Sensoren / Geräte ▼
MetaMCP
│
▼
mcp-searxng
│
▼
SearXNG
│
▼
Internet
Das Modell besitzt damit zwei Arten von Wissen beziehungsweise Handlungsmöglichkeiten:
Home Assistant sagt ihm, was im Haus passiert.
MCP gibt ihm zusätzliche externe Werkzeuge.
Warum SearXNG?
Für die Websuche wollte ich möglichst keinen weiteren kommerziellen API-Dienst benötigen.
Deshalb habe ich SearXNG selbst gehostet.
SearXNG besitzt eine HTTP-Such-API und kann Suchergebnisse unter anderem als JSON ausgeben. Das JSON-Format muss dafür in der Konfiguration aktiviert sein. SearXNG Dokumentation
SearXNG selbst ist allerdings noch kein MCP-Server.
Dafür verwende ich:
mcp-searxng von ihor-sokoliuk
Dieses Projekt verbindet einen MCP-Client mit einer vorhandenen SearXNG-Instanz und stellt Websuche und das Lesen von Webseiten als Tools bereit. Es besitzt außerdem einen HTTP-Modus mit /mcp als MCP-Endpunkt und /health als Healthcheck. GitHub
In meinem Aufbau stehen dem LLM dadurch unter anderem diese Werkzeuge zur Verfügung:
searxng_web_search
searxng_search_suggestions
web_url_read
searxng_instance_info
Das Entscheidende dabei ist web_url_read.
Das LLM kann also zunächst suchen, ein relevantes Ergebnis auswählen und danach auch den Inhalt der gefundenen Seite lesen. GitHub
MetaMCP als zentrale Werkzeugschicht
Zwischen Home Assistant und mcp-searxng läuft bei mir zusätzlich MetaMCP.
MetaMCP ist ein MCP-Aggregator beziehungsweise Gateway.
Man kann mehrere MCP-Server zu sogenannten Namespaces zusammenfassen und diese wiederum über einen gemeinsamen Endpoint veröffentlichen. MetaMCP unterstützt dabei sowohl SSE- als auch Streamable-HTTP-Endpunkte. GitHub
Das ist für meine aktuelle Websuche eigentlich schon fast überdimensioniert.
Aber strategisch gefällt mir die Lösung sehr.
Heute hängt dort nur SearXNG.
Später können dort weitere Werkzeuge hinzukommen.
Home Assistant sieht trotzdem nur einen Tool Provider.
Zum Beispiel könnte man dort irgendwann ergänzen:
SearXNG
Kalender-MCP
Dokumenten-MCP
lokale Wissensdatenbank
weitere APIs
und für den Conversation Agent sieht das alles wie ein gemeinsamer Werkzeugkasten aus.
Der aktuelle Docker-Stack
Bei mir läuft Home Assistant OS als virtuelle Maschine unter Proxmox.
Die Websuch-Komponenten laufen separat auf einem Docker-Host und werden über Portainer verwaltet.
Der Stack besteht derzeit aus:
SearXNG
mcp-searxng
MetaMCP
PostgreSQL für MetaMCP
Alle Komponenten befinden sich in einem gemeinsamen Docker-Netzwerk.
Dadurch kann beispielsweise mcp-searxng intern einfach auf:
http://searxng:8080
zugreifen.
Und MetaMCP erreicht mcp-searxng intern über dessen Docker-Servicenamen.
Nach außen muss nur das veröffentlicht werden, was Home Assistant tatsächlich erreichen soll.
Und dann kam die lange Fehlersuche
Eigentlich hätte es jetzt funktionieren müssen.
Tat es aber nicht.
Home Assistant meldete beim Hinzufügen des MCP-Servers nur:
Verbindung fehlgeschlagen
oder:
Unerwarteter Fehler
Das Interessante war: Jeder einzelne technische Baustein funktionierte.
Der MCP-Healthcheck war erreichbar.
Ein manueller initialize-Request funktionierte.
Die Antwort enthielt eine gültige MCP-Session-ID.
Der Event-Stream funktionierte.
notifications/initialized funktionierte.
tools/list funktionierte.
Und alle vier SearXNG-Tools wurden sauber zurückgegeben.
Der entscheidende Test mit dem offiziellen MCP-Python-SDK
Um auszuschließen, dass MetaMCP oder mcp-searxng mit Home Assistants MCP-Version inkompatibel sind, habe ich einen separaten Python-Container gestartet.
Darin wurde dieselbe MCP-SDK-Version verwendet wie in Home Assistant.
Ein sehr kleiner Testclient konnte den Endpoint problemlos verwenden:
import asyncio
from mcp import ClientSession
from mcp.client.streamable_http import streamable_http_client
URL = "http://server/metamcp/home-assistant-websearch/mcp"
async def main():
async with streamable_http_client(URL) as (read, write, _):
async with ClientSession(read, write) as session:
result = await session.initialize()
print("INITIALIZE OK:", result.serverInfo)
tools = await session.list_tools()
for tool in tools.tools:
print(tool.name)
asyncio.run(main())
Das Ergebnis war sinngemäß:
INITIALIZE OK
SearXNG__searxng_web_search
SearXNG__searxng_search_suggestions
SearXNG__web_url_read
SearXNG__searxng_instance_info
Damit war der MCP-Server als Ursache praktisch ausgeschlossen.
Der mutmaßliche Fehler in Home Assistant 2026.8.0
Beim Durchsehen des Home-Assistant-Codes fiel anschließend etwas auf.
In der von mir verwendeten Version wurde die MCP-Session bereits innerhalb von mcp_client() initialisiert:
await session.initialize()
yield session
Der Config Flow bekam diese Session anschließend zurück und rief nochmals:
response = await session.initialize()
auf.
Die gleiche Session wurde beim Einrichten also effektiv zweimal initialisiert.
Unser Test-Patch bestand darin, mcp_client() nur noch Transport und ClientSession erzeugen zu lassen:
yield session
Die Initialisierung passiert anschließend genau einmal am jeweiligen Aufrufer.
Beim Abrufen der Tools beispielsweise:
async with mcp_client(...) as session:
await session.initialize()
result = await session.list_tools()
Und beim Aufruf eines Tools entsprechend:
async with mcp_client(...) as session:
await session.initialize()
result = await session.call_tool(...)
Wichtig: Ich bezeichne das bewusst als mutmaßlichen Bug beziehungsweise reproduzierbares Problem in meiner 2026.8.0-Installation, solange Home-Assistant-Core-Maintainer das Issue noch nicht bestätigt haben.
Ich habe dazu inzwischen ein Issue mit vollständiger Beweiskette eingereicht.
Der Moment, an dem es funktionierte
Nach dem Patch habe ich Home Assistant neu gestartet und exakt denselben MetaMCP-Endpoint wieder hinzugefügt.
Diesmal meldete Home Assistant:
Konfiguration für metamcp-unified-… erstellt.
Danach erschien der neue MCP-Provider im Local-OpenAI-LLM-Agenten unter:
Tool Providers
Dort musste ich ihn nur noch aktivieren.
Und damit hatte Big Pickle plötzlich Zugriff auf die Websuche.
Der erste Test
Meine Testfrage war:
„Suche im Internet nach den neuesten Nachrichten über Home Assistant vom heutigen Tag. Nenne mir drei Meldungen mit Quelle.“
Die Antwort enthielt tatsächlich aktuelle Informationen des gleichen Tages, inklusive Quellen.
Damit funktionierte erstmals die komplette Kette:
Sprache
↓
Voice Satellite
↓
Home Assistant Assist
↓
Big Pickle
↓
MCP Tool Call
↓
MetaMCP
↓
mcp-searxng
↓
SearXNG
↓
Internet
↓
Ergebnis zurück zum LLM
↓
Sprachantwort
Das war für mich der Punkt, an dem das Projekt von „interessant“ zu „wirklich alltagstauglich“ gekippt ist.
Der nächste Schritt: Das Modell soll selbst entscheiden, wann es suchen muss
Natürlich möchte ich nicht jedes Mal sagen:
„Suche im Internet nach …“
Das Modell soll selbst erkennen, wann sein eigenes Wissen möglicherweise veraltet ist.
Der System-Prompt meines Agents enthält deshalb Regeln nach diesem Prinzip:
Nutze die Websuche selbstständig, wenn eine Frage Informationen betrifft,
die sich seit deinem Wissensstand geändert haben könnten.
Dazu gehören insbesondere:
- Nachrichten und aktuelle Ereignisse
- Sportergebnisse
- Softwareversionen und Releases
- aktuelle Preise
- aktuelle Personen und Ämter
- Termine und Veranstaltungen
- Informationen mit Zeitbezug wie:
aktuell, heute, gestern, neueste, derzeit, momentan
Verlasse dich bei solchen Fragen nicht auf dein internes Trainingswissen.
Nutze stattdessen die Websuche.
Bei stabilen Fakten ist keine Websuche notwendig.
Wenn du unsicher bist, ob dein Wissen noch aktuell ist,
bevorzuge eine Websuche.
Damit soll das LLM beispielsweise:
„Wie hoch ist der Eiffelturm?“
ohne Tool beantworten.
Aber bei:
„Was ist heute bei Home Assistant passiert?“
selbstständig suchen.
Genau das unterscheidet für mich einen echten Agenten von einem Chatbot.
Warum das für mich wirklich Alexa ersetzen kann
Der interessante Punkt ist nicht, dass Home Assistant jetzt ebenfalls Wetter oder Fußballergebnisse beantworten kann.
Der interessante Punkt ist, dass dieselbe Intelligenz gleichzeitig Zugriff auf mein Zuhause und auf externe Informationen besitzt.
Der Assistent kann also verstehen:
„Mach es hier etwas heller.“
und ein Home-Assistant-Tool verwenden.
Er kann aber auch verstehen:
„Was ist heute bei Home Assistant neu?“
und die Websuche benutzen.
Und grundsätzlich kann er auch beide Welten kombinieren.
Das ist ein ganz anderes Modell als klassische Smart-Speaker-Skills.
Und was ist mit Datenschutz?
Für mich ist das ebenfalls ein wesentlicher Punkt.
Das bedeutet natürlich nicht automatisch, dass mein gesamter Sprachassistent vollständig offline ist.
Das hängt davon ab, welche Komponenten man verwendet:
- Speech-to-Text
- Text-to-Speech
- LLM
- externe APIs
- Suchmaschinen
Man kann Teile davon lokal betreiben und andere nicht.
Aber der fundamentale Unterschied ist:
Ich entscheide selbst, welche Komponente welche Daten erhält.
Voice Satellite und Home Assistant können lokal laufen.
SearXNG läuft bei mir selbst.
MCP und MetaMCP laufen bei mir selbst.
Die Haussteuerung läuft bei mir selbst.
Und wenn ich später ein ausreichend gutes lokales LLM einsetzen möchte, kann auch dieser Teil ersetzt werden.
Das System ist also nicht an einen einzigen Cloudanbieter und dessen Smart-Speaker-Ökosystem gebunden.
Mein aktueller Stack
Zusammengefasst:
Proxmox
│
├── Home Assistant OS VM
│ │
│ ├── Assist
│ ├── Voice Satellite
│ ├── Local OpenAI LLM
│ ├── Big Pickle
│ └── MCP Integration
│
└── Docker Host / Portainer
│
├── SearXNG
├── mcp-searxng
├── MetaMCP
└── PostgreSQL
OpenCode gehört dabei ausdrücklich nicht zu dieser Runtime-Kette.
OpenCode war der Ideengeber.
Ich habe dort gesehen, wie mächtig ein LLM wird, wenn man ihm über MCP gute Werkzeuge gibt. Das Konzept habe ich anschließend auf meinen Home-Assistant-Sprachassistenten übertragen.
Nützliche Referenzen
Für alle, die das nachbauen oder sich tiefer einlesen wollen:
OpenCode Home-Assistant-Add-on von Magnus Øverli
Home Assistant MCP-Integration
Home Assistant Assist Satellite
Fazit
Der Weg dahin war deutlich länger als gedacht.
Vor allem der MCP-Fehler in Home Assistant hat viel Zeit gekostet.
Aber das Ergebnis ist für mich ziemlich beeindruckend:
Mein Home-Assistant-Sprachassistent kann mein Haus steuern, mit einem LLM frei kommunizieren und selbstständig aktuelle Informationen aus dem Internet beschaffen.
Damit ist Voice Satellite für mich nicht mehr nur ein Bastelprojekt, um „Alexa ohne Amazon“ nachzubauen.
Es ist inzwischen eher das Gegenteil:
Alexa wird zum Vergleichsmaßstab für das alte Konzept eines Sprachassistenten.
Das Interessante an Home Assistant + LLM + MCP ist, dass ich nicht mehr auf die Funktionen beschränkt bin, die ein Hersteller vorgesehen hat.
Ich kann dem Agenten neue Werkzeuge hinzufügen.
Heute ist das eine Websuche.
Morgen vielleicht Dokumente, lokale Wissensdatenbanken oder andere interne Dienste.
Und genau deshalb glaube ich inzwischen:
Ein echter Alexa-Ersatz mit Home Assistant ist nicht nur möglich – er kann deutlich leistungsfähiger sein.
Das ist ein echter Gamechanger. Vorallem bei der Smarthome Steuerung. Statt den vorgegebenen Intents wird jetzt ein LLM verwendet. Somit funktioniert das, was du oben beschrieben hast, jetzt auch auf allen meinen Echo Geräten. Die Unterhaltungen sind jetzt viel natürlicher und kontextbezogen. Wie man es halt von anderen KI Chatbots, wie z.B. ChatGPT, kennt. Aktuelle Ereignisse sind logischerweise jetzt auch problemlos abfragbar.
