Google Cast Broken 109, HA and Casts on same network.

[N5A]

The problem

Google Cast broken somewhere between 108 and 109. Home Assistant and Casts all on the same IOT VLAN. mDNS works well My PCs on the private VLAN can see the cast devices within the IOT VLAN.

Cast Integration states it cannot find any cast devices on network.

Environment

HA Ver 109.6
HA Hosted within the Hassio VM. Virtualbox running VM on Win10 Host. Win10 has dual network connections. Wired goes to IOT Vlan, wireless to Private lan.

Problem-relevant configuration.yaml

No Cast Config in Config Yaml.

Traceback/Error logs

Additional information

HA's VM's Network card is bound to the wired card of the minipc.

[probot-home-assistant]

cast documentation
cast source
_{^{(message by IssueLinks)}}

[probot-home-assistant]

Hey there @emontnemery, mind taking a look at this issue as its been labeled with a integration (cast) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[pr0fetul]

I have the same issue - HA 109.6 on Docker on Synology. Since 2 days now, my 7 Google Cast devices (2 Chromecasts, 4 Google Mini's, and 1 Google Nest Home) are no longer accessible from HA.
In Docker Network I have 1 network - host - under which are listed: homeassistant, hassio_multicast and addon_15ef4d2f_esphome; hassio which contains: addon_core_configurator, hassio_audio, hassio_cli, hassio_dns, hassio_supervisor; and bridge which contains only hassio_supervisor.

All Google devices and NAS/HA docker are in the same network, no subnetworks. I do not know how to approach this.
HA is 109.6, Docker version of HA is: 20200330-1.

[tprelog]

I'm not sure if this is related ... My chrome-cast devices (and cast group) are showing up in HA but the connection is unreliable ... My logs are constantly filled with ...

2020-05-18 02:23:56 WARNING (Thread-5) [pychromecast.socket_client] [Speaker(10.10.1.126):8009] Heartbeat timeout, resetting connection
2020-05-18 02:51:29 WARNING (Thread-7) [pychromecast.socket_client] [Bathroom speaker(10.10.1.196):8009] Heartbeat timeout, resetting connection
2020-05-18 03:07:49 WARNING (Thread-9) [pychromecast.socket_client] [Bedroom TV(10.10.1.168):8009] Heartbeat timeout, resetting connection
2020-05-18 04:26:03 WARNING (Thread-12) [pychromecast.socket_client] [Family Room Stereo(10.10.1.104):8009] Heartbeat timeout, resetting connection
2020-05-18 04:41:18 WARNING (Thread-8) [pychromecast.socket_client] [Workshop Stereo(10.10.1.103):8009] Heartbeat timeout, resetting connection
2020-05-18 04:41:33 ERROR (Thread-8) [pychromecast.socket_client] [Workshop Stereo(10.10.1.103):8009] Failed to connect to service Chromecast-Audio-7177c30f31bc88204b464fb7e0016345._googlecast._tcp.local., retrying in 5.0s
2020-05-18 04:55:17 ERROR (Thread-11) [pychromecast.socket_client] [Basement(10.10.1.107):42482] Error reading from socket.
2020-05-18 04:55:17 WARNING (Thread-11) [pychromecast.socket_client] [Basement(10.10.1.107):42482] Error communicating with socket, resetting connection
2020-05-18 04:55:17 ERROR (Thread-11) [pychromecast.socket_client] [Basement(10.10.1.107):42482] Failed to connect to service Google-Cast-Group-a1bdd1b479494e1b99a694645f0a91ad-1._googlecast._tcp.local., retrying in 5.0s
2020-05-18 04:55:42 WARNING (Thread-10) [pychromecast.socket_client] [Bedroom Stereo(10.10.1.107):8009] Heartbeat timeout, resetting connection
2020-05-18 04:56:02 ERROR (Thread-11) [pychromecast.socket_client] [Basement(10.10.1.104):42482] Error reading from socket.
2020-05-18 04:56:02 WARNING (Thread-11) [pychromecast.socket_client] [Basement(10.10.1.104):42482] Error communicating with socket, resetting connection
2020-05-18 04:56:02 ERROR (Thread-11) [pychromecast.socket_client] [Basement(10.10.1.107):42482] Failed to connect to service Google-Cast-Group-a1bdd1b479494e1b99a694645f0a91ad-1._googlecast._tcp.local., retrying in 5.0s

( Note: Each device does have a unique IP, I just changed them here)

I am running a virtualenv install of Home Assistant Core 0.109.6 -- Cast devices and Home Assistant are on the same network sub-net

[emontnemery]

@tprelog Please note exposing internal IPs are in no way a security or privacy risk, and by changing the logs you just make them harder to read. Anyhow, can you please confirm the IP addresses indicated in the logs are the correct ones?

[emontnemery]

@pr0fetul, @N5A
If Google Cast devices can't be found, it means that either:

• Some custom component is pinning a version of pychromecast or zeroconf which is not compatible with home assistant
• mDNS is not working, because:
  • mDNS request packets sent by home assistant do not reach the Chrome Cast devices
  • mDNS response packets sent by the Chrome Cast devices do not reach Home Assistant.
  • This will happen if:
    • HA and the Chrome Cast devices are on different networks (different VLAN or different subnets)
    • Some firewall rule is blocking mDNS
    • Some network hardware is dropping mDNS packets, for example a WiFi AP may not forward multicast packets from wireless to wired or vice verse

There is a guide here for docker: https://www.home-assistant.io/docs/installation/docker/, please note that Home Assistant should be on the host network which must be the same (same subnet, same VLAN) as that of the Chrome Cast devices.

The equivalent will be needed for VirtualBox.

It is also possible to setup mDNS forwarding, some hints here: https://www.home-assistant.io/integrations/discovery/#mdns-and-upnp

Finally, for Windows 10, another user had isssues due to what may be a bug in Windows: #34631 (comment)

[pr0fetul]

Hi @emontnemery , thank you very much for the fast reply.
So, in my case, NAS Fw is disabled, I do not use any other firewall. NAS, Docker and HA are on the same Host. NAS DSM 6.2.2-24922 Update 4, Docker installed version 18.09.0-0513. Nothing has been changed on the Router that serves the network (Archer C9) before the issue happened, and since then, only a reboot of the router yesterday - as I thought that something was not ok with it, but it works fine.
If you tell me how I can test for mDNS traffic from/to NAS I can try to get some logs / data

[tprelog]

@emontnemery -- Sorry about that.

I have have changed my comment above to include the direct copy from my logs.

[pr0fetul]

I think I solved the issue on my side. In Synology - Control Panel - Info Center - I had the Bonjour Printer Broadcast service disabled. Once enabled - miracle - all Google Cast devices showed up. I restarted HA - they are here - and working again. Also in same Control Panel - Security - Firewall - I enabled it and added ports 5353 and 1900 UDP traffic All Allowed.

For now it seems that all my Cast devices are back working. I will monitor it and report if it breaks again.

[emontnemery]

@pr0fetul Great! "Bonjour" is Apple's naming for mDNS, so it makes sense enabling that option has an impact.

[emontnemery]

@tprelog No worries! I would say the reconnects you see in the log are pretty normal, Chrome Casts are generally not super stable and are reported by some users to reboot daily, possibly to dial home to Google for whatever reason.
Also, since Chrome Casts will install firmware updates from Google without any notice, behavior will change over time.

Anyhow, Home Assistant should always be able to reconnect to Chrome Casts if the connection has been severed.

You could perhaps try to setup a ping sensor with a short interval, https://www.home-assistant.io/integrations/ping/#binary-sensor, to check if the Chrome Casts can be pinged when Home Assistant loses its connection.

[jazbraz]

I have an strange error. When I integrate Google cast on the integration page the devices is discovered and all found. But when I restart HA they are Inaccessible. All of them. And if I delete the integration and restart, they are discovered and I am able to re-add them again.

Someone else having that problem??

[emontnemery]

@jazbraz please open a new issue for your problem, it doesn't seem related to this one

[rsimiciuc]

@jazbraz I'm having the same issue recently. I've opened this ticket: #35922

[hmmbob]

I am seeing similar behavior. With 0.109, I had to run an Avahi reflector on my host to get mDNS working again (I am running a docker based setup without --net=host; yes that is not according to install instructions). That worked great, but with 0.110 I am seeing weird behavior:

Upon HA reboot, all devices show as unavailable - every reboot again.
Restarting the HA container or host does not make a difference. With avahi-browse on the host I am able to confirm that both the LAN and the Docker net where the containers attach to see (and resolve) all 7 Cast devices. But HA still shows them as unavailable.

The fix? Rebooting my WiFi access points, which probably triggers another advertise or so by the Chromecasts. If I do this, they show up one-by-one in HA again without me touching HA - confirming that mDNS works....

Strange....

[emontnemery]

@N5A did you solve your problem yet?

[N5A]

Sorry I have been out dealing with a new job and figuring out moving to a new state. , issue has not changed. Just tried readding the integration, same failure. No detected chromecasts.

[N5A]

Taking a snapshot now, will update to 110.4, check/test.. then next also update the hassio os.

[N5A]

No change with the update to 110.4, OS update proceeding.

[emontnemery]

There are changes in 0.109 requiring a working mDNS setup, #35735 (comment)

[N5A]

Note in the OP, mDNS is up and working. PCs in private VLAN can see Casts in IOT VLAN, HA also exists in the IOT Vlan.

I will investigate if Vbox is at fault and possibly mucking up the mDNS passage between HA and the network.

[N5A]

Vbox is in Bridged mode for network so its going direct to the NIC. so no interference should be there.

[N5A]

@emontnemery How can I see if HASSIO is pinning some version of what you mentioned? Nothing else looks to be amiss.

[N5A]

HAH... and now when I go look with zero changes... the casts were auto discovered.

[scadaguru]

I am also having same issue. Home Assistant running under docker with host mode. There is no VLAN at all and has only one subnet. If I specify IP/host for Google Cast device HA never finds it and no error in the log. But if I use UI integration "Google Cast" it finds all devices but I want only one device by specifying IP address as shown below:

cast:
  media_player:
    - host: 192.168.1.61

[emontnemery]

@scadaguru which HA version are you on?

[scadaguru]

@scadaguru which HA version are you on?

Latest 0.110.5

[emontnemery]

@scadaguru OK, can you collect and share three logs please, with logs enabled as listed below:

1. Startup log with only host: 192.168.1.61 added
2. Log when adding UI integration "Google Cast"
3. Startup log when UI integration "Google Cast" is added

logger:
   default: info
   logs:
     homeassistant.components.cast: debug
     homeassistant.components.cast.media_player: debug
     pychromecast: debug
     pychromecast.discovery: debug
     pychromecast.socket_client: debug
     homeassistant.components.zeroconf: debug
     zeroconf: debug

[scadaguru]

@emontnemery First of all appreciate your time and efforts, thanks a lot.

I added logging details you provided and was going through logs and noticed it has tons of information about my devices. But here is good news! When I was adding IP of that Google home device it did not show up automatically in my entities list but I noticed in the log which said it discovered with lot more details about the device.

So then I click configure Google Cast from UI and it showed only one device (rather than all devices about 12) which I specified using IP. I guess I was wrong thinking that UI Google Cast will bring all the devices but it did just one which I put in the configuration file. I was expecting to show up in the entity list automatically without doing anything from UI. May be I didn't read document correctly that even after manually specifying an IP still I need to configure from UI to include it I think this got changed recently earlier those showed automatically once you specify IP in config.

Once more thank you so much for your time and help, sorry for the confusion.

[emontnemery]

@bdraco scadaguru's problem with a fully manual config is that the manual configuration is blocked because cast devices have already been discovered, and is waiting for the user to confirm adding the discovered setup.

Sample configuration:

cast:
  media_player:
    - host: 192.168.0.10

Prints of return value from FlowManager.async_init:

2020-06-07 21:29:31 ERROR (MainThread) [homeassistant.data_entry_flow] FlowManager.async_init result {'type': 'form', 'flow_id': '540dd911173741768beb5d652c9f0325', 'handler': 'cast', 'step_id': 'confirm', 'data_schema': None, 'errors': None, 'description_placeholders': None}
^--- This is the first discovered cast, blocked waiting for user confirmation
2020-06-07 21:29:31 ERROR (MainThread) [homeassistant.components.cast] cast async_setup OrderedDict([('media_player', [OrderedDict([('host', '192.168.0.10')])])])
2020-06-07 21:29:31 ERROR (MainThread) [homeassistant.data_entry_flow] ------------> result {'type': 'abort', 'flow_id': '99ec105603df44d3a76ddf5d7c4869a4', 'handler': 'cast', 'reason': 'single_instance_allowed', 'description_placeholders': None}
^--- This is the manual setup, rejected because the discovery flow is active

Not sure if this is a bug, or just a documentation issue?

[bdraco]

    async def async_step_import(self, _):
        """Handle a flow initialized by import."""
        if self._async_in_progress() or self._async_current_entries():
            return self.async_abort(reason="single_instance_allowed")

        return self.async_create_entry(title=self._title, data={})

Import is explicitly preventing them from being created in if discovery triggers first.

It looks like that was added in #15630 for cast and sonos.

I think it should be ok to change it to something like this and update the tests to preserve the original intent

diff --git a/homeassistant/helpers/config_entry_flow.py b/homeassistant/helpers/config_entry_flow.py
index 81881d943c..768973b051 100644
--- a/homeassistant/helpers/config_entry_flow.py
+++ b/homeassistant/helpers/config_entry_flow.py
@@ -59,6 +59,9 @@ class DiscoveryFlowHandler(config_entries.ConfigFlow):
             for flow in in_progress:
                 self.hass.config_entries.flow.async_abort(flow["flow_id"])
 
+        if self._async_current_entries():
+            return self.async_abort(reason="single_instance_allowed")
+
         return self.async_create_entry(title=self._title, data={})
 
     async def async_step_discovery(self, discovery_info):
@@ -76,7 +79,7 @@ class DiscoveryFlowHandler(config_entries.ConfigFlow):
 
     async def async_step_import(self, _):
         """Handle a flow initialized by import."""
-        if self._async_in_progress() or self._async_current_entries():
+        if self._async_current_entries():
             return self.async_abort(reason="single_instance_allowed")
 
         return self.async_create_entry(title=self._title, data={})

[emontnemery]

@bdraco That change works, but the UI shows multiple cast integrations on first startup, one is triggered by discovery, the second one triggered by the import:

By aborting the discovery flow on import that can be avoided:

diff --git a/homeassistant/helpers/config_entry_flow.py b/homeassistant/helpers/config_entry_flow.py
index 81881d943c..43d281aa5b 100644
--- a/homeassistant/helpers/config_entry_flow.py
+++ b/homeassistant/helpers/config_entry_flow.py
@@ -59,6 +59,9 @@ class DiscoveryFlowHandler(config_entries.ConfigFlow):
             for flow in in_progress:
                 self.hass.config_entries.flow.async_abort(flow["flow_id"])

+        if self._async_current_entries():
+            return self.async_abort(reason="single_instance_allowed")
+
         return self.async_create_entry(title=self._title, data={})

     async def async_step_discovery(self, discovery_info):
@@ -76,9 +79,14 @@ class DiscoveryFlowHandler(config_entries.ConfigFlow):

     async def async_step_import(self, _):
         """Handle a flow initialized by import."""
-        if self._async_in_progress() or self._async_current_entries():
+        if self._async_current_entries():
             return self.async_abort(reason="single_instance_allowed")

+        # Cancel other flows.
+        in_progress = self._async_in_progress()
+        for flow in in_progress:
+            self.hass.config_entries.flow.async_abort(flow["flow_id"])
+
         return self.async_create_entry(title=self._title, data={})

Do you think that's reasonable?

[emontnemery]

@N5A Is your problem solved, and this issue can be closed?

[emontnemery]

Closing this as it seems it has been fixed.
Please comment if it's not the case.