Core: TTS.google_say not working with HTTPS (even with base_url)

[sallgood]

Make sure you are running the latest version of Home Assistant before reporting an issue.

You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:

Home Assistant release (hass --version):
0.35.3

Python release (python3 --version):
Python 3.4.2

Component/platform:
tts

Description of problem:
TTS will not play to a Google Home if HTTPS is enabled. I have tried it both with and without http: base_url and get the same result. The problem goes away as soon as I comment out ssl_certificate and ssl_key from http: and restart (disabling SSL). I use secrets.yaml for my cert and key, and the problem persists if I remove the !secret call and include the hardcoded string to the key and cert.

Expected:
TTS to be able to google_say to a Google Home.

Problem-relevant configuration.yaml entries and steps to reproduce:

https://github.com/sallgood/homeassistant/blob/master/configuration.yaml

1. Enable SSL in http:. Include base_url (or don't include base_url)
2. Enable TTS
   3a. on the /service page, call TTS > google_say > {"entity_id":"media_player.master_bedroom_home","message":"testing"}
   3b. In my automation.yaml I also have a tts.google_say triggered via input_boolean. This produces the same failure.

Traceback (if applicable):

Additional info:

[sallgood]

http: base_url: https://bla.example.com:8123

I just tried this, and it results in tts.google_say using the following:
media_content_id=https://https://bla.example.com:8123/api/tts_proxy/f20034b8ac54b843c236d73310f06ae7e976e575_google.mp3

[TechnologyAnimal]

i was able to reproduce the issue you are experiencing @sallgood . i also tried updating configuration.yaml as suggested by @pvizeli , but that unfortunately didn't solve the problem.

any other suggestions would be greatly appreciated.

[rpitera]

Leave out the "https://" in your base_url statement. Should look like this:

http:
  base_url: bla.example.com:8123

[sallgood]

That is what I have. I only changed it to test per Pascal's recommendation.

On Mon, Dec 26, 2016, 9:29 AM rpitera [e-mail] wrote:

Leave out the "https://" in your base_url statement. Should look like
this:

http:
base_url: bla.example.com:8123

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/5064#issuecomment-269220418,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATe0pL8j6UQiZhW9smN3lJmgKAlXbw-Rks5rL91tgaJpZM4LVWT1
.

[sallgood]

Hey guys - here is an updated list of the various things I've done to try and get this to work. I really appreciate the help and recommendations so far. I look forward to getting this solved.

As soon as I disable SSL all of the issues go away and TTS works perfectly . When SSL is enabled the Google Home will make a ding the very first time after HASS is restarted and a google_say command is sent to it, but it will never play the text (mp3). After that first ding, it ignores all subsequent commands without response or log. Debug shows it is receiving the commands and its state changes as a result.

1) Base URL in http:

• no base_url
• base_url: bla.example.com:8123
• base_url: https://bla.example.com:8123 (results in google_say command calling media_content_id at this address (notice the double https://): https://https://bla.example.com:8123/api/tts_proxy/f20034b8ac54b843c236d73310f06ae7e976e575_google.mp3)
• base_url: bla.example.com (without the trailing port)

2) I've tried including all the various optional fields in the TTS component initialization as per the reference at https://home-assistant.io/components/tts/. This include:

• leaving cache directory as default
• changing cache directory to /var/opt/homeassistant/www
• changing permissions on the directory so all users can access
• enabling/disabling cache in the tts initialization (cache: true, cache: false)

3) I've tried calling TTS through most every way possible

• as an automation tied to a boolean switch:

- alias: TTS Google Home
  trigger:
    - platform: state
      entity_id: input_boolean.google_tts
      to: 'on'
  action:
    - service: tts.google_say
      data_template:
        entity_id: media_player.master_bedroom_home
        message: "Bonjour Catherine comment va tu ?"
        cache: false

• via the bla.example.com:8123/dev-service with the following various JSON. I've flipped cache to both true and false in these as well:
  {"entity_id":"media_player.master_bedroom_home","message":"blah blah blah"}
{"entity_id":"media_player.master_bedroom_home","data":{"message":"blah blah blah"}}
{"entity_id":"media_player.master_bedroom_home","data_template":{"message":"blah blah blah","cache":"true"}}
{"entity_id":"media_player.master_bedroom_home","message":"blah blah blah","cache":"true"}

• for the above JSON I've also tried flipping to a different Google Home device with the same problem, media_player.living_room_home

[rpitera]

Well, you should have gotten an error on the automation because the action is incorrectly formatted.

It should be:

- service: tts.google_say
  entity_id: media_player.master_bedroom_home
  data:
    message: 'Bonjour Catherine comment va tu ?'

Firstly, the entity_id should come first and be in line with the service: line. Second, since you are just using text and not input from a sensor, you should be using data: instead of data_template:. Third problem is using double instead of single quotes. And lastly, you should actually cache this as it isn't going to change and therefore it will respond faster the next time you trigger it. cache: false is more useful when you are including variables from sensors (data_template) because that variable will likely change the next time it is called so no need to cache it.

Also, I would set up your tests as scripts instead of automations as it's easier to fire them directly on command.

Be advised that if you haven't set up your language codes, it's going to butcher that French when it tries to pronounce it in US English, which is the default. LOL

[sallgood]

Ok, I tried this as a script and neither of these is working. Also, can you explain why my regular old calls via the dev-service tab aren't working either?

  google_say_test:
    alias: Google Say Test
    sequence:
      - service: tts.google_say
        entity_id: media_player.master_bedroom_home
        data:
            message: 'Testing the script way'

This doesn't work either:

  google_say_test:
    alias: Google Say Test
    sequence:
      service: tts.google_say
      entity_id: media_player.master_bedroom_home
      data:
        message: 'Testing the script way'

Here is a snippet from the log generated when I execute the script. Does this help with anything?

16-12-26 17:41:37 homeassistant.core: Bus:Handling <Event call_service[L]: service=google_say, domain=tts, service_call_id=1978116848-4, service_data=entity_id=['media_player.master_bedroom_home'], message=Testing the script way>
16-12-26 17:41:37 homeassistant.core: Bus:Handling <Event call_service[L]: service=play_media, domain=media_player, service_call_id=1978116848-5, service_data=media_content_id=https://sallgood.hopto.org:8123/api/tts_proxy/1a192d15a5f97bd6347d4648be0731f85312c014_google.mp3, media_content_type=music, entity_id=['media_player.master_bedroom_home']>
16-12-26 17:41:37 homeassistant.core: Bus:Handling <Event service_executed[L]: service_call_id=1978116848-1>
16-12-26 17:41:37 pychromecast.controllers: Not launching app CC1AD845 - already running
16-12-26 17:41:37 homeassistant.core: Bus:Handling <Event service_executed[L]: service_call_id=1978116848-5>
16-12-26 17:41:37 homeassistant.core: Bus:Handling <Event service_executed[L]: service_call_id=1978116848-4>
16-12-26 17:41:37 homeassistant.core: Bus:Handling <Event service_executed[L]: service_call_id=1978116848-3>

[pvizeli]

Sorry for https in base_url. That is not needed. If you use a other port than 443 you need set the port with base_url.

Try to use quote for language. I.e. no will not work without quote while the yaml parse read that as false.

Can you try to play your tts url from play_media service inside i.e. vlc?

[sallgood]

Hey all - so I got to messing around with it last night and was able to get it working intermittently via the Script that rpitera recommended building. But it seems to break and stop responding. If I wait 30 minutes or so (that is a rough estimation) I can send the script again and have my Google Homes "ping" but not say the text. Is there a timeout or something built into the code that would prevent it from playing a new string if it failed the last one? Can it get stuck on a bad command and stop working? There are no errors or anything else in the logs outside of what I listed in my previous post.

[jabesq]

Same issue here:

Home Assistant release (hass --version):
0.35.3

Python release (python3 --version):
Python 3.4.2

base_url correctly setup to something like: hass-example.duckdns.org:8123 (which is crashing zeroconf BTW)

Media Player: Sonos

No particular message on logs, but Sonos app says it was unable to read the mp3 file connection to hass-example.duckdns.org:8123 has been lost (of course hass-example.duckdns.org is just a placeholder of my real domain name)

No problem seen if I disable SSL

[pvizeli]

Is you SSL certificate valid?

2016-12-28 13:23 GMT+01:00 Hugo Dupras [e-mail]:

Same issue here:

Home Assistant release (hass --version):
0.35.3

Python release (python3 --version):
Python 3.4.2

base_url correctly setup to something like: hass-example.duckdns.org:8123
(which is crashing zeroconf BTW)

Media Player: Sonos

To particular message on logs, but Sonos app says it was unable to read
the mp3 file connection to hass-example.duckdns.org:8123 has been lost
(of course hass-example.duckdns.org is just a placeholder of my real
domain name)

No problem seen if I disable SSL

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/5064#issuecomment-269470144,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOoMLEjjRG8pbIcdSis6IUrGS8AHeApHks5rMlTOgaJpZM4LVWT1
.

[jabesq]

Yes, provided by Let's Encrypt and renewed begin of December for 3 month

[rpitera]

I'm just going to post these here in hopes that it may trigger something for you as things are working regularly on my end.

configuration.yaml:

homeassistant:
  name: Home
  latitude: 40.658939
  longitude: -74.39030385
  elevation: 52
  unit_system: imperial
  time_zone: America/New_York
  customize: !include customize.yaml

http:
  api_password: !secret http_password
  ssl_certificate: /etc/letsencrypt/live/westofeast.no-ip.org/fullchain.pem
  ssl_key: /etc/letsencrypt/live/westofeast.no-ip.org/privkey.pem
  base_url: westofeast.no-ip.org

###<unrelated configs omitted, this is further down>###

#
# TTS Settings
#
tts:
  - platform: google
    language: 'en-uk'

scripts:
test_tts.yaml -

sequence:
- service: tts.google_say
  entity_id: media_player.living_room_home
  data:
    message: 'Hello, Robert. This is a test of Home Assistant Voice Notifications on Google Home. Cheers!'

test_tts2.yaml -

sequence:
- service: tts.google_say
  entity_id: media_player.living_room_home
  data_template:
    message: 'Hello, Robert. The temperature outside is currently {{ states.sensor.dark_sky_temperature.state }} degrees.'
    cache: false

[jabesq]

@rpitera So your home-assistant is working on port 80 and not port 8123 (default), as it is not specified in your http.base_url ? (my base_url is something like hass-example.duckdns.org:8123)

if Yes, I will try to modify my iptables to forward port 80 to 8123 for my raspi

[rpitera]

No, I have SSL configured. My router redirects any requests to the RPi running HA made on 443 to 8123.

[jabesq]

I try to open and redirect my port 443 to 8123 but still no success

[ytilis]

Ran into this same issue. I use a reverse proxy, so my HASS install is accessible via HTTPS on port 443. But HASS insists on sending the link with an http prefix. Specifying the port wasn't working, and although I have a redirect to https, Google Home didn't seem to want to follow the redirect for the media file.

My solution was that, since the device was on the same internal network as the HASS anyway, I changed the base_url to 192.168.1.100:8123 which is the IP of my HASS device, with no protocol specified, and the port number appended to the end.

This issue might be solvable by adding a protocol parameter, so we can specify http, https, ftp, etc. If I have time down the road I might try it, but if someone else wants to give it a shot, feel free.

[jabesq]

It is now working for me. I still don't know what was the real root cause, but what I suspect it is that I was using a "multiple-domain" certificate for my home-assistant (ie: valid for hass.duckdns.org, hass.ddns.net and jabesq-hass.noip.com) and even if it was working correctly with a browser (no warning saying that the certificate was not valid), it might create issue with my Sonos speaker, but it is only a supposition.
Now I have a specific certificate for my hass and it is working properly

[Mike1082]

@jabesq Can you share some details about your config? I am having this issue with the Sonos as well.

Home Assistant release (hass --version): 0.35.3
Python release (python3 --version): Python 3.4.2

Tried base_url: hass-example.duckdns.org:8123 and 10.0.1.240:8123 (HA local IP)
Same message in the Sonos app about it not being able to access the cached .mp3 file "at "
I did not think to try disabling SSL, but I suspect that would work fine.
Both HA and Sonos are on the same subnet.

configuration.yaml:

http:
  api_password: !secret api_password
  base_url: 10.0.1.240:8123
  ssl_certificate: '/etc/letsencrypt/live/redacted/fullchain.pem'
  ssl_key: '/etc/letsencrypt/live/redacted/privkey.pem'

tts:
  - platform: google

test_tts.yaml: (script)

sequence:
- service: tts.google_say
  entity_id: media_player.living_room
  data:
    message: 'Hello. This is a test of Home Assistant Voice Notifications on Sonos.'

Some more info: My certificate is not multi-domain. Same as @rpitera I have my router forwarding port 443 to 8123. At the moment, my Sonos is joined to HA via Discovery. Did you specify a Sonos component, perhaps? Any other differences?

Thanks!

[jabesq]

My setup is the following one:

Home Assistant release (hass --version): 0.35.3
Python release (python3 --version): Python 3.4.2

DNS provided by duckdns (ie: jabesq.duckdns.org)
SSL certificate for this url provided by LetsEncrypt, using certbot-auto on the same machine which run hass.

https://jabesq.duckdns.org:8123 is reachable from inside and outside my LAN (through DNSmasq as my modem does not provide any loopback mechanism)

port 443 is redirected to 8123.

my configuration.yaml:

homeassistant:
     # Name of the location where Home Assistant is running
     name: Home
     # C for Celcius, F for Fahrenheit
     temperature_unit: C
     unit_system: metric
     # Pick yours from here: http://en.wikipedia.org/wiki/                       List_of_tz_database_time_zones
     time_zone: Europe/Paris
     #location required to calculate the time the sun rises and sets
     latitude: !secret home_latitude
     longitude: !secret home_longitude
     customize: !include customization.yaml
     # Impacts weather/sunrise data (altitude above sea level)
     elevation: 8

 http:
     api_password: !secret api_password
     ssl_certificate: !secret ssl_certificate
     ssl_key: !secret ssl_key
     base_url: jabesq.duckdns.org
     trusted_networks:
       - 127.0.0.1
       - ::1
       - 192.168.2.0/24
tts:
   - platform: google

(then my sensors, scripts, automations...)

my scripts.yaml

 test_tts:
     alias: Test for TTS
     sequence:
       - service: tts.google_say
         entity_id: media_player.bureau
         data:
             message: 'Hello. This is a test of Home Assistant Voice. Cheers!'

[Mike1082]

@jabesq Thank you for the info, I will give it a try later when I get home without the port in the base_url: field.

[Mike1082]

Confirmed, removing the port specification from my base URL did the trick. Thanks!

[pvizeli]

Yeah, it is the base url they need same for access external.

[auduny]

What is the reason why this now is a problem. I have a setup of haproxy listening on https on 8122, forwarding over pure http to a docker running host-networking (--net=host) on port 8123. This worked like a charm earlier, but not now (more or less running a new version of HEAD every day). For some reason it did work for a while to run "text-to-speech" directly on the media device, but not through the automation-config. And I cannot find a combination of base_url that works for me either.

[miniconfig]

@auduny When I lest tested this a week ago, it looked to me that the URL for tts was generated as https:// only if the ssl_certificate and ssl_key were specified for the http component. This was a problem for me, because I'm using an apache proxy to do the SSL to a non-SSL hass instance. I don't know anything about docker networking, but it sounds like you're doing something similar. I opened up a feature request on the forum to allow this to be forced, but I haven't had a chance to look into fixing it myself yet.

[auduny]

Somehow this started working again now with the lastest realease by removing base_url completly. But it still logs
17-01-18 14:20:48 homeassistant.components.tts: Error on load tts: Wrong tts file format!
Even though it works. It also seem to log it 10 second interval without actually firing of the tts-component to say something

[ddykhoff]

Removing port :8123 from the base_url: in http: did the trick for me, as mentioned by others in this thread.

[master-kenobi]

I am using a self signed certificate as per instruction from https://home-assistant.io/cookbook/tls_self_signed_certificate/

Then I do a port forwarding from port 443 to 8123 and I added this in my config...

http:
  api_password: !secret http_password
  base_url: hass.mydomain.com
  ssl_certificate: /home/pi/.homeassistant/fullchain.pem
  ssl_key: /home/pi/.homeassistant/privkey.pem

When I visit https://hass.mydomain.com/ in my browser, I can view the frontend (after ignoring the security warnings).

However, Google TTS via VLC player is not working.

[andrey-git]

Google TTS doesn't work with self-signed certificates.

I guess we could make HA listen on two ports one with SSL and one without.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[WeatherWitch]

Running Hass version 0.45.0
Still not working with SSL .

Is this issue being looked at?

[andrey-git]

@WeatherWitch are you running with self-signed certificate?

[WeatherWitch]

@andrey-git I'm using a letsencrypt cert

[andrey-git]

Then it should work

[WeatherWitch]

@andrey-git
My issue is the same as OP and I have read the entire thread.
I do not have the ability to forward port 443 to 8123 from my router.
If I don't use ssl, everything works as expected.

Any ideas greatly appreciated.

[andrey-git]

Are you connecting from inside the network where HA runs or from outside?

[WeatherWitch]

@andrey-git I'm connecting from both.

[andrey-git]

When you are connecting from inside why do you need to port-forward on the router?
Do you have a proxy in from of HA?
Are you using api_password?

[WeatherWitch]

@andrey-git

When you are connecting from inside why do you need to port-forward on the router?

I don't need it from home - But I like to access from work to check commute times/wewather etc.

Do you have a proxy in from of HA?

No, I don't

Are you using api_password?

Yes.

[andrey-git]

Could you try without api_password?

So when you are inside the network, have no, api_password,
you have base_url: https://yourdomain.com:8123 tts still doesn't work?

Could you run (assuming linux) host <yourdomain.com>?

[WeatherWitch]

@andrey-git
Tried without api_password
Also messed around with combinations of base_url with no change.

