Home Assistant release (hass --version):
0.26.3
Component/platform:
discovery
Description of problem:
When Chromecast Audio groups are discovered, the wrong friendly name is assigned to each group.
For instance, I have 3 Chromecast Audio: Living Room, Kitchen and Dining Room. I made groups for all the combinations of them, and in Home Assistant they're discovered as "Living Room", "Living Room", "Living Room", and so on for the other rooms. Internally, they're assigned names as "Living_Room", "Living_Room_2", "Living_Room_3", but this makes it difficult for me to organize the views and control them anyway.
Expected:
I expect the Chromecast Audio groups to be correctly recognized with their respective friendly names.
Additional info:
I found that in the cast component the Chromecast objects are initialized with the (host, port) combination, that doesn't correctly detect groups. Instead, here we could use pychromecast._get_all_chromecasts() rather than discover_chromecasts() and we would already get Chromecast objects back, to directly pass to the CastDevice initializer. After a first look, the change would consist of 2 modified lines. I'm not sure if this impacts other parts of the system too, since I just installed Home Assistant on my RPi3 yesterday.
I'll be happy to read the contributing guide and write needed tests, after I setup a development environment to properly test the changes.
Please discuss here if this would be welcome (or wrong).
Thanks by the way for the amazing platform!
Yes, this is an issue for me as well! I was so confused as to why I was getting extra Chromecasts showing up! Having the name of the group would be wonderful!
I didn't start working on this yet since I was waiting for feedback from the main maintainer. I'd be happy to tackle this (it's quite easy to solve IMHO) as soon as he gives me the greenlight.
You could probably write the change and submit a pull request, if there's an issue they'll hammer it out on there.
This is an issue for me also with the two Chromecast Audio devices that are also assigned a group for synchronized audio play.
Are you waiting for permission from @balloob? I think he mostly deals with PRs, I would just go ahead and sub not one if the change is as easy as you say. To the best of my understanding he is in favor of things that fix bugs as long as they don't break things.
You're completely right! I'm not waiting for permission anymore but unfortunately have very few time at disposal to start setting up a test environment, applying the change and testing that everything works as expected :(
I'll try to do what I can, but don't expect much
Whatever you can do is greatly appreciated, and i'd be happy to help test!
Does anybody here have a link where to look at how to setup a dev environment and to start a local instance from source?
Ok, so I found another way to fix the issue, but it's not really nice and efficient. The main issue is, though, that I can't seem to setup the tests environment in a way that all tests run and pass (even before my modification).
I'll push to my fork and open a PR, hoping that somebody can take over and finish the job, or explain me how to setup my environment in a way that I can finish it myself.
I've been looking into this as well. Here's a report of this issue upstream in pychromecast https://github.com/balloob/pychromecast/issues/94
Your fix is probably a little better than mine: https://gist.github.com/hcooper/34a32fdec4338b83582c29e9db31eb76 (only works for chromecasts not autodiscovered or hardcoded).
I'm giving your patch a test, and see if I can get the tests to work.
So, it took some time but my fix was merged 馃憤 I guess this will be in the next release!
Most helpful comment
So, it took some time but my fix was merged 馃憤 I guess this will be in the next release!