A voice assistant turns sound into an action and an answer. Separating those stages makes failures much easier to diagnose. Rhasspy helped popularize modular, locally processed voice systems, but its main repository was archived on October 6, 2025. This page preserves the architectural lesson; for a new project, the exercise below uses Home Assistant Assist. See the Rhasspy repository’s status.
Follow one command through the system
- Capture: a microphone produces audio. Device selection, clipping, room noise, and distance affect everything downstream.
- Activation: a button or wake word starts a request. Wake-word recognition does not establish who is speaking.
- Speech recognition: audio becomes text, such as “turn on demo alert.”
- Intent handling: the system matches the words to an allowed action and a named entity.
- Execution: Home Assistant changes that entity and records the result.
- Response: an answer becomes text and, optionally, synthesized speech.
Rhasspy could exchange messages between these stages using MQTT and the Hermes conventions. That is one architecture, not a requirement for every local assistant. Home Assistant’s modern voice tools use their own integrations, including Wyoming for local speech services.
Make the action work before adding a microphone
- Complete the Home Assistant helper exercise and keep the Demo alert helper. Temporarily disable those practice automations so they cannot change it during this experiment.
- In Home Assistant’s voice-assistant settings, expose only Demo alert to Assist. Give it a short, distinct name and confirm your assistant uses the Home Assistant conversation agent.
- Open Assist’s text interface and type “turn on demo alert.” Check the actual helper state on the dashboard.
- Type “turn off demo alert,” then deliberately use an unknown name. The unknown request should not operate some other device.
- If text fails, check entity exposure, naming, language, and the conversation agent before troubleshooting microphones.
Add local speech in a separate step
On a supported Home Assistant OS setup, follow the local Assist guide to install a speech recognizer and Piper for spoken responses. Speech-to-Phrase supports a constrained command vocabulary; Whisper supports broader speech but needs more compute. Choose them based on the commands and host you have, rather than buying a satellite first.
Repeat the same on/off requests using an existing phone with the Home Assistant app. Initially use push-to-talk. Add a wake word only after capture, transcription, and action execution work reliably. Confirm that the selected recognition and synthesis services are local if local processing is your goal; a local microphone alone does not establish where processing happens.
Measure a useful result
Try ten requests from the intended location. Record the recognized words, whether the correct entity changed, and time to response. Repeat with a fan running and at a different distance. These observations show whether to fix microphone placement, names, or processing speed.
If the text is wrong, inspect the audio path and language setting. If the text is right but the action fails, inspect exposure and intent matching. If the action succeeds but the reply is silent, test the output device separately. Keep spoken control limited to reversible experiments initially; the system hearing a phrase is not proof of the speaker’s identity.