Google Nest Mini for notification sounds -- summary of methods and alternatives (Was: Rule that watches for idle status on a Google Mini speaker is not triggering as expected)

Background: When you do playTrack() on a Google Mini speaker, your sound file is preceded by a bloop sound. I hate the bloop and I want to defeat it. Subsequent playTrack() operations will not go bloop if they are made within 5 minutes. It appears to be impossible to mute the bloop with device mute and volume commands--I've scoured all the forums I can find. (A couple people reported success but follow-up posts were "didn't work for me." And these were different HA systems, too.)

So, I thought I would use Rule Machine to play "comfort noise" periodically. By watching for the player to return to status=idle and staying there for a while, we can trigger playing some silence to reset the timeout.

I had thought that when playing the silent mp3, the status change from playing to idle would retrigger the rule... But that does not seem to be happening reliably. In the logs, sometimes I see only 2 plays before it stops.

Before I start troubleshooting, can someone verify that my rule logic is sound? Should this rule as written retrigger itself indefinitely? If so, cool, I will figure out what's wrong.

And if the rule is faulty because I am misunderstanding something, I would appreciate a pointer in the right direction.


Try this:

TRIGGER - periodic schedule (every 4min 30sec)

ACTION - run custom command "initialize()" on LIV Speaker (Gray) (find it listed under "speech devices" after selecting custom action)

You might get the bloop the first time like always but it shouldn't do it again.

Thanks! I will try that now and report back.

(I just finished another test that might work too ... I realized that the Chromecast Integration app had a "polling" option, which had not been on. With polling turned on, my RM action DID seem to be retriggering automatically. I then tried pausing my RM and using just the polling option -- that did not work, and I could see in the log where the speaker switched from media source "Hubitat" to "None," which indicates that the bloop will return.)

1 Like

Drat, that didn't work.

I played a test sound at 2:10 (highlight) and got the bloop to start the timeout timer, then activated the initialize() rule. You can see that at 2:16 the media source dropped from Hubitat to None, which seems to precede bloops. At 2:25 I played the test sound again and the bloop was back.

As you can see there are no Initialize() entries in the log, but that doesn't happen if you Initialize() from the device page either.

The Initalize() commands do appear in Events though so the rule seems to be working.

Here's the Rule --

And the Action detail.

Does initialize() need a parameter?

Thanks for the help, I appreciate it!


I poked around the forum and found other discussions about initialize() to keep these devices from blooping. In one post someone included log entries that show initalize appearing as a debug level entry.

I cannot replicate this, my logs never show initialize() and it makes me wonder if my initialize() command is working at all.

1 Like

Darn let me see if I can think up another method. I wonder if refresh() would work instead of initialize()

It's been a very long time since I messed around with using the Google Mini things as notification speakers so I haven't thought about this problem in awhile...

I am kinda surprised your original silent mp3 didn't do the trick...

oh and to see the "initialize" command show up in logs as in the image you referenced, just make sure you go to the actual device page and make sure debug logging is enabled for the device.

Ah there is initialize() in the logs, I think I just screwed up and didn't save preferences to turn on debug logging.

I'll let the rule cook and make sure it's actually sending the command and retest. I'll also test by manually mashing the Initialize and Refresh buttons.


OK, the Initialize() command is definitely firing off on schedule, but it does not prevent the Media Source changing to None.

Here in green are the Initialize() commands. In yellow we see it spontaneously drop the Hubitat as the Media Source. Then when I play the test sound (pink), it switches the Media Source from None to Hubitat, it bloops, and the sound plays.

Now that I know what I am looking for I see many references to the Initialize() technique, but maybe Google changed something and it no longer works?

One more update; I think I got it to work, but if you know another method @a.mcdear that would still be great info. My method is heavy-handed and it would be nice if there was something more elegant.

