Core: Cast groups unavailable

[soldag]

Home Assistant release with the issue:
0.66.0.beta1

Last working Home Assistant release (if known):
0.65.6

Operating environment (Hass.io/Docker/Windows/etc.):
Raspbian GNU/Linux 9 (stretch)

Component/platform:
media_player.cast

Description of problem:
Since update to the latest beta version, my cast groups are unavailable now and then. However, the single devices of the groups can be controlled, but not the groups itself. I encountered this issues typically in the morning. When restarting HASS, all cast devices and groups are available, again.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

discovery:
media_player:
  - platform: cast

Traceback (if applicable):

Additional information:

[OttoWinter]

Hmmm, thanks for reporting this 👍

Seems a lot like https://github.com/home-assistant/home-assistant/issues/13483 and probably due to the groups changing their "elected leader". Could you also enable debug logs as mentioned in the comment in there? It would really help.

[j0barr]

I managed to catch it happening to me with 66.1. "main_speakers" and "everything" are groups. I only had homeassistant.components.media_player set to debug. Does that work? I can try full debug if you want. Haven't managed to catch it like that yet.

home-assistant.log

[OttoWinter]

Thank you very much for the logs! They definitely help with ruling out a possible explanation which I previously deemed most likely. Here's my analysis if someone's interested:

So with these logs, it's pretty clear that the issue is due to the cast groups changing their "elected leader" to another chromecast audio/google home (they do this quite often in order to keep latency down). Let's go through step by step what's happening:

1. All manually added cast devices are added ("Setting up media_player.cast", "Discovered chromecast ChromecastInfo(host='...', port=8009, ...)", "Connecting to cast device", "Querying device status", "Connection successful!")
2. discovery: finds the cast groups and we set them up too ("Found new service: google_cast", "Starting internal pychromecast discovery.", "Discovered previous chromecast ChromecastInfo", "Discovered chromecast ChromecastInfo", "Connection successful!")
3. After a while the cast devices change host (from 10.0.0.26 to 10.0.0.25, "Discovered chromecast with same UUID") and we disconnect from the socket from the previous group leader ("Disconnecting from previous chromecast socket.") and re-connect to the new leader ("Connecting to cast device ChromecastInfo")
4. First, this new connection seems to work fine (14:23:48 "Connection successful!")
5. The discovery component calls our async_setup_platform code again (14:25:13 "Setting up media_player.cast"). This is expected and seems to be handled correctly judging from the logs.
6. A few seconds after 5. the connection to a socket fails (14:25:20 "Error reading from socket.", "Cast device availability changed: LOST", "Failed to connect, retrying in 5.0s"). I'm not 100% sure whether this socket is the old socket or the new correct one. This would need pychromecast's debug logs too.

At first, I thought this issue was most likely caused by 3. not working correctly and us not detecting the switched hosts, but your logs clearly show that that's not the case.

A few possible explanations I think could be it:

1. Disconnecting+Reconnecting somehow fails; especially the disconnecting part
2. Quite unlikely, but maybe we don't receive a "reconnected" message from pychromecast even though the connection is working again. This would lead us to show the entity as being "unavailable" even though we have a good connection.
3. In 5, we're checking the chromecast's HTTP API. While unlikely, maybe this somehow influences the active socket.

[dshokouhi]

Hey guys just chiming in that I am also seeing this issue. What is odd is that my group went from unavailable to available several hours later

[OttoWinter]

@dshokouhi Thanks for sharing that! This issue is getting quite complicated 😅 My first guess would be that what you're seeing is that if the group changes its elected leader again (a second time), it magically works again. I have no idea why though

[j0barr]

Maybe back to the original elected leader? :)

[OttoWinter]

Hmmm, that might be it, but I have not idea how that could affect the socket client. Oh gosh, this is getting interesting... 😂

[dshokouhi]

@OttoWinter I understand that cast groups get added automatically. If home assistant were to know exactly what devices we have in a group would that help determine which group got updated? Trying to help and think of scenarios because obviously if we do a restart it will work again for X amount of time. I may not fully understand the elected leader concept but I figured if we just define what devices are in the group it may be easier to determine the changed group? I surely don't mind listing them in the config to get it working lol.

[OttoWinter]

@dshokouhi The problem is that not only the host (or IP address) of the device that is the "elected leader" or the device that accepts all commands changes, but also the port number. And that dynamically, so there's no way that a user can list the cast members in their configuration.

btw, from what I know now, the issue is not related to the discovery aspect of the cast integration. In fact, we discover elected leader changes just fine. The issue seems to be somewhere in the disconnect from old leader + connect to new leader code.

[dshokouhi]

Oh wow nice to hear you guys seem to have pinned down the issue :) if you need any help testing I am sure myself and others would be glad to help.

[OttoWinter]

I'm still trying to find out what exactly caused this, but If you'd like to help 😬, it would be good to know whether with the following configuration the issue still happens (with discovery: disabled).

media_player:
  - platform: cast
    scan_interval: 1234567890

I personally am not seeing the issue with my setup with that config, but it would be good to get some data from others too. This configuration should not really affect anything and the cast integration should still work (without the new semi-polling mode I introduced in the linked PR). If the error doesn't appear with that configuration, it would mean that we know the code change that caused this, but I still have no idea why the connections drop.

[dshokouhi]

Ok I have disabled discovery for google_cast, and applied the same config for the media_player component. Will reply back if I notice the issue.

[dshokouhi]

@OttoWinter the issue came back overnight, one of my groups is currently unavailable and the other one went unavailable over night and became available again.

[OttoWinter]

@dshokouhi Ok. At least that rules out one possible explanation... Thanks very much!

[Spartan-II-117]

I'd be happy to help test as well if there's are any new updates,

[benjamin1492]

I just closed my issue after troubleshooting and determining that cast groups are causing my problems, and that this issue probably relates to mine.

If I include cast groups in global or cast discovery, then I lose the ability to cast to all but a few of my cast-enabled devices when Home Assistant starts up. If I explicitly define just the individual devices and exclude cast groups, then everything works fine. As a point of clarification, when I say "lose the ability to cast", I mean that when I hit the cast icon in Pandora, Spotify, or Google Play Music, I only get the devices with very old firmwares as options (Sony Speaker with Chromecast Built-In and an Insignia Alarm Clock with Chromecast Built-in). None of the Chromecast Audios, Google Homes, Nvidia Shields, nor any of the associated groups show up.

I've attached a log.

home-assistant test2.log

[fanaticDavid]

I'm also seeing this behaviour today, running Home Assistant 0.67.1:

The more-info dialog shows the details of the bottom group, but the state of the top group is identical. I also have the individual Chromecast Audio units in my Home Assistant setup. It seems one of them (Garoeda I) was unavailable for about half a minute and that caused the two groups (which include that specific Chromecast Audio) to become and remain unavailable.

This is what syslog logged on my Raspberry Pi 3:

pi@Ra:~ $ cat /var/log/syslog | grep unavailable
Apr 22 17:13:41 Ra hass[13460]: #033[32m2018-04-22 17:13:41 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.garoeda_i, old_state=<state media_player.garoeda_i=off; friendly_name=Garoeda I, supported_features=21437 @ 2018-04-22T04:38:21.736327+02:00>, new_state=<state media_player.garoeda_i=unavailable; friendly_name=Garoeda I, supported_features=21437 @ 2018-04-22T17:13:41.211439+02:00>>#033[0m
Apr 22 17:13:42 Ra hass[13460]: #033[32m2018-04-22 17:13:42 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.home_audio, old_state=<state media_player.home_audio=off; friendly_name=Home Audio, supported_features=21437 @ 2018-04-22T04:38:21.754878+02:00>, new_state=<state media_player.home_audio=unavailable; friendly_name=Home Audio, supported_features=21437 @ 2018-04-22T17:13:42.196000+02:00>>#033[0m
Apr 22 17:13:47 Ra hass[13460]: #033[32m2018-04-22 17:13:47 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.home_audio_with_bathroom, old_state=<state media_player.home_audio_with_bathroom=unavailable; friendly_name=Home Audio with bathroom, supported_features=21437 @ 2018-04-22T15:47:52.989243+02:00>, new_state=<state media_player.home_audio_with_bathroom=off; friendly_name=Home Audio with bathroom, supported_features=21437 @ 2018-04-22T17:13:47.477800+02:00>>#033[0m
Apr 22 17:13:47 Ra hass[13460]: #033[32m2018-04-22 17:13:47 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.home_audio, old_state=<state media_player.home_audio=unavailable; friendly_name=Home Audio, supported_features=21437 @ 2018-04-22T17:13:42.196000+02:00>, new_state=<state media_player.home_audio=off; friendly_name=Home Audio, supported_features=21437 @ 2018-04-22T17:13:47.500569+02:00>>#033[0m
Apr 22 17:14:16 Ra hass[13460]: #033[32m2018-04-22 17:14:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.garoeda_i, old_state=<state media_player.garoeda_i=unavailable; friendly_name=Garoeda I, supported_features=21437 @ 2018-04-22T17:13:41.211439+02:00>, new_state=<state media_player.garoeda_i=off; friendly_name=Garoeda I, supported_features=21437 @ 2018-04-22T17:14:16.308174+02:00>>#033[0m
Apr 22 17:14:16 Ra hass[13460]: #033[32m2018-04-22 17:14:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.home_audio_with_bathroom, old_state=<state media_player.home_audio_with_bathroom=off; friendly_name=Home Audio with bathroom, supported_features=21437 @ 2018-04-22T17:13:47.477800+02:00>, new_state=<state media_player.home_audio_with_bathroom=unavailable; friendly_name=Home Audio with bathroom, supported_features=21437 @ 2018-04-22T17:14:16.640050+02:00>>#033[0m
Apr 22 17:14:16 Ra hass[13460]: #033[32m2018-04-22 17:14:16 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.home_audio, old_state=<state media_player.home_audio=off; friendly_name=Home Audio, supported_features=21437 @ 2018-04-22T17:13:47.500569+02:00>, new_state=<state media_player.home_audio=unavailable; friendly_name=Home Audio, supported_features=21437 @ 2018-04-22T17:14:16.659293+02:00>>#033[0m

