Google home devices not found

hi.
i have version 0.63 of home assistant, and have noticed that my google home devices are no longer found.
i tried setting them up then manually within the media_player configuration as cast platform and IP… but here there is also no luck
the logs are full of “slow setup” errors… and can not connect …
the devices (google home and google home mini) are online and i can control them via google home app on the phone.
i did of course 'google" the issue and there are lots of forums with issues of the pyChromeCast component being less than 1.0 having an issue… i have version 2.0.0 (updated just now to 2.0.1) but still ahve issues.

the google home and google home mini software has version 1.31.114510 and the chromecast which is being found has 1.30.113131 … so i am guessing its an issue with the firmware on the google home devices… but i was wondering if anyone else has the issue or has a work around for me.

Have you tried updating? if i recall correctly, 0.62 to 0.63 had issues because they overhauled the unique id for all media_player devices.

i misspoke … i am on version .64 from version .59 … so maybe i did do something totally wrong here… but that doesnt explain why the chrome cast would work.

which rev of 0.64?

Hi, I just did a massive cleanup for the cast integration for 0.66 (https://github.com/home-assistant/home-assistant/pull/13275) because the old code was getting pretty un-maintainable. Even though I tested it quite thoroughly, there could very well be a bug in there too. Especially since Google’s Cast devices are quite a mess and never seem to stick to a standard. Anyway, could you enable debug logs for the cast component and tell me the results? Thanks very much!

logger:
  default: error
  logs:
    pychromecast.socket_client: debug
    pychromecast: debug
    homeassistant.components.media_player.cast: debug

The “the logs are full of ‘slow setup’ errors… and can not connect …” are expected now if you have the cast devices set up by IP and one of them isn’t available. Could you maybe also provide the configuration you’re using (specifically the media_player#cast and discovery: parts)?

hi @petro
thanks for the reply
revision is currently 0.64.0
here my configuration yaml settings for the discovery and cast parts.\

discovery:
  ignore:
    - denonavr
    - philips_hue

and

  - platform: denonavr
    host: 192.168.0.74
    name: Denon AVR
  - platform: cast
    name: Kitchen Home
    host: 192.168.0.56
  - platform: cast
    name: Niclas
    host: 192.168.0.61

and thats about it.
i will try setting up the logging as u said… but i am not yet the complete expert :)… i actually did an update of the pychomecast stuff using pip3 --install … and now the version is 2.0.0 … i thought it had incremented up to 2.1 … but this didnt happen.

Well, the media changes that broke my device didn’t get into 0.64 until build 3. You may want to update to the latest and greatest. Chances are there was an issue that has since been fixed.

Ah yes, I didn’t see you we’re using 0.64.0 - There have been quite a few fixes to the cast platform recently and I would strongly advise you touse the latest Home Assistant version if you want the latest fixes.

In my experience, the support for all Google Cast devices is very unstable for several releases now. I must restart Hass every couple of hours because it loses connectivity. I hope this gets stable soon as I use a lot of cast devices in several automations.

ok i will update to .66 and let u know what happens.

so… the good news is that my cast devices are now there …
but the tts functionality doesnt work …
and everything philips hue doesnt work :slight_smile:

there seems to be a problem with aiohttp in 66.1 -> i downgraded to 65.1 and now my philips works again… with the expense that in ths version google home again doesnt work
so i guess something changed between 65 and 66 which makes google cast work … but its unusable for me at the moment until the aiohttp issue is fixed… but that has nothing to do with this thread.

Check the release notes on the hue breaking change in 0.66

@Sjee … thanks
u mean:
Refactor Hue: If you specify a bridge in your config, the host key is now required and needs to be a valid ip address. Option allow_in_emulated_hue has been removed. Exclude the lights via the emulated hue config. If you are using a custom component for Hue, this will break! Ask custom component author for an update. (@balloob - #13043) (hue docs) (light.hue docs) (breaking change)

my hue configuration was already set up like this correclty with host etc :)… so this isnt it.

That’s what I thought as well but after upgrading to 0.66 I had to remove the “-” in front of host:

Double check or post your config and log.

1 Like

i will wait for 67 again …

my config looks like this:

hue:
  bridges:
    - host: 192.168.0.54

so i am supposed to remove the - here?.. how would i specify then multiple bridges… normally the - means a list member