Where we are, for the benefit of future searchers --

  • The Google Nest Mini seems to have a 5 minute timeout after which it bloops when you do playTrack().
    • In the device logs, if you see the media source change from Hubitat to None that means the next playTrack() will bloop.
  • You can try to keep the connection alive by taking action before the 5 minute timer elapses ...
    • refresh() alone did not keep the media source on Hubitat.
    • initialize() alone did not keep the media source on Hubitat.
    • Activating "polling" in the Chromecast Integration (beta) app alone did not keep the media source on Hubitat. (I'm honestly not sure what it does, as it generates no log traffic.)
    • Doing playTrack() with a silent sound file alone helped, but was not perfect, as the rule would stop re-triggering after just a couple of repeats. This didn't make sense to me. ¯\_(ツ)_/¯

I found 2 things that seemed to work.

One, doing playTrack() with silent sound file every few minutes with Polling turned on in the Chromecast Integration (beta) app. I am still not sure why polling helped, since what polling does is not clear.

Two, every few minutes doing initialize() and then a couple seconds of silence via playTrack().

I like the latter since it is more explicit.

This is the actual rule I am using and it's been good so far, but it has only been about 30 minutes 5 hours.

In this sample log you can see we begin on media source = None, play a test sound (in yellow, with bloop!), then 6 more Initialize()/playTrack(silence) actions occur, and then much later when we play the second test sound (green) we are still on media source = Hubitat and there is no bloop!

I still do not understand why the original Rule that simply used playTrack() without any extra commands did not repeat reliably. But at least now I may have a workaround.

1 Like

I, too, have already a multi-year odyssey when it comes to Chromecast. :man_shrugging:

The only reliable method is to run playTrack or speak regularly (e.g. every 4:30).
BUT: Because of the timeout IMHO set to "infinite" in the Chromecast driver, there are huge problems when a Chromecast device cannot be reached (hello Google?)!
Then all the sent commands pile up - and the load on the Hubitat increases more and more...

BTW: Instead of playing a silent track you can also use speak " ", which generates a silent MP3.

Thank you for stopping in!

Yikes! I wonder if RM can make that check? I'm not at all sure how to do that but it would be a cool optimization.

If the timeout in the driver is too long maybe we can ask the team for a change?

Fantastic, thanks!

My rule has been running for hours now and the bloop is still absent. Wish I knew why initialize() seemed important to this, but... It's working, I won't complain. Until I have a hub meltdown, anyway...

1 Like

I tried this many times (to often? :thinking:), e.g.:

But maybe you'll have better luck, so please let's go! :+1:

1 Like

I'll throw my two cents in on at least one of those threads. I can see you have already been very diligent!

1 Like

I have 3 Google/Nest Mini speakers. For a long time I was also trying to avoid the "bloop" sound. Some things worked temporarily, but nothing actually fixed the underlying issue. The underlying issue seems to be that these particular devices are simply designed to go into a sleep mode when not being used. I gave up on this idea, because the need to have my hubitat spend every few minutes trying to keep a device awake that was designed to go to sleep when not being used... well it just seemed like a huge waste of resources that could be put to use doing useful things. Ultimately, I gave up on it and I just deal with the "bloop". It ONLY happens when somebody rings the doorbell.

Ultimately, I WANTED to use these devices to announce status alerts. For example, to have it speak "Front door is open" or "Kid's window is open" like many home security systems do. I came to the conclusion that trying to be overly fancy with cheap gadgets that aren't designed to be fancy was basically just practice in futility.

My plan moving forward is to buy an IKEA SONOS compatible speaker, which should be able to accomplish all these things without all the hacks of the cheap Google speakers.

I may buckle and get a Sonos too but cost aside they're enormous. Everything about the Nest Mini is perfect... Everything other than the bloop. So I'm going to keep trying, though I may end up where you are.

1 Like

Maybe take a look at these speakers. I use them all over the house to announce things. They work perfect in the Sonos App.

Those seem to be the cheapest and smallest Sonos speakers so they are on my list if the Google Mini doesn't work out.

Someone else mentioned an old Sonos amp that can be found used for less, too, but you'd need to provide a speaker.

or try alexa.. pretty cheap and echo's work well for me

You can play an mp3/wav hosted on the Hubitat on your Alexa devices? In other threads I was told that is not possible. It would be good news.

1 Like

How to play music you own on an Amazon Echo | TechHive.

Interesting, thanks. I am already a Plex user so I will try that.

Unfortunately that other method requires subscription software.

1 Like

even this speaker costs 6 times as much as a Google Mini/Nest...
I have one in every room, 10 in total. :face_with_spiral_eyes:

IMHO Alexa TTS by Hubitat is very ... cumbersome... :man_shrugging: