M5 Atom Echo - crash on Announce #71
Comments
|
Full cycle from boot to
Checked that the URL is correct and it plays in my browser without issue (using correct duckdns url not xxx'd out). |
|
I can confirm the same thing: LED turns blue, then a hard crash/reboot Edit: I'm noticing that all of the reports, including mine, are using https. I wonder if that's the root of the problem. |
I thought similar but it can't be local setup as I use 'home built' voice assistant running arduino based esphome and re-speaker using IDF neither have any issue with playing from a tls source point. Adding http_request: to the config doesn't help at all I notice that My home brew uses mp3 and the respeaker FLAC. Interestingly the re-speaker uses FLAC due to it low resource usage . probably worthe looking at the re-speaker code from formatBCE as it seems very close to the VA developers code base and does work :) Here is my home brew running the same sequence as my M5 example above (without crashing) , Yes its seriously under resourced but is only used to run some night sequences from saying 'goodnight' so it only needs to manage 'Done'. [14:22:58][D][voice_assistant:642]: Event Type: 8 |
|
I am seeing the same thing after the latest update. I can get one response out of it before it crashes and resets itself. any idea how to roll the firmware back? |
The original project should still be the old build (was yesterday). So restart from the project page. If not, then in the closed issue m5 won't compile I changed the code to use the speaker rather than media player. Drop that into you m5 , make any changes needed to localise ( API keys, WiFi etc) and compile. |
|
I can confirm that the issue only occurs when using https. |
|
Same this for me, crash on announce |
|
Just got an M5 Stack Atom Echo, delighted to get it setup, and are hitting the same issue. I've flashed both the bin provided through the ESPHome.io's ready-made projects page, Home Assistant's $13 voice assistant page, and rolling my own. When I begin the HA "Set up voice assistant" wizard, I get this crash on the device... And yes for HA I've set both my internet and local URL through the same https address, as I've got SSL setup in HA and not through a reverse proxy. Via my local DNS server, I've tied the local IP address of my HA machine to the public subdomain I use. Public DNS for the domain of course is tied my upstream internet IP address. 
The URL to the wav file downloads and plays just fine via my browser. Edit: I can also confirm, I don't encounter the crash if I switch HA into HTTP mode. |
|
Same issue after updating to 2025.2.1 |
|
I have the same issue, in fact I also reported it here thinking it wasn't the same because I don't experience a crash - the device throws an error because it can't access the WAV file, but nothing else happens. My certificate is generated by a local CA and not a simple self-signed one, was hoping to get the "verify_ssl: false" to work but can't figure out where to place it as every example I have found doesn't get accepted. |
|
I should have noted, my cert comes from Let's Encrypt. I tried the M5 Atom Echo media player build from the ready-made projects page, and the device will play WAV files from HA over SSL just fine. |
|
I am also using Let's Encrypt |
|
So for my situation it means that either I need a way to add my CA certificate to the store used so that it's trusted, or for the "verify_ssl: false" to be available so that it ignores the problem. Perhaps then it will be able to read the sound file but then crash out like yours are doing. |
|
I think you can add a section below where the package is imported to override configs https://esphome.io/components/http_request.html Something like this http_request:
verify_ssl: false |
I tried exactly that with 2025.2.0 and it would not compile, hence why I submitted the issue, but I now tried it again as I wanted to grab the complier error for putting here and would you believe it, the compile worked. I'm away from device at the moment so I can test actual speech, but I will do so later and report if mine now crashes like is being reported. |
This seems to fix the issue for me. I just added it at the end of the yaml file and recompiled it. (Using version 2025.2.1 of esphome.) |
|
Unfortunately not for me, I still get: I made sure to clean the build files beforehand just to be sure, and confirmed the WAV could be played from another machine. |
This also fixed it for me. It wasn't crashing, but there was no voice output until I made this addition. |
|
@cineafx @josephperry could you share your yaml file so I can compare it to mine? I must have something else that is blocking the command or it simply doesn't work even with my certificate. |
Sure: substitutions:
name: m5stack-atom-echo-fde114
friendly_name: M5Stack Atom Echo fde114
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: XXXXXXXX
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
http_request:
verify_ssl: false |
|
Thanks @cineafx pretty much what I have, so it got me thinking about anything else that has recently changed. I recalled updating my proxy server but that made no sense because internally I should be talking directly to my HA server. Appears I'm not, and the change to the proxy included fixing SSL web connections to TLS1.3 - so for the internal proxy I set it to TLS1.2+ and bang, it started working. So add another limitation: seems it does not support TLS1.3 No crashing but I do now hear the voice response, but it's extremely low volume and barely audible. It was perfectly loud before all the problems, so something else I need to look into now. |
Due to the new media player usage there is now a volume control: |
|
@cineafx you're a superstar, had not spotted that and works a treat. I was recalling this happening when I first got the M5AE last year and was going through old files to see if I had added anything to the yaml at the time. |
|
I was also able to get it working with: Though, it seems odd because I've got a valid Let's Encrypt TLS cert, so it should verify. My reverse proxy that hosts the cert supports TLSv1.2, so if v1.3 is also an issue I luckily didn't hit that. |
|
Yeah same here. Even though I have Let's Encrypt certificates, turning off SSL verify worked. This wasn't a problem for me until a recent update. |
|
Another confirmation that disabling TLS verification works as a stopgap with a Let's Encrypt cert and TLS 1.3. I'd suggest updating the ticket description to make it more specific to this issue. |
I have this problem on home assistant, forgive my ignorance, but where / which file is this added to exactly? (all my config is via the UI) |
Are you running the ESPHome dashboard locally?
You should I don't think you can change it on the pre-built binaries. |
|
No, just via home assistant...., guessed as much,.,, will have to wait for an actual fix to come out. Thanks. |
|
For all with SSL/DNS/HTTP_CLIENT problem - i SOLVED this here: esphome/issues#6807. |
|
I got a Home Assistant Voice Preview Edition recently and it's connecting to my Home Assistant over https just fine. Digging into the HAVPE ESPHome config I noticed this line which is highly relevant to the errors we're seeing. If TLS 1.3 is not enabled by default on esphome that's sure to cause problems. I don't have the time to test this myself right now, but I think if you add esp32:
framework:
sdkconfig_options:
CONFIG_MBEDTLS_SSL_PROTO_TLS1_3: "y"to your configuration, it should work without the need to set |
|
I tested the The issue only seems to be with the Atom Echo. I've never had issues with my ESP32-S3-Box. |
|
Added this
Updated but still does not work for me. |
After #60 the Atom Echoes crash when Announcing.
I've test two Echoes, one setup with
esphomelocally with a yaml that includes w/ a remote_package and another setup via the ready made project on the esphome.io website. Both have the issue. Per comments on the PR it seems others are have this issue as well.The text was updated successfully, but these errors were encountered: