ESPHome Voice Assistant z lokalnym wake-word: asystent głosowy HA bez chmury

Czym jest ESPHome Voice Assistant i dlaczego działa w pełni lokalnie

ESPHome Voice Assistant to asystent głosowy zbudowany na prostym module ESP32, który zamiast wysyłać nagranie do chmury, przetwarza komendy na miejscu, w Twojej sieci. Wake-word, czyli słowo wybudzające, wykrywa się bezpośrednio na mikrokontrolerze. Reszta rozpoznawania mowy trafia do serwera Home Assistant, gdzie działa silnik STT i TTS.

Nie ma tu żadnego round-tripu do zewnętrznego dostawcy. Nagranie nie opuszcza domu. To zmienia wszystko, jeśli zależy Ci na prywatności albo masz słabe łącze.

Mechanizm jest prostszy, niż się wydaje. Mikrofon zbiera dźwięk, lekki model detekcji wake-word sprawdza, czy pada fraza wybudzająca. Jeśli tak, strumień audio leci przez WiFi do HA, tam zamienia się na tekst, a intencja trafia do konwersacji. Odpowiedź wraca jako dźwięk do głośnika urządzenia.

Dlaczego to działa offline? Bo cały łańcuch: detekcja, transkrypcja i synteza mowy, siedzi na sprzęcie, który kontrolujesz. Chmura nie jest potrzebna, tylko wygodna. A wygoda bywa kosztowna.

Moim zdaniem ESPHome Voice Assistant wygrywa z gotowymi asystentami komercyjnymi nie dlatego, że jest lepszy technicznie, ale ponieważ daje pełną kontrolę nad danymi i integracją z Home Assistant. Zamknięte ekosystemy mają dopracowany sprzęt, ale nie pozwalają podmienić silnika STT na własny. Tu możesz.

Trzeba tylko pamiętać, że lokalnie nie znaczy bezobsługowo. Serwer musi mieć zasoby. Ale o tym za chwilę.

Sprzęt i komponenty do budowy lokalnego asystenta głosowego

Zbudowanie asystenta głosowego, który nie wysyła nagrań do chmury, wymaga trzech elementów: mikrofonu, mózgu i głośnika. Brzmi prosto, ale diabeł tkwi w szczegółach. Każdy z tych komponentów ma swoje pułapki, o których warto wiedzieć przed zakupem.

Mikrofon to najważniejszy element całego łańcucha. Wake-word działa lokalnie, więc jakość dźwięku na wejściu decyduje o tym, czy asystent w ogóle usłyszy komendę. Tanie moduły USB za kilkanaście złotych zbierają echo i szum otoczenia, przez co fałszywe wybudzenia stają się codziennością. Lepszy wybór to mikrofon z matrycą MEMS lub gotowy moduł z redukcją szumów, na przykład popularne w społeczności HA płytki z układem XMOS.

Mózg to najczęściej Raspberry Pi 4 lub 5, mini PC albo serwer NAS. ESP32 nie udźwignie rozpoznawania mowy i modelu wake-word jednocześnie, więc pełni zwykle rolę terminala audio. Głośnik wystarczy zwyczajny, byle nie generował trzasków przy starcie odtwarzania.

Moim zdaniem ESP32-S3 z zewnętrznym mikrofonem działa lepiej niż Raspberry Pi z tanim mikrofonem USB, ponieważ całe przetwarzanie audio dzieje się bliżej źródła dźwięku, a opóźnienia są mniejsze. Wyobraź sobie sytuację, w której stoisz trzy metry od urządzenia i mówisz cicho. Na tanim USB Pi zgubi połowę sylab, a dobrze skonfigurowany ESP32 złapie całe zdanie.

Kompletny zestaw da się złożyć w przedziale 400-1000 zł. Ceny w 2026 roku spadły, głównie za sprawą dostępności ESP32-S3 i modułów audio.

Konfiguracja ESPHome: wake-word, mikrofon i przetwarzanie mowy na urządzeniu

