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.
(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.)
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.
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.
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.
EDIT TO ADD
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.
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.
I, too, have already a multi-year odyssey when it comes to Chromecast.
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.
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...
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.
), e.g.:
