My System:
Ryzen 9 5450
16 GB Ram
RTX 3090 24 GB Ram
(2) R Pi 5
(2) Jabra 410
Environment
- Home Assistant: 2025.12.2 (Core)
- Wyoming Integration: Built-in
- Satellites: 2x Raspberry Pi 5 running Wyoming Satellite
- Wake Word: OpenWakeWord (local on each Pi, port 10400)
- STT: Wyoming Faster-Whisper (remote server, port 10300)
- TTS: Wyoming Piper (remote server, port 10200)
Architecture:
Jabra 410 USB Mic
↓
Wyoming Satellite (Pi5, port 10702)
↓
OpenWakeWord (local, port 10400) ← Audio should go here while waiting for wake word
↓ [wake word detected]
HA Wyoming Integration
↓
Whisper STT (remote)
↓
[Transcript returned to satellite]
↓
Custom orchestrator processes response
↓
Piper TTS → Audio back to satellite
The Problem
After a successful voice interaction completes, one of my satellites (sat2/Office) frequently gets stuck. The satellite service reports “Waiting for wake word” but wake word detection never triggers, even when speaking directly into the microphone.
Failure rate: Approximately 8-15 minutes after a successful interaction Affected satellite: Primarily sat2, sat1 is more stable (identical hardware and software)
Diagnostic Evidence
Using strace to monitor where the satellite sends audio chunks:
Working satellite (sat1):
sendmsg(15, ..."audio-chunk"...) → fd 15 = connection to OpenWakeWord (127.0.0.1:10400)
Broken satellite (sat2):
sendmsg(17, ..."audio-chunk"...) → fd 17 = connection to Home Assistant (10.0.0.16:58414)
The satellite’s audio routing is stuck sending to HA instead of to the local wake word service. The satellite state machine believes it’s still in “streaming to HA” mode rather than “waiting for wake word” mode.
Socket verification on broken sat2:
bash
$ sudo ss -anp | grep 1475
tcp ESTAB 10.0.0.151:10702 10.0.0.16:58414 users:(("python",pid=1475,fd=17)) # HA connection
tcp ESTAB 127.0.0.1:41656 127.0.0.1:10400 users:(("python",pid=1475,fd=15)) # Wake word connection (exists but unused)
Both connections exist, but audio goes to the wrong one.
Service Status When Broken
All services report healthy:
wyoming-satellite.service- active (running)wyoming-openwakeword.service- active (running)- Connections established
- arecord process running
- Last log entry: “Waiting for wake word” (hours ago)
What Does NOT Fix It
Restarting wyoming-satellite service- Restarting wyoming-openwakeword service
- Rebooting the satellite Pi
- Reloading the Wyoming integration in HA
- Deleting and re-adding the satellite device in HA
What DOES Fix It
Full Home Assistant reboot
Reproduction
- Set up Wyoming satellite with local OpenWakeWord
- Connect to Home Assistant Wyoming integration
- Successfully complete a voice interaction (wake word → STT → response)
- Wait 8-15 minutes
- Attempt another wake word trigger - fails
- Verify with strace that audio is going to HA connection instead of wake word connection
Hypothesis
The Wyoming integration is not properly releasing the satellite back to wake word detection mode after the voice pipeline completes. Something in HA’s state management keeps the satellite in “streaming” mode indefinitely.
Additional Notes
- Both satellites run identical software (same satellite.py, same service files)
- sat1 is more stable than sat2, suggesting possible race condition or connection order issue
- The satellite code itself appears correct - it’s HA that’s holding the connection in the wrong state
- Custom modifications to satellite.py for speaker identification and direct orchestrator calls, but the audio routing issue occurs at the Wyoming protocol level before any custom code runs
Questions
- Is there a way to force the Wyoming integration to release a satellite back to wake word mode?
- Are there debug logs I can enable in HA to see why the pipeline isn’t completing properly?
- Has anyone else experienced this with multiple Wyoming satellites?
Happy to provide additional logs or diagnostics. Thanks for any help!