Fundament lokalnego asystenta głosowego to dobrze dobrany sprzęt i poprawnie skonfigurowany firmware. Na ESP32-S3 z PSRAM (np. moduły z 8 MB pamięci) mieści się jednocześnie model wake-word, bufor audio i lekki stos sieciowy. Bez PSRAM większość konfiguracji z lokalnym wykrywaniem frazy aktywującej zwyczajnie się nie zmieści.

Mikrofon podłączasz przez I2S. W praktyce najczęściej trafiasz na układy INMP441 albo ICS-43434. Pierwszy jest tańszy, drugi lepiej radzi sobie z szumem otoczenia. Wybór próbkowania 16 kHz i 16 bitów to standard, na którym opiera się cały łańcuch rozpoznawania mowy.

Konfigurację zaczynasz od zdefiniowania mikrofonu i głośnika w YAML. Potem dodajesz komponent voice_assistant i wskazujesz adres serwera Home Assistant. Wake-word możesz wykrywać na dwa sposoby: przez mikroWakeWord działający bezpośrednio na ESP, albo przez zewnętrzny silnik na serwerze. Pierwsze rozwiązanie odciąża sieć, drugie daje większą czułość na różne wymowy.

Diabeł tkwi w szczegółach. Zły gain mikrofonu potrafi sprawić, że asystent nie usłyszy cię z dwóch metrów, a zbyt wysoki zbierze każdy szum z kuchni. Moim zdaniem lepiej zacząć od konserwatywnego gainu i podnosić go stopniowo, testując wykrywanie w realnych warunkach, niż od razu ustawić maksimum i walczyć z fałszywymi aktywacjami.

Wyobraź sobie sytuację, w której asystent stoi w salonie obok telewizora. Przy domyślnych ustawieniach potrafi wybudzić się od dialogu z filmu. Rozwiązaniem bywa obniżenie czułości wake-word albo dodanie filtra dolnoprzepustowego, który odcina część pasma mowy z tła.

Kluczowa zasada: cała ścieżka od mikrofonu do transkrypcji może zostać w twojej sieci lokalnej. Chmura nie jest tu konieczna, choć wymaga to więcej pracy przy konfiguracji.

Integracja z Home Assistant i lokalnym LLM w 2026 roku

Sam wake-word to dopiero początek. Prawdziwa siła pojawia się, gdy ESPHome Voice Assistant połączysz z lokalnym LLM działającym poza chmurą. Home Assistant od 2025 roku rozwija natywne wsparcie dla agentów konwersacyjnych, które mogą korzystać z modeli uruchomionych na własnym sprzęcie.

Mechanizm jest prosty. Satelita ESPHome przechwytuje mowę, wysyła ją do pipeline'u HA, a ten przekazuje transkrypcję do wybranego agenta. Jeśli agent to lokalny LLM, cała rozmowa zostaje w twojej sieci. Żadne nagranie nie opuszcza domu.

W 2026 roku masz do wyboru kilka ścieżek integracji:

• Ollama jako backend dla agenta konwersacyjnego HA, z modelami takimi jak Llama 3.x czy Qwen, uruchamianymi lokalnie na GPU lub CPU.
• Wyoming Protocol do komunikacji między satelitą a usługami STT, TTS i agentem, co pozwala mieszać komponenty różnych dostawców.
• OpenAI-compatible API wystawiane przez lokalne serwery wnioskowania, dzięki czemu HA widzi je jak zwykłego agenta.
• Własny agent w Node-RED lub AppDaemon, jeśli potrzebujesz niestandardowej logiki wywoływania usług HA na podstawie odpowiedzi modelu.

Moim zdaniem Ollama sprawdza się lepiej niż chmurowe API do zadań sterowania domem, ponieważ opóźnienie odpowiedzi jest przewidywalne, a model nie odmawia wykonania polecenia z powodu polityk zewnętrznego dostawcy. Różnica w jakości rozumienia języka bywa odczuwalna przy złożonych pytaniach, ale do typowych komend typu "zgaś światło w kuchni" lokalny model w zupełności wystarcza.

Diabeł tkwi w szczegółach konfiguracji. Trzeba zadbać o poprawny pipeline w ustawieniach HA, dobrać model do dostępnej pamięci VRAM i przetestować opóźnienia. Bez owijania w bawełnę: pierwsze uruchomienie rzadko działa od strzała. Ale gdy już ruszy, masz asystenta, który nie wysyła twoich rozmów do żadnej chmury.

