I haven’t yet, primiary because I wanted to avoid install Nginx to keep services running on HA as lean as possible.
Does anyone know why this problem has occurred all of a sudden? What has changed to break the SONOS TTS feature?
I haven’t yet, primiary because I wanted to avoid install Nginx to keep services running on HA as lean as possible.
Does anyone know why this problem has occurred all of a sudden? What has changed to break the SONOS TTS feature?
I gave up and installed Nginx and added the necessary lines to the http block within the config file. Still didn’t work for me. Will continue researching the problem and try again in a few days.
You and me both. I added the Nginx and added the lines of code into the http section, still nothing. Not sure its coincidence or just the same version had breaking changes to multiple things, but none of my 8 or so alexa devices wont work as well. TTS says use notify.alexa, and notify.alexa brings up an unknown error. Its been over a month now, and I didnt make any changes to any of the automations or scripts that were working before.
Would love a fix.
@scofieldjace and @Sunstarwu - does HomeAssistant report the the same error as before or has it changed?
That’s one of the problems @mdok I’m not seeing errors from HA, I can only see errors within the Sonos app if I have it open on my phone when I try to trigger TTS.
“Unable to play xxx.mp3 - The connection to xxx.duckdns.org was lost”
Like others this previously used to work but no longer does.
For all you guys that are still not working AFTER installin NGINX addon.
Installation of NGINX objective is to keep ssl interface with HA from outside your LAN while you keep plain http from inside.
So, after installing the addon you need also to configure your config yaml to get the internal communications without ssl encryption and change the base url of the tts from the external address to the internal one (http://192.168.0.X:8123)
So yours must look like this:
Hope it helps!
If you go to “Developer Tools” → “Service” → choose you tts-google service and mediaplayer and add some text. Then hit “Call Service”.
Go to the log and see that HA says.
@Mr.H.99, great post, thx
do you have these port-forwards?
Public port → local port
80 → 80
443 - > 443
8123 → 8123
Hi mdok,
NGINX configuration needs port forwarding in the router.
Mine is
80 → 80
81 → 81
443 → 443
So to acces HA from outside now I not set the port and only like: https://xxx.duckdns.org
I got mine working by simply reflashing HA to a new SD and starting again, not restoring any backups/snapshots, rebuild everything from scratch.
@MickW69 do you have installed DuckDNS addon and have added the ssl certificate lines to the configuration.yaml?
This is the key point. DuckDNS includes the option to move to an https interface, and here comes the issue with the dns missmatch handshake error.
If you can access through http to your fresh install this is why you don’t have any issues now.
I had been using Nabu casa before and after the problem, I kinda figured that I wasn’t “supposed to” need DuckDNS or anything to get it working
Hey guys - just to make sure I got this all right: Currently nobody has a working TTS solution with Sonos while using DuckDNS and Let’s Encrypt?
For me it also failed a couple of weeks ago (probably after an update to Sonos?) - I don’t have any error in the HA but the “connection lost” error in the Sonos App.
I did consider switching to Remote UI via NC, but didn’t want to rely on a cloud service for that (even though it would be more secure as it wouldn’t need an open port…). Doing it just for TTS also appears a bit much, but alas…
I can confirm, that it is still not working.
I can’t get the NGINX addon to work. Everytime I try I get an error:
[10/5/2021] [7:58:09 AM] [Nginx ] ›
info Testing Nginx configuration
[10/5/2021] [7:58:09 AM] [Nginx ] ›info Reloading Nginx
[10/5/2021] [7:58:09 AM] [Express ] ›warning Command failed: /usr/bin/certbot certonly --non-interactive --config “/etc/letsencrypt.ini” --cert-name “npm-13” --agree-tos --email “[email protected]” --preferred-challenges “dns,http” --domains “xxxx.duckdns.org”
Saving debug log to /data/logs/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Performing the following challenges:
http-01 challenge for xxxx.duckdns.org
Using the webroot path /data/letsencrypt-acme-challenge for all unmatched domains.
Waiting for verification…
Challenge failed for domain xxxx.duckdns.org
http-01 challenge for xxxx.duckdns.org
Cleaning up challenges
Some challenges have failed.
So I more or less gave up.
Thanks for the feedback! I used this opportunity to activate remote access via Nabu Casa, removed the DuckDNS add-on, deactivated SSL and removed the port forwarding. Took some digging through the logs to clean up atferwards, but appears to be working fine.
TTS with Nabu Casa Cloud to Sonos now works fine (it uses the local IP of HA without SSL: http://192.168.23.6:8123/api/tts_proxy/3935b7c721b3a0d3e8342a635e0f9154f4f5f755_de-de_a9c18110b0_cloud.mp3)
Also seems to be a bit faster now, but that might be wishful thinking… Let’s see how reliable the NC service is. 
Just to add to the data. Same problem. I’m an HAOS install running on Raspberry Pi 4 hardware. Sonos worked correctly for over a year up until I upgraded from 2021.9.3 to 2021.10.0. I use DuckDNS/Let’s Encrypt and a pfSense firewall with a loopback configured for the https address. I can control the SONOS devices (volume, playlists, radio, etc), but cannot TTS or play MP3’s stored on my HA device.
After researching this for a while, I think the problem is being caused by two factors that occurred within a few weeks of each other. First, the Let’s Encrypt root certificate server changed from DST Root CA X3 to ISRG Root X1. Subsequently, Sonos seems to have locked down their devices to only accept SSL requests from a certain pool of certificate authorities, DST Root CA X3 being one of them, but ISRG Root X1 not making the cut.
Exhibit 1: DST Root CA X3 Expiration (September 2021) - Let's Encrypt
Exhibit 2: Sonos Developer
Personally, I don’t think this gets fixed until Sonos relaxes their SSL certificate standard a bit. They won’t even accept SSL’s from Sectigo, which is one of the largest SSL providers on the planet. We should all lodge a complaint in the Sonos TS forums. https://en.community.sonos.com/
Wow - great research @RightSpin 
But how can it be working for some with the Nginx addon - it is still the same Certificate thats beeing used - or?
Question:
For those of you who have success with the Nginx addon - have you disabled the DuckDNS addon and/or changed hostname.duckdns.org to something new?
@mdok No, after configuring nginx DuckDNS addon is still enabled and using the same hostname. Only had to remove the following lines from config and add the trusted proxy as mentioned above.
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem