Chromecast binding - how do people use it?

I’m trying to do some work on the Chromecast binding, primarily to get it more stable, but also to weed out other bugs I come across.

There are so many things to pursue there, that I feel like a headless chicken at times. So, I need to try to focus my effort, or I’m afraid I’ll never get anywhere.

I’m writing this topic because I want to get an idea of what most people use it for. I’ve understood that many use the binding, I keep seeing it in thread dumps, and when I suggest that people disable it because it’s unstable, they are hesitant and reply that they rely on it for their larger setup.

At the same time, when looking at what it offers, it’s quite limited. You can retrieve various data from the Chromecast, but when I test it, most channels are UNDEF, so it’s hard to see that you get a lot of value from the data you can retrieve. It doesn’t even properly update the playback location during playback (seconds).

When it comes to the actions, it’s also quite limited. You can play a URL, which will work if the Chromecast likes the source format. But, there are more practical ways to do that than via OH.

Apart from that, it’s the audio sink. I’m wondering if this is what most people use..? It does have some limitations though, I’ve looked at it, and if you send an audio file to the sink, it will abort whatever the Chromecast is currently doing, start the default media player, and play the audio file. It won’t resume what the Chromecast was already doing before that, so it’s quite disruptive in you want to use the device for watching videos.

This makes me wonder: Exactly what is it used for? Are people using it to control audio-only devices as a way for OH to output sound into the home? Or, what is it?

Any input is appreciated, I guess nobody knows how “everybody else use it”, I just need to get some examples of what people use it for, to know what to focus on.

I just installed it when I was new to openHAB. ‘The more the merrier’, was my thinking. :wink: But I don’t really do anything with it.

I did add the chromecasts to my ‘shutdown when habitats leave or press the “shut down everything” switch’ routine. But I don’t suppose that saves a lot of energy.

I do notice that chromecasts are regularly ‘discovered’, although they’re already added as thing.

Yes, it was the same with me originally. I thought “why not”, but then I found that I never actually used it for anything, and that it made OH slow and buggy. So, I removed it some years back, and haven’t missed it. Of course, if it didn’t have any negative effects, I would probably still run it, but it isn’t “a sacrifice” for me to not run it.

I get the impression that this isn’t the case for everybody, as I’ve seen people being very hesitant to disable/uninstall it.

Yes, there are quite a few issues here. While debugging, I’ve also discovered that jmdns often “rediscover” my Chromecast, which might be the reason why the binding does so as well. Exactly why this happens is unclear to me, but I suspect that jmdns might send a notification if any of the registered properties change. So, it could be that the Chromecast update some property broadcast via mDNS from time to time, which then triggers this “chain of events”.

I use it as follows:

  • send announcements: even though it’s disruptive I find it useful enough
  • monitory what’s playing: just a way to keep up with what my son is playing on the devices, I just log it out and don’t really do anything else with it yet

It looks like this:

2025-10-27 16:15:16.954 [INFO ] [penhab.automation.script.ui.cc_alert] - KitchenHomeHub | YouTube Music | The Kiffness | Mr. Incredible

The Google TVs do not report what’s being played but when/if I want some of that I’ll try the Google TV add-on.

1 Like

I use it to play sounds, ringbels, or announce notifications (reminders or if I slow cook meet on my BBQ that it reached the temperature I want, however for the last I always had issues with stability of the chromecast and in particular Google TTS in Openhab, so few years back I installed Home Assistant on docker that sends the actual commands to the chromecast, and I send strings to HA via MQTT, and HA does its magic).

1 Like

I just have a single Chromecast, so I can’t test creating groups/zones. Have any of you tried doing that, and knows if it works to send something to a group/zone?

Yes, a group will show up as a separate Chromecast device to OH, and therefore it will have its own Thing. From that point it acts like a single device.

Sending an announcement works, except if the Thing is offline of course or the Chromecast binding is otherwise misbehaving.

All my announcements go to my all speakers group.

UID: chromecast:audiogroup:21632c10-9553-4136-80c3-21202c34e900
label: All speakers group
thingTypeUID: chromecast:audiogroup
configuration:
  ipAddress: someIP
  port: 32033
  refreshRate: 10
