Rather than give you an answer, I’d suggest an approach that is likely to help you with both this and future issues:
If an automation breaks with a new release:
check the log messages - what error is given?
The line number may be off, but the error is usually accurate.
Does the release have any breaking changes?
(in this case, there is a LARGE jump of almost 6 months, so less useful)
Consider a separate pre-production / test install of HASS on a VM / RPi.
Create a full backup, separately backup key files like automations.yaml, and copy to a separate machine. Then…
Create a NEW test automation using the GUI to perform some or all of the problematic actions.
Study what the automated tools have created - the syntax and service names may have changed.
Writing complex automations using the GUI isn’t always ideal, but it is a good way of generating correct YAML for testing.
Your code mixes MQTT, media player, and TTS so it’s unclear which area is the problem however:
There were changes to the syntax around MQTT sensors (reversed the heirarchy), so this may need rework to publish.
Playing an audio file still works for me using media_player.play_media, but with a local saved WAV file.
there are no errors in the logs regardings this
i use a docker based installation
tts.google_say brought an error because the tts configuration did not change the service name from google_translate_say, i change that so that error vanished again, but i still get this media-source
i tried to add the notify service as in Notify using TTS - Home Assistant
but that doesn’t change anything, i still get this media-source-url thingy
you describe basically my system configuration which worked before the update to 2022.9.1
the thread title is now misleading, i found out so far that the change of behavior is in the google_tts service
my opinion, becasue that’s the component which now sends different data
a simple static service call with a static text to give out a speech results in a media-source-url i have given an example above
my whole call chain ist:
a script which takes a text message and a language code, sends them to tts.google_say and a mqtt topic (for text output on a display)
tts sent ( past tense, before the update ) an http-url to the universal media player; now just this weird “media-source://”-url. the cache directory is /config/tts, last file created there is from yesterday, when i created a new automation given an audio response to a new sensor threshold
the ump sends the absolute http-url (past tense) to my “esp32 media players” which play them using esp-audio. yes, this is older than the esphome mediaplayer support, but worked for nearly a year and is totally unrelated to the error
the ump works if given a working http-url
do i have some kind of authentication with google tts? i didn’t had that before…
i also tried googling this weird kind of url prefix as
“media-source” “tts/google_translate” https://www.google.com/search?q=“media-source”+“tts%2Fgoogle_translate”
but i find only people with problems, but no solutions
some suspect it has to do with internal url, which i have configured, i do not have an external url.
i only use HA at home inside my private network.
i am on
Home Assistant 2022.9.1
Frontend 20220907.0 - latest
in form of an docker image
is this some kind of developer version which may have bugs ?
this would explain a lot
Use the terminal emulator to look in /root/config/tts - HASS calls Google TTS, caches the audio as an MP3, then serves it out locally on the LAN from the cache directory. (Interestingly, cache_dir: /tmp/tts seems to be ignored, perhaps relocated by a container jail).
The same method works to play local MP3 files, although some setup may be needed to create a local directory to store audio (e.g. /media/sounds/sound.wav = media-source://media_source/local/sounds/sound.wav.
ISTR using dev tools to call the Media Player: Play service with a known good local URI to test this with a ChromeCast. IPv6 / mDNS / hostname issues also are worth checking.
The only other factor I’m aware of is if you pay Nabu Casa - if so, access to extra TTS voices is available. I now pay, but thought TTS worked before.
ok. i got the same problem.
so the only solution is to store MP3 files and let the local tablets and sonos or other media play the local mp3 files? ouch