I’ve noticed the same thing. As a workaround for my reminders I set the volume and then delay 10 seconds before playing. 10s is probably overkill but I haven’t had time to tweak it yet.
it’ll work great as long as your CC is idle. After being idle for about 5 min it’ll go off.
When you play something then, first you’ll hear the annoying connection noise and you may lose the beginning of your announcement hence the script above…
Okay, I will give this a shot tomorrow. I noticed that the Chromecast played a connection sound some of the times which would be nice to get rid of.
But it seems that your automation only triggers every 2 minutes. The issue with the beginning of the announcement getting dropped happens far more often that that.
that’s why I have this automation, I NEVER miss the beginning of an announcement and I only hear the connection sound when I restart HA (which takes a few minutes.
I have to say credit’s where credit’s due though, the original idea/automation came from @hoffsta, check his post here
Triggering lolouk44’s automation every 2 minutes should be often enough the keep the Chromecasts always connected/awake. It prevents them turning off as this power saving mode happens after about 5 minutes of being idle.
I’m assuming the audio1sec.mp3 file is one second of silence? EDIT: it is. I just read the link to hoffsta’s post.
It’s an interesting solution. I will probably change to it so I dont need the delay for instant TTS alerts. I only use TTS for reminders at the moment and they are not time critical but I have plans to use this more often.
In fact at some stage I am going to overhaul my entire alerting method to have one alert script that decides where (three apple devices, three Chromecasts, TVs, Kodi boxes, ect…) to send text messages, TTS, or play sounds and have each automation just pass the message and a priority to this script. Got a lot of other basic things to fix/develop first though.
I ran into a problem using the method with media_player.volume_set.
When trying to set the volume to for example 0.5, when the volume was already 0.5, the issue with the sound beeing cut at the beginning was still present. And setting different sound levels, 0.51 and 0.52 for different TTS announcements feels like a bad idea.
I also tried to mute and unmute the sound before playing the TTS message, but the problem was present there too.
Delay for 0.1 seconds (without this delay, the problem persist)
Then play the TTS announcement.
In combination with the automation from @lolouk44 the Chromecast Audio doesn’t go to sleep and the TTS are played without cut-outs (as of now). I will continue with my testing and let you now of any further failures.
Today I have found yet another way to solve the issue at hand. And it works without both the automation playing a 1 seconds silence every two minutes (which by the way stops the music when playing from a music app on the iPhone) and without changing the volume before every TTS announcment.
For some reason I cannot explain it works perfect (at least in my setup)
if you look at my automation it’ll check that the GH is not already playing before it plays the 1 sec audio
(actually I check that each individual GH and the group with both my GH devices isn’t in playing state )
Your method with work too though you’d have an ever slight delay before you hear the announcement, and most likely you’ll also hear the connection chime which I hate…
if you look at my automation it’ll check that the GH is not already playing before it plays the 1 sec audio
Yes, I noticed that But that only work if I stream music from Home Assistant to the Chromecast Audio. When I stream music from Spotify and apps alike to the Chromecast, Home Assistant is unaware of the status of the Chromecast Audio. It is seen as off.
Your method with work too though you’d have an ever slight delay before you hear the announcement, and most likely you’ll also hear the connection chime which I hate…
That was the weird thing. When using the wait_template and the delay I don’t hear the “connection chime”, it just starts playing the TTS announcement, perfectly complete. Even if the Chromecast is in the idle or off state.
Maybe you could give it a shot and see how your device behave? There might be some difference in how the Google Home and the Chromecast Audio operate. I would be really interested anyway because I intend to buy a Google Home Mini soon
Interesting. Google Home acts as a ChromeCast audio so from from HA’s point of view it makes not difference. I actually use ChromeCasts to play music and my GH’s for announcements (and regular interactions)
I’ll see if I get some time to try your method…
Also I personally find that audio/mp4 is more reliable than other formats. Can you can try for both the doorbell play and the keep alive?
Also you mentioned TTS, but it looks like you’re playing some MP3 file. Where is the TTS?
What happens when you manually play the mp3 on the media_player via the Services tab?
Not that it should, but wondering if setting the volume makes the CC “busy”.
Have you tried to add a delay of like 1 sec between volume set and play? I don’t have that issue personally, but worth a try
For me it’s the same, not entirely sure why. I ended up loading the sound files on my webserver (apache) and linking to it using the server’s IP address rather than going online for it.