Just tried...
sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8123

Can now access using https without :8123 suffix still no change :-(

[WeatherWitch]

This is what I'm getting with logging switched on...

2017-05-21 20:35:15 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 1808746768: Received {'id': 10, 'service_data': {'entity_id': 'media_player.living_room_home', 'message': 'test'}, 'domain': 'tts', 'type': 'call_service', 'service': 'google_say'}
2017-05-21 20:35:15 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: service_call_id=1973282800-1, service=google_say, domain=tts, service_data=entity_id=media_player.living_room_home, message=test>
2017-05-21 20:35:15 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: service_call_id=1973282800-2, service=play_media, domain=media_player, service_data=entity_id=['media_player.living_room_home'], media_content_type=music, media_content_id=redacted/api/tts_proxy/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3_en_-_google.mp3>
2017-05-21 20:35:15 DEBUG (Thread-1) [pychromecast.controllers] Receiver:Updating status
2017-05-21 20:35:15 DEBUG (Thread-1) [pychromecast.socket_client] Sending: Message urn:x-cast:com.google.cast.receiver from sender-0 to receiver-0: {'requestId': 9, 'type': 'GET_STATUS'}
2017-05-21 20:35:15 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_executed[L]: service_call_id=1973282800-2>
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.socket_client] Received: Message urn:x-cast:com.google.cast.receiver from receiver-0 to sender-0: {'status': {'volume': {'muted': False, 'controlType': 'master', 'stepInterval': 0.019999999552965164, 'level': 0.6399999856948853}}, 'requestId': 9, 'type': 'RECEIVER_STATUS'}
2017-05-21 20:35:15 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_executed[L]: service_call_id=1973282800-1>
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.controllers] Received status: CastStatus(is_active_input=False, is_stand_by=True, volume_level=0.6399999856948853, volume_muted=False, app_id=None, display_name=None, namespaces=[], session_id=None, transport_id=None, status_text='')
2017-05-21 20:35:15 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 1808746768: Sending {'success': True, 'id': 10, 'type': 'result', 'result': None}
2017-05-21 20:35:15 INFO (Thread-12) [pychromecast.controllers] Receiver:Launching app CC1AD845
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.socket_client] Sending: Message urn:x-cast:com.google.cast.receiver from sender-0 to receiver-0: {'requestId': 10, 'appId': 'CC1AD845', 'type': 'LAUNCH'}
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.socket_client] Received: Message urn:x-cast:com.google.cast.receiver from receiver-0 to *: {'status': {'volume': {'muted': False, 'controlType': 'master', 'stepInterval': 0.019999999552965164, 'level': 0.6399999856948853}, 'applications': [{'statusText': 'Ready To Cast', 'namespaces': [{'name': 'urn:x-cast:com.google.cast.broadcast'}, {'name': 'urn:x-cast:com.google.cast.media'}], 'transportId': 'f6d8505a-1d8f-418b-841f-5af5444ac426', 'displayName': 'Default Media Receiver', 'isIdleScreen': False, 'appId': 'CC1AD845', 'sessionId': 'f6d8505a-1d8f-418b-841f-5af5444ac426'}]}, 'requestId': 10, 'type': 'RECEIVER_STATUS'}
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.controllers] Received status: CastStatus(is_active_input=False, is_stand_by=True, volume_level=0.6399999856948853, volume_muted=False, app_id='CC1AD845', display_name='Default Media Receiver', namespaces=['urn:x-cast:com.google.cast.broadcast', 'urn:x-cast:com.google.cast.media'], session_id='f6d8505a-1d8f-418b-841f-5af5444ac426', transport_id='f6d8505a-1d8f-418b-841f-5af5444ac426', status_text='Ready To Cast')
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.socket_client] Sending: Message urn:x-cast:com.google.cast.tp.connection from sender-0 to f6d8505a-1d8f-418b-841f-5af5444ac426: {'userAgent': 'PyChromecast', 'senderInfo': {'version': '15.605.1.3', 'sdkType': 2, 'connectionType': 1, 'browserVersion': '44.0.2403.30', 'systemVersion': 'Macintosh; Intel Mac OS X10_10_3', 'platform': 4}, 'type': 'CONNECT', 'origin': {}}
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.socket_client] Sending: Message urn:x-cast:com.google.cast.media from sender-0 to f6d8505a-1d8f-418b-841f-5af5444ac426: {'requestId': 11, 'type': 'GET_STATUS'}
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.controllers] Start app_launch_event_function...
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.socket_client] Sending: Message urn:x-cast:com.google.cast.media from sender-0 to f6d8505a-1d8f-418b-841f-5af5444ac426: {'requestId': 12, 'sessionId': 'f6d8505a-1d8f-418b-841f-5af5444ac426', 'type': 'LOAD', 'media': {'contentType': 'music', 'contentId': 'redacted/api/tts_proxy/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3_en_-_google.mp3', 'streamType': 'BUFFERED', 'metadata': {}}, 'customData': {}, 'currentTime': 0, 'autoplay': True}
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.socket_client] Received: Message urn:x-cast:com.google.cast.media from f6d8505a-1d8f-418b-841f-5af5444ac426 to *: {'status': [], 'requestId': 0, 'type': 'MEDIA_STATUS'}
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.controllers] Media:Received status {'status': [], 'requestId': 0, 'type': 'MEDIA_STATUS'}
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.socket_client] Received: Message urn:x-cast:com.google.cast.media from f6d8505a-1d8f-418b-841f-5af5444ac426 to sender-0: {'status': [], 'requestId': 11, 'type': 'MEDIA_STATUS'}
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.controllers] Media:Received status {'status': [], 'requestId': 11, 'type': 'MEDIA_STATUS'}
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.socket_client] Received: Message urn:x-cast:com.google.cast.media from f6d8505a-1d8f-418b-841f-5af5444ac426 to *: {'status': [{'playbackRate': 1, 'mediaSessionId': 1, 'playerState': 'IDLE', 'extendedStatus': {'media': {'contentType': 'music', 'contentId': 'redacted/api/tts_proxy/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3_en_-_google.mp3', 'streamType': 'BUFFERED', 'metadata': {}}, 'playerState': 'LOADING'}, 'media': {'contentType': 'music', 'contentId': 'redacted/api/tts_proxy/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3_en_-_google.mp3', 'streamType': 'BUFFERED', 'metadata': {}}, 'currentItemId': 1, 'repeatMode': 'REPEAT_OFF', 'supportedMediaCommands': 15, 'currentTime': 0, 'volume': {'muted': False, 'level': 1}}], 'requestId': 0, 'type': 'MEDIA_STATUS'}
2017-05-21 20:35:15 DEBUG (Thread-12) [pychromecast.controllers] Media:Received status {'status': [{'playbackRate': 1, 'mediaSessionId': 1, 'playerState': 'IDLE', 'extendedStatus': {'media': {'contentType': 'music', 'contentId': 'redacted/api/tts_proxy/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3_en_-_google.mp3', 'streamType': 'BUFFERED', 'metadata': {}}, 'playerState': 'LOADING'}, 'media': {'contentType': 'music', 'contentId': 'redacted/api/tts_proxy/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3_en_-_google.mp3', 'streamType': 'BUFFERED', 'metadata': {}}, 'currentItemId': 1, 'repeatMode': 'REPEAT_OFF', 'supportedMediaCommands': 15, 'currentTime': 0, 'volume': {'muted': False, 'level': 1}}], 'requestId': 0, 'type': 'MEDIA_STATUS'}
2017-05-21 20:35:15 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.living_room_home, old_state=<state media_player.living_room_home=off; supported_features=21437, friendly_name=Living room Home @ 2017-05-21T21:34:05.871879+01:00>, new_state=<state media_player.living_room_home=idle; app_name=Default Media Receiver, supported_features=21437, media_content_id=redacted/api/tts_proxy/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3_en_-_google.mp3, is_volume_muted=False, media_position_updated_at=2017-05-21T21:35:15.735661+01:00, app_id=CC1AD845, volume_level=0.6399999856948853, media_position=0, friendly_name=Living room Home @ 2017-05-21T21:35:15.737768+01:00>>
2017-05-21 20:35:15 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 1808746768: Sending {'event': {'time_fired': datetime.datetime(2017, 5, 21, 20, 35, 15, 737934, tzinfo=<UTC>), 'data': {'entity_id': 'media_player.living_room_home', 'old_state': <state media_player.living_room_home=off; supported_features=21437, friendly_name=Living room Home @ 2017-05-21T21:34:05.871879+01:00>, 'new_state': <state media_player.living_room_home=idle; app_name=Default Media Receiver, supported_features=21437, media_content_id=redacted/api/tts_proxy/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3_en_-_google.mp3, is_volume_muted=False, media_position_updated_at=2017-05-21T21:35:15.735661+01:00, app_id=CC1AD845, volume_level=0.6399999856948853, media_position=0, friendly_name=Living room Home @ 2017-05-21T21:35:15.737768+01:00>}, 'origin': 'LOCAL', 'event_type': 'state_changed'}, 'id': 2, 'type': 'event'}
2017-05-21 20:35:16 DEBUG (Thread-12) [pychromecast.socket_client] Received: Message urn:x-cast:com.google.cast.receiver from receiver-0 to *: {'status': {'volume': {'muted': False, 'controlType': 'master', 'stepInterval': 0.019999999552965164, 'level': 0.6399999856948853}, 'applications': [{'statusText': 'Now Casting', 'namespaces': [{'name': 'urn:x-cast:com.google.cast.broadcast'}, {'name': 'urn:x-cast:com.google.cast.media'}], 'transportId': 'f6d8505a-1d8f-418b-841f-5af5444ac426', 'displayName': 'Default Media Receiver', 'isIdleScreen': False, 'appId': 'CC1AD845', 'sessionId': 'f6d8505a-1d8f-418b-841f-5af5444ac426'}]}, 'requestId': 0, 'type': 'RECEIVER_STATUS'}
2017-05-21 20:35:16 DEBUG (Thread-12) [pychromecast.controllers] Received status: CastStatus(is_active_input=False, is_stand_by=True, volume_level=0.6399999856948853, volume_muted=False, app_id='CC1AD845', display_name='Default Media Receiver', namespaces=['urn:x-cast:com.google.cast.broadcast', 'urn:x-cast:com.google.cast.media'], session_id='f6d8505a-1d8f-418b-841f-5af5444ac426', transport_id='f6d8505a-1d8f-418b-841f-5af5444ac426', status_text='Now Casting')
2017-05-21 20:35:16 DEBUG (Thread-12) [pychromecast.socket_client] Received: Message urn:x-cast:com.google.cast.media from f6d8505a-1d8f-418b-841f-5af5444ac426 to sender-0: {'requestId': 12, 'type': 'LOAD_FAILED'}
2017-05-21 20:35:16 DEBUG (Thread-12) [pychromecast.socket_client] Message unhandled: Message urn:x-cast:com.google.cast.media from f6d8505a-1d8f-418b-841f-5af5444ac426 to sender-0: {'requestId': 12, 'type': 'LOAD_FAILED'}
2017-05-21 20:35:17 DEBUG (Thread-12) [pychromecast.socket_client] Received: Message urn:x-cast:com.google.cast.receiver from receiver-0 to *: {'status': {'volume': {'muted': False, 'controlType': 'master', 'stepInterval': 0.019999999552965164, 'level': 0.6399999856948853}, 'applications': [{'statusText': 'Ready To Cast', 'namespaces': [{'name': 'urn:x-cast:com.google.cast.broadcast'}, {'name': 'urn:x-cast:com.google.cast.media'}], 'transportId': 'f6d8505a-1d8f-418b-841f-5af5444ac426', 'displayName': 'Default Media Receiver', 'isIdleScreen': False, 'appId': 'CC1AD845', 'sessionId': 'f6d8505a-1d8f-418b-841f-5af5444ac426'}]}, 'requestId': 0, 'type': 'RECEIVER_STATUS'}
2017-05-21 20:35:17 DEBUG (Thread-12) [pychromecast.controllers] Received status: CastStatus(is_active_input=False, is_stand_by=True, volume_level=0.6399999856948853, volume_muted=False, app_id='CC1AD845', display_name='Default Media Receiver', namespaces=['urn:x-cast:com.google.cast.broadcast', 'urn:x-cast:com.google.cast.media'], session_id='f6d8505a-1d8f-418b-841f-5af5444ac426', transport_id='f6d8505a-1d8f-418b-841f-5af5444ac426', status_text='Ready To Cast')