channels:
  - id: control
    channelTypeUID: system:media-control
    label: Media Control
    configuration: {}
  - id: stop
    channelTypeUID: chromecast:stop
    label: Stop
    description: Stops the player. ON if the player is stopped.
    configuration: {}
  - id: volume
    channelTypeUID: system:volume
    label: Volume
    description: Change the sound volume of a device
    configuration: {}
  - id: mute
    channelTypeUID: system:mute
    label: Mute
    description: Mute audio of the device
    configuration: {}
  - id: playuri
    channelTypeUID: chromecast:playuri
    label: Play URI
    description: Plays a given URI
    configuration: {}
  - id: appName
    channelTypeUID: chromecast:appName
    label: App
    description: Name of the currently running application
    configuration: {}
  - id: appId
    channelTypeUID: chromecast:appId
    label: App Id
    description: Id of the currently running application
    configuration: {}
  - id: idling
    channelTypeUID: chromecast:idling
    label: Idling
    description: Is Chromecast active or idling
    configuration: {}
  - id: statustext
    channelTypeUID: chromecast:statustext
    label: App Status
    description: Status reported by the current application
    configuration: {}
  - id: currentTime
    channelTypeUID: chromecast:currentTime
    label: Current Time
    description: Current time of currently playing media
    configuration: {}
  - id: duration
    channelTypeUID: chromecast:duration
    label: Duration
    description: Length of currently playing media
    configuration: {}
  - id: metadataType
    channelTypeUID: chromecast:metadataType
    label: Media Type
    description: The type of the currently playing media. One of GENERIC, MOVIE,
      TV_SHOW, AUDIO_TRACK, PHOTO
    configuration: {}
  - id: albumArtist
    channelTypeUID: chromecast:albumArtist
    label: Album Artist
    description: The name of the album's artist
    configuration: {}
  - id: albumName
    channelTypeUID: chromecast:albumName
    label: Album Name
    description: The name of the album
    configuration: {}
  - id: artist
    channelTypeUID: system:media-artist
    label: Media Artist
    description: Artist of a (played) media file
    configuration: {}
  - id: broadcastDate
    channelTypeUID: chromecast:broadcastDate
    label: Broadcast Date
    description: The broadcast date of the currently playing media
    configuration: {}
  - id: composer
    channelTypeUID: chromecast:composer
    label: Composer
    description: The composer of the current track
    configuration: {}
  - id: creationDate
    channelTypeUID: chromecast:creationDate
    label: Creation Date
    description: The creation date of the currently playing media
    configuration: {}
  - id: discNumber
    channelTypeUID: chromecast:discNumber
    label: Disc Number
    description: The disc number of the currently playing media
    configuration: {}
  - id: episodeNumber
    channelTypeUID: chromecast:episodeNumber
    label: Episode Number
    description: The episode number of the currently playing media
    configuration: {}
  - id: image
    channelTypeUID: chromecast:image
    label: Image
    description: The image that represents this media. Normally cover-art or scene
      from a movie
    configuration: {}
  - id: imageSrc
    channelTypeUID: chromecast:imageSrc
    label: Image URL
    description: The image URL that represents this media. Normally cover-art or
      scene from a movie
    configuration: {}
  - id: locationName
    channelTypeUID: chromecast:locationName
    label: Location Name
    description: The location of where the current media was taken
    configuration: {}
  - id: location
    channelTypeUID: system:location
    label: Location
    description: Location in lat./lon./height coordinates
    configuration: {}
  - id: releaseDate
    channelTypeUID: chromecast:releaseDate
    label: Release Date
    description: The release date of the currently playing media
    configuration: {}
  - id: seasonNumber
    channelTypeUID: chromecast:seasonNumber
    label: Season Number
    description: The season number of the currently playing media
    configuration: {}
  - id: seriesTitle
    channelTypeUID: chromecast:seriesTitle
    label: Series Title
    description: The series title of the currently playing media
    configuration: {}
  - id: studio
    channelTypeUID: chromecast:studio
    label: Studio
    description: The studio of the currently playing media
    configuration: {}
  - id: subtitle
    channelTypeUID: chromecast:subtitle
    label: Subtitle
    description: The subtitle of the currently playing media
    configuration: {}
  - id: title
    channelTypeUID: system:media-title
    label: Media Title
    description: Title of a (played) media file
    configuration: {}
  - id: trackNumber
    channelTypeUID: chromecast:trackNumber
    label: Track Number
    description: The track number of the currently playing media
    configuration: {}

You should be ably to create a Group in Google Home consisting of just one speaker, unless they hide that option when you only have one speaker.

1 Like

I think they should, but that is probably limited to content that is being played using the “Google Cast protocol”. If you play content directly from the Android system, there’s no reason why that would be visible via the protocol that the Chromecast binding uses.
I did create a virtual Android TV using Android Studio once, and did some testing, but I think it was very slow and awkward to work with. There is something with the network setup for the virtual devices running under Android studio that introduces some limitations too, from what I remember, so I think I concluded that this wasn’t really a viable way to test anything.

Yes, I know that a group will “simulate a device”, I just wasn’t sure if it would actually work to send content to it. I’m not sure exactly how the Chromecasts handle this, as the “virtual device” has its own IP address, so I guess that one of the devices will assume the responsibility for the IP and then forward to the others.

There are MultizoneStatus events that are ignored by the binding, and I’m trying to figure out if that information should be used for anything: [chromecast] Make use of events by lsiepel · Pull Request #19319 · openhab/openhab-addons · GitHub

They do according to their own documentation. I read that you must have at least two devices for the option to appear.

I did a quick search and indeed the IP address is the same as one of the speakers.

Ah, that was a surprise to me. But, ok, then that speaker/device must have the responsibility to forward it to the other members.

Ports are different though. The speaker is on 8009 and the groups it belongs to (this speaker belongs to multiple groups) are on ports 32033 and 32062. I have no idea how the device is chosen. This particular device is the least powerful one, a Chromecast Audio that i connected to a speaker that is rarely turned on.

Yeah, ports must be different when they reuse the same IP address. I imagined that they created a new one, but I guess just using a different port is fine as well.

Only Google knows that, I suspect, but it could be done “dynamically”. I read somewhere that if one of the members of a group is shut on or off, the whole group is “reset” and playback must be re-initiated. So, the devices might just do an “election” when they find each other, and pick one. If you have more than two, it would be interesting to see what happens to the group if you turn off the one in charge.

Audio announcements using Google tts. Works for a while. I suspect that the Google tts token silently expires rendering the whole setup inop.

I’ve never tested the TTS stuff - are none of the open source solutions good enough to be usable? It’s a shame to have to rely on commercial APIs for this, both for privacy, cost and reliability.

I use Piper TTS and as long as the Chromecast Thing itself is ONLINE it works. It’s rendered locally so no API key or other such complication. There are several other options as well.

I find Piper to be quite good. Though I see that they moved repos, maybe they changed the license or something.

1 Like

I have a few Chromecast audios around the house that I bought when they were released. I have them connected to amps via DACs and use them to play music from Spotify, internet radio stations and from files on my android phone. In OH I have a rule that allows me to choose an internet radio station from a selection of my favourites and have it casted to the CC audio in that room.

1 Like

i use chromecast binding to make announcements for doorbell and other events.I wish we could use the broadcast feature like in Home Assistant so when i play music in the speaker group ,the music can resume after the announcement…

3 Likes

This sounds like it would be a huge improvement, but to do that, I must figure out how HA does it (I’m not familiar with the “broadcast feature”).

Any hints as to what I look for is appreciated, links to docs, terms, or of course source code would all be helpful.

Edit: I’m struggling to find this in HA, but I find requests for it where it’s deemed “not possible”:

I would guess Google Cast - Home Assistant and from there core/homeassistant/components/cast at dev · home-assistant/core · GitHub?

Yes, I meant specific references to this “feature”. I need to figure out, if they do it, if it’s done using the cast protocol or not. This binding only uses the cast protocol, and unless you can do it using that, a lot of work would be needed to support some other protocol.

While this issue is old, it gives the impression that this is not a cast protocol “feature”: