I’ve been able to play media and TTS through Google Cast devices for a long time, but sometime in the last week or two it stopped working on just one device, a Nest Audio Speaker, even though I’ve made no changes on my end. My other Google Cast devices work fine.
I’ve experimented with all the integrations that seem relevant, and they all exhibit the same symptom: the Nest Audio Speaker makes a notification sound, and nothing else.
I am using a self-signed certificate for my HA instance, but I’m not sure how that would lead to the symptoms I’m observing. I am connected to Nabu Casa.
Integrations I’ve tried, all of which exhibit the same behavior (works on Google Cast devices other than the Google Nest Audio)
Same here with nabucasa cloud tts. All my other google nest audio work fine. Don t understand what happen…
See that in my log :
Enregistreur: homeassistant.components.cast.media_player
Source: components/cast/media_player.py:405
intégration: Google Cast (documentation, problèmes)
S'est produit pour la première fois: 12:13:10 (1 occurrences)
Dernier enregistrement: 12:13:10
Failed to cast media http://192.168.1.41:8123/api/tts_proxy/0b1ab1b10b35959a150acb914ecf991bde23173e_fr-fr_e43c31a13b_cloud.mp3 from internal_url (http://192.168.1.41:8123). Please make sure the URL is: Reachable from the cast device and either a publicly resolvable hostname or an IP address
Same issue here, on two nest minis. Connected with nabu casa and have tried unplugging and reconnecting power to the minis. Tried changing ‘local network’ under network settings to/from auto to a fixed ip adress.
The only thing I know thats changed on my end since it stopped working is updating music assistant and installing latest two HA versions 2024.9.1 and 2024.9.2.
I noticed my TTS wasn’t working after upgrading to 2024.9.2 but I just ignored it because I noticed at night and I was tired. I just went to test it out now (the next day) and at first, my TTS script I had didn’t work, but then I went in to devices, found the media player I was trying to use and noticed it was “off”. I used the power button in HA and turned it on, then tried my TTS script and it worked.
Either the media player needs to be “on” before TTS will get passed to it now, or it was something temporary and resolved itself (or maybe it was a one-time state that fixed itself when I turned it on manually). I did tweak my script so it checks the media player state first and will turn it on before trying to send TTS.
Unlike others mentioning they’re getting errors, I had no errors recorded at all - it would set the volume and I’d hear a little boop, but nothing would be said afterwards.
Yeah, but it’s on & off, or, up & down, or…
You get the picture
Seems to me that the tts part is working, on my end at least. Eg. generating.
But the “unknown, no id3” .mp3 file resulting, is thrown away by MA, somehow.
The “turn-on-before-play” work around stopped working for me for a month or 2.
It was my last solution, now it seems harder to work around.
Again. It all comes down to DNS, Google Devices, and Home Assistant.
Drop the Google DNS to something else (Preferably local) and you’ll never have these issue.
This a 3-4+ year old issue. Has been going on for a while. The immediate option to fix was to move to Nabu Casa and yadda yadda. Sorry, fix it at the source. Drop Google DNS and redirect elsewhere. I can almost guarantee with 99.99% certainity your issue will fix.
But, take what I say with a grain of salt. I am but a mere early HA adopter, owner of the very first run HA shirts, and around before CSS and Lovelace was ever a thing.
It’s DNS, as others have pointed out. For me, here, it turned out that even though my router’s DHCP server gives clients my local DNS servers, the Nest speakers would use Google’s DNS at 8.8.8.8 / 8.8.4.4 anyway. So myhomeassistant.mydomain.local wouldn’t look up (of course) so the speaker would “ding” and start up but no speech. A couple of NAT rules to re-direct my disobedient speaker’s request to 8.8.8.8 to the local DNS cleared it right up.
Seriously, don’t just blindly do this but if you’re familiar enough with iptables to add and remove NAT rules, this worked for me:
Funny you should say that just now… I have a second HA (the less experimental one I actually use) and, trying a different speaker, have my TTS-related automations back working completely by adding two steps before the TTS play: Powering the speaker off (counterintuitively) and waiting 1s. That might have controlled for a race condition - if quite by accident since I hadn’t thought of that.
Back when I noticed TTS not working for me in 2024.9.2, I modified my scripts to check if the media player is in an off state. If it is, I send the turn_on command, then I wait for the media player’s state to change to on or idle (with a 5s timeout), and then I continue with setting volume and the TTS. I actually did this so that I could access and save the volume (since it didn’t seem to be exposed unless in an on/idle state) in a scene
Prior to 2024.10.2, even that wasn’t working every time; it would adjust the volume but not play the TTS in some cases. It seems better now that I’ve updated.
Do you think it’s the powering off that’s making it work for you, or the 1s delay? Also, does it work first time? When I had the issue, it failed on the first TTS attempt, but a subsequent try would work, until you waited a while and then the first try would fail again.
If it being off were the case then sending the first failed attempt would turn it on, and the second attempt would fire off normally. No matter how many times I did it (when it was failing) it would never send TTS to any device. That was years ago, and I gave up on it.
As soon as I got to hijacking the Google DNS it instantly worked. I can disable/enable TTS through home assistant on command by turning off/on a firewall rule.
I think people are just getting lucky with it working through trial and error. It could also be the DDNS services being used might just not be liked by Google.
Hard to deny reproduceable results WRT DNS though. I added a rule in the firewall earlier this year on a whim after finding a solution and its been rock solid. After so many years I gave up on it, nice that its working again.
