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

Wake word selection does not change if updated in home assistant's Assist configuration #107

Closed
khalob opened this issue Feb 11, 2024 · 4 comments · May be fixed by #111
Closed

Wake word selection does not change if updated in home assistant's Assist configuration #107

khalob opened this issue Feb 11, 2024 · 4 comments · May be fixed by #111

Comments

@khalob
Copy link

khalob commented Feb 11, 2024

I may be misunderstanding what is happening but, I am finding that:

  1. Wake word names need to be passed in using --wake-word-name
  2. If you don't supply a value all default wake words are used (multiple words)?
  3. If you want to only have one wake word at a time, you have to supply that in the wyoming-satellite script. As a byproduct, changing the Assist configuration's wakeword value does nothing.
    image
  4. If you are using openWakeWord in Home Assistant, your custom wake words will only work if specified in the --wake-word-name value of the wyoming-satellite script.
@llluis
Copy link
Contributor

llluis commented Feb 12, 2024

The satellite can be configured as one (and only one) of the 3 following types (depending on parameters in the command line):

  1. Always streaming
  2. V(oice) A(activity) D(etection)
  3. Local wake word

For 1 and 2, wake word is configured in Home Assistant as per your screenshot.
For 3, configuration in Home Assistant is ignored (irrelevant) and wake word selection is done by the parameter in the command line. It's dependent on the service configuration in openwakeword and the satellite itself.

Regarding your points:

  1. Yes, if satellite configured as "type 3". --wake-word-name is ignored in types 1 and 2.
  2. Multiple words are not supported. Again, in types 1 and 2, you don't need to supply a value in command line and HA is used. In type 3, if wake word is not supplied, the satellite won't work.
  3. and 4. You always have only one wake word at a time. It all depends who is doing the wake word detection, HA or the satellite. If HA, you have to install the custom wake word in HA, if the satellite, it's local.

@khalob
Copy link
Author

khalob commented Feb 13, 2024

@llluis Ahh I see I appreciate the clear feedback, thank you! At some point I got it responding to multiple wakewords.. not sure how to reproduce it at this point though. I'll post steps if I figure it out.

My goal is to have #2 VAD. However, passing "--vad" in as a parameter for Docker results in some issues. Note, these issues do not occur if I do not pass this "--vad" parameter.

image

Any idea what could be causing that? Do I even need to pass in "--vad" if I'm supplying a "--wake-uri" already? This is running on a pi 4.

@llluis
Copy link
Contributor

llluis commented Feb 13, 2024

If you want to have VAD, you must supply --vad and must not supply --wake-uri as the satellite will start streaming to home assistant when it detects voice activity and it will be home assistant who will do wake word detection.

I never ran it in Docker, but I see in your log you seem to be missing the silerovad requirement.
I quick checked the Dockerfile and it seem to be missing some requirements files which were split a while ago.
Can you please replace the contents of the requirements.txt file, rebuild your docker and report back if it works?

wyoming==1.5.2
zeroconf==0.88.0
pyring-buffer==1.0.0
webrtc-noise-gain==1.2.3
pysilero-vad==1.0.0

If it works, there will be some rework to be done in the setup script to correct everything.

@khalob
Copy link
Author

khalob commented Feb 13, 2024

Yep, that works. VAD isn't crashing anymore and yes it changes dynamically based on the Assist configuration in Home Assistant. Thanks!

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

Successfully merging a pull request may close this issue.

2 participants