And this is what happened according to Home Assistant:

2018-04-22 17:13:41 WARNING (Thread-6) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-04-22 17:13:42 WARNING (Thread-8) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-04-22 17:13:51 ERROR (Thread-10) [pychromecast.socket_client] Failed to connect. No retries.
2018-04-22 17:14:11 ERROR (Thread-6) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-04-22 17:14:12 ERROR (Thread-8) [pychromecast.socket_client] Failed to connect: timed out. aborting due to stop signal.
2018-04-22 17:14:16 ERROR (Thread-11) [pychromecast.socket_client] Error reading from socket.
2018-04-22 17:14:16 ERROR (Thread-12) [pychromecast.socket_client] Error reading from socket.
2018-04-22 17:14:16 WARNING (Thread-11) [pychromecast.socket_client] Error communicating with socket, resetting connection
2018-04-22 17:14:16 WARNING (Thread-12) [pychromecast.socket_client] Error communicating with socket, resetting connection
2018-04-22 17:14:16 ERROR (Thread-11) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-04-22 17:14:16 ERROR (Thread-12) [pychromecast.socket_client] Failed to connect, retrying in 5.0s

I do not use the discovery component, and my configuration for the Cast component is basic:

- platform: cast

[benjamin1492]

Did some further testing today and have included the logs and some screenshots. The first screenshot is my casting choices when cast groups are turned off in Home Assistant, but all other cast devices are turned on (meaning I'm selecting them individually with their host ip address). Everything shows up, including the groups.

The "home assistant log test6" is when I turned groups on by:
platform: cast

While Home Assistant was running, I also restarted the router and then restarted every single cast device individually. All that should be evident in the log. None of that worked as you can see in screenshot 2, which is my list of casting choices. The Sony speaker and the Insignia Alarm clock, both running much older versions of chromecast software are the only devices present. The groups you see are groups that contain one or both of those two devices.

home-assistant test6.log

I then commented out platform: cast to remove the groups, but kept my individual selections by host, ie:

###platform: cast

platform: cast
   host: 192.168.85.141
   name: Living Room

Just like screenshot 1, all my device and groups now show up as cast targets. I included "home assistant log test7" with these conditions to compare against test6.

home-assistant test7.log

[fanaticDavid]

@benjamin1492 I'm not entirely convinced your issue is related to the issue being reported here. This issue is about the unavailable state that Cast groups get inside Home Assistant.

[benjamin1492]

Can you cast to your devices from, say, your phone, when they show as unavailable in Home Assistant? While I didn't post any screenshots, I too am seeing devices and groups become unavailable. I've always assumed the two issues were related. However, if you're still able to cast to a device / group that's unavailable in Home Assistant, then I agree I may have a different issue.

[fanaticDavid]

I will have to test that when my Cast groups are unavailable the next time, as they have suddenly gone back to their off state almost 2 hours ago:

Syslog:

pi@Ra:~ $ cat /var/log/syslog | grep unavailable
Apr 23 02:17:23 Ra hass[13460]: #033[32m2018-04-23 02:17:23 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.home_audio, old_state=<state media_player.home_audio=unavailable; friendly_name=Home Audio, supported_features=21437 @ 2018-04-22T17:14:16.659293+02:00>, new_state=<state media_player.home_audio=off; friendly_name=Home Audio, supported_features=21437 @ 2018-04-23T02:17:23.181650+02:00>>#033[0m
Apr 23 02:17:23 Ra hass[13460]: #033[32m2018-04-23 02:17:23 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.home_audio_with_bathroom, old_state=<state media_player.home_audio_with_bathroom=unavailable; friendly_name=Home Audio with bathroom, supported_features=21437 @ 2018-04-22T17:14:16.640050+02:00>, new_state=<state media_player.home_audio_with_bathroom=off; friendly_name=Home Audio with bathroom, supported_features=21437 @ 2018-04-23T02:17:23.219506+02:00>>#033[0m
Apr 23 02:17:43 Ra hass[13460]: #033[32m2018-04-23 02:17:43 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.garoeda_i, old_state=<state media_player.garoeda_i=off; friendly_name=Garoeda I, supported_features=21437 @ 2018-04-22T17:14:16.308174+02:00>, new_state=<state media_player.garoeda_i=unavailable; friendly_name=Garoeda I, supported_features=21437 @ 2018-04-23T02:17:43.591443+02:00>>#033[0m
Apr 23 02:17:59 Ra hass[13460]: #033[32m2018-04-23 02:17:59 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.garoeda_i, old_state=<state media_player.garoeda_i=unavailable; friendly_name=Garoeda I, supported_features=21437 @ 2018-04-23T02:17:43.591443+02:00>, new_state=<state media_player.garoeda_i=off; friendly_name=Garoeda I, supported_features=21437 @ 2018-04-23T02:17:59.393369+02:00>>#033[0m

Home Assistant log:

2018-04-23 02:17:43 WARNING (Thread-6) [pychromecast.socket_client] Heartbeat timeout, resetting connection

[benjamin1492]

Please test to see if they are available as cast targets regardless of status. What I've found is that whether they are "off" or "unavailable", they will not show up as available to cast to from Pandora, Google Play Music, or any other app that has cast capability. I'd love to have validation of that behavior.

[Spartan-II-117]

Most of the time my devices have become unavailable, I have still been able to cast to them from my phone or google home. although i have sometimes had to restart my phone to do so.

[benjamin1492]

It's very weird. Regardless of the media player status within Home Assistant, I can tell a Google Home to play a song on any of the individual Chromecast Audios or Google Homes and it will do so. If I try tell it to play to a cast group, however, only one set of speakers will play, which I assume is the leader of the group. And if I open Pandora or Google Play Music and hit the Cast icon, none of the individual devices or groups show up as options (except - as noted in an earlier comment - the older firmware devices with Chromecast built-in from Sony and Insignia. Those are solid).

As a reminder, this behavior is only when I have Home Assistant running with platform: cast discovering the groups. If I allow it to only discover the individual cast players, then everything works fine both in Home Assistant and in Pandora, Google Home, etc.

[dshokouhi]

In addition to unavailable I just noticed unknown as well.

[benjamin1492]

@dshokouhi Are you using cast groups in Home Assistant? I've found if I remove them, then the unavailable issue goes away (unfortunately, so too does a bunch of functionality). Could you test by removing cast groups and see if you get to:

[dshokouhi]

@benjamin1492 this bug is only about cast groups so removing them to test is not an option. They need to work which is why we are troubleshooting this.

[benjamin1492]

Understood. I'll wait on the resolution to this one, and if it doesn't fix my problem, I'll reopen my other case. For now, I'll leave ya'll alone to get the cast groups fixed.

[grangemd]

I am having an issue where none of my cast components show up in home assistant anymore even if I use discovery.

[Spartan-II-117]

running the beta, I have not had a cast group issue for the past 24 hours, which looks to be a record recently,

[benjamin1492]

So my problem is definitely different. Running the beta, I was able to get all the devices to A) show as available in Hass, and B) show as cast targets. But that only lasted for about 15 minutes before I was back to A) only the leader playing when cast group selected, and B) having no cast targets for GPM or Pandora. The 15 minutes to failure is an improvement...used to be instantaneous as soon as I started Hass.

[Spartan-II-117]

@benjamin1492 have you tried removing/unplugging devices one by one to see if one of them is a factor?

[psfales]

