Play a local mp3 file on Alexa Echo dot

@aasimenator @Schmandre I read this thread thoroughly and had the same issues as other contributors.

Converting the mp3s using the method below solved the issue

ffmpeg -y -i az.mp3 -ac 2 -codec:a libmp3lame -b:a 48k -ar 16000 az-converted.mp3
1 Like

Thanks for reply. Used the command, still “simon says eu skill error”

This is my config:

service: notify.alexa_media
data:
  message: <audio src="http://192.168.0.1:8123/local/Gong-converted.mp3"/>
  target: media_player.andres_echo_dot
  data:
    type: tts

Any ideas?

Hi,

You’re using a local source file, AWS cloud has no way to access it

I have my mp3 hosted publicly on SSL eg

message: "<audio src='https://foobar.org.uk/mp3/az-converted.mp3' />"

eg

service: notify.alexa_media
data:
  message: "<audio src='https://automatiseer.eu/audio/kleine-wasjes-grote-wasjes.mp3' />"
  target: 
    - media_player.my_echo_dot
  data:
    type: tts

Thanks for the info ^^ I changed the whole thing to an external link. Unfortunately with the same error message. If I try to call up the URL externally, this works without any problems. However, as soon as I try to play it via the echo, I get the known error.

However, if I use your link, I hear the correct sound. Just yours ^^

What else am I doing wrong here?

As I said. The sound is now externally accessible. Tested via mobile phone without WLAN

service: notify.alexa_media
data:
  message: <audio src='https://push.schmandre.de/vAye3/tAMipEyE54.mp3/raw'/>
  target: media_player.andres_echo_dot
  data:
    type: tts

If I use

service: notify.alexa_media
data:
  message: <audio src='https://automatiseer.eu/audio/kleine-wasjes-grote-wasjes.mp3'/>
  target: media_player.andres_echo_dot
  data:
    type: tts

anything is working.

Do I have to release any special ports?

If needs needs to be a direct link to the file not a webpage

Wrong content type

1 Like

Okay. I have now adjusted the link and uploaded the file. The error still exists, but the feedback was correct.

cmd_nnsRbZkiXD

Is it possible that the whole thing doesn’t work behind a reverse proxy? For test purposes, I uploaded the mp3 to a public mp3 hoster. If I use the link of the external service provider, it works, if I use my link, it doesn’t work… I can’t understand why at the moment.

I’ll join here, too…

I also try (almost) in vain to play my mp3s on my echo.
I haven’t touched lambda.py yet.

I have a demo mp3 that I converted with jovo.
with the following code I can play them on my echo:

service: notify.alexa_media
data:
  message: <audio src='https://kt-montage.com/files/smarthomeyourself/mp3/001.mp3'/>
  data:
    type: tts
  target: media_player.nathalies_echo_dot

this works!

but unfortunately somehow ONLY from my server.
now i’ve tried to upload the whole thing to amazons3, for example, but then i get the error again: simon says eu skill…


edit:
I uploaded the same file to amazon s3, for example.
but is not played.
I can not understand that unfortunately

message: <audio src='https://ktamazons3.s3.eu-central-1.amazonaws.com/smarthomeyourself/001.mp3'/>

it is absolutely the same file. just on a different server.
a user from our discord had also tried to upload this file to his server (one.com), but it didn’t work there either?!?

it would be really nice if we found a solution here that works for everyone.

I’m in the same boat. Don’t think this is proxy related but more to do with LE certificates as mentioned by @Goldwing . I can see in my proxy logs the client is closing the connection during SSL handshake indicating it does not like something related to LE certificate. Maybe it has something to do with the R3 intermediate certificate expiration last September 29th 2021 that is known to cause issues for some clients especially IoT devices.

1 Like

Interestingly even the Jovo mp3 files do not work for me (with or without double quotes), I created a couple (if someone can test them in the next 24h would be great):

  message: <audio src='https://v3.jovo.tech/audio/tN8qYny3-alarm1.mp3'/>
  message: "<audio src='https://v3.jovo.tech/audio/KDCpCylI-alarm1.mp3'/>"

but this one does:

Go figure :confused:

Ok this explains it:

Certificate chain
 0 s:CN = v3.jovo.tech
   i:C = US, O = Let's Encrypt, CN = R3

Jovo uses LE cert as well signed by the expired R3 so no wonder it is not working.

UPDATE: Ok, solved my problem and now I can play mp3 hosted locally on my hassio. After taking a tcpdump and looking at the failed handshake with wireshark I could see Alexa using only CBC ciphersuites in the Client Helo message:

Adding one of them, like ECDHE-RSA-AES128-CBC-SHA256 to my SSLCipherSuite stanza on the proxy solved the problem for me. Of course the CBC ciphersuites are not recommended for use these days due to their weaknesses (tls - Why does SSL Labs now consider CBC suites weak? - Information Security Stack Exchange) but there you go, alexa is still using them.

1 Like

Playing mp3 and many other files over Amazon Alexa is a nightmare for me, I found an easy solution using Volumio.
I use my old Raspberry pi 3 B for Volumio server and share music to Amazon Alexa over Bluetooth 5.0 RX TX transmitter and working very good so far.

image

amazing! I have to deal with that first… I’ve never done that before ^^

@Olti , this is of course also a solution! thanks for the hint. But before I get new hardware, I’ll try a few other options =)
Maybe PLEX is still a way?!

1 Like

@ [MrThiemann]

Volumio was easier for me but maybe also Plex can work on same way.

This is what worked for me. I’ve been fighting with this for two days and am ready to pull hair out. Can’t play anything at jovo or locally (using DuckDNS and letsencrypt as well). I would prefer to host the files locally but for now backblaze is a good solution. Thanks!

1 Like

Good evening everyone,

The whole thing has given me the decisive food for thought and also solved my problem. After I made the following SSL settings, everything worked again

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384";
ssl_ecdh_curve X25519:secp521r1:prime256v1:secp384r1;

Found your video from here and got it working. Had a look at your other videos and there was so much stuff you explained that was on my list I’m currently working my way through the lot! Thanks

Hi
Could you please share how you updated it ?
I’m new to this.
Thanks

:face_with_monocle:
I am using nginx-proxy-manager and autogenerated Letsencrypt certificates (included) to access my local home assistant.
How can I add

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384";
ssl_ecdh_curve X25519:secp521r1:prime256v1:secp384r1;

To the nginx proxy manager?

2 Likes

Couple of days ago i move my HA also behind a nginx-proxy-manager.
Here is my setup, took me a bit of trail and error, but the media works on my Echo’s.
I did NOT change anything in my HA config.

afbeelding

In NPM it uses a Letsencrypt certificate, but automatiseer.eu still uses the cloudflare certificate.