Playing mp3 on Google home mini

I have read a few similar threads, but I don’t couldn’t find this info (and what I hope to be an easy question. I have (successfully) installed cast-web so that I can trigger custom (TTS) messages across my home via Google home mini speakers. I’d like to play a custom mp3. I’ve placed a short mp3 in Dropbox and created a sharable link. I am working to set up a rule that will play the mp3. I am assuming, based on reading, that I should use the “playTrack” command. But I am confused on what the values would be for the Arguments. I have looked for cast-web documentation, but don’t really see where it’s explained.

Any ideas? Here’s what is presented.

Thanks for posting. One of the best places to look for documentation is the official SmartThings Capability documentation. For example, here’s a link to the Audio Notification capability:

We’ve seen this happen a few times, but it looks like the SmartThings API is returning the arguments in the wrong order, so you’ll want to flip the ‘Advanced’ toggle in the top-right corner of the card and adjust the parameters accordingly.



  • trackUri (String)
  • volume (Number

For most audio devices, you can specify just a single string argument with the URL to the track. So in your case, flip the advanced toggle on and delete the numeric argument.

Or you can optionally rearrange the arguments and include the URL (as a String) as the first argument and the volume (as a Number) as the second argument.

1 Like

Works perfectly! Thank you for your (quick) help!


I suspect there’s no way to avoid this, @josh, but I wonder if you have any guesses. When playing a file (PlayTrack) to my Google speaker (via the cast-api), prior to playing the file, the Google Speaker plays an audible tone. It’s kind of like an audio acknowledgement that it is waking up to do something. Does that make sense?

I wish there was a way to have it simply play the file and not sound a tone first. Like I said, this is probably something coded into the Google speaker and not something we can control. Just thought I’d throw out the long shot question.

I vaguely recall that from when I tested it and I recall discussion in the Hubitat community (for their native Chromecast integration) mentioning the same thing. If I remember correctly, the device author said it’s a limitation of the API. You might post in the cast-web-api device author’s thread to see if they have any suggestions?

1 Like