Using Wake Word freezes HA installation

Hi everyone,

I’m using HAOS 16.2 on a VM on Proxmox.

I’m also using the voice functionality, with the " Wyoming Protocol" integration, with openWakeWord, Piper, Speech-to-Phrase and Whisper, in combination with a ESP32-S3-Box hardware.

This has been working, quite well and without any problems for quite a while.

However, since a few days, I’m having the following issue: when I say the wake word:

  • The ESP32-S3-Box does not indicate it picked up the wake word (normally the screen will change to indicate it’s listening to a command)
  • The HA installation goes to 100% cpu (well 50% cpu since it has 2 cores assigned in the VM, so 1 core goes to 100%)
  • The entire HA installation freezes, the web interface stops showing anything. I can still open a console though.
  • The only way to restore functionality is to restart the host. Then HA will work fine again, until I use the wake word

I had a look at the different log files, but nothing really jumps out. HA is also not reporting any available updates.

EDIT: When it happens, I see this process responsible for the issue (I used ‘top’ from the command line):

Can anyone assist me in pinpointing the source of this problem, and/or help me solve it?

Thank you in advance,
Wim

Look at HA logs

What happened before crash? What was running? Look at log before restart home-assistant.log.1

What happened before crash?

  • I say the wake word

What was running?

  • My regular HA installation. All running fine, as it has been for many months.

Look at log before restart home-assistant.log.1

  • No errors or warnings, nothing special jumps out

It “feels” as if the ESP32-Box registers the wakeword, then contacts HA to get some info or something, and then the HA install goes to 100% cpu, never replies to the ESP32-Box, and just freezes. It doesn’t really “crash”, it’s just stuck at full cpu forever.

I added the process that is getting stuck in my initial post.

doesnt need to be special. It will look normal.
question is what was running when CPU spiked.

HA as a whole doesnt just burn CPU so not likely an base HA issue. It could be addon. so the thing to look for is which addon is causng the problem. the python process you see running is the HA software running. that’s normal. The addons are included in that I believe and are likely the issue.

Are you running LLM addon? that would start with voice assistant.

Thanks for trying to help!

I’m sure it’s related to using the wake word. The satellite device hears the wake word, then talks to the HA instance, and this makes the HA instance go to 100% and never reply to the satellite, since I suppose it’s in an endless loop somewhere.

Normal behaviour was (until a few days ago): The satellite device hears the wake word, then talks to the HA instance, then gets some reply from HA, and then shows on its screen it’s listening for a command.

I’m suspecting as you mentioned it’s linked to one of the “Voice” addons, of which I have installed (as per the documentation) openWakeWord, Piper, Speech-to-Phrase and Whisper.

I have no idea on how to troubleshoot this further, any help would be appreciated.

For completeness sake, here are all the addons I have installed:

Thanks in advance

Disable the addon and test

Can you use nabu casa for voice to test?

The voice devices can run wake word so you can enable that. What version HA?

Disable the addon and test

  • I disabled all 4 voice related addons (openWakeWord, Speech-to-Phrase, Piper, Whisper), but result remains the same. When I say the wake word → HA 100% cpu and unresponsive. The satellite will indicate after a while the HA is unreachable, the web interface stops working at all.

Can you use nabu casa for voice to test?

  • I’m not sure what you mean by that?

The voice devices can run wake word so you can enable that.

  • I already set it up so the device will detect the wake word locally (it is not using HA for that). However, it seems that when the device detects the wake word, there is still some communication to/from HA before it starts accepting commands. It’s this communication that is causing the endless 100% cpu.

Version of HA

  • The problem started a few days ago, when i was on core 2025.10.3. In the meantime I’m on 2025.10.4 (same issue). I’m on HAOS 16.2.

Thank you so much for this thread. I had exactly the same issue, but it grew into a bigger problem today.

My ESP32-S3-BOX-3s have not been responding to commands this week and I have been having some odd behaviour from HA. I sat down to try and root cause this earlier. I was narrowing into the voice assistant; as soon as the wake word was uttered, the GUI would immediately stop working and I saw high CPU usage.

After a couple of reboots of the VM while working on this, my entire instance stopped working. I have been trying for hours to figure out why I could not get the GUI to load at all (through all sorts of reboots and even a restoration of a backup to a fresh VM). There was no errors in the logs and the add-ons (SSH, AdGuard, etc) were all up and working fine. I tried using the CLI, but a lot of the commands were blocked as HA seemed to be perpetually starting up.

This thread gave me a thought; I have just been around the house and pulled the power on all of the ESP32-S3-BOX3 devices and now HA is back to normal (phew).

I have HAOS 16.2, performed the 2025.10.4 core update yesterday and it is installed as a VM in Unraid. I have the openWakeWord add-on (amongst others), but use the HA Cloud for TTS.

Have been working again this morning to try and resolve this.

Plugged one ESP32-S3-BOX3 device back in, updated it to 2025.10.3 FW (latest ESPHome) and attempted the wake word again with the same result. Could not see any relevant errors in the logs, the same as yesterday.

Digging around looking at the configuration of everything, I noticed that the ‘Wake word’ entity was disabled for these devices. Enabling this again appears to have resolved the issue for me.

Happy to hear you solved it for you, unfortunately the circled option in your post was grayed out in my setup (I have no idea why).

Just for giggles, I changed the option below, “Wake Word engine location” from ‘on device’ to ‘in Home Assistant’, which immediately triggered the issue (100% cpu, interface unresponsive/down). What started just for giggles quickly turned into a nightmare, as I could not revert this change. For me to be able to revert it, the device needs to be on/connected, but as soon it connects now, HA goes to 100% and unresponsive.

I decided to then remove the device from HA, reflash it with the latest firmware, and re-add it to HA. This took me the major part of the afternoon, as it required several retries (both for the firmware flashing, and the setting up in HA), with behaviour I can’t explain (for example in one try it added the device to HA, but it didn’t show up under ‘assist device’, in another try I managed to add it to HA, but all entities (such as Wake Word) were grayed out, and listed as ‘disabled by device’).

After several retries and then some more, now it seems to be working as before and stable.

I don’t really want to mark this as ‘solution’ as I don’t know what caused it, and I don’t really know what fixed it. Just wanted to share my experience in case others would encounter the same issue.

Post the yaml for your Voice Assistant. Did you make any modifications from defaults?

I’m not sure it’s this what you mean (if not, please let me know where I can find the yaml you’re referring to, I’m not that experienced with HA)…

I only added the last line (as per the documentation) so it connects to a hidden wifi (which works fine). All the rest are defaults.

/homeassistant/esphome/esp32-s3-box-3-******.yaml

substitutions:
  name: esp32-s3-box-3-******
  friendly_name: ESP32 S3 Box 3
packages:
  esphome.voice-assistant: github://esphome/wake-word-voice-assistants/esp32-s3-box-3/esp32-s3-box-3.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}
api:
  encryption:
    key: ***


wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: True