Took me a while to figure out why the on-device wake word was no longer working after a restart until I muted & unmuted. My understanding is that the use_wake_word config is for detecting audio with the esp-adf libraries & VAD then sending the audio data through the pipeline to be processed by openWakeWord. Unfortunately this conflicts with microWakeWord processed locally.
Seems to have been surfaced after the otherwise helpful https://github.com/esphome/firmware/pull/214. Before, the on_value automation in wake_word_engine_location would run set_use_wake_word(false) at boot when it's configured for On device detection. Now with the init_in_progress check, that doesn't run and is initially left on.
Here's a potential fix that also removes the use_wake_word config, defaulting to false to match the "On device" initial_option.
Took me a while to figure out why the on-device wake word was no longer working after a restart until I muted & unmuted. My understanding is that the
use_wake_wordconfig is for detecting audio with the esp-adf libraries & VAD then sending the audio data through the pipeline to be processed by openWakeWord. Unfortunately this conflicts with microWakeWord processed locally.Seems to have been surfaced after the otherwise helpful https://github.com/esphome/firmware/pull/214. Before, the
on_valueautomation inwake_word_engine_locationwould runset_use_wake_word(false)at boot when it's configured for On device detection. Now with theinit_in_progresscheck, that doesn't run and is initially left on.Here's a potential fix that also removes the
use_wake_wordconfig, defaulting to false to match the "On device" initial_option.May relate to https://github.com/esphome/firmware/issues/219 as well.