[sallgood]

I never was able to get TTS working while HTTPS was enabled. I ended up disabling SSL in HASS and instead having an nginx reverse proxy handle encrypted traffic. It works without an issue now, and I even have it implemented in with a few automations.
I wonder if anyone out there is successfully using TTS and Google Homes with SSL enabled.

[WeatherWitch]

I think the issues is...
media_content_id=redacted/api/tts_proxy/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3_en_-_google.mp3
Is not accessible?

@sallgood thanks for the heads up, I'll give nginx a try.

It's a shame the letsencrypt documented setup does not work, as I would assume most people are using dynamic addressing and need workarounds?

[andrey-git]

@WeatherWitch
Sorry for nitting, could you spell the redacted in more detail, as is it https://domain.com:8123 or without https? or without port?

Also, could you run host <that reducted url> on both on the machine where you run HA an on another machine in your network?

[WeatherWitch]

@andrey-git Sorry for the late reply - busy week :-(
The redacted is just the url...
Tried https with and without port number with no difference.
Also tried nginx but got into a right mess, so have removed it!

[tube0013]

Seeing the same behavior with 0.45.1 and using an ssl cert. just the thump tone, no spoken text.

[cinzas]

Any plans to permit self signed certificates ?

[andrey-git]

@cinzas the devices that consume the sound file (Sonos, Chromecast) don't trust the self signed certificate.

Whoever has this problem with proper cert please run 'host ha_url' on both ha machine and another machine on the network.

[cinzas]

@andrey-git m you're right, the problem is on the client side, who's not accepting self signed certificates ...

I liked your idea of having HA listen on two ports one with SSL and one without, then we could expose SSL to the outside, and use the non-SSL port to expose internally so google home is able to play it.

[andrey-git]

@cinzas However getting a proper let's encrypt certificate is easy. So the two-port solution is not worth the effort just for the self-signed setup.

[cinzas]

@andrey-git: You must renew it every 90 days and need to have port 80 exposed to internet. Currently my port 80 is already used on other internal equipment, but yes, in that case it works :)

[andrey-git]

@cinzas If you have a domain (some free 3rd level might work too) and a router supporting custom DNS entries (ddWRT does) you don't need exposure to internet: https://home-assistant.io/docs/ecosystem/certificates/tls_domain_certificate/

[sendorm]

My router does not support nat forwarding. So in order to access hass within the network, I had to put a dns server at my raspberry pi. That maps the ip (192.168.x.x) of the raspberry pi to the outside address (xxxx.ddns.net)
I can access from outside via: https://xxxx.ddns.net and within network via https://192.168.x.x:8123.

The problem is google dns does not work. The mp3 is being generated. I've tried different base_url configurations with no luck.

[sendorm]

I found the solution:
base_url: xxxx.ddns.net:8123

fixes the problem with nat forwarding disabled routers with ssl.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[donaldtse118]

updated version 0.56.1
DuckDNS and let's encrypt , tts still not working when https enabled.

[ntalekt]

Same issue on 0.56.2

[Paxy]

Just this morning resolved the issue by workaround described by @johnnieblows (https://community.home-assistant.io/t/google-chromecast-text-to-speech-and-ssl/15262/8?u=paxy).

Looks like Google Home use external DNS to resolve only(?!) HTTPS streams URL.
By redirecting all outgoing DNS requests to your DNS server, you can workaround this issue.

On Mikrotik, it is just about adding DSTNAT rule that redirects all UDP port 53 traffic to routers local IP address.

[ntalekt]

Thanks @Paxy but that's not working for me still. I did notice that my base_url was resolving to WAN IP so I'm sure that is part of my problem (as I don't have it open from the outside yet). I resolved that by adding my base_url to /etc/hosts on my Pi-hole nameserver, now from HA it's resolving to the LAN IP. However it still isn't working.

I've been playing with the config and I noticed some things.

1. With only base_url and api_password defined it still doesn't work. I've tried base_url as ha.example.com:8123 and ha.example.com.

http:
  base_url: ha.example.com:8123
  api_password: !secret ha_password

1. With only api_password, ssl_certificate, and ssl_key it still doesn't work.

http:
  api_password: !secret ha_password
  ssl_certificate: !secret ssl_certificate
  ssl_key: !secret ssl_key

However, I can still get to ../api/tts_proxy/_<whatever>__en_-_google.mp3 in both examples.

[ntalekt]

Did a little more testing and noticed something. When setting the base_url to the local HA IP (e.g. 192.168.2.20) it still works, however when adding the SSL cert to the config it doesn't work. Note that I want to use SSL locally and don't want to port forward anything so I won't be able to access HA from anywhere other then my local LAN. My SSL certificate is from SSLS.

Works: HA creates TTS mp3 via google TTS and Sonos can access and play it

http:
  base_url: 192.168.2.20:8123
  api_password: !secret ha_password

Doesn't work: HA creates TTS mp3 via Google TTS and Sonos can't access and play it

http:
  base_url: 192.168.2.20:8123
  api_password: !secret ha_password
  ssl_certificate: !secret ssl_certificate
  ssl_key: !secret ssl_key

When on the configuration that doesn't work I looked at the Sonos app on my phone and it says "Unable to play '65329ea1ff5c_en_-_google.mp3' the connection to 192.168.2.20:8123 was lost.

I looked in my TTS folder and saw the test mp3 was created. From Chrome on my desktop I tried to browse to https://192.168.2.20:8123/api/tts_proxy/65329ea1ff5c_en_-_google.mp3 and it played fine. However, from the HA box I tried wget https://192.168.2.20:8123/api/tts_proxy/65329ea1ff5c_en_-_google.mp3 and I got this:

Connecting to 192.168.2.20:8123... connected.
ERROR: The certificate of ‘192.168.2.20’ is not trusted.
ERROR: The certificate of ‘192.168.2.20’ hasn't got a known issuer.
The certificate's owner does not match hostname ‘192.168.2.20’

I resolved the certificate error by

1. Downloading the root and intermediate certificates from my cert provider (mine came in a bundle).
2. Create a directory for extra CA certificates in /usr/share/ca-certificates:
   sudo mkdir /usr/share/ca-certificates/extra
3. Copy the CA .crt file to this directory:
   sudo cp foo.crt /usr/share/ca-certificates/extra/foo.crt
4. Let OS add the .crt file's path relative to /usr/share/ca-certificates to /etc/ca-certificates.conf:
   sudo dpkg-reconfigure ca-certificates
5. Test again

This might resolve the issue for some of you.

I also tested the same scenarios with the base_url set to my common name (e.g. ha.example.com) and it produced the same results as when the base_url was set to the LAN IP.

[epegzz]

@ntalekt I'm having the same issue: mp3 file is playable via browser, but Sonos won't play it. How did you access the Sonos log files? I could not find any options in the Sonos app.

[ntalekt]

@epegzz I'm not sure about the Sonos logs. To test I would open the Sonos media_player and input some text in the "Text to speak" field. Then I'd open the Sonos app and try and press play again and it would give me that error message.

[ntalekt]

I just setup an NGINX proxy with my SSL cert as a workaround. It's probably a better solution in the long run anyway.

[robertw]

I am also having the same problems sonos error when trying-to play is can not play file xxxx lost connection .....

[epegzz]

@ntalekt excellent idea with the nginx proxy!

[pvizeli]

I can't use a IP. Your SSL certificate need to be valid with base_url and it need to be supported on sonos CA-list.

[jolaca01]

I have the same problem and if you try to run the service call to a Chromecast mediaplayer it works. So I think the problem is still there, and related to how Sonos validates SSL certificates. Actually I think this issue has nothing to do with issue #11031.
The thing is that LetsEncrypt certificates are not in the Sonos CA validated list as you can see here:
http://musicpartners.sonos.com/node/339
However I don't know the way to solve my problem without having to change to another certificate.
Any idea now that the problem seems more focused?? Thanks!

[jolaca01]

I've been told that LetsEncrypt certificates are DST root X3 type so they are indeed listed as valid for Sonos. So I was wrong thinking the problem was there. Now I'm lost, and don't know how to solve this. Any idea??

[ameulen01]

my solution was to add the entire chain in the servercertificate. Sonos only trusts the certificate authorities enlisted here http://musicpartners.sonos.com/node/339, but if you send the entire chain to the Sonos it will trust the certificate from the chain.

so if you create your cer /csr file just add al the intermediate and root ca in the same file:

-----BEGIN CERTIFICATE-----
encoded server certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
encoded intermediate CA 1
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
encoded intermediate CA 2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
encoded root CA
-----END CERTIFICATE-----

after that copy the certificate to your HASS configuration and configure the certificate in configuration.yaml under http: >> ssl_certificate:

[jolaca01]

Thanks very much, ameulen01. I will proceed and try as you say even if let's encrypt is telling me they are valid and included as a CA for Sonos (DST root X3). JUst one question, for what you're saying I should include together with that scheme data from::

• encoded server certificate
• intermediate CA 1 certificate
• Intermediate CA 2 certificate
• Root CA certificate
  I'm going to proceed that way to have the full certificate in one file BUT, from Let's encrypt I only have this 3 files:
  cert.pem
  chain.pem
  privkey.pem (private key not certificate)

So how can I do the above with this only 2 certificates?. I'm noob with all that as you can see, sorry for that. Thanks in advance. I'm also going to copy my question in your answer on HA, just in case, thank you again!!

[ameulen01]

Yes, but i think the Sonos also need the intermediate CA certificate(s) al up to the chain to the DST root X3 Ca. If i'm right you can just open the chain.pem file with a notepad and copy the entire content to a new file where you first copy the content from your server certificate, then the content of the chain file. also make sure the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- is on a new line for every certificate. The new file you can give the extension of *.pem or *.cer (you can double click on it in Windows to view if it is correct) and configure it under configuration.yaml under http: >> ssl_certificate:

the privkey.pem you can keep it the way it is.

if you name it *.cer you can open the file and view the content in readable format, there you have two fields 'issued to' and 'issued by', for every certificate you can view which CA certificate is above in the chain. so you have to collect every certificate (intermediate or root CA) to make the entire chain complete.

for the 'DST root X3' CA the Sonos only trusts certificates which are directly issued from this CA, and these are only issued for the bigger companies like google or amazon and not available in the webshops. the certificates you buy on the internet are issued by intermediates and therefore the Sonos also needs the intermediate CA to verify this.

[jolaca01]

Thanks again, ameulen01, I really appreciate your efforts to help me: I've tried but still not working for me. Let me explain what I've done:
My DDNS site is from synology, so my site name is this way: myname.synology.me
From synology certificate I have:

• cert.pem
• privatekey.pem
• syno-ca-cert.pem
• syno-ca-privkey.pem
  On the other hand as I said form LetsEncrypt:
• cert.pem
• chain.pem
• privkey.pem
  So first of all, I have tried a simple new certificate like this:
  -----BEGIN CERTIFICATE-----
  Content of file cert.pem from Lets Encrypt
  -----END CERTIFICATE-----
  -----BEGIN CERTIFICATE-----
  Content of file chain.pem form Lets Encrypt
  -----END CERTIFICATE-----

This didn't seem to work (HA didn't run), however when opening the .cer file created it showed the certificate as valid and with this route:
DST Root CA X3-->LetsEncrypt Authority X3 -->myname.synology.me
And I was allow to see the certificate for DST Root and also for LetsEncrypt, but not for synology.me

So as this didn't work because I couldn't run HA, I've tried to combine this one with the synology.me certificate doing something like this:
-----BEGIN CERTIFICATE-----
Content of file cert.pem from Lets Encrypt
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Content of file chain.pem form Lets Encrypt
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Content of file cert.pem from synology.me
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Content of file syno-ca-cert.pem from synology.me
-----END CERTIFICATE-----
That didn't work either and when opening the .cer file showed the same, the certificate as valid with the same above route. But HA didn't run with that. Should I have used a different combination of combined certificates?? Please bear with me as I feel I'm getting closed to get it working . Thanks!!

[ameulen01]

Oke, let me explain how i set it up. i Run Hass on a raspberry Pi and have a comodo certificate which have 2 intermediate certificates and the root CA AddTrust External CA Root.

i have this config in configuration.yaml

http:
  # Uncomment this to add a password (recommended!)
  api_password: <password>
  trusted_networks:
    - <internal network>/24
  # Uncomment this if you are using SSL/TLS, running in Docker container, etc.
  ssl_certificate: /home/homeassistant/.homeassistant/<cert-chain>.crt
  ssl_key: /home/homeassistant/.homeassistant/<priv-key>.key
  base_url: <fqdn>:8123

the important part is that the base_url have to match with the 'issued to' in the certificate. also i can connect to my hass externally where the base_url have a mapping to my external IP. only if i have to connect to hass in my internal LAN then also my url have to be resolvable to the internal address. luckely my router do this by itself and translates the external ip back to the internal adress. Most routers don't and then you have to have a internal dns server which points the FQDN to the internal adress.

after adding the cert chain it started working for me.

in your case the DST Root CA X3-->LetsEncrypt Authority X3 -->myname.synology.me seems correct. that the option is grayed out in the certification path is normal windows behaviour (is with every certificate) as the screen you are viewing is already the certificate and there you can view up in the chain.

which confusing me is that hass won't start. which maybe have something to do that the private key file does not match the server certificate? is it possible that the synology priv key and the lets encrypt are mixed up? I don't have a synology but i think that the synology CA is a selfsigned CA from your synology itself. and for the sonos i think you need the let's encrypt certificate.

so your first approach was correct i think but maybe with the wrong private key file. also when you start hass maybe you can view the home-assistant.log to see what went wrong.

[jolaca01]

Thank you very much, I finally solved it. My new certificate was right but I didn't have it installed in the correct folder. It's srtange but when in docker the path:
ssl_certificate: /config/cert.pem
and the one for:
ssl_key: /config/privkey.pem
Seem to be pointing to different directories, I guess one relative and one absolute. I've copied the new certificate to the folder missing and everything's working now!! Thank you!!

[ameulen01]

Great to hear that it is solved! Hopefully our discussion will make things clear for some other people which are struggling with the same kind of issue.

[jolaca01]

Indeed!! Thanks to your explanation now it would be much clearer to anyone with the same issue. To make the thread more complete I'm going to add how to check that the private key matches with the certificate for the usual let's encrypt certificate, as a member of the let's encrypt forum indicated me kindly:

openssl pkey -in privkey.pem -pubout -outform pem | sha256sum
openssl x509 -in cert.pem -pubkey -noout -outform pem | sha256sum
If both those SHA256 hashes are identical then you have the right private key!
Thanks again ameulen01!!

[tynor88]

So the LetsEncrypt certificates won't work with SONOS? That's a pitty 👎

Everything works for me (playing the media from the generated URL), but SONOS won't play it.

[ameulen01]

Yes, also LetsEncrypt cert will work with Sonos, just read the conversation from me and jolaca01 to find out how. You have to present the entire certificate chain with also the intermediate CA certificate to Sonos to validate your HA server certificate.

[tynor88]

@ameulen01 actually it works nicely with Nginx infront of HA. So I have https://mydomain.com:443 -> http://localhost:8123 and my files plays fine through SONOS.

If I configure HA to run locally with SSL it doesn't work anymore. E.g. https://mydomain.com:443 -> https://localhost:8123

Any idea?

[ameulen01]

Yes, because now the Sonos player with http don't have to access your audio files from your HA server through https and do not have to verify a certificate.

when you turn on ssl with the let's encrypt certificate you need three things for Sonos to do a proper verification:

1. the certificate must not be expired
2. the base url in your HA configuration have to match the common name presented in your certificate. So when your Sonos have to access your HA internally it has to resolve https://mydomain.com:443. Or your router do also translation to your internal ip address when you access your url through your external ip address (from your own LAN) or you have to have a internal DNS server which maps your URL to your internal Home assistant IP adress.
3. the public key from the certificate have to be verified with a CA certificate. because Sonos only have the CA certificate in top of the chain 'DST Root CA X3' it is not the CA from which the Lets Encrypt certificate is signed. for that the Sonos player need also the intermediate certificate 'LetsEncrypt Authority X3'. because Sonos don't have it you have to present it. therefore you have to edit your certificate and merge the 'LetsEncrypt Authority X3' intermediate CA certificate with your HA certificate. you can just open both files with a notepad and create a new file like this:

-----BEGIN CERTIFICATE-----
encoded LetsEncrypt certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
encoded 'LetsEncrypt Authority X3'
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
encoded 'DST Root CA X3'
-----END CERTIFICATE-----

i think you can leave the DST Root CA X3 out because according to this list http://musicpartners.sonos.com/node/339 the Sonos player already have it.

[HydrelioxGitHub]

I've used the @Paxy trick (redirect dns request) and it did it. Thank you for your help.

[jrkoiter]

Had this issue as well: TTS file pulled from Google just fine, with correct address pushed to Sonos, but no play. Comment of @ameulen01 fixed it: use 'fullchain.pem' instead of 'cert.pem' from the Let's Encrypt files.

[jnmacd]

DNS re-direct fixed it for me, thanks @Paxy

I am using pfSense and host my own DNS resolver.
My base_url is something like home.mydomain.com, which resolves to my WAN address.
I can access outside my LAN just fine, but using that address locally never worked. So I had my DNS resolver always resolve that address to my LAN address for HA.. worked just fine.

Google Home apparently does not use the issued DNS nameserver, and always uses 8.8.8.8 or whatever.

Now since its hijacked, google home properly uses the LAN address.

[tschmidty69]

Can this be marked as resolved since it is a configuration issues at this point?