Lokale Sprachsteuerung in Home Assistant mit Whisper & Piper

Lokale Sprachsteuerung verbindet vier Aufgaben: ein Aktivierungswort erkennen, Sprache in Text umwandeln, einen passenden Befehl ausführen und die Antwort vorlesen. Mit Home Assistant, Whisper und Piper kann diese Verarbeitung im eigenen Netzwerk bleiben. Entscheidend ist die gesamte Kette: Ein lokaler Sprachassistent macht eine angeschlossene Cloud-Steckdose noch nicht offlinefähig.

1. Die Aufgaben der Komponenten

Whisper erstellt aus der Aufnahme Text. Der lokale Home-Assistant-Gesprächsagent ordnet unterstützte Sätze einer Aktion zu. Piper erzeugt daraus eine gesprochene Antwort. Der Sprachsatellit ist ein separates Gerät mit Mikrofon und Lautsprecher, beispielsweise in einem Raum. Das sind getrennte Aufgaben mit unterschiedlichen Fehlerquellen.

Das Aktivierungswort kann auf dem Satelliten mit microWakeWord oder serverseitig etwa mit openWakeWord erkannt werden. Bei serverseitiger Erkennung muss Audio bereits vor der Erkennung ins lokale Netzwerk gelangen; abhängig vom Gerät prüft die Erkennung von Sprachaktivität, ob gerade gesprochen wird, und begrenzt damit diesen Datenstrom. Eine pauschale Aussage „Audio wird erst nach dem Aktivierungswort übertragen“ wäre daher falsch. Das englische Aktivierungswort legt nicht automatisch die Sprache der anschließenden Befehle fest.

2. Hardware nach Messwerten auswählen

Eine feste Antwortzeit lässt sich aus der Modellbezeichnung nicht ableiten. Mikrofonqualität, Hintergrundgeräusche, Sprache, Satzlänge und gleichzeitige Aufgaben beeinflussen das Ergebnis. Ein kleines Whisper-Modell benötigt weniger Rechenleistung, kann aber gerade bei Namen schlechter transkribieren. Ein erster Vergleich sollte dieselben zehn kurzen Befehle mit zwei Modellgrößen verwenden und sowohl Fehler als auch Wartezeit erfassen.

Die übliche faster-whisper-Ausführung nutzt CPU oder unterstützte NVIDIA-GPUs über CUDA. Ein Google Coral Edge TPU ist dafür kein austauschbarer Beschleuniger. Bei zu langsamer Transkription kommt ein leistungsfähigerer lokaler Rechner infrage. Für einen begrenzten Satz von Haussteuerungsbefehlen ist außerdem Speech-to-Phrase eine Alternative; frei formulierte Inhalte sind damit stärker eingeschränkt. Whisper bleibt sinnvoll, wenn offene Transkription benötigt wird.

3. Lokale Dienste und Assistent einrichten

1. Installationsart prüfen: Home Assistant OS bietet verwaltete Apps, früher Add-ons genannt. Home Assistant Container benötigt separat betriebene Sprachdienste. Die frühere Supervised-Installation ist seit Home Assistant 2025.12 nicht mehr unterstützt.
2. Sprachdienste bereitstellen: Bei Home Assistant OS Whisper und Piper installieren und starten. Die entdeckten Wyoming-Integrationen übernehmen. Externe Dienste lassen sich über ihre tatsächliche Adresse und ihren konfigurierten Port anbinden. Wyoming verbindet diese Dienste mit Home Assistant; die ESPHome-Integration verbindet den entsprechenden Satelliten.
3. Assistent anlegen: Unter Einstellungen → Sprachassistenten die gewünschte Sprache, Home Assistant als Gesprächsagent, Whisper als Spracherkennung und Piper als Sprachausgabe wählen. Modell und Stimme müssen zur Sprache passen und zunächst heruntergeladen werden.
4. Eine Testentität freigeben: Beispielsweise eine lokal angebundene Lampe mit eindeutigem Namen und zugeordnetem Raum. Eine Entität steht in Home Assistant für eine einzelne Funktion oder einen Zustand, etwa den Ein-/Aus-Zustand einer Lampe. Allein die vorhandene Entität erlaubt Assist noch nicht, die Lampe zu steuern.
5. Erst Text, dann Sprache testen: Ein einfacher Textbefehl trennt Probleme mit Namen und Freigaben von Problemen bei Mikrofon und Transkription. Anschließend denselben Befehl über den Satelliten prüfen.

Sprachdienste gehören in ein vertrauenswürdiges Netz mit begrenzter Erreichbarkeit. Eine Portnummer aus einem Beispiel ist keine Freigabe ins Internet. Ein optionaler Cloud-Gesprächsagent oder eine Cloud-Integration verändert den Datenweg und muss bei einer gewünschten vollständig lokalen Kette gesondert betrachtet werden.

4. ESP32-S3-BOX-3: passende Firmware statt beliebiger Pins

Die BOX-3 ist kein beliebig verdrahtetes ESP32-Entwicklungsboard. Mikrofone, Audio-Codecs, Lautsprecher, Speicher und Tasten benötigen die zur Gerätevariante passende Konfiguration. Eine allgemeine YAML-Datei mit frei gewählten I²S-Pins ist deshalb keine vollständige BOX-3-Anleitung.

Für BOX, BOX-3 beziehungsweise BOX-Lite beschreibt die offizielle Home-Assistant-Geräteanleitung die jeweilige Installation und verlinkt die zugehörigen ESPHome-Konfigurationen. Nach der gerätespezifischen Einrichtung müssen WLAN-Verbindung, ESPHome-Integration, gewählter Assistent und Aktivierungswort zusammenpassen. Bereits vorhandene Gerätekonfigurationen benötigen vor einem Firmwarewechsel eine Sicherung.

Bei Eigenbauten gehören zusätzlich Netzwerkzugang, gültige API-Verschlüsselung, Audioein- und -ausgabe sowie Start und Wiederaufnahme der Aufnahme zum vollständigen Entwurf. use_wake_word: true aktiviert weder allein eine vollständige Dauerschleife noch automatisch microWakeWord auf dem Gerät. Die automatische Konfigurationsprüfung erkennt Fehler in den Einstellungen, ersetzt aber keinen Mikrofon- und Lautsprechertest am tatsächlichen Aufbau.

5. Fehler an der richtigen Stelle suchen

• Keine Aktivierung: Mikrofonstummschaltung, Erkennungsort, gewähltes Aktivierungswort und Verbindung des Satelliten prüfen.
• Falscher Text: Aufnahmequalität, Abstand, Sprache und Whisper-Modell vergleichen. Verstärkung schrittweise verändern; Übersteuerung verschlechtert die Erkennung.
• Richtiger Text, keine Aktion: Freigabe für Assist, Namen, zusätzliche Bezeichnungen (Aliase), Raum und unterstützte Formulierung prüfen. Der eingebaute Agent arbeitet mit Satzmustern; zusätzliche Sätze können gezielt ergänzt werden.
• Aktion ohne hörbare Antwort: Piper-Ausgabe und Audioverbindung zum Satelliten getrennt prüfen. Ein funktionierender Mikrofonweg belegt keinen funktionierenden Lautsprecherweg.

Die Debug-Ansicht des betroffenen Sprachassistenten hilft, die einzelnen Schritte auseinanderzuhalten. Das Protokoll einer konkreten fehlgeschlagenen Anfrage ist aussagekräftiger als ein pauschaler Austausch aller Komponenten.