My Home Assistant Voice PE has just arrived, but I’m unfortunately falling at a relatively early hurdle.
It is found as a new device in HA and added. It’s on the WiFi, and I think it has done its update, then I get “hello” quickly followed by “The voice assistant is unable to connect to Home Assistant” dialog. The “Help Me” link takes me to Troubleshooting Assist - Home Assistant but everything on that page assumes it is already added as a voice assistant, but that’s not the case for me.
To sum up, it is setup as a device in the ESPHome integration, but not as a Voice Assistant. It will wake on “OK Nabu”, but doesn’t respond to any questions, not even with any sort of “I can’t contact Home Assistant” etc.
Things I’ve tried so far in various combinations:
Reloading the device from ESPHome and setting it up again
Deleting device from ESPHome and trying again from mobile
Deleting device from ESPHome and trying again from PC browser
ESPHome “configure”, “Allow the device to perform Home Assistant actions”
Factory reset by long hold on button then trying again
Updated to beta firmware (from 24.12.8 to 25.1.0)
Restart Home Assistant
When I delete the device, the hardware shows pulsing red LEDs, so it is actually aware of the connection/disconnection at some level.
I am running Home Assistant full OS install, as a VM, with its own IP.
Core 2024.12.5
Supervisor 2024.12.0
Operating System 14.1
Frontend 20241127.8
My network is Unifi.
Phone attempting onboarding (iPhone) is on same WiFi network to one adding device to. I don’t have access to an Android to try at the moment.
I’ve got the exact same problem and tried the same things to no avail
I was thinking it was related to running it in docker on my homelab, but seeing as you have the hassio install I guess that might not be the issue for me then.
The link “help me” link in the error message leads to a section indicating the issue might be the local url for home assistant. This was set incorrectly for me (auto doesn’t work for docker install) but setting it to a valid url where homeassistant can be reached on the local network didn’t fix it for me.
Other threads here indicate possible issues with TLS, but if the local url is used it’s http, not https so that shouldn’t be the case either.
Local network config was actually it for me - thank you very much Dan - hope you get yours sussed.
I had left the previous IP address for Home Assistant bare metal before I virtualised it. Corrected that, removed it from ESPHome, restarted Home Assistant and factory reset the device (don’t know if all those steps were necessary) and it added OK now!
Do you have multiple VLANs in your network?
I have separate IoT VLAN with 2,4GHz WiFi, where my Voice Assistant PE is connected.
HA server listening for the users (mobile apps) in another VLAN.
So my local URL for mobile app is NOT the same that should be used by HAVAPE.
Does anyone know how to specify the HA local URL for Voice Assistant only?
I’ve “took control” by connecting it directly to ESP Home, but there was no URL in the (default) config file.
Managed to find the correct installer for the Voice PE here: Home Assistant Voice PE so I’ve unbricked the device and i’m back to where I started, but now with logs:
[13:40:22][D][micro_wake_word:379]: Starting wake word detection
[13:40:22][D][light:036]: 'voice_assistant_leds' Setting:
[13:40:22][D][light:047]: State: OFF
[13:40:22][D][light:109]: Effect: 'None'
[13:40:22][D][i2s_audio.microphone:377]: Starting I2S Audio Microphne
[13:40:22][D][i2s_audio.microphone:381]: Started I2S Audio Microphone
[13:40:22][D][micro_wake_word:417]: State changed from IDLE to DETECTING_WAKE_WORD
[13:40:25][D][light:036]: 'voice_assistant_leds' Setting:
[13:40:25][D][light:047]: State: ON
[13:40:25][D][light:051]: Brightness: 66%
[13:40:25][D][light:109]: Effect: 'Replying'
[13:40:25][D][media_player:080]: 'Media Player' - Setting
[13:40:25][D][media_player:087]: Media URL: http://192.168.1.67:8123/api/esphome/ffmpeg_proxy/a444e7685385ea130f4b9516893f4876/DkLnEZjm6-KPrg6XM2R-nQ.flac
[13:40:25][D][media_player:093]: Announcement: yes
[13:40:25][D][voice_assistant:515]: State changed from IDLE to STREAMING_RESPONSE
[13:40:25][D][voice_assistant:522]: Desired state set to STREAMING_RESPONSE
[13:40:25][D][ring_buffer:034]: Created ring buffer with size 48000
[13:40:25][D][ring_buffer:034]: Created ring buffer with size 48000
[13:40:25][D][ring_buffer:034]: Created ring buffer with size 65536
[13:40:25][D][ring_buffer:034]: Created ring buffer with size 65536
[13:40:25][D][power_supply:033]: Enabling power supply.
[13:40:25][D][nabu_media_player.pipeline:173]: Reading FLAC file type
[13:40:30][E][nabu_media_player:305]: The announcement pipeline's file reader encountered an error.
[13:40:30][D][voice_assistant:515]: State changed from STREAMING_RESPONSE to IDLE
[13:40:30][D][voice_assistant:522]: Desired state set to IDLE
[13:40:30][D][light:036]: 'voice_assistant_leds' Setting:
[13:40:30][D][light:047]: State: OFF
[13:40:30][D][light:109]: Effect: 'None'
[13:40:40][D][power_supply:048]: Disabling power supply.
Nothing indicating an actual connection issue there… But trying to download the requested URL manually gives a 200 response code with a 0 byte response body. Feels like some timeout somewhere casue the 200 response code is returned immediately but then the it takes pretty much exactly 5 seconds before the connection is closed with 0 bytes body.
gnux@VRRR:~$ time curl -vvv http://192.168.1.67:8123/api/esphome/ffmpeg_proxy/a444e7685385ea130f4b9516893f4876/DkLnEZjm6
-KPrg6XM2R-nQ.flac
* Trying 192.168.1.67:8123...
* Connected to 192.168.1.67 (192.168.1.67) port 8123 (#0)
> GET /api/esphome/ffmpeg_proxy/a444e7685385ea130f4b9516893f4876/DkLnEZjm6-KPrg6XM2R-nQ.flac HTTP/1.1
> Host: 192.168.1.67:8123
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Content-Type: application/octet-stream
< Date: Mon, 06 Jan 2025 12:56:32 GMT
< Server: Python/3.13 aiohttp/3.11.11
<
* Connection #0 to host 192.168.1.67 left intact
real 0m5.052s
user 0m0.003s
sys 0m0.000s
I ran into this issue as well because I run Home Assistant as a container in a k3s cluster.
As suggested in this comment, the fix was indeed in Home Assistant’s local network settings, but the fix was different for my situation.
Since I run Home Assistant in Kubernetes, by default the “Automatic” setting for the local network was using the Pod IP, which for me is not an IP address that is routable from devices on my local network.
I actually had to create a static LAN IP for Home Assistant (I used a MetalLB service), disable the “Automatic” local network settings, and manually set that static LAN IP.
Might be a niche case, but hopefully someone else with this issue will stumble on this answer!
This (alex.thompson’s Kubernetes install) was the same situation for my HA install, except Home Assistant is running in a Docker container with bridge networking. The “automatic” local network link in Home Assistant Companion App was populated with the container’s non-routable IP. I entered the container’s LAN IP and it went easily from there!
Tried this didn’t work. So if you thought your device was bricked, you have to hold down button before you plug in the voice pe then connect using the link
I had the same issue. But the for the Home Assistant URL I ended up setting a dns resolver with pfsense to point to an internal url that redirects to the ip address of my home assistant server. The local I still have my ip listed. But above that is where I put the internal url.
I had this issue with HA in a container, and fixed it by changing the URL in HA UI->Settings->System->Network.
Instead of the automatic “Home Assistant URL”, which was defaulting to the Docker VLAN one with the default 8123 port, I changed it to the host IP address with the host bound port, which is 30103, the port TrueNAS Scale binds to the internal 8123 port in docker. Basically I changed it to the address I access the WebUI through.
Makes sense now that I think of it, since the HA container has no way of knowing which host IP and port its internal port is bound to, and the VPE has no way of getting into the docker VLAN except through the externally bound port. Easy to avoid if you bind 8123:8132 during deployment, instead of 30103:8123 as TrueNAS did for me.
