Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inactivity Timeout Needed After Wake Word Detection ? #237

Open
lmsanch opened this issue Nov 7, 2024 · 0 comments
Open

Inactivity Timeout Needed After Wake Word Detection ? #237

lmsanch opened this issue Nov 7, 2024 · 0 comments

Comments

@lmsanch
Copy link

lmsanch commented Nov 7, 2024

Description:

When the wyoming-satellite service detects the wake word ("ok_nabu"), the system correctly transitions the LED to a "listening" or "command-ready" state. However, if no command follows the wake word within a reasonable time (e.g., 5-10 seconds), the system remains indefinitely in the listening state with LEDs in the active color. This can lead to a situation where the microphone and LEDs are effectively "stuck," requiring manual intervention to reset the state.

Expected Behavior:

After the wake word is detected, if no additional command is received within a defined timeout period:

The LEDs should revert to an idle state.
Optionally, the wyoming-satellite service could automatically restart to reset the microphone and LEDs, readying the system for future commands.

Observed Behavior:

The LEDs remain in the active "listening" state indefinitely when no command follows the wake word.
The microphone does not revert to idle and appears to be "stuck," making it necessary to manually restart the wyoming-satellite service.

Steps to Reproduce:

Activate the system and speak the wake word ("ok_nabu").
Do not follow up with any further command.
Observe that the system remains in the active state without reverting to idle.

Proposed Solution:

Implement an inactivity timeout after the wake word detection. If no command is received within the set timeout (e.g., 5-10 seconds), or handle this with HomeAssistant?

The LEDs should change back to the idle state.
Optionally, restart the wyoming-satellite service to reset the microphone and other related states.

Environment:

cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: seeed2micvoicec [seeed-2mic-voicecard], device 0: bcm2835-i2s-wm8960-hifi wm8960-hifi-0 [bcm2835-i2s-wm8960-hifi wm8960-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0

id: satellite
description: Computer
product: Raspberry Pi Zero 2 W Rev 1.0
serial: 0000000095fc6234
width: 64 bits
capabilities: smp cp15_barrier setend swp tagged_addr_disabled

Additional Context:

This feature would prevent the system from remaining in an active state indefinitely and ensure that it is always ready to respond to future wake word triggers. I am planning to write a service to "chat" to Perplexity API and I am nit sure if HomeAssitant is needed or ads a level of complication for me (new to it), but it would be nice to have so I can also query all my home devices.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant