Chromecast Integration died!

At some point in the past few releases, the Chromecast integration moved away from yaml to the UI, and dropped support for specifying a specific host IP of a Chromecast device.

No problem you say, it gets discovered via mDNS. Great, if you’ve got net=host, or are running hass on a dedicated device. I’m not, and I’m sure there are others out there also running on docker can can’t or don’t want to set net=host. I’m actually running on kubernetes, but I am not convinced that is the issue at hand.

So sure, as an ugly hack™ I wrote a python script that echos mDNS entries. Pretty fake, but hey, it points at the right Chromecast, but it works… or it did. With the latest few updates even that broke as well.

Did something change in the Chromecast protocol? I doubt it. Does the Chromecast integration need data that is sent in the mDNS broadcasts other than the IP address? If not, why can’t I target this integration manually? If some of data contained in the mDNS broadcasts truly is needed for the Chromecast integration, can be it be retreived once the IP is known?

If mDNS is really, really required, I am tempted to write a service that listens outside of the docker network (or outside of the vlan, etc), and sends them via mqtt to a service that blasts them out onto the homeassistant network/vlan. I’d much rather just set the IP of the Chromecast in the HA integration manually.

This probably isn’t unique to Chromecasts, and may apply to more services designed to use mDNS.

I get what you are saying, but please note, the method you choose to run the container (without host networking) is not supported by the Home Assistant project.

Figures, looks like I can blame Google for much of my woes: https://github.com/home-assistant/core/pull/34082.

Running with net=host, or putting the Chromecast on the same VLAN. is not going to happen here.I don’t see supporting documentation that the move away from a HTTP query was required by Google, but I didn’t dig deep yet. Either way pulling that http method of configuring/obtaining Chromecast configuration data was a breaking change that (maybe) didn’t need to occur and feels very frustrating. I am sure there are other users who would love to be able to put their Chromecast on the guest-only Wifi network…

FWIW I have my Chromecast devices on a separate VLAN with mDNS repeater enabled and it works great. I do have host networking set on my docker container though. Why are you opposed to host networking?

I have them seperated as well, the Google devices are in their own VLAN and firewalled. They cannot initiate a connection to other devices and their DNS is forced in the routing as well.

A mDNS repeater relays the mDNS traffic from the VLAN having my Google Homies to my HA instance.

Sometimes mdns isn’t that easy or simply not working fine, bring both worlds together and make it configurable. Using tcp connection and filling in a host ip or using mdns and some autodiscovery.

Running with host networking would break the reverse proxy configurations I have set, although I do have some ideas. I would like to avoid any solution that involves additional containers.

I totally forgot about mDNS repeaters are supported by many routers. That would be the right solution for cross-vlan support, leaving only containerized setups that don’t set net=host.

That is a configuration problem. Running a reverse proxy on a host networked container is perfectly valid and doable. Home Assistant Supervised and OS installation types actually rely on this (e.g., via Ingress and the multiple available reverse proxy add-ons like NGinx). In those installation types, HA runs on the host network as well.

If it was working with YAML, and other solutions didn’t work for you; since the team doesn’t want to support it, you could potentially downgrade the component to a version which supports YAML.

I would not recommend that method describe above, ever. Besides the changes around cast aren’t related to the YAML policies either @nitobuendia. Stop throwing everything in that direction.

Will you be there to support the average joe that tries your method (and believe me someone without an understanding of what its doing will try), then gets in trouble and comes to the forums for help then finds it not supported and then gets a bad taste about HA

think about it, its not a viable method

1 Like

Hi @frenck

I didn’t say that YAML is the solution. The author did:

“At some point in the past few releases, the Chromecast integration moved away from yaml to the UI …”

As such, I suggested them that they can revert to that version.

If you read the post, I also said that the solution is not recommendable, but some people may still prefer that over the existing support. It’s every individual’s choice at that point.