It makes sense. I’ve been trying to use HTTPS i will do it when i have time. You just have to use Let’s encrypt addon i think.
Great thing, this HA Cast. Bought a Google Nest Hub after reading the blog post. Installed it. Got discovered by HA right away. Casting via the https://cast.home-assistant.io/
per view works fine. Also the start-casting works via the type: cast
entities in Lovelace. But I only got that running by view < number >, not by view < path >. Maybe it’s related to the fact I’m using
views:
- !include ui-lovelace/home.yaml
...etc...
I get path errors (shown on the Nest Hub) if i use view: home
or view: ui-lovelace/home
or even view: ui-lovelace/home.yaml
. But with view numbers, it’s fine.
Can’t wait to see more features, especially trigger casting a specific card from an automation. (E.g. show some specific light buttons when a movement sensor is triggered at a certain period of the day.)
Did you put the view name in quotes? I found I even had to put the view number in quotes. If you haven’t set a path for a view that may also be why. I think the path name is different to the title.
Ah, path
is not referring to the path where my yaml’s for the views are stored. My files are in <config-folder>/ui-lovelace/<view-file>.yaml
and my view
definition is in <config-folder>/ui-lovelace.yaml
. I don’t use paths in my views then.
But whatever I try (view: "home", view: "Home", view: home, view: Home)
, only view: 1
works. But I can live with that.
I have a Facebook Portal (it was a present), would be super cool to be able to use cast with that too
see here https://www.home-assistant.io/lovelace/views/#paths
You have to explicitly define a path for the view - it’s not the title or name used here. If you don’t define a path it uses 0, 1, 2 etc as the path. I agree it’s a bit confusing too.
Just for shits & giggles I added path to my views:
views:
- title: Home Assistant
icon: mdi:home-assistant
path: home_assistant
cards:
- type: vertical-stack
and cast…
title: Chromecast Control
show_header_toggle: false
entities:
- type: cast
name: System
view: "home_assistant"
hide_if_unavailable: true
Works perfectly. The view MUS have inverted commas around it. This was my ‘0’ view and I can use either “0” OT “home_assistant”
Either works.
I’ve just found out that I needed to add a NAT rule to do a hairpin NAT, as I figured out the reason why my views wouldn’t cast when logged in via cast.home-assistant.io.
Since you provide a HTTPS link for this to work, it assumes that everything is configured to be set up using your external WAN address. So when it comes time to connect, our computer receives a message from HASS via cast.homeassistant.io, and then replies to that with it’s internal address. Since the HASS webserver is expecting a response from the external address, it will ignore that response and time out.
Mikrotik users can use the rules from the second example in the wiki here: https://wiki.mikrotik.com/wiki/Hairpin_NAT
That link also provides more information about this issue.
Thx @DavidFW1960 . Adding the path
s for all view
s did it. For me the double quotes (") weren’t necessary.
I can’t get that up and running.
My HA is published over https with an own certificate. I can access the frontend from outside of my network.
When I start the cast- I constantly get an Image with the HA logo, a heart and the Nabu Casa logo. Under this there is a message written: Not connected
Any hint would be nice!
I have the same issue.
I have my own certificate authority so have my own cert in HA. Normally I block outside access but even with outside access open I get the same Image of HA logo, heart and Nabu Casa logo with message Not Connected.
I’m guessing cast.home-assistant.io might be getting a certificate invalid error because my root cert is not publicly available.
I’m also using Nginx as a reverse proxy and there was a mention about that above, but they are able to connect, just not display cards, so I’m guessing that is a separate issue.
Have a look after you select cast and pick a device to cast to, go back to the device you are casting from and make sure you select a view to cast (its an option that comes up after). After I make that selection HA casts properly.
sorry. i’m late to the party.
i’m just wondering what’s the difference between this and a tablet with fully kiosk browser?
Good question, which no one seems to want to answer
Well, this works on your Google Cast devices
Not everybody will have tablets scattered around the house, but may have a variety of Cast devices (Home Hub or clone, or even a TV with ChromeCast).
I guess it works for people who have a cast device already. But would I buy one as a device just to use for HA? Probably not.
I guess what @masterkenobi and I want to know is, is there some advantage or secret sauce that makes a cast frontend any better than a browser frontend?
Flip your question around - if you already have Cast devices would you buy some tablets just for HA… probably not Just because you have a solution already doesn’t invalidate this.
Is it better in a general perspective (ignoring the fact that better is personal) - probably not. Is it worse, also probably not. It’s simply a different approach.
Of course, the flip is true too. As long as I’m not missing out on anything by not having a cast device…
(well I have a chromecast, and it works, but my TV is not touch, and even if it was, any f****er who puts their fingers on my tv dies a long slow death!)
Thanks for all your replies. Next questions are…
What is the cheapest cast device that I can try it on?
Can I use any Android tablet and install an app to support this?
What if I don’t have both? Which one should I go for?
Yes, but it does not work either.