Just chiming in because I'm seeing the same thing. My group will randomly go "unavailable" a few times a day, and then a few hours later it goes back to available again. I only have two devices in the group, so it seems plausible that when the leader selection is changed, it toggles between the two devices. At this moment, it's showing as unavailable in HA, but I'm able to use the group with Pandora

[OttoWinter]

Hi, so I had another look at this problem today to see what could be causing this. One potential problem is that the disconnection logic is currently not perfect and we don't wait until the previous socket has truly disconnected when re-establishing a connection. This doesn't seem like something that could cause this error to me but I'm running out of potential causes.

I've update the cast integration a bit to resolve above issue. If someone wants to help, copy this file to <config_dir>/custom_components/media_player/cast.py. I'm not sure if it would solve the issue but it would at least be worth a try.

[psfales]

I've been running that 4/28 version for about a day and it hasn't solved the problem, but subjectively, I think it may a little different. It went unavailable three times today, but both were only for a minute or so (rather than hours like I think it was before)

[OttoWinter]

@psfales Thanks for testing! I think 30 seconds to 60 seconds are more or less expected and there's not much we can do to cut this time down:

• It takes 10-15 seconds until we receive the mDNS message with the new host.
• Then we need to disconnect from the old chromecast. Can take up to 5-10 seconds depending on the amount of data waiting to be transferred and so on.
• Finally, we need to connect to the new host. Can take 10+ seconds. Especially while the new host is still setting up to receive connections.

[psfales]

Unfortunately, it hasn't stayed so good. It went unavailable at 5:30 this morning and stayed unavailable for 2.5 hours until I rebooted

[OttoWinter]

Oh noes :/ Reopening then...

Unfortunately, I won't be able to work on this for the next week and a half though because I'm in the process of studying for my final exams 📚

[psfales]

Certainly understand about your schedule. When you have time, I'm curious.... Is it possible to tell when the elected leaders changes, or which device it is at any given time? I think it would be interesting to confirm that the group going unvailable (or return to available) is correlated with a leader change.

[OttoWinter]

There's no real visual way to see that from the front-end. But if you have debug logs enabled you can see a Disconnecting from previous chromecast message in there when a leader change is detected.

[kristoffernolgren]

I experience this problem I'm pretty new to Homeassistant but am a developer. Let me know if you need anything!

[JIOB]

I also have this problem. Not a developer but happy to test/help where I can.

[kristoffernolgren]

For me it consistently works to reboot my homeassistant to get access to the cast group.

[JIOB]

Same goes for me and the time a group takes to become unavailable seems totally random. I went away for a week so no music was played via other devices and on my return all groups were available. Unsure if a total fluke or due to not casting from other devices there was no need to elect a new group "leader". I presume Home Assistant was casting TTS weather alerts etc because i forgot to switch them off.

[Spartan-II-117]

@JIOB, did you check your history? i'd be really curious to kno if not
interacting with it caused it to hold stable

On Fri, May 18, 2018 at 5:15 AM JIOB [e-mail] wrote:

Same goes for me and the time a group takes to become unavailable seems
totally random. I went away for a week so no music was played via other
devices and on my return all groups were available. Unsure if a total fluke
or due to not casting from other devices there was no need to elect a new
group "leader". I presume Home Assistant was casting TTS weather alerts etc
because i forgot to switch them off.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/13530#issuecomment-390188171,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEuJQHrfPVcCjQ3uWSxKLDI_pSNvpWk1ks5tzrtNgaJpZM4TADhw
.

[JIOB]

I didn't check at the time and its since been overwritten. If the same situation occurs again prior to a fix ill ensure i've got a log to share.

[kristoffernolgren]

Not my proudest work, but I just did this as a cludge:

- alias: 'All unavailable for 3 minutes'
  trigger:
    platform: state
    entity_id: media_player.all
    to: 'unavailable'
    for:
      minutes: 15
  action:
    service: homeassistant.restart

homeassistant reboots whenever the group is unavialable for more than 15 minutes. I have a feeling this will come back and bite me in the ass...

[dshokouhi]

I am actually wondering if maybe the cast platform can create a service call that allows us to basically "reload" the groups like what happens during a home assistant restart. A hass restart is the only way to bring the groups back maybe there is a way to trigger the rediscovery of just the cast groups when they become unavailable? I think I saw some platforms use unloading like hue maybe something similar can be triggered here? Sorry if I am shooting in the dark just trying to help offer ideas/suggestions :)

[kristoffernolgren]

I have been thinking the same, but not sure if it has to be a service, it should just do it if the groups lose connection in that case.

[aliaghil]

It's because of mess with configuration.
I had same problem, I checked all my configuration and there was some parts that I correct them. Then I removed the database and restart the machine. It's been about 10 days that I don't have that problem anymore.

[JIOB]

I agree with @dshokouhi and @kristoffernolgren it would be nice if some logic could be built in to restart the service when a group/groups become unavailable.

@aliaghil which parts of your configuration did you correct? My configuration now only contains..

- platform: cast

[aliaghil]

1. In my configuration I had this code in sensors:

sensor
  - platform: systemmonitor
    resources:
      - type: since_last_boot
      - type: processor_use
      - type: memory_free
      - type: disk_free
        arg: /
  - platform: template
    sensors:
      time_template:
        friendly_name: Time
        value_template: '{{ as_timestamp(now()) | timestamp_custom("%d/%m   %H:%M", True) }}'
      since_last_boot_template:
        friendly_name: Up Time
        value_template: >
          {%- set s = states.sensor.since_last_boot.state.split('.')[0] -%}
          {{ s }}
  - platform: version
    name: version 

and I changed it to:

sensor:
  - platform: systemmonitor
    resources:
      - type: since_last_boot
      - type: processor_use
      - type: memory_free
      - type: disk_free
        arg: /
  - platform: template
    sensors:
      time_template:
        friendly_name: "Time"
        value_template: '{{ as_timestamp(now()) | timestamp_custom("%d/%m   %H:%M", True) }}'
      since_last_boot_template:
        friendly_name: "Up Time"
        value_template: >
          {%- set s = states.sensor.since_last_boot.state.split('.')[0] -%}
          {{ s }}
  - platform: version
    name: "Version"

In my sensors wherever there was friendly_name: I used quotation mark for it.

1. After version 0.60 developers add cloud component, and I add it to my configuration, but didn't use it, even I didn't login to it. I think the problem was because of this, after I configured it, and logged in to it, the problem gone.

2. in configuration.yaml i had these:

homeassistant:
customize_glob: !include config/customize_glob.yaml
packages: !include_dir_named config/packages/
frontend:
extra_html_url:
/local/custom_ui/state-card-custom-ui.html 

I disabled them.

1. I was using separated config
   I found it out, these files shouldn't go in the config folder config/config
   automations.yaml
   entity_registry.yaml
   known_devices.yaml
   scripts.yaml
   secrets.yaml
   I bring them back to root config folder.

2. the last one
   I update all my automation with Automation editor.

[JIOB]

@aliaghil are you saying that those steps have permanently fixed your instance of the cast component?

[aliaghil]

