Matter - Google Speakers

Hi there,

I currently use a number of Google speakers as TTS devices and media players off a Hubitat C8 using the Chromecast Integration (beta - don't understand why this is still in beta as it has been around for 4+ years).

The problem is that the speakers often 'lose connectivity' - this is not a network connectivity loss, but rather some level of session loss between the hub and random speakers. The speakers are responsive in Google Assistant and using a scheduled Hubitat routine to initialize the speakers recovers them, but it is not optimal from a security event announcement point of view due to the random dropouts.

Now for my question;

Will I be able to pair Google speakers with Hubitat using Matter/Thread to overcome this problem whilst keeping the same speaker active in the Google ecosystem?

If by "will I be able to," you mean "can I today?", then no. You can't pair them as Matter devices at all to my knowledge; they are Matter controllers, like your hub (sort of like how you can't pair mine Zigbee hub/coordinator to another -- different roles). If you mean "will I be able to some day?", then maybe, but I doubt it for the same reason. And even if Google ends up making it either pairable or at least exposing some sort of device for the Google speaker out as a Matter device, there's no guarantee TTS would come along as part of that (I don't even think anything that could communicate text for TTS is part of the Matter standard today; for speakers, just power and volume).


Isn't this a good reason for the Chromecast integration to stay beta until such issues are successfully addressed?

Thanks for clarifying

As a built-in app - I assumed it would be production quality.

Why? It clearly identifies itself as a beta app.

1 Like

Because software generally moves between beta to production over a timeframe that long.

But it didn't, and is still marked as "beta"...

I understand what you are saying, don't get me wrong. I also would have preferred it to have come out of beta long ago, but I believe there were internal changes in staffing / personnel that likely affected this to some degree.

So what would you have them do? If there aren't resources to work on it right now due to competing priorities, should they remove it altogether (even though it works for some)? Or leave it in with the "beta" moniker? I think most would prefer the latter.


Well, clearly this app didn't. Hence, it remains marked as beta. I am unsure what point you're trying to make.

You started by questioning why this app was still in beta after 4+ years while simultaneously pointing out an issue you've encountered with the app.

That issue, and perhaps others, are why it is has stayed in beta. And why it continues to identify itself as a beta integration.

If I was dissatisfied with any beta app that hasn't production status in a long while, I would consider three options:

  • Not use it
  • Write an integration that works
  • Use a platform with a stable version of the app in question
1 Like

I asked this question a couple years back. IIRC, the response was that there was some reluctance to commit to it being "final" when mother Google could completely re-engineer or abandon the capability at any point.


Staff have said repeatedly that they don't advise use of Hubitat like you would a purpose-built security system...HE is great home automation, but is not purpose-built for security tasks. I also use HE for door/window open notifications, but consider it a "nice to have" and don't treat HE like it's a true security system.

If you are still missing notifications w/your current re-initialization schedule then you can schedule your re-initialization of your devices more frequently.


Or switch to using airplay devices like Sonos or HomePod minis. Not the cheapest solution (especially Sonos, but IKEA’s are less pricey), and HP minis require an iPhone for setup (which can obviously be a deal breaker), but they have been very reliable for me. I also use Echo Speaks, which has also been extremely reliable, but does depend on Amazon not breaking things on their end.

1 Like

I have the same issues with both Google and Samsung Speakers. What I found that seems to work is clearing the Queue, initializing, then refreshing the speakers. I use a virtual switch to trigger it. I have been using this since the old version of rule machine and never moved it to the new version because it works.

You could do like me, and flip the virtual switch on demand. OR, you could schedule it.

This is what my rule looks like. Top half is for Samsung, bottom half (Highlighted) is for Google.

1-For Google, there is no clear queue).
2-I use the "speak" to verify that they are working after the refresh. You don't need this and can leave it out.

Refresh Rule


Echo speaks broke when Heroko pulled the plug on hobbyists (gotta love Salesforce). Is the Sonos speaker integration reliable?

It is possible to run the Echo Speaks Server locally (i.e. sans Heroku). There are many users who do so. Here's one link with instructions:

Reliable - yes. Very reliable. But it is still cloud dependent for TTS mp3s to be encoded.


Didn’t break for those of us running the server locally. Just need a rpi, or spare pc. I just put Ubuntu on a spare pc.

1 Like

I haven't had much luck with the "initialize" command, personally. What seems to work for me is to add a playTrack command as the first action in a can either play a 1 second of silence audio file, or just enter a filename that doesn't exist.

Do you run the Refresh directly after the initialize? (Just trying to narrow down why it does work for me).

Did not realize it would not break anything to run a play track for a non-existent file. Will have to try that.