I copied the mp3 file into the play track and the message is still truncated.
It works. It played the whole message
Can't be this simple of a fix, can it???
Either way - it's a lot simpler than trying to play a silence audio file and then the TTS file so I'm going to refactor the app to use it.
I'll remove the app level setting for silence and make it per device (default off) since it seems to happen to certain devices. My google mini doesn't seem to need any kind of extra silence - at least not in my limited testing.
I pushed a new version 1.0.6 with the following changes:
- remove the app level silence settings and replaced them with a driver level lead-in silence setting. It's defaulted to 0/off so make sure to set it for any device that has this clipping issue
- refactor how silence is added to TTS.. before app would play a silence .wav file and then play the original TTS .mp3; Now it uses SSML when generating the TTS mp3 file to add the silence to the generated mp3 -- no separate silence wav file needed
- added a new driver option 'stop after TTS is complete'; this matches what the built-in driver does too -- if checked, every play TTS will have that initial beep message vs today the first one typically will but subsequent messages right after won't
I still have 1 more idea up my sleeve but want to get feedback on this first..
Works like a charm! I added a 1 sec delay to the Nest Hub and the TTS worked correctly. Did not need to add a delay to the Nest mini speakers.
Thanks for sticking with this and developing a solution. Much appreciated.
Looks like that (1.0.6) has done it for me with the Nest Hub Max. 
I set a delay of 1 second and it’s cleanly playing the text with and without a volume change. I also enabled the option to stop after playing the announcement.
Really appreciate you sticking with us and figuring this out. Now I need to update my rules and such to use this integration.
In case this is still useful/relevant. Nest Speaker went into the "Offline" state, so I'm able to do above tests. Play text fails at this point.
Device info:
Logs:
Ping failing in this case (I've previously seen "Offline" state in Chromecast integrations but the speaker was still pingable. Not sure if that had ever been the case in this chromecast integration.
Initialize command in driver brought Connection Status back to Idle. However Playback Status is still Offline, and Play Text still fails.
Connection status returned to Offline just after added the last couple of screen caps above.
To be clear, I think my Nest hub Offline issues are device (and maybe network) specific), not related to this integration. Never used to go offline, but likely some "upgrade" from Google messed things up for me at some point. My Google Home OG and Google Home Mini do not go offline.
Summarizing what AI got out of the logs... when the Hub tries to connect to that device the connection hangs and blocks any other connection made after it. That 130 second timeout isn't something we can control or reduce.
Calling initialize doesn't actually fix anything - just sets the state to Init (which will force it to re-connect but nothing can really happen until that first connection times-out)
Root cause — a blocking TLS connect. Every method … ran for 130,xxx ms warning is interfaces.rawSocket.connect(…secureSocket:true…)
blocking. Hubitat's rawSocket connect is synchronous with no connect-timeout option, and a device that drops SYN packets (powered but
flaky — exactly what "ping fails but it's not fully dead" looks like) takes the full OS TCP timeout, ~130s, to fail. So:
1. The app poll stalls for minutes. pollDevices calls each child's refresh() serially on one thread, and refresh() called connect()
inline. One stuck device blocks the whole poll and every device behind it — that's your pollDevices … ran for 524,010 ms (≈4 stacked
130s connects in a single cycle), plus all the overlapping poll warnings.
2. User commands hang 130s then fail. playText/speak → announce → enqueue → pump (state IDLE) → connect() inline → 130s block →
action dropped. That's playText … ran for 130,067 ms, and it re-paid the 130s on every retry because the offline guard was only in
refresh(), not the command path.
3. Initialize only half-recovered. It reset state.conn/connectionStatus but never cleared playbackStatus (left at OFFLINE by
markOffline) — exactly the reporter's "Connection Status = Idle but Playback Status = Offline." And since the device was genuinely
unreachable, the connect Initialize schedules 2s later blocked 130s and re-marked it offline ("Play Text still fails / went back to
Offline just after"). Initialize can't revive a truly-unreachable device.
...
What this does and doesn't fix
- Fixes: the 130s stalls on the app poll and on user commands, the cascading poll pile-up, and Initialize's misleading half-reset.
- Can't fix (platform limits): we can't shorten the ~130s connect (no timeout knob in rawSocket), and nothing can make TTS play to a
device that's actually unreachable. Recovery still relies on the 300s markOffline retry reconnecting once the device comes back — but
that retry no longer hurts anything now that it's off the foreground threads.
It did make 1 change which was to prevent blocking other devices when 1 device is stuck like this.
If you have any other ideas of things that could help to un-stick it let me know.. only thing that comes to mind is a reboot but I'm guessing you've tried that many times before too
Glad some good may come from my misfortune. 
I've reconfirmed that Initialize doesn't seem to help, so at this point for my issues a reboot seems the only option.
Yeah, I've been rebooting the Nest hub when it gets offline, but not a great solution as wife has made it clear the "constant" rebooting (and it does seem to be necessary almost daily) is not to be allowed. 
I think I'm just going to have to switch to one of my HomePods for Family Room announcements for now. For whatever reason my Nest hub can no longer stay connected to my network (regardless of using either 5 or 2.4 network).
Are you using mixed network with the same SSID? That was causing issues for me. So, I took the 2.4 off of my main network and set it up on my "IOT" network as a standalone 2.4(not segmented since I just use my wifi router in AP mode). I did this years ago and has helped immensely
Just watching the development unfold.
Haven’t jumped the fence from HE app yet as there seems to be a few situations still being handled.
Query. Is this a normal day in the logs for a device or are things still being tuned?
I have a lot of Google CC stuff but mainly subscribe to 3 groups and one speaker for HE use.
These are logs today from one Mini and one group, of mixed devices, that covers the house.
Thanks for the suggestions...I have a separate network/SSID for my 2.4 network for IoT devices, so nothing mixed (don't like that myself, either).
I think it's a Google Nest hub issue...none of my other speakers (Google Home OG, Google Home Mini, HomePod Minis) fall off the network like the Nest hub is doing. Glad I got it as a freebie from one of my sons, I'd be upset if I'd paid money for it.
I've moved all of my announcements that were on my Nest Hub to one of my HomePods. So I'm a well mixed home...two Google speakers and two HomePod Minis, and we are all getting along. 
Very nice integration, @jpage4500, as usual, anything you touch is quality stuff.
According to AI this is normal/expected behavior.
Verdict: not a functional problem — the driver is recovering exactly as designed
Every line in that screenshot is the reconnect machinery doing its job. Read bottom-up, each device shows the same healthy sequence:
socket drops → driver notices → driver reconnects. The two devices are also hours apart (Master Bedroom ~02:27, Everywhere group
~04:22), so this is occasional idle-drop churn, not a tight loop.
Master Bedroom (dev:2735)
1. 02:27:16.593 warn — socket down (socketStatus:receive error: Read timed out) — Hubitat's raw-socket layer reported the read timed
out; socketStatus() caught it and tore the socket down. Correct.
2. 02:27:16.641 error — InterruptedException … (method socketStatus) — 48 ms later. This is platform noise (see below).
3. 02:29:00 warn — GET_STATUS unanswered x3 … forcing reconnect + socket down (status-timeout) — the reconnected socket went stale (a
"zombie" connection — TCP alive, but the receiver stopped answering polls). The zombie watchdog counted 3 missed polls and forced a
clean reconnect. This watchdog exists precisely for this case — working as intended.
Everywhere group (dev:2742)
1. 04:22:20.686 warn — socket down (socketStatus:send error: Broken pipe (Write failed)) — the far end had already closed; our next
write failed. Caught, torn down. Correct.
2. 04:22:20.712 error — InterruptedException … (method socketStatus) — platform noise again.
3. 04:22:45.723 warn — heartbeat: no data for >35s - reconnecting + socket down (heartbeat-timeout) — the 35 s watchdog backstop
firing. Correct.
Groups ("Everywhere group") and idle Cast devices routinely drop their 8009 sockets — this is normal Cast behavior, not something the
driver caused.
The one thing that's ugly: the error-level InterruptedException
This is the only line that looks alarming, and it's essentially cosmetic. When the socket dies, Hubitat interrupts the thread blocked
in the socket read/write; that interrupt surfaces as RuntimeException: InterruptedException and gets attributed to socketStatus (the
socket callback on the stack). It's a side effect of the teardown, logged at ERROR by the platform's uncaught-exception handler — it
does not stop the reconnect (you can see recovery proceed right after it every time).
I'll lower the logging on the error and warnings to debug so you'll only see them if debug is enabled on the app.
Just starting to test he new integration.
First thing I notice, from a WebCore perspective, is that setVolume doesn’t seem to work with Groups.
I have a 2 second delay for setVolume to ‘set’ before the speak.
Events shows the action but I hear no volume difference.
Finished and returning old volume:
messaging piston
I tried it with a single mini and it works.
I tried it with 2 different groups and it sets the volume to 80 but fails to say anything.
I tried a leading delay of 2 sec, nada.
Where to test from here? Re-install? I’m on the latest build 1.07.
Second large Martini on the way so testing suspended due to possible result skew.
Anyone having trouble with this not following when a device changes IP address? If a google mini gets a new dynamic local IP address from the router this does not detect it. The only way to get that device back online is to disable the old google mini and re add it using the manual IP feature. I have 7 google devices.
Just as a tip. I have at least 12 of these things. I finally gave in a few months ago with all my Group functionality failing and created MAC reservations for all the devices/pairs. That ruled out any IP issues in the the equation.
Yeah, I think it’s pretty standard/expected if you have something on your home network that other things need to point AT (like a device the hub needs to connect to to control), then you really want to either do a true fixed IP, or what is normally even easier, set up a fixed reservation on the DHCP server so that device always get the same IP but stays “dynamic”.
If something on your network is just a client, then you don’t need to worry about it.
Thank you! I will do it!