@JIOB yes. I update hassio to 0.71.0 and unfortunately the problem come back again :(
I'm going to downgrade it to v0.70.1 and see what's going on...

[JIOB]

Just updated HomeAssistant to 0.72.0 and it forced me to reconfigure my Google cast devices. Anybody know if the change has the ability to fix this issue? Will post back if i find anything.

[psfales]

I also updated to 0.72.0 and got the dialog about forcing me to reconfigure
Google Cast. But I don't understand what this means. It apparently
created a file in the config directory called ".config_entries.json" which
has an entry for "Google Cast." But other than that one-time interaction
I don't see any change in behavior. "Google Cast" does not appear anywhere
in the UI and all the Chromecast, Chromecast Audio, and audio groups that
were there before are still lthere.

On Sun, Jun 24, 2018 at 6:28 AM, JIOB [e-mail] wrote:

Just updated HomeAssistant to 0.72.0 and it forced me to reconfigure my
Google cast devices. Anybody know if the change has the ability to fix this
issue? Will post back if i find anything.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/13530#issuecomment-399749490,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKyoCsrJK8dEx3GKnh19WWJhmAk19vjBks5t_3fbgaJpZM4TADhw
.

[harry19023]

After updating to 0.72.0 and using the new UI config method, I am still experiencing this issue. So it doesn't look like the new config method fixed the issue.

[kdjordjev]

I am having the same issue here with 0.72.
Individual devices work, by group gets dropped. I do not recall having this issue before

The HA log shows the issue happening first two nights ago @2:38am, which seems to somehow recovered (stopped reporting errors in the log) , and similar errors last nigh @2:27am , which have not recovered yet

2018-07-05 02:38:17 ERROR (Thread-10) [pychromecast.socket_client] Error reading from socket.
2018-07-05 02:38:17 WARNING (Thread-10) [pychromecast.socket_client] Error communicating with socket, resetting connection
2018-07-05 02:38:17 ERROR (Thread-10) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-05 02:38:22 ERROR (Thread-10) [pychromecast.socket_client] Failed to connect. No retries.
2018-07-05 02:38:39 WARNING (Thread-8) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-05 02:38:54 ERROR (Thread-8) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-05 02:41:58 WARNING (Thread-9) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-05 02:42:05 ERROR (Thread-9) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-05 03:05:35 WARNING (Thread-7) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-05 03:05:38 ERROR (Thread-7) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-05 03:29:43 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved

2018-07-06 02:27:17 ERROR (Thread-191485) [pychromecast.socket_client] Error reading from socket.
2018-07-06 02:27:17 WARNING (Thread-191485) [pychromecast.socket_client] Error communicating with socket, resetting connection
2018-07-06 02:27:17 ERROR (Thread-191485) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-06 02:27:22 ERROR (Thread-191485) [pychromecast.socket_client] Failed to connect. No retries.
2018-07-06 02:27:45 WARNING (Thread-8) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-06 02:27:52 ERROR (Thread-8) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-06 02:51:57 WARNING (Thread-7) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-06 02:52:04 ERROR (Thread-7) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-06 02:52:15 ERROR (Thread-481327) [pychromecast.socket_client] Error reading from socket.
2018-07-06 02:52:15 WARNING (Thread-481327) [pychromecast.socket_client] Error communicating with socket, resetting connection
2018-07-06 02:52:15 ERROR (Thread-481327) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-06 04:35:58 WARNING (Thread-9) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-06 04:36:01 ERROR (Thread-9) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-06 07:41:15 ERROR (MainThread) [homeassistant.core] Timer got out of sync. Resetting

[eeepsylon]

I use Chromecast Audio groups extensively and use playing/off state changes to trigger many automations. (volume setting, turning off and on connected amps etc).

Here's a log from last night, which shows the groups becoming unavailable at 22:36, coming back 61s later, then going unavailable again 1s later. The groups recover at 23:37:15, when pychromecast reconnects to the Sony.

There are two groups, "All" and "Downstairs". "sony" is the A/V receiver with cast built in. 'sony_2' is the songpal component of same device. I doubt that's relevant, other than to show that songpal and pychromecast both report unavailable at roughly the same times.

Casting GPM to the CCA 'bedroom' begins at 22:23 and ends at 23:22.

2018-07-11 22:23:36 INFO bedroom -> 'idle'
2018-07-11 22:23:36 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: service_data=entity_id=media_player.bedroom, volume_level=0.15, service_call_id=1975828368-6972, service=volume_set, domain=media_player>
2018-07-11 22:23:36 INFO (Thread-21) [pychromecast.controllers] Receiver:setting volume to 0.1
2018-07-11 22:23:36 INFO bedroom -> 'playing'
...
2018-07-11 22:34:33 INFO bedroom -> 'playing'
2018-07-11 22:36:01 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered previous chromecast ChromecastInfo(host='10.0.0.60', port=8009, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxe99d', model_name='STR-DN860', friendly_name='Sony')
2018-07-11 22:36:04 WARNING (Thread-53) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-11 22:36:06 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered previous chromecast ChromecastInfo(host='10.0.0.60', port=42904, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx7cdc', model_name='Google Cast Group', friendly_name='All')
2018-07-11 22:36:06 DEBUG (Thread-53) [homeassistant.components.media_player.cast] Cast device availability changed: LOST
2018-07-11 22:36:06 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered previous chromecast ChromecastInfo(host='10.0.0.60', port=42760, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx0422', model_name='Google Cast Group', friendly_name='Downstairs')
2018-07-11 22:36:06 WARNING (Thread-52) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-11 22:36:06 DEBUG (Thread-52) [homeassistant.components.media_player.cast] Cast device availability changed: LOST
2018-07-11 22:36:06 INFO downstairs -> 'unavailable'
2018-07-11 22:36:06 INFO all -> 'unavailable'
2018-07-11 22:36:11 WARNING (Thread-24) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-11 22:36:11 DEBUG (Thread-24) [homeassistant.components.media_player.cast] Cast device availability changed: LOST
2018-07-11 22:36:11 INFO sony -> 'unavailable'
2018-07-11 22:36:36 ERROR (Thread-53) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-11 22:36:36 ERROR (Thread-52) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-11 22:36:41 ERROR (Thread-24) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-11 22:37:19 INFO sony_2 -> 'unavailable'
2018-07-11 22:37:55 INFO sony_2 -> 'off'
2018-07-11 22:37:55 DEBUG (Thread-52) [homeassistant.components.media_player.cast] Cast device availability changed: CONNECTED
2018-07-11 22:37:55 INFO all -> 'off'
2018-07-11 22:37:55 DEBUG (Thread-24) [homeassistant.components.media_player.cast] Cast device availability changed: CONNECTED
2018-07-11 22:37:55 DEBUG (Thread-53) [homeassistant.components.media_player.cast] Cast device availability changed: CONNECTED
2018-07-11 22:37:55 INFO sony -> 'off'
2018-07-11 22:37:55 INFO downstairs -> 'off'
2018-07-11 22:37:56 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered previous chromecast ChromecastInfo(host='10.0.0.60', port=8009, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxe99d', model_name='STR-DN860', friendly_name='Sony')
2018-07-11 22:37:56 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered chromecast ChromecastInfo(host='10.0.0.92', port=42904, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx7cdc', model_name='Google Cast Group', friendly_name='All')
2018-07-11 22:37:56 DEBUG (MainThread) [homeassistant.components.media_player.cast] Discovered chromecast with same UUID: ChromecastInfo(host='10.0.0.92', port=42904, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx7cdc', model_name='Google Cast Group', friendly_name='All')
2018-07-11 22:37:56 DEBUG (MainThread) [homeassistant.components.media_player.cast] Disconnecting from chromecast socket.
2018-07-11 22:37:56 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered chromecast ChromecastInfo(host='10.0.0.92', port=42760, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx0422', model_name='Google Cast Group', friendly_name='Downstairs')
2018-07-11 22:37:56 INFO all -> 'unavailable'
2018-07-11 22:37:56 DEBUG (MainThread) [homeassistant.components.media_player.cast] Discovered chromecast with same UUID: ChromecastInfo(host='10.0.0.92', port=42760, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx0422', model_name='Google Cast Group', friendly_name='Downstairs')
2018-07-11 22:37:56 DEBUG (MainThread) [homeassistant.components.media_player.cast] Disconnecting from chromecast socket.
2018-07-11 22:37:56 INFO downstairs -> 'unavailable'
2018-07-11 22:38:01 DEBUG (MainThread) [homeassistant.components.media_player.cast] Connecting to cast device ChromecastInfo(host='10.0.0.92', port=42760, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx0422', model_name='Google Cast Group', friendly_name='Downstairs')
2018-07-11 22:38:01 INFO (Thread-20) [pychromecast] Querying device status
2018-07-11 22:38:01 DEBUG (MainThread) [homeassistant.components.media_player.cast] Connecting to cast device ChromecastInfo(host='10.0.0.92', port=42904, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx7cdc', model_name='Google Cast Group', friendly_name='All')
2018-07-11 22:38:01 ERROR (Thread-20) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-11 22:38:01 INFO (Thread-6) [pychromecast] Querying device status
2018-07-11 22:38:01 ERROR (Thread-6) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-11 22:39:20 INFO bedroom -> 'idle'
2018-07-11 22:39:20 INFO bedroom -> 'playing'
...
2018-07-11 23:22:37 INFO bedroom -> 'playing'
2018-07-11 23:22:51 INFO (Thread-11) [pychromecast] Quiting current app
2018-07-11 23:22:51 INFO (Thread-11) [pychromecast.controllers] Receiver:Stopping current app '2872939A'
2018-07-11 23:22:51 INFO bedroom -> 'off'
2018-07-11 23:37:14 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered chromecast ChromecastInfo(host='10.0.0.60', port=42904, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx7cdc', model_name='Google Cast Group', friendly_name='All')
2018-07-11 23:37:14 DEBUG (MainThread) [homeassistant.components.media_player.cast] Discovered chromecast with same UUID: ChromecastInfo(host='10.0.0.60', port=42904, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx7cdc', model_name='Google Cast Group', friendly_name='All')
2018-07-11 23:37:14 DEBUG (MainThread) [homeassistant.components.media_player.cast] Connecting to cast device ChromecastInfo(host='10.0.0.60', port=42904, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx7cdc', model_name='Google Cast Group', friendly_name='All')
2018-07-11 23:37:14 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered chromecast ChromecastInfo(host='10.0.0.60', port=42760, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx0422', model_name='Google Cast Group', friendly_name='Downstairs')
2018-07-11 23:37:14 INFO (Thread-3) [pychromecast] Querying device status
2018-07-11 23:37:14 DEBUG (MainThread) [homeassistant.components.media_player.cast] Discovered chromecast with same UUID: ChromecastInfo(host='10.0.0.60', port=42760, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx0422', model_name='Google Cast Group', friendly_name='Downstairs')
2018-07-11 23:37:14 DEBUG (MainThread) [homeassistant.components.media_player.cast] Connecting to cast device ChromecastInfo(host='10.0.0.60', port=42760, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx0422', model_name='Google Cast Group', friendly_name='Downstairs')
2018-07-11 23:37:14 INFO (Thread-4) [pychromecast] Querying device status
2018-07-11 23:37:15 DEBUG (MainThread) [homeassistant.components.media_player.cast] Connection successful!
2018-07-11 23:37:15 INFO all -> 'off'
2018-07-11 23:37:15 DEBUG (MainThread) [homeassistant.components.media_player.cast] Connection successful!
2018-07-11 23:37:15 INFO downstairs -> 'off'
2018-07-12 02:23:21 WARNING (Thread-30) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-12 02:23:21 DEBUG (Thread-30) [homeassistant.components.media_player.cast] Cast device availability changed: LOST
2018-07-12 02:23:21 INFO lounge_mini -> 'unavailable'
2018-07-12 02:23:36 DEBUG (Thread-30) [homeassistant.components.media_player.cast] Cast device availability changed: CONNECTED
2018-07-12 02:23:36 INFO lounge_mini -> 'off'
2018-07-12 02:23:38 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered previous chromecast ChromecastInfo(host='10.0.0.89', port=8009, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx6e34', model_name='Google Home Mini', friendly_name='Lounge Mini')
2018-07-12 02:45:48 WARNING (Thread-29) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-12 02:45:48 DEBUG (Thread-29) [homeassistant.components.media_player.cast] Cast device availability changed: LOST
2018-07-12 02:45:48 INFO office -> 'unavailable'
2018-07-12 02:45:55 ERROR (Thread-29) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-12 02:46:00 DEBUG (Thread-29) [homeassistant.components.media_player.cast] Cast device availability changed: CONNECTED
2018-07-12 02:46:00 INFO office -> 'off'
2018-07-12 02:46:03 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered previous chromecast ChromecastInfo(host='10.0.0.94', port=8009, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx569d', model_name='Chromecast Audio', friendly_name='Office')
2018-07-12 03:15:51 WARNING (Thread-28) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-12 03:15:51 WARNING (Thread-27) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-12 03:15:51 DEBUG (Thread-28) [homeassistant.components.media_player.cast] Cast device availability changed: LOST
2018-07-12 03:15:51 DEBUG (Thread-27) [homeassistant.components.media_player.cast] Cast device availability changed: LOST
2018-07-12 03:15:51 INFO chromecast_lounge -> 'unavailable'
2018-07-12 03:16:07 DEBUG (Thread-28) [homeassistant.components.media_player.cast] Cast device availability changed: CONNECTED
2018-07-12 03:16:07 INFO chromecast_lounge -> 'off'
2018-07-12 03:16:10 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered previous chromecast ChromecastInfo(host='10.0.0.91', port=8009, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxaf8e', model_name='Chromecast', friendly_name='Chromecast Lounge')
2018-07-12 04:05:28 WARNING (Thread-26) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-12 04:05:28 DEBUG (Thread-26) [homeassistant.components.media_player.cast] Cast device availability changed: LOST
2018-07-12 04:05:28 INFO bedroom_home -> 'unavailable'
2018-07-12 04:05:35 ERROR (Thread-26) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-12 04:05:41 DEBUG (Thread-26) [homeassistant.components.media_player.cast] Cast device availability changed: CONNECTED
2018-07-12 04:05:41 INFO bedroom_home -> 'off'
2018-07-12 04:05:42 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered previous chromecast ChromecastInfo(host='10.0.0.90', port=8009, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx2fc7', model_name='Google Home', friendly_name='Bedroom Home')
2018-07-12 04:51:47 WARNING (Thread-32) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-12 04:51:47 DEBUG (Thread-32) [homeassistant.components.media_player.cast] Cast device availability changed: LOST
2018-07-12 04:51:47 INFO bedroom -> 'unavailable'
2018-07-12 04:51:55 ERROR (Thread-32) [pychromecast.socket_client] Failed to connect, retrying in 5.0s
2018-07-12 04:52:00 DEBUG (Thread-32) [homeassistant.components.media_player.cast] Cast device availability changed: CONNECTED
2018-07-12 04:52:00 INFO bedroom -> 'off'
2018-07-12 04:52:04 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered previous chromecast ChromecastInfo(host='10.0.0.93', port=8009, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxb78c', model_name='Chromecast Audio', friendly_name='Bedroom')
2018-07-12 04:56:25 WARNING (Thread-25) [pychromecast.socket_client] Heartbeat timeout, resetting connection
2018-07-12 04:56:25 DEBUG (Thread-25) [homeassistant.components.media_player.cast] Cast device availability changed: LOST
2018-07-12 04:56:25 INFO kitchen -> 'unavailable'
2018-07-12 04:56:39 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered previous chromecast ChromecastInfo(host='10.0.0.92', port=8009, uuid='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx2458', model_name='Chromecast Audio', friendly_name='Kitchen')
2018-07-12 04:56:41 DEBUG (Thread-25) [homeassistant.components.media_player.cast] Cast device availability changed: CONNECTED
2018-07-12 04:56:41 INFO kitchen -> 'off'

[rgruebel]

Since switching to hassio I have the problem too:

Any news on this issue?

[j0barr]

Still not working for me with the latest version :(

[e1miran]

@OttoWinter @balloob - Is anyone actively working on this issue? This has been broken for months. I used to have automations to play music and announcements to certain groups. But casting to groups is anything but reliable. My logs are full of pychromecast failure to connect errors. What can we do to help test/debug?

[j0barr]

Yeah, absolutely nothing has changed since this was first reported (neither better nor worse). :(

[JIOB]

I moved my TTS announcements to broadcasts instead due to this issue. Still a problem for me but now just for media group control in HASS. Happy to help test.

[benjamin1492]

I have a far from ideal workaround for triggering automations while casting to speaker groups. I'm using the Unifi WAP component to monitor the bytes flowing to Chromecast Audio's. If one spikes above 20000, then the amp supplying power to the speakers it feeds turns on. There's usually a delay of 5-20 seconds given the polling frequency, but it's otherwise tolerable. Also, if there are no spikes on any of the Chromecasts for 10 minutes, then the corresponding amp is (hopefully) turned off. This is only for cast groups...casting to individual Chromecast Audio's is much more straightforward. Also, to make this work, I had to convert all of the Chromecast Audio's from wired to wireless because the Unifi controller doesn't track bytes for wired devices. I haven't noticed any issues going to wireless, but I'd really prefer to keep them wired.

While this is a passable work around, it is only about 60% effective. The speakers always turn on, but only turn off after 10 minutes about half the time. I haven't figured out why yet, so I have an automation that turns off all the amps at midnight.

[smoke007]

I moved my TTS announcements to broadcasts instead due to this issue. Still a problem for me but now just for media group control in HASS. Happy to help test.

@JIOB Would you mind please sharing how you are doing broadcasts? That sounds like a perfect solution for what I'm trying to do. Are you using this add-on? https://community.home-assistant.io/t/community-hass-io-add-on-google-assistant-webserver-broadcast-messages-without-interrupting-music/37274

Thank you

[JIOB]

@smoke007 I am indeed using that add-on. I'm running it in a Docker container as i don't run HASSIO but its running perfectly! My only issue is the playback with broadcasts isn't always in sync.

[smoke007]

Thanks, I'll check that out then. I like the idea of the broadcast not killing any music that was playing.

As since cast groups stopped working, I just listed out my cast devices within my script/automation as a work around for now.

alias: TTS Test
sequence:

• data:
  entity_id: media_player.basement_speakers, media_player.basement_assistant,
  media_player.garage_assistant, media_player.pole_barn_assistant
  volume_level: 0.6
  service: media_player.volume_set
• data:
  entity_id: media_player.basement_speakers, media_player.basement_assistant,
  media_player.garage_assistant, media_player.pole_barn_assistant
  message: This is a test message. Is the volume loud enough?
  service: tts.google_say

[Shadex12]

I too would like to know where things are at with this issue. I used to have automations fire when certain groups were playing etc. They've been useless for months.

[josephkiser04]

Agree this is still an issue. Now I am even starting to get this with certain cast devices.

[iorifly]

I have the same problem

[joydashy]

Wish there was a way to vote on issues, this is such a pain, having to reboot HA nightly to keep Chromecast groups somewhat operational.

[j0barr]

My server shuts down over night and starts up the next morning. The groups
are often already non-functional by the time I get home from work!

On Thu, Sep 20, 2018 at 11:01 AM joydashy [e-mail] wrote:

Wish there was a way to vote on issues, this is such a pain, having to
reboot HA nightly to keep Chromecast groups somewhat operational.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/13530#issuecomment-423102075,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQNwbRzGtM6FyPjMn9UnszZ3-4qDxLq0ks5uc1l1gaJpZM4TADhw
.

[joydashy]

My server shuts down over night and starts up the next morning. The groups are often already non-functional by the time I get home from work!
…
On Thu, Sep 20, 2018 at 11:01 AM joydashy @.*> wrote: Wish there was a way to vote on issues, this is such a pain, having to reboot HA nightly to keep Chromecast groups somewhat operational. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13530 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AQNwbRzGtM6FyPjMn9UnszZ3-4qDxLq0ks5uc1l1gaJpZM4TADhw .

My HA also reboots when it needs to use Chromecast groups and detects they are Unavailable. This of course introduces a delay in the functionality. It's a sucky workaround!

[awarecan]

Give 0.78.1 a try

[joydashy]

Give 0.78.1 a try

Looks promising! Will update soon.

[e1miran]

Updated to 0.78.1 yesterday evening. This morning woke up to 2 of my 4 groups Unavailable... and one of my individual chromecast audios, as well. Had to restart HA to re-connect to them.

[soldag]

I also still have the issues with 0.78.1.

[benjamin1492]

Also still having the same problem with 0.78.1

[awarecan]

If you don't want to share you config and/or log, please click the "+1" reaction icon to express "I have same problem"

[benjamin1492]

@awarecan
Thanks for your help with this. If you need anything in addition to what I've attached, please let me know. I'd be glad to help any way I can in getting this resolved.

Here's my config:

# Chromecast Audios

  - platform: cast
    name: Den
    host: 192.168.85.130

  - platform: cast
    name: Kitchen
    host: 192.168.85.145

  - platform: cast
    name: Dining Room
    host: 192.168.85.146

  - platform: cast
    name: Living Room
    host: 192.168.85.144

  - platform: cast
    name: Patio
    host: 192.168.85.173

  - platform: cast
    name: Master Bedroom
    host: 192.168.85.142

  - platform: cast
    name: Master Bathroom
    host: 192.168.85.149

  - platform: cast
    name: Master Closet
    host: 192.168.85.147

  - platform: cast
    name: Playroom
    host: 192.168.85.141

  - platform: cast
    name: Office
    host: 192.168.85.143

  - platform: cast
    name: "Sloane's Speaker"
    host: 192.168.85.125

  - platform: cast

#Google Home
  - platform: cast
    name: Office Home
    host: 192.168.85.160

  - platform: cast
    name: Master Bedroom Home
    host: 192.168.85.115

  - platform: cast
    name: "Sloane's Alarm Clock"
    host: 192.168.85.205

  - platform: cast
    name: Kitchen Home
    host: 192.168.85.118

  - platform: cast
    name: Den Home
    host: 192.168.85.128

#Chromecast Videos
  - platform: cast
    name: Den Chromecast
    host: 192.168.85.100

  - platform: cast
    name: Den Shield
    host: 192.168.85.204

  - platform: cast
    name: Playroom Shield
    host: 192.168.85.203

And here's the output from logger with focus on chromecast:
home-assistant.log

[joydashy]

I can also confirm that https://github.com/home-assistant/home-assistant/pull/16732 has not fixed this.

Which makes sense, as that fix refers to it being a problem for 15 days, but I have had this problem for much longer. Current issue is also much older.

[awarecan]

@benjamin1492, 0.78.1 would not resolve your issue since you are configuring host IP address manually.

However, the #16786 may help to fix your problem, I rewrote the device connection logic for your case.

[psfales]

78.1 did not help me either. It lasted about a day, but now I have both my group and my cast devices showing as unavailable.

[awarecan]

I created a new PR #16804, not sure if it will help, but you can try.

16786 caused more problem than fixed, I closed it.

[iorifly]

0.78.3 - same problem - group unavailable

[Wonkavator]

Running 0.78.3 this is my log when the cast group 'Home' got unavailable. The cast devices are setup by the discover feature, no IP component configuration:

2018-09-24 13:00:48 DEBUG (zeroconf-ServiceBrowser__googlecast._tcp.local.) [homeassistant.components.media_player.cast] Discovered chromecast ChromecastInfo(host='192.168.178.39', port=42673, uuid='a1883456-632f-4b0b-a2c6-fa6a246f1010', manufacturer='', model_name='Google Cast Group', friendly_name='Home') 2018-09-24 13:00:48 DEBUG (MainThread) [homeassistant.components.media_player.cast] Discovered chromecast with same UUID: ChromecastInfo(host='192.168.178.39', port=42673, uuid='a1883456-632f-4b0b-a2c6-fa6a246f1010', manufacturer='', model_name='Google Cast Group', friendly_name='Home') 2018-09-24 13:00:48 DEBUG (MainThread) [homeassistant.components.media_player.cast] Disconnecting from chromecast socket. 2018-09-24 13:00:48 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.home, old_state=<state media_player.home=off; friendly_name=Home, supported_features=21437 @ 2018-09-24T08:56:49.289521+02:00>, new_state=<state media_player.home=unavailable; friendly_name=Home, supported_features=21437 @ 2018-09-24T13:00:48.276523+02:00>> 2018-09-24 13:00:49 DEBUG (Thread-15) [pychromecast.socket_client] Sending: Message urn:x-cast:com.google.cast.tp.connection from sender-0 to receiver-0: {'type': 'CLOSE', 'origin': {}} 2018-09-24 13:00:49 DEBUG (Thread-15) [pychromecast.socket_client] connection listener: 70432210 (CastStatusListener) 2018-09-24 13:00:49 DEBUG (Thread-15) [homeassistant.components.media_player.cast] Received cast device connection status: DISCONNECTED 2018-09-24 13:00:49 DEBUG (MainThread) [homeassistant.components.media_player.cast] Connecting to cast device ChromecastInfo(host='192.168.178.39', port=42673, uuid='a1883456-632f-4b0b-a2c6-fa6a246f1010', manufacturer='', model_name='Google Cast Group', friendly_name='Home') 2018-09-24 13:00:50 DEBUG (SyncWorker_5) [pychromecast.controllers] Receiver:Updating status 2018-09-24 13:00:50 DEBUG (SyncWorker_5) [pychromecast.socket_client] Sending: Message urn:x-cast:com.google.cast.tp.connection from sender-0 to receiver-0: {'type': 'CONNECT', 'origin': {}, 'userAgent': 'PyChromecast', 'senderInfo': {'sdkType': 2, 'version': '15.605.1.3', 'browserVersion': '44.0.2403.30', 'platform': 4, 'systemVersion': 'Macintosh; Intel Mac OS X10_10_3', 'connectionType': 1}} 2018-09-24 13:00:50 DEBUG (SyncWorker_5) [pychromecast.socket_client] Sending: Message urn:x-cast:com.google.cast.receiver from sender-0 to receiver-0: {'type': 'GET_STATUS', 'requestId': 1} 2018-09-24 13:00:50 DEBUG (SyncWorker_5) [pychromecast.socket_client] Connected! 2018-09-24 13:00:50 DEBUG (MainThread) [homeassistant.components.media_player.cast] Connection successful! 2018-09-24 13:00:50 DEBUG (Thread-19) [pychromecast.socket_client] Received: Message urn:x-cast:com.google.cast.receiver from receiver-0 to sender-0: {'requestId': 1, 'status': {'userEq': {'high_shelf': {'frequency': 4500.0, 'gain_db': 0.0, 'quality': 0.707}, 'low_shelf': {'frequency': 150.0, 'gain_db': 0.0, 'quality': 0.707}, 'max_peaking_eqs': 0, 'peaking_eqs': []}, 'volume': {'controlType': 'master', 'level': 0.19118767976760864, 'muted': False, 'stepInterval': 0.019999999552965164}}, 'type': 'RECEIVER_STATUS'} 2018-09-24 13:00:50 DEBUG (Thread-19) [pychromecast.controllers] Received status: CastStatus(is_active_input=None, is_stand_by=None, volume_level=0.19118767976760864, volume_muted=False, app_id=None, display_name=None, namespaces=[], session_id=None, transport_id=None, status_text='') 2018-09-24 13:01:04 ERROR (Thread-19) [pychromecast.socket_client] Error reading from socket. 2018-09-24 13:01:04 WARNING (Thread-19) [pychromecast.socket_client] Error communicating with socket, resetting connection 2018-09-24 13:01:04 DEBUG (Thread-19) [pychromecast.socket_client] connection listener: 6fdd62f0 (CastStatusListener) 2018-09-24 13:01:04 DEBUG (Thread-19) [homeassistant.components.media_player.cast] Received cast device connection status: LOST 2018-09-24 13:01:04 DEBUG (Thread-19) [homeassistant.components.media_player.cast] Cast device availability changed: LOST 2018-09-24 13:01:04 DEBUG (Thread-19) [pychromecast.socket_client] connection listener: 6fdd62f0 (CastStatusListener) 2018-09-24 13:01:04 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=media_player.home, old_state=<state media_player.home=off; friendly_name=Home, supported_features=21437 @ 2018-09-24T13:00:50.220474+02:00>, new_state=<state media_player.home=unavailable; friendly_name=Home, supported_features=21437 @ 2018-09-24T13:01:04.444502+02:00>> 2018-09-24 13:01:04 DEBUG (Thread-19) [homeassistant.components.media_player.cast] Received cast device connection status: CONNECTING 2018-09-24 13:01:04 DEBUG (Thread-19) [pychromecast.socket_client] connection listener: 6fdd62f0 (CastStatusListener) 2018-09-24 13:01:04 DEBUG (Thread-19) [homeassistant.components.media_player.cast] Received cast device connection status: FAILED 2018-09-24 13:01:04 ERROR (Thread-19) [pychromecast.socket_client] Failed to connect, retrying in 2.0s 2018-09-24 13:01:06 DEBUG (Thread-19) [pychromecast.socket_client] connection listener: 6fdd62f0 (CastStatusListener) 2018-09-24 13:01:06 DEBUG (Thread-19) [homeassistant.components.media_player.cast] Received cast device connection status: CONNECTING 2018-09-24 13:01:06 DEBUG (Thread-19) [pychromecast.socket_client] connection listener: 6fdd62f0 (CastStatusListener) 2018-09-24 13:01:06 DEBUG (Thread-19) [homeassistant.components.media_player.cast] Received cast device connection status: FAILED 2018-09-24 13:01:06 DEBUG (Thread-19) [pychromecast.socket_client] Failed to connect, retrying in 2.0s 2018-09-24 13:01:08 DEBUG (Thread-19) [pychromecast.socket_client] connection listener: 6fdd62f0 (CastStatusListener) 2018-09-24 13:01:08 DEBUG (Thread-19) [homeassistant.components.media_player.cast] Received cast device connection status: CONNECTING 2018-09-24 13:01:08 DEBUG (Thread-19) [pychromecast.socket_client] connection listener: 6fdd62f0 (CastStatusListener) 2018-09-24 13:01:08 DEBUG (Thread-19) [homeassistant.components.media_player.cast] Received cast device connection status: FAILED 2018-09-24 13:01:08 ERROR (Thread-19) [pychromecast.socket_client] Failed to connect. No retries. 2018-09-24 13:01:08 DEBUG (Thread-19) [pychromecast.socket_client] connection listener: 6fdd62f0 (CastStatusListener) 2018-09-24 13:01:08 DEBUG (Thread-19) [homeassistant.components.media_player.cast] Received cast device connection status: DISCONNECTED

[edif30]

@awarecan under new PR #16804 the groups still don't come back as per this issue.

[e1miran]

@awarecan under new PR #16804 the groups still don't come back as per this issue.

Confirmed here, as well.

[awarecan]

16804 only addressed issue of start up hanging in manual configure scenario, rest logic reverted back to 0.77. So if you have group unavailable issue before, you still have it now.

I don't have "group" myself, I won't be able to reproduce or debug that issue, so I am afraid I won't be able to help much.

[balloob]

@awarecan this is where you suggest people to buy you two Google Homes so you can create a group 👍

[joydashy]

If a donation towards a Ghome Mini or so would help get this bug fixed, I'm in. This is by far my biggest issue with HA right now.

[Wonkavator]

If a donation towards a Ghome Mini or so would help get this bug fixed, I'm in. This is by far my biggest issue with HA right now.

I would be in as well.

[datafx]

You can just use a couple of chromecast audio units since they are a bit cheaper.

[benjamin1492]

I'm in as well, but want to add my two cents on how to proceed. As background, I have a very robust Google cast implementation: 10 Chromacast Audios, 4 Google Homes, an Insignia alarm clock, and a Sony speaker with Chromecast built-in. Ever since Google updated the firmware in Nov-17, this has been a problem. However, none of the Chromecast Built-in devices that remain on old firmware such as the Sony speaker or Insignia alarm clock are impacted. My suggestion is that each of us willing to send equipment to awarecan for this project send something different: a full size Google Home, a Google Home Mini, a Chromecast Audio, and at least 2 Chromecast built-in devices. This would allow awarecan to build a variety of different groups to test the code - group of all built-ins, group of Google devices, and a mixed group.

This integration has been a graveyard for many a capable Home Assistant developer just because of it's overall complexity. This approach will give us the best shot at finally getting this thing resolved. I'd even be willing to throw a $100 bounty out there for a final fix, in addition in addition to a Google Home.

Awarecan: You mission should you choose to accept it is to fix the Cast platform for good. Shoot me an address and I'll get a Home en route.

[joydashy]

That works as well, I think @awarecan should let us know what would actually be most helpful.

[Roemer]

I have only one google home mini and it regularly (after a few hours) goes to unavailable until I restart HA. Is this the same issue or is this fixed with #16804? I am using manual configuration.

[gezonthenet]

Still having this issue on Home Assistant 0.79.3

[iorifly]

I have this problem too. It does not seem to have much interest in solving...

[josephkiser04]

@awarecan Is there anything we can do to help? Donations, devices, etc? I agree with most people here this desperately needs to be corrected once and for all and I know many of us are willing to help in anyway we can.

[iorifly]

Dear, someone working on this problem ???

[allmoney]

Same problem in Home Assistant 0.80.2

[fillwe]

Yeah still experiencing this on 0.82

[j0barr]

Has no one tried reverting whatever component changed back in March? Nothing has been fixed regarding this issue since it cropped up back then.

[edif30]

@j0barr this issue has nothing to do with any changes. The issue has been present since day 1 of Google Cast Groups being available and integrated into HA. It has to do with how the leader of the group (which is comprised of all the devices in the group) is elected. If the leader changes (happens relatively frequent), the group goes unavailable. You can see this with netdisco. More than likely a dev will have to do a big rewrite in order to address this issue.

[j0barr]

That's odd if nothing has changed because I swear it was working for me back with version 65 (you might be right, though, of course!)

[edif30]

You can easily revert back to that version and test. Or set up a dev environment and only add the cast devices. You will see that the groups go unavailable. Trust me, I've been involved in this issue since day 1.

[j0barr]

Yeah, I'll try that if I get a chance I guess. In any case, it sounds like this will just be broken until further notice unless someone tackles it specifically then. I was under the impression that it really had worked at some point (even the initial report above suggests it worked in 0.65.6).

[edif30]

Issue goes back way further than that. https://github.com/home-assistant/home-assistant/issues/7782 is when I first started tracking the problem.

[bryanyork]

Looked into this for a bit, going to see if the latest version of zeroconf would fix this. Zeroconf is used for pychromecast which is used for the Cast component.

Two fixes from their changelog interest me:

Switched from netifaces to ifaddr (pure Python)
ServiceBrowser entries are being refreshed when 'stale' now
https://github.com/jstasiak/python-zeroconf/blob/master/README.rst

The current version used by pychromecast is 0.17.7

[OttoWinter]

@bryanyork Nope, that is unrelated. The issue is that when the cast group changes its elected leader we are currently not re-connecting to the new elected leader in the way the chromecast expects. We do get the callback from zeroconf that it has changed the leader. And we currently do try to disconnect from the old leader and re-connect to the new one. However, something in that process is behaving in a way that the chromecast doesn't expect, and though many hours of debugging I haven't been able to resolve the problem yet. This issue is particularly hard to diagnose because it just happens randomly every few hours, so if you test something you always have to wait that amount of time for the change to trigger again.

[Shadex12]

I've noticed that restarting HA always fixes this problem. What is it about restarting HA that causes this to be fixed, at least temporarily?

Is it possible we could make the software mimic whatever a reboot does to get around the issue?

I'd tried adding an automation to reboot if cast groups become unavailable but that became unreliable too as sometimes HA wouldn't come back,

[darylsargent]

I've noticed that restarting HA always fixes this problem. What is it about restarting HA that causes this to be fixed, at least temporarily?

I'm with @Shadex12, a restart will fix it. I was using cast groups as a alarm warning, but with them disappearing (going unavailable) I have temporarily reverted to a single speaker.

Can't add much to the discussion except to add my encouragement for a fix.

[ajfriesen]

I am on Hassio 0.82.1 and my groups were also "unavailable" after some time in the middle of the night.

• I have two groups. Each of them were "off" from 22:47 to 02:19. (2018.12.04)
• Then they were "unavailable" from 02:19 to 03:08. (2018.12.05)
• Then again they went to status "off" from 03:08 to 04.57. (2018.12.05)
• Then they went unavailable until now: 04:57 to 22:04.

Logs on hassio:
https://paste.ubuntu.com/p/J6Nt3pSzH9/

If I can help in any way let me known.

[kalkih]

Same issue here on HA 0.84.2.

Groups change to unavailable every other day and refuses to come back, restarting HA always does the trick.

[tungmeister]

This issue is still present, any progress on this? I'm having to reboot home assistant daily at the moment due to this.

[ashmckenzie]

Curious if reloading core via clicking 'RELOAD CORE' at /config/core helps?

[tehshane]

Curious if reloading core via clicking 'RELOAD CORE' at /config/core helps?

Doesn't appear to. Just tried it a couple of times, and the cast group is still unavailable.

[thomashermine]

Curious if reloading core via clicking 'RELOAD CORE' at /config/core helps?

I tried as well, with no success — the group is still unavailable.

[joydashy]

Still have this problem also (on 0.84.6). I detect it using AppDaemon and then force a restart of HASS. It triggers every 1-2 days.

[JIOB]

Just throwing out there that if lack of hardware is the barrier to this being fixed, I'd be more than happy to contribute with a donation of a Google Home Mini or Chromecast.

[tehshane]

Just throwing out there that if lack of hardware is the barrier to this being fixed, I'd be more than happy to contribute with a donation of a Google Home Mini or Chromecast.

Get 'em while you can. Google just pulled the plug on the Chromecast Audio. 😭

[benjamin1492]

I've given up on the Home Assistant Google Cast integration for now. Because I already had a smartthings v2 hub and MQTT HA integration to control Nexia thermostats, I'm using the smartthings Google Chromecast integration along with a node.js server:
https://community.smartthings.com/t/release-cast-web-1-0-0-chromecast-device-handler-smartapps/88038
Then I send the player/group states back to HA through the same MQTT bridge. I really just use it to turn 20 year-old, energy-sucking, whole-house amps on only when music is playing, and this works fine for that. Because I couldn't figure out a way to send notifications from HA back to the smartthings Chromecast app through MQTT, I did have to add the Google Homes back to Home Assistant. I turned discovery completely off and added them by IP address. This means I have to rely on the Home Assistant group functionality instead of the built-in cast groups, but the synchronization hasn't been too bad.

The Google Homes go through availability issues from time to time, but this setup hasn't gimped my whole system like it did previously with 34 discovered entities (19 devices, 15 groups). That was causing devices and groups to not only disappear from Home Assistant, but to also disappear from all other cast-capable apps (Google Home, Chrome browser, Pandora, etc).

If anyone else decides to go this route, I'd be happy to provide some pointers. I have worked on this for many hours over the weekend, but finally have as stable as it's ever been.

[JIOB]

Just throwing out there that if lack of hardware is the barrier to this being fixed, I'd be more than happy to contribute with a donation of a Google Home Mini or Chromecast.

Get 'em while you can. Google just pulled the plug on the Chromecast Audio. 😭

Well would you look at that! I hope they replace it with something that has comparable functionality pretty soon!

[tehshane]

Well would you look at that! I hope they replace it with something that has comparable functionality pretty soon!

I've gotten the impression that the Google Home speakers are their focus going forward. 😢

[ttaidapos]

And here I was thinking I was special only to find this as I was submitting a new issue. Let me know if there's anything else that's required to dig into this issue. It's a shame because I can't get my media tab to work properly :)

[joydashy]

Not sure if something has changed, am on 0.84.2 and currently have an uptime of 267 hours without automatic restart due to Cast groups going unavailable for too long. Anyone else experiencing a possible improvement? Perhaps a fix/change on Google side?

[ttaidapos]

No improvement here.

[JIOB]

Non here either (0.86.2)

[masterz666]

I'm affected by the issue as well.
I'm looking for a workaround until the issue is resolved.

I've seen that restarting Home Assistant does solve the issue, so something is capable of healing this 'unavailable' status in HA.
Does anyone know how to reproduce this without a complete restart ?

My idea would be to create an automation which does something like:
If
no cast devices are running
and
at least 1 cast group is 'unavailable'
then
reload the chomecast integration (-> heal)

Any idea on which service/function to use ?

[emontnemery]

This should be fixed in beta 0.88.0b0

Please give it a try!

To provoke errors, try restarting casts that are members of an audio group, either through the Google Home app or by simply power cycling.
Note: It's normal that the group goes offline and comes back a few times as group leadership may be handed over several times if the restarted unit is the preferred group leader.

In case it's still not working, a complete HA log - from starting HA until group is no longer - is needed for debugging.

Logger options in configuration.yaml

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

[masterz666]

Hi,

I pulled Home assistant Dev 0.89 in a docker container (fresh config, host networking) and used discovery to autoconfigure my chromecasts and groups.
They are discovered but all 'unavailable'.
The attached log shows "Failed to connect" errors.
https://paste.ubuntu.com/p/4BRQ3hhQBC/

[emontnemery]

@masterz666 That should be fixed in beta 0.88.0b2

[soldag]

@emontnemery I'm on 0.88.0b0 since Thursday and didn't had this issue since then. Seems like it really fixed it (at least for me) 🎉

Thanks for you work! 👍

[masterz666]

on 0.88b2 I sometime have this in the log. is this expected ?
[Chromecast salon:8009] Heartbeat timeout, resetting connection

[edif30]

I don't want to jump the gun but I think the new pychromecast update may have solved this issue! And mainly due to a experimental commit. https://github.com/balloob/pychromecast/pull/268. Crossing fingers but this is very promising!

[emontnemery]

@edif30, @soldag Thanks for the feedback! balloob/pychromecast#268 is included in HA 0.88 via #21097 so I'll go ahead and close this issue.

[emontnemery]

@masterz666 The print means HA lost the connection to a chromecast. At least for me, chromecasts are not extremely stable and reboot now and then, so yes, I'd say its expected.

[benjamin1492]

Does anyone on this thread have a Sony or Insignia speaker with Chromecast Built-in? If so, have you noticed them causing any issues after updating to the new pychromecast? The new version still isn't working for me, which I think makes me the exception based on the recent feedback. I'm now trying to troubleshoot my cast install, and starting with the less common devices.

[backcountrymountains]

semi-unrelated:
@ttaidapos can you post your yaml for those media player cards that you posted pics of?

Thanks.

[ttaidapos]

For what it's worth. I'm on 88.2 and the group casting still going strong! Still have a plethora of errors though.

Line 718: 2019-03-03 04:58:09 WARNING (Thread-12) [pychromecast.socket_client] [Baby display:8009] Heartbeat timeout, resetting connection
    Line 1807: 2019-03-04 02:01:09 WARNING (Thread-2) [pychromecast.socket_client] [Living Room Speaker:8009] Heartbeat timeout, resetting connection
    Line 1828: 2019-03-04 02:22:58 WARNING (Thread-7) [pychromecast.socket_client] [Office display:8009] Heartbeat timeout, resetting connection
    Line 1829: 2019-03-04 02:28:16 WARNING (Thread-9) [pychromecast.socket_client] [Kitchen Speaker:8009] Heartbeat timeout, resetting connection
    Line 1830: 2019-03-04 02:28:23 WARNING (Thread-6) [pychromecast.socket_client] [Bedroom Speaker:8009] Heartbeat timeout, resetting connection
    Line 1836: 2019-03-04 02:34:31 WARNING (Thread-15) [pychromecast.socket_client] [Bathroom Speaker:8009] Heartbeat timeout, resetting connection
    Line 1873: 2019-03-04 03:17:51 WARNING (Thread-12) [pychromecast.socket_client] [Baby display:8009] Heartbeat timeout, resetting connection
    Line 1894: 2019-03-04 03:42:43 WARNING (Thread-5) [pychromecast.socket_client] [Soundbar Speaker:8009] Heartbeat timeout, resetting connection
    Line 1944: 2019-03-04 04:36:27 WARNING (Thread-10) [pychromecast.socket_client] [Dining Room Speaker:8009] Heartbeat timeout, resetting connection
    Line 1988: 2019-03-04 05:26:33 WARNING (Thread-14) [pychromecast.socket_client] [Kitchen display:8009] Heartbeat timeout, resetting connection

[ttaidapos]

semi-unrelated:
@ttaidapos can you post your yaml for those media player cards that you posted pics of?

Thanks.

It's a lot and I take no credit for it. I have modified it the yaml a lot. here it is and best of luck!
https://pastebin.com/RbWJVNhH

[frankhommers]

I lose cast groups still with 0.97.2...