M5Stack Atom Echo: Microphone setup fails after one detection when using wake word detection in HA

[ezcGman]

Hey there,

this is basically a duplicate of #74, #85, #89, #90 & #91, but I wanted to give some more context that I've found out.

Issue:
When the "wake word detection engine" is set to "in Home Assistant", the detection only works once, then never responds again. So you can use the wake word, let it do something and after that it will never respond again to the wake word. You have to power cycle it, or press the top button on the Echo to make it work again.
And yes, this happens with and without openWakeWord.

Versions I've tried and all have the same issue:

• Flashed from here: https://www.home-assistant.io/voice_control/thirteen-usd-voice-remote/
• Flashed from here: https://esphome.io/projects/
• And currently using this config (after adopting it in ESPHome Builder) with some minor adjustments: https://github.com/esphome/wake-word-voice-assistants/blob/main/m5stack-atom-echo/m5stack-atom-echo.yaml

I made some minor adjustments (different wake word, debug logging and fast_connect, as my Wi-Fi is hidden):

substitutions:
  name: esph-voice-living-room
  friendly_name: Voice Assistant Living Room
  ap_name: "Voice LR Fallback AP"
  ap_ip: 192.168.42.1
  micro_wake_word_model: hey_jarvis
packages:
  m5stack.atom-echo-wake-word-voice-assistant: github://esphome/wake-word-voice-assistants/m5stack-atom-echo/m5stack-atom-echo.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}
api:
  encryption:
    key: xxx

logger:
  level: debug

wifi:
  ssid: !secret wifi_ssid_iot
  password: !secret wifi_password_iot
  fast_connect: true
  reboot_timeout: 3min

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: ${ap_name}
    password: !secret wifi_password_ap
    manual_ip:
      static_ip: ${ap_ip}
      gateway: ${ap_ip}
      subnet: 255.255.255.0

I think the issue is not on the device, but inside HA. After enabling debug output, I can see it going through the states and after using a wake word once, it ends up in "IDLE" after going through "STOP_MICROPHONE".
So deeper look:
This is the flow of states after boot up and how it will respond to the wake word:

[09:50:34][D][voice_assistant:506]: State changed from IDLE to START_MICROPHONE
[09:50:34][D][voice_assistant:512]: Desired state set to START_PIPELINE
[09:50:34][D][voice_assistant:506]: State changed from START_MICROPHONE to STARTING_MICROPHONE
[09:50:34][D][voice_assistant:506]: State changed from STARTING_MICROPHONE to START_PIPELINE
[09:50:34][D][voice_assistant:506]: State changed from START_PIPELINE to STARTING_PIPELINE
[09:50:34][D][voice_assistant:506]: State changed from STARTING_PIPELINE to STREAMING_MICROPHONE
[09:50:34][D][voice_assistant:512]: Desired state set to STREAMING_MICROPHONE

This is the flow of states when it detects the wake word, responds and then stops working:

[09:52:07][D][voice_assistant:506]: State changed from STREAMING_MICROPHONE to STOP_MICROPHONE
[09:52:07][D][voice_assistant:512]: Desired state set to AWAITING_RESPONSE
[09:52:07][D][voice_assistant:506]: State changed from STOP_MICROPHONE to STOPPING_MICROPHONE
[09:52:07][D][voice_assistant:506]: State changed from STOPPING_MICROPHONE to AWAITING_RESPONSE
[09:52:12][D][voice_assistant:506]: State changed from AWAITING_RESPONSE to STREAMING_RESPONSE
[09:52:12][D][voice_assistant:512]: Desired state set to STREAMING_RESPONSE
[09:52:13][D][voice_assistant:506]: State changed from STREAMING_RESPONSE to IDLE
[09:52:13][D][voice_assistant:512]: Desired state set to IDLE
[09:52:13][D][voice_assistant:506]: State changed from IDLE to START_MICROPHONE
[09:52:13][D][voice_assistant:512]: Desired state set to START_PIPELINE
[09:52:13][D][voice_assistant:506]: State changed from START_MICROPHONE to STARTING_MICROPHONE
[09:52:13][D][voice_assistant:506]: State changed from STARTING_MICROPHONE to START_PIPELINE
[09:52:13][D][voice_assistant:506]: State changed from START_PIPELINE to STOP_MICROPHONE
[09:52:13][D][voice_assistant:512]: Desired state set to IDLE
[09:52:13][D][voice_assistant:506]: State changed from STOP_MICROPHONE to STOPPING_MICROPHONE
[09:52:13][D][voice_assistant:506]: State changed from STOPPING_MICROPHONE to IDLE

Note that it goes from START_PIPELINE to STOP_MICROPHONE and sets the desired state to IDLE. So that is the reason why it doesn't respond: The microphone got stopped. There is only one more log that could hint something, but not sure if that is related, I doubt it:

[...]
[09:52:13][D][voice_assistant:506]: State changed from START_MICROPHONE to STARTING_MICROPHONE
[09:52:13][D][esp-idf:000][speaker_task]: I (109592) I2S: DMA queue destroyed

[09:52:13][D][esp-idf:000]: I (109598) I2S: DMA Malloc info, datalen=blocksize=1024, dma_buf_count=4

[09:52:13][D][i2s_audio.speaker:129]: Stopped Speaker
[09:52:13][D][voice_assistant:506]: State changed from STARTING_MICROPHONE to START_PIPELINE
[...]

Looking at the code, the only place where a transition to STOP_MICROPHONE with a desired state of IDLE happens, is in failed_to_start(): https://github.com/esphome/esphome/blob/58fe8b39b20c8fe9767107a6136ca30873b82056/esphome/components/voice_assistant/voice_assistant.cpp#L515C22-L515C37
The only place I found failed_to_start() being called is here: https://github.com/esphome/esphome/blob/58fe8b39b20c8fe9767107a6136ca30873b82056/esphome/components/api/api_connection.cpp#L1486
But there is no logging, nothing. So I tried looking inside the HA logs (incl. Whisper) but again nothing: I even set HAs global logs to "debug" and still nothing. Or at least I couldn't find anything that remotely looks like something.

So I guess something is broken inside HA that makes the Echo failing to start the microphone after one use.
Let me know how I can help any further!

Greetings,

Andy!

[BigBobbas]

Hi,
I've just tested my edited verson of the stock firmware and I am able to repeatedly issue wake words with no issue ( tested with openwakeword) . If you wanted to try it feel free https://github.com/BigBobbas/esphome_firmware/blob/main/M5%20Stack%20Atom%20Echo/M5%20Stack%20Atom%20Echo%20180320125.yaml
If this works I can submit a PR. This also adds a 3rd option to the "wake word engine location" of "disabled" for users that only wish to use the device with the front button to issue commands.
Cheers
Rob

[fishbone222]

After 2025.x our M5Stack Atom Echo was literal dead as well.
After trying a lot of different yaml's including the one of @BigBobbas I tried again with the one from github and the Echo is working again as expected.

I'm on ESPHome 2025.3.3

I did "clean build files" and "install".
Then (this was important in our case!) I changed the local network domain under Settings -> System -> Network to use just http not https, I deleted the Echo, readopted it AND executed the wizzard under Settings -> Devices and Services -> ESPHome -> Echo Device -> "three dots" -> Set up voice assistant

I reference the git yaml in my Echo's yaml instead of copying it over :
packages: m5stack.atom-echo-wake-word-voice-assistant: github://esphome/wake-word-voice-assistants/m5stack-atom-echo/m5stack-atom-echo.yaml@main