[BETA] Google Chromecast+

@jpage4500 Any idea what this error is about? I tried it with and without a value in the Pre-roll lead-in delay. I believe it is the reason why my Nest hub still truncates the first part of the TTS stream. Note that I did insert the mp3 file in my browser and it is correct. It also works correctly on the Nest mini speakers, but not the Nest hub (with the screen)

I am running your version 1.03

Thanks.

By offline you're talking about connectionStatus? I have 9 cast-enabled devices (3 google minis, 2 JBL speakers, a shield TV and a couple of google powered TV's) -- the only ones that I see offline at any point yesterday/today are the TV's which are off so that's expected.

Since I can't reproduce I won't be able to know if any changes help so the best thing to do to get it working is enable debug logging in the app (it'll auto disable after 24 hours), reproduce the issue and then copy & paste the logs (screenshots aren't as helpful) into a code snippet like this:

dev:19652026-07-09 10:06:21.134 AMdebugGC+ [Google Mini (attic)] media: IDLE
dev:19652026-07-09 10:06:21.074 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.media -> c65dc130-2be3-4709-aeec-f75b313ac8f6: {"type":"GET_STATUS","requestId":5605}
dev:19652026-07-09 10:06:19.812 AMdebugGC+ [Google Mini (attic)] media: PLAYING | Announcement
dev:19652026-07-09 10:06:19.736 AMdebugGC+ [Google Mini (attic)] media: BUFFERING
dev:19652026-07-09 10:06:19.414 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.media -> c65dc130-2be3-4709-aeec-f75b313ac8f6: {"type":"GET_STATUS","requestId":5604}
dev:19652026-07-09 10:06:19.389 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.media -> c65dc130-2be3-4709-aeec-f75b313ac8f6: {"type":"GET_STATUS","requestId":5603}
dev:19652026-07-09 10:06:19.330 AMdebugGC+ [Google Mini (attic)] media: IDLE
dev:19652026-07-09 10:06:18.846 AMdebugGC+ [Google Mini (attic)] media: PLAYING | Announcement
dev:19652026-07-09 10:06:18.823 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.media -> c65dc130-2be3-4709-aeec-f75b313ac8f6: {"type":"LOAD","requestId":5602,"autoplay":true,"currentTime":0,"media":{"contentId":"http://192.168.0.200/tts/600fe9490863f854176dc568a627011f.mp3","streamType":"BUFFERED","contentType":"audio/mpeg","metadata":{"metadataType":0,"title":"Announcement","subtitle":""}}}
dev:19652026-07-09 10:06:18.678 AMdebugGC+ [Google Mini (attic)] media: BUFFERING
dev:19652026-07-09 10:06:18.519 AMdebugGC+ [Google Mini (attic)] media: IDLE | Announcement
dev:19652026-07-09 10:06:18.361 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.media -> c65dc130-2be3-4709-aeec-f75b313ac8f6: {"type":"GET_STATUS","requestId":5601}
dev:19652026-07-09 10:06:18.282 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.media -> c65dc130-2be3-4709-aeec-f75b313ac8f6: {"type":"GET_STATUS","requestId":5600}
dev:19652026-07-09 10:06:18.250 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.media -> c65dc130-2be3-4709-aeec-f75b313ac8f6: {"type":"GET_STATUS","requestId":5599}
dev:19652026-07-09 10:06:17.996 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.media -> c65dc130-2be3-4709-aeec-f75b313ac8f6: {"type":"LOAD","requestId":5598,"autoplay":true,"currentTime":0,"media":{"contentId":"http://192.168.0.200/local/gcplus-silence.wav","streamType":"BUFFERED","contentType":"audio/wav","metadata":{"metadataType":0,"title":"Announcement","subtitle":""}}}
dev:19652026-07-09 10:06:17.989 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.tp.connection -> c65dc130-2be3-4709-aeec-f75b313ac8f6: {"type":"CONNECT"}
dev:19652026-07-09 10:06:17.985 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.media -> c65dc130-2be3-4709-aeec-f75b313ac8f6: {"type":"GET_STATUS","requestId":5597}
dev:19652026-07-09 10:06:17.981 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.tp.connection -> c65dc130-2be3-4709-aeec-f75b313ac8f6: {"type":"CONNECT"}
dev:19652026-07-09 10:06:17.903 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.receiver -> receiver-0: {"type":"LAUNCH","appId":"CC1AD845","requestId":5596}
dev:19652026-07-09 10:06:17.860 AMinfoGC+ [Google Mini (attic)] TTS: "this is a test" (mode=none)
dev:19652026-07-09 10:06:00.129 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.receiver -> receiver-0: {"type":"GET_STATUS","requestId":5595}
dev:19652026-07-09 10:05:53.315 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.tp.connection -> receiver-0: {"type":"CONNECT"}
dev:19652026-07-09 10:05:03.372 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.receiver -> receiver-0: {"type":"GET_STATUS","requestId":5594}
dev:19652026-07-09 10:04:00.118 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.receiver -> receiver-0: {"type":"GET_STATUS","requestId":5593}
dev:19652026-07-09 10:03:48.746 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.tp.connection -> receiver-0: {"type":"CONNECT"}
dev:19652026-07-09 10:03:00.120 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.receiver -> receiver-0: {"type":"GET_STATUS","requestId":5592}
dev:19652026-07-09 10:02:00.103 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.receiver -> receiver-0: {"type":"GET_STATUS","requestId":5591}
dev:19652026-07-09 10:01:48.452 AMtraceGC+ [Google Mini (attic)] TX urn:x-cast:com.google.cast.tp.connection -> receiver-0: {"type":"CONNECT"}