Prywatność, opóźnienia i wydajność: chmura kontra rozwiązanie lokalne

Pierwsza różnica jest oczywista. Asystent w chmurze wysyła fragment twojej wypowiedzi na serwer producenta, zanim dostanie jakąkolwiek odpowiedź. Lokalny wake-word w ESPHome działa inaczej: mikrofon nasłuchuje, ale dopóki nie padnie słowo wywołujące, żadne nagranie nie opuszcza urządzenia.

Co to oznacza w praktyce? Dom nie ma drugiego ucha po drugiej stronie internetu. Gdy sieć padnie, lokalny asystent nadal reaguje na podstawowe komendy, a chmurowy po prostu milknie.

Z opóźnieniami bywa różnie. Wake-word na ESP32 reaguje lokalnie w ułamku sekundy, ale samo rozpoznanie mowy i wykonanie akcji zależy już od tego, gdzie stoi silnik STT. Jeśli postawisz go na tym samym sprzęcie co Home Assistant, nie ma dodatkowej podróży w sieć. To zmienia wszystko przy komendach typu "zgasić światło".

Moim zdaniem lokalny wake-word wygrywa z chmurą przede wszystkim w kwestii prywatności, bo dane nie opuszczają domu bez wyraźnej zgody. Cena? Trzeba poświęcić trochę czasu na konfigurację i pogodzić się z tym, że polski model STT bywa mniej dokładny niż komercyjne usługi. Diabeł tkwi w szczegółach.

Wydajność lokalnego rozwiązania zależy od sprzętu. Na Raspberry Pi 4 z modelem średniej wielkości odpowiedzi potrafią zająć kilka sekund. Na mocniejszym mini-PC z akceleracją schodzi to poniżej sekundy. Chmura nie ma tego problemu, ale oddajesz jej kontrolę nad tym, kiedy i jak długo działa.

Najczęściej zadawane pytania (FAQ)

Poniżej zebrałem pytania, które pojawiają się najczęściej, gdy ktoś stawia pierwszy lokalny asystent głosowy na ESPHome i Home Assistant. Odpowiedzi są krótkie, konkretne i oparte na tym, jak te rzeczy działają w praktyce.

Czy wake-word działa bez internetu? Tak, i to jest cała idea tego rozwiązania. Model wykrywania słowa aktywującego działa lokalnie na urządzeniu lub w Home Assistant, więc chmura nie jest do niczego potrzebna. Internet przydaje się dopiero wtedy, gdy chcesz, żeby asystent odpowiedział na pytanie o pogodę albo sterował usługą zewnętrzną szerzej opisaliśmy to w artykule "Home assistant ai agent lokalny llm 2026".

Jaki sprzęt wystarczy? Do samego wykrywania wake-wordu wystarczy ESP32, ale pełny pipeline STT plus TTS wymaga już mocniejszego zaplecza. Poniżej zestawienie typowych scenariuszy.

Czy to trudne do skonfigurowania? Szczerze? Na start nie. Podstawowa konfiguracja to kilka wpisów w YAML i jedno urządzenie. Schody zaczynają się, gdy chcesz dopasować model do własnego języka i poprawić skuteczność wykrywania w hałaśliwym pomieszczeniu. Tu diabeł tkwi w szczegółach.

Czy działa po polsku? Wake-word tak, pod warunkiem że wybierzesz model wytrenowany pod polskie słowa. Z rozpoznawaniem mowy bywa różnie i zależy głównie od użytego silnika STT. Warto przetestować kilka opcji, zanim uznasz, że coś jest nie tak.

Czy warto rezygnować z chmury całkowicie? Moim zdaniem lokalny pipeline wygrywa z chmurowym w kwestii prywatności i braku miesięcznych opłat, ale przegrywa pod względem jakości odpowiedzi na złożone pytania. Jeśli zależy Ci głównie na sterowaniu światłem i prostych komendach, lokalne rozwiązanie w zupełności wystarczy. Jeśli oczekujesz rozmowy na dowolny temat, hybryda bywa rozsądniejszym kompromisem.