core

core copied to clipboard

Proposed change

In some situations it may be preferred to cast via the internal URL. Ref: https://github.com/home-assistant/core/pull/73764

To give a concrete example: I am using Home Assistant Cast to power a Magic Mirror with a Chromecast driving the background display. Unfortunately our internet connection is quite unstable which leads to random white screens on the display. I would like to avoid this by using a local connection instead of an external or cloud connection. Source: https://github.com/home-assistant/core/pull/73764#issuecomment-1160879443

This is a new attempt at solving this situation/requirement by adding a configuration option to the Cast component instead of adding an attribute to the service call as suggested by @emontnemery in https://github.com/home-assistant/core/pull/73764#issuecomment-1161856149.

Type of change

• [ ] Dependency upgrade
• [ ] Bugfix (non-breaking change which fixes an issue)
• [ ] New integration (thank you!)
• [x] New feature (which adds functionality to an existing integration)
• [ ] Deprecation (breaking change to happen in the future)
• [ ] Breaking change (fix/feature causing existing functionality to break)
• [ ] Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• [x] The code change is tested and works locally.
• [x] Local tests pass. Your PR cannot be merged unless tests pass
• [x] There is no commented out code in this PR.
• [x] I have followed the development checklist
• [x] The code has been formatted using Black (black --fast homeassistant tests)
• [x] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• [ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• [ ] The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• [ ] New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• [ ] Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• [ ] No score or internal
• [ ] 🥈 Silver
• [ ] 🥇 Gold
• [ ] 🏆 Platinum

To help with the load of incoming pull requests:

• [ ] I have reviewed two other open pull requests in this repository.

Hey there @emontnemery, mind taking a look at this pull request as it has been labeled with an integration (cast) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

Home Assistant Cast is hosted on https://cast.home-assistant.io. Browser security context does not allow making requests from an HTTPS context to an HTTP context, which is why we're only communicating over the external URL.

Cast devices also use their own DNS so you can't override the DNS and offer a valid SSL certificate.

So basically, this PR is not going to solve your problem. With flaky internet the https://cast.home-assistant.io website will not load, which is the source of your problems.

Home Assistant Cast is hosted on https://cast.home-assistant.io.

I don't think this is relevant if the Cast is launched via the service call show_lovelace_view from within Home Assistant, right? At least the only references to cast.home-assistant.io I could find in the source code were the DEFAULT_CORS and test mocks.

Browser security context does not allow making requests from an HTTPS context to an HTTP context, which is why we're only communicating over the external URL.

I have HTTPS for my internal URL using Traefik with Let's Encrypt via the DNS-01 TXT-record based challenge, so I also don't see any issue here. I don't want to change the default, I just would like to be able to route my Chromecast via the internal (local) URL on demand (as an advanced configuration option).

Cast devices also use their own DNS so you can't override the DNS and offer a valid SSL certificate.

Yes, you can do that somewhat easily. As stated above, a valid SSL certificate for a public domain which is just routed locally, is no problem with the DNS-01 challenge (those TXT-records are of course available in public, but not the A-records, so I have split DNS on the domain in that sense). And forcing the Chromecast devices to use a local DNS server is also achievable with e.g. iptables on a Linux-based router like this:

iptables -t nat -A PREROUTING -s <Chromecast-IP> -d 8.8.8.8 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.1:53
iptables -t nat -A PREROUTING -s <Chromecast-IP> -d 8.8.8.8 -p udp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53
iptables -t nat -A PREROUTING -s <Chromecast-IP> -d 8.8.4.4 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.1:53
iptables -t nat -A PREROUTING -s <Chromecast-IP> -d 8.8.4.4 -p udp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53

So basically, this PR is not going to solve your problem.

I do indeed think that this will at least help solve my problem (at least partially). Otherwise I would not be working and spending rare spare time on this PR.

With flaky internet the https://cast.home-assistant.io website will not load, which is the source of your problems.

The casting does indeed work at the beginning and for quite some time, but after a quite random amount in the order of >30 minutes to a couple of hours, the Chromecast screen will just go blank white with some errors appearing in the logs.

@balloob Therefore I kindly ask you to reconsider your vote on this PR and re-open it in order to support my use case. I just pushed a new version to my branch which fixes the earlier test failures.

HA Cast app is always served from cast.home-assistant.io. That's how Cast works.

We won't consider configuration options for a use case serving probably just you and maybe a handful more users in the future.