Try to isolate the issue to the smallest possible reproducible steps -- for example for TTS just manually use the Play Text command in the driver - skip any other commands like initialize/refresh/etc. The goal is to not need any kind of workarounds like this anyway so if anything I think these steps would get in the way or break things.

(note: most of these are general debugging steps for anyone but I figured I'd write it once and point users to this post going forward)

If the logs don't have enough info, I'll add more.. but, this is the best I can come up with atm

It's saying one of the drivers wasn't updated. Are you using HPM? I would expect it to happen to everyone if the HPM packageManifest.json was missing something

Oops, missed that you weren't rebooting, lazy reading.

I actually started w/that approach at first, but it wasn't enough, announcements would still go missing. That's when I started "brute-force" rebooting the speakers, but as noted, wife really hates the speakers rebooting randomly when they report offline, due to the various reboot noises and announcements.

It's been a while since I've tried the initialize/refresh approach, so I may re-enable that old rule and try it again, in case there's been a change to the speakers' FW that makes it more effective.

FWIW - I had AI write a description how the whole TTS flow works (partly for myself but figured it'd help anyone who uses it). I added it to the first post

Thanks, nice background info for folks, and nice work on this overall.

You might consider adding a configurable preference to the device driver to run the Initilze command at regular intervals (user chooses minutes between initialize commands). I just used the device's Initialize command and it did bring my Nest speaker back to life and allow it to play an announcement.

I use this method and use cron to send the sequence every hour. I have 9 assorted Google assistants and I can count on one hand the number of times they have stopped responding over the years. I did not have any success using the similar option within the built in Google integration.

1 Like

To help debug this - the next time the device is in a bad state - first look at the device page and report what the conn State Variable and connectionStatus attribute. Then, try sending playText only and send the logs

1 Like

I'll let things run as they have been and should be able to capture something worthwhile.

@jpage4500

OK, I did have duplicate drivers installed. Reinstalled using HPM and now no errors, however, the initial text is still being cut off on the Nest Hub (video). Using speak text on the Nest Hub device child. The delay is there but the first sentence is cut off. The pre-roll is enabled with a 2 second delay. It works on the Nest Mini speakers but not the Nest Hub. The mp3 file is correct.

Any idea of how I can troubleshoot.? Logs are below. Thank you!

Here's what I've got so far:

  Here's the mechanism: the pre-roll warms the speaker with one media item (silence), then replaces it with a second item (the mp3). A
  Nest Mini keeps its audio pipeline running continuously across that swap → clean start. A Nest Hub is a display — on each new LOAD it
  cold-starts a fresh presentation for that item (new "Announcement" card + display path), and audio output doesn't begin until that
  presentation is up ~1–1.5s later. The warm-up is thrown away at the swap, so the first sentence of the mp3 plays (position advancing)
  before the Hub is actually making sound.

  That explains both things you're seeing: it clips on the Hub but not the Mini, and raising the lead-in didn't help — the delay
  lengthens the silence, but the latency is after the swap, which no pre-swap delay can cover.

  Cheap way to confirm before I build anything: on the Hub, use Play Track with any plain music URL. If the start of that is clipped
  too (not just TTS), it proves the Hub cold-starts every media item — and the fix has to make the speech not be a fresh item.

The important thing to test here is: use Play Track with any plain music URL. Set this in the Play Track field: https://github.com/jpage4500/hubitat-drivers/raw/refs/heads/master/google-chromecast-plus/test.mp3

It's just a TTS file that says "this is a test of the emergency broadcast system". It worked great on my google mini. See if it's clipped for you at all. The answer will help drive the fix.

I also updated this app with some extra logging (1.0.4). I'll feed it back to AI when anyone sends me the results and go from there. It does sounds like a fix is possible to all of this.. just want to make sure I (AI) figures out the root cause first.


btw - sendings logs in a code snippet is preferred over a screenshot since AI needs to first convert it to text.. it's great at that but ultimately it's extra tokens/$$

The track played great on the Nest Hub using “Play Track”. No problems. It played well and was not clipped.

I then tried to Speak two sentences on the same Nest Hub and it again was clipped. It only spoke the second sentence.

1 Like

Try unchecking "Pre-roll silence" setting in the app and click Done. Then try playing the 2 sentences again and see if anything changes

  The only thing Speak does that Play Track doesn't is the pre-roll swap — LOAD silence, then replace it mid-playback with the TTS.
  That swap is what clips, specifically on the Hub:

  - Play Track = one LOAD into an idle device → clean ✅
  - Speak = LOAD silence → (swap) LOAD TTS while silence is playing → the Hub drops the start of the replacement ❌

Assuming that doesn't work (because why would it :grinning_face:) there's 1 other thing I can think of and that would be changing that silence.wav file to silence.mp3

Maybe the Nest has an issue switching between a silence.wav file and a Hubitat generated .mp3 file.. that's worth a shot too

Also - copy/paste logs since there might be something in there which will take this in a different direction

I unchecked “Pre-roll silence” and it did not make a difference. The first sentence was clipped. It only played the second sentence.

Not sure how to change the silence.wav file to silence.mp3. Are there some lines in the app code that you want me to change on my end? If so let me know

Thanks for all your help. If you want to take a break from this I would understand.

EDIT: Here is a code snippet of the log with Pre-roll silence unchecked:

```
dev:17872026-07-10 7:23:23.485 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> e70c6394-67f5-44da-882b-44e7c9be5569: {"type":"GET_STATUS","requestId":660}
dev:17872026-07-10 7:23:22.473 amdebugGC+ [Kitchen display] media: IDLE
dev:17872026-07-10 7:23:22.471 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.receiver -> receiver-0: {"type":"SET_VOLUME","volume":{"level":0.65},"requestId":659}
dev:17642026-07-10 7:23:22.372 aminfoKitchen display - [Google Nest Hub] is idle
dev:17872026-07-10 7:23:22.342 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> e70c6394-67f5-44da-882b-44e7c9be5569: {"type":"GET_STATUS","requestId":658}
dev:17872026-07-10 7:23:20.260 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> e70c6394-67f5-44da-882b-44e7c9be5569: {"type":"GET_STATUS","requestId":657}
dev:17872026-07-10 7:23:19.453 amdebugGC+ [Kitchen display] media: PLAYING | Announcement
dev:17642026-07-10 7:23:19.432 aminfoKitchen display - [Google Nest Hub] is playing
dev:17872026-07-10 7:23:19.406 amdebugGC+ [Kitchen display] media: BUFFERING
dev:17642026-07-10 7:23:19.389 aminfoKitchen display - [Google Nest Hub] is buffering
dev:17872026-07-10 7:23:19.365 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> e70c6394-67f5-44da-882b-44e7c9be5569: {"type":"GET_STATUS","requestId":656}
dev:17872026-07-10 7:23:19.337 amdebugGC+ [Kitchen display] media: IDLE | Announcement
dev:17872026-07-10 7:23:19.254 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> e70c6394-67f5-44da-882b-44e7c9be5569: {"type":"LOAD","requestId":655,"autoplay":true,"currentTime":0,"media":{"contentId":"http://192.168.11.100/tts/3a9210e05a56e555a1ffb67e908c29a1.mp3","streamType":"BUFFERED","contentType":"audio/mpeg","metadata":{"metadataType":0,"title":"Announcement","subtitle":""}}}
dev:17872026-07-10 7:23:19.247 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.receiver -> receiver-0: {"type":"SET_VOLUME","volume":{"level":0.65},"requestId":654}
dev:17872026-07-10 7:23:19.245 amdebugGC+ [Kitchen display] TTS: begin (conn=APP_CONNECTED, transport=set, mode=restore)
dev:17872026-07-10 7:23:19.239 aminfoGC+ [Kitchen display] TTS: "This is a test. This is another test" (mode=restore, volume=65, voice=Salli)
```


EDIT: Here are the logs with the Pre-Roll checked with a 2 sec delay using your Version 1.05. Note the first sentence is still truncated.

```
dev:17872026-07-10 8:08:36.937 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"GET_STATUS","requestId":702}
dev:17872026-07-10 8:08:35.922 amdebugGC+ [Kitchen display] media: IDLE
dev:17872026-07-10 8:08:35.920 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.receiver -> receiver-0: {"type":"SET_VOLUME","volume":{"level":0.65},"requestId":701}
dev:17642026-07-10 8:08:35.859 aminfoKitchen display - [Google Nest Hub] is idle
dev:17872026-07-10 8:08:35.827 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"GET_STATUS","requestId":700}
dev:17872026-07-10 8:08:32.913 amdebugGC+ [Kitchen display] media: PLAYING | Announcement
dev:17642026-07-10 8:08:32.885 aminfoKitchen display - [Google Nest Hub] is playing
dev:17642026-07-10 8:08:32.862 aminfoKitchen display - [Google Nest Hub] is buffering
dev:17872026-07-10 8:08:32.860 amdebugGC+ [Kitchen display] media: BUFFERING
dev:17872026-07-10 8:08:32.765 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"GET_STATUS","requestId":699}
dev:17872026-07-10 8:08:32.727 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"GET_STATUS","requestId":698}
dev:17642026-07-10 8:08:32.672 aminfoKitchen display - [Google Nest Hub] is idle
dev:17872026-07-10 8:08:32.667 amdebugGC+ [Kitchen display] media: IDLE
dev:17872026-07-10 8:08:32.607 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"LOAD","requestId":697,"autoplay":true,"currentTime":0,"media":{"contentId":"http://192.168.11.100/tts/2a766eb9468cabbc782a0d063fa73100.mp3","streamType":"BUFFERED","contentType":"audio/mpeg","metadata":{"metadataType":0,"title":"Announcement","subtitle":""}}}
dev:17872026-07-10 8:08:30.581 amdebugGC+ [Kitchen display] media: PLAYING | Announcement
dev:17642026-07-10 8:08:30.550 aminfoKitchen display - [Google Nest Hub] is playing
dev:17642026-07-10 8:08:30.416 aminfoKitchen display - [Google Nest Hub] is buffering
dev:17872026-07-10 8:08:30.411 amdebugGC+ [Kitchen display] media: BUFFERING
dev:17872026-07-10 8:08:30.112 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"GET_STATUS","requestId":696}
dev:17872026-07-10 8:08:30.067 amdebugGC+ [Kitchen display] media: IDLE | Announcement
dev:17642026-07-10 8:08:30.062 aminfoKitchen display - [Google Nest Hub] is idle
dev:17872026-07-10 8:08:29.932 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"GET_STATUS","requestId":695}
dev:17872026-07-10 8:08:28.982 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"GET_STATUS","requestId":694}
dev:17872026-07-10 8:08:28.949 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"GET_STATUS","requestId":693}
dev:17872026-07-10 8:08:28.918 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"LOAD","requestId":692,"autoplay":true,"currentTime":0,"media":{"contentId":"http://192.168.11.100/local/gcplus-silence.wav","streamType":"BUFFERED","contentType":"audio/wav","metadata":{"metadataType":0,"title":"Announcement","subtitle":""}}}
dev:17872026-07-10 8:08:28.916 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.receiver -> receiver-0: {"type":"SET_VOLUME","volume":{"level":0.65},"requestId":691}
dev:17872026-07-10 8:08:28.914 amdebugGC+ [Kitchen display] TTS: begin (conn=APP_CONNECTED, transport=set, mode=restore)
dev:17872026-07-10 8:08:28.912 amdebugGC+ [Kitchen display] conn: APP_LAUNCHING -> APP_CONNECTED (DMR launched)
dev:17872026-07-10 8:08:28.911 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.tp.connection -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"CONNECT"}
dev:17872026-07-10 8:08:28.909 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"GET_STATUS","requestId":690}
dev:17872026-07-10 8:08:28.907 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.tp.connection -> 5139b2ed-18a7-462f-bc5c-b9cb5d353f2a: {"type":"CONNECT"}
dev:17642026-07-10 8:08:28.905 aminfoKitchen display - [Google Nest Hub] media source is Hubitat
dev:17872026-07-10 8:08:26.974 amdebugGC+ [Kitchen display] conn: READY -> APP_LAUNCHING (launching DMR)
dev:17872026-07-10 8:08:26.972 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.receiver -> receiver-0: {"type":"LAUNCH","appId":"CC1AD845","requestId":689}
dev:17872026-07-10 8:08:26.901 aminfoGC+ [Kitchen display] TTS: "This is a test. This is another test." (mode=restore, volume=65, voice=Salli)
```

1 Like

It will be great when the bugs die so I can test and maybe remove all my piston mods for the current devices.

I have been on the built-in app since inception. It took me a few years to figure out the way to init the devices, set default vol on boot and reliably say text when called upon.

The new ver of HE’s app still needs my tweaks but the ‘blip’ is now gone when I set the init vol. :wink:

Actually, before I get to that whole silence.mp3 thing I want to recap something...

  1. playing back a TTS generated .mp3 by an online service and hosted on a github repo worked.. no silence

  2. playing back a TTS generated .mp3 by Hubitat didn't work - clipped

There's not many differences between these 2 cases so one of them must be the issue right?

Here's some of the differences I can see (I used AI to come up with any differences it could see as well)

  • mp3 hosted by github.com vs local hub
  • mp3 generated by an online service vs Hubitat TTS engine
  • Play Text (TTS) sets the title to "Announcement". Play Track sends an empty title. I think this is what causes my Google Mini to play a little beep before playing back the message. Play Track doesn't play any beep first.

We can quickly rule out the Hubitat generated TTS mp3 file..
@Sakman (or anyone else who can reproduce this issue) - can you use Play Track with this URL: https://github.com/jpage4500/hubitat-drivers/raw/refs/heads/master/google-chromecast-plus/hub-tts.mp3

It's the same test TTS but this one was generated by my Hub. I expect it'll work just fine like it does for me

@Sakman - 1 more note/question -- AI noticed your log was sending a 'set volume 65' before playing back TTS. Can you remove that? I want to do a clean test to try and isolate the issue. Just use the Play Text (no volume) command in the device driver -- also with that silence option still disabled in the app

But your trace shows volume=65 and an actual SET_VOLUME {"level":0.65} on the wire — so this device has that preference set to 65

For anyone else who's also looking to use this for TTS and have issues -- what device are you using? Can you also run the same tests to try and get more data

Just select text on that screen (try to capture everything from before the issue to after it) -> copy -> then in a new message click that "</>" icon and paste the text between the "```" marks

1 Like

Here's how we can test this step too..

  1. run Play Text with a message
  2. search the hubitat logs for ".mp3" - you should see something like this:
  3. copy that URL and paste it into Play Stream URL

1 more thing I'd like anyone with the clipping issue to try...

  • turn OFF Pre-roll silence option on app (image below)
  • pass this string to Play Text: <break time="2s"/>this is a test


You can adjust that break time value but try it and see if this plays the whole message.

Interesting, running this Hubitat generated mp3 file and the message was truncated.

```
2026-07-10 9:58:19.463 aminfoKitchen display - [Google Nest Hub] is idle
dev:17872026-07-10 9:58:19.461 amdebugGC+ [Kitchen display] media: IDLE
dev:17852026-07-10 9:58:17.972 amtraceGC+ [Bathroom speaker] TX urn:x-cast:com.google.cast.tp.connection -> receiver-0: {"type":"CONNECT"}
dev:17882026-07-10 9:58:17.962 amtraceGC+ [Elaine's study speaker] TX urn:x-cast:com.google.cast.tp.connection -> receiver-0: {"type":"CONNECT"}
app:23422026-07-10 9:58:16.715 aminfoAlready Activated
app:23422026-07-10 9:58:16.714 aminfoActivation Event: 'Study motion sensor (Hue)' motion active
dev:17642026-07-10 9:58:16.319 aminfoKitchen display - [Google Nest Hub] is playing
dev:17872026-07-10 9:58:16.317 amdebugGC+ [Kitchen display] media: PLAYING
dev:17642026-07-10 9:58:16.239 aminfoKitchen display - [Google Nest Hub] is buffering
dev:17872026-07-10 9:58:16.237 amdebugGC+ [Kitchen display] media: BUFFERING
dev:17872026-07-10 9:58:15.809 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.media -> 080d8176-e5ec-4826-9385-b629d71f71dc: {"type":"LOAD","requestId":749,"autoplay":true,"currentTime":0,"media":{"contentId":"https://github.com/jpage4500/hubitat-drivers/raw/refs/heads/master/google-chromecast-plus/hub-tts.mp3","streamType":"BUFFERED","contentType":"audio/mpeg","metadata":{"metadataType":0,"title":"","subtitle":""}}}
dev:17872026-07-10 9:58:15.807 amdebugGC+ [Kitchen display] conn: READY -> APP_CONNECTED (DMR already running, transport reconnected)
dev:17872026-07-10 9:58:15.805 amtraceGC+ [Kitchen display] TX urn:x-cast:com.google.cast.tp.connection -> 080d8176-e5ec-4826-9385-b629d71f71dc: {"type":"CONNECT"}
dev:17872026-07-10 9:58:15.803 aminfoGC+ [Kitchen display] playMedia: https://github.com/jpage4500/hubitat-drivers/raw/refs/heads/master/google-chromecast-plus/hub-tts.mp3 (mode=none)
```


But running the mp3 file from your post above in Play Tracks and it works. Also I ran the Hubitat generated mp3 file on my Nest Mini and it works there.