Chromecast binding - Youtube not working?

Add-ons Bindings
1

Hi there!

I’m trying to make the chromecast binding work with youtube and a sony tv (internal chromecast).

I used this thing:

Thing chromecast:chromecast:5891d2830c5896deef4a15a493bc6001          "Chromecast TV"                 [ipAddress="192.168.100.15", port=8009]

These Items:

Player  StartPlaying          "Start Playback"                           {channel="chromecast:chromecast:5891d2830c5896deef4a15a493bc6001:control"}
String  PlayUri               "Play Uri"                              {channel="chromecast:chromecast:5891d2830c5896deef4a15a493bc6001:playuri"}
Switch  Play                 "Play"
Switch  Stopit               "Stop "                              {channel="chromecast:chromecast:5891d2830c5896deef4a15a493bc6001:stop"}

This rule:

rule "Chromecast"

when 

    Item Play changed to ON

then 

    PlayURI.sendCommand("https://www.youtube.com/watch?v=YPq41499v_M")
    StartPlaying.sendCommand("PLAY")

end

Am I doing something wrong? the screen tries to cast something but it stays there with a blue cast icon and stays like that forever.

Thanks!

2

You can’t do what you’re trying to do. The Chromecast binding can send video/audio streams to a Chromecast, but you’re just telling it to play a URL for a webpage. So it’s trying to do that and can’t find any media.

There’s a trick to get it going, but I don’t know whether or not it works. I haven’t tried it, I just searched the forum for “Chromecast youtube”.

You could also try getting the actual video stream that youtube is using to deliver the video to your web browser.

3

I actually tried to get this to work as per Russ’s linked thread and could not. If you figure it out, post up how you did it

4

I´ve seen that post too, tried it but didn’t work :pensive:

5

In the future, you should mention what you’ve read/tried. :wink:

I’m guessing that Google changed the application/json string that gets sent to the Chromecast. You might be able to dig that out from some Google developer documentation.

6

OK Thanks.

It seems the Chromecast binding is not very useful at the moment. Also the official documentation is confusing since it provides examples for audio only and an advanced rule for triggering other stuff that is not the core of the binding itself (which in my opinion should be making cast work for video as the main feature and audio as a secondary). There are no examples on how to make it work. The ones provided leaves you scratching your head and are not explained.

Hopefully someone (as our friend giving a workaround up there) will make it work.

7

It might be important to realize a few things about openHAB. openHAB is not a media management and streaming system. It actually really sucks at this use case and even after a lot of effort and work what you end up with is going to be brittle and limited.

But that isn’t the only use for Chromecasts in a home automation system. Don’t forget that Home Hubs and Home speakers are ChromeCasts too. One of the primary use cases of the Chromecast add-on is to be able to send announcements and alert sounds and stuff like that to these speakers (e.g. have the speakers announce that the dryer is done).

That use case is very useful. This is how most of us are using this add-on, not because that’s the only thing it supports but because that’s all we care about. This is the core part of the binding.

To control what videos are playing on a screen is better left to something that is good at that job as even if the binding were good at supporting that, openHAB itself is really bad at it.

8

Thanks Rich, I know that Openhab is not suitable for absolutely anything us (the users) want it to do, but in defense of what I said above, Chromecast primary use is video and audio streaming, that is what anyone would think when someone says “chromecast”. I’m absolutely not against secondary uses, and thinking out of the box is what this community is all about.

What I say, is that the documentation of that binding is not useful at the state it is now. I know that no one is being paid for the effort put into this (before someone wants to lecture me with that) but if someone is going to contribute, they should do it in a meaningful way, meaning that the documentation should be understandable, it should not contradict itself and it should provide basic configuration steps to get the binding working as it was thought to. In this case, if the binding doesn’t support video, it could clearly say so and let users like me use our time in other things. Further complexity should be treated in the forums not in the official doc (take a look at the offcial doc of this binding and you will understand). Right now, I have literally no clue on how this binding works, could not find any explanation on how this works and the official doc is very poorly made.

Sorry if someone feels bad about this, but I think a key point in this DIY free proyect is to have good starting information.
I like/use Openhab and I really think its great, so don’t feel touched if I say that something doesn’t work and its somehow abandoned, I know the rules “it’s free, don’t rant” and I’m not ranting, just saying something that anybody can check.

9

But it does support video if you pass it some actual video. A URI to a Youtube web page isn’t the actual video. It’s a web page with a video stream embedded in it along with a ton of JavaScript and other content. If you pass it a URI to an MP4 it will play that video without problem.

The link Russ provided above was an attempt to find the URI for the actual video on a YouTube page. If that can be worked out it will work too.

The root problem here is a lack of understanding that a regular old Youtube URI is not a URI to the actual media, be it audio or video. That could be made more clear in the docs.

I just reread the binding docs and I don’t see anything there that is contradictory.

It seems pretty clear to me actually.

It tells you how to discover the Chromecasts on your network or how to add one manually.

It tells you the three types of Thing the binding supports.

It tells you each of the Channels the the Things support and what they are for.

It even provides some text examples for how one could configure it manually instead of through the UI.

Maybe if you ask some more specific questions we can answer them. Or perhaps your understanding on how Things, Channels, Links and Items work together, which is a generic openHAB thing documented elsewhere and doesn’t belong in the readme for a specific add-on.

Maybe another go at an explanation might work.

  1. Install the binding
  2. Go to Things and press the + button
  3. Choose Chromecast and start a scan
  4. Accept all the Thing for the discovered Chromecasts.

That’s all the setup that is involved. And all of that is covered in the main OH docs and a full description does not belong in the add-ons readme.

Moving on:

  1. Create Items and link them to the Channels you care about. You are all about playing a video so you care about first five Channels in the list on the README.
  2. To play a video, sendCommand a URI to some media. But it has to be a URI to the actual media, not a web page showing some media. If you right click and choose “save link as” you need to get the raw video or audio file. Not an html file or php file or some other web page.
  3. To control the media currently playing use the control Channel to send STOP/PLAY/PAUSE type commands.

And I completely disagree with your assertion that the example is the wrong one. It may not be your primary reason to use the Chromecast add-on, but I can assure you it is the primary use case most of us have for using the Chromecast add-on. And the “play a video” use case is so simple as to be all but worthless as an example.

rule "Play a video"
when
    Item PlayVideo received command
then
    PlayURI.sendCommand("http://openhabian:8080/static/myvideo.mp4")
end

That’s assuming myvideo.mp4 was placed in /etc/openhab/html (i.e. $OH_CONF/html) and served up by openHAB itself.

As with any issue like this, filing an issue is a first step. But ultimately it won’t go very far unless and until you submit a PR to fix it too. Obviously those who wrote the add-on docs feel they are already adequate. I think they are adequate, though could definitely see a bit added about how the URI needs to point at the actual media, not a web page, and perhaps a list of supported media file formats too). So just saying “I don’t understand” isn’t going to go very far. If we knew how to do better we would have done so already.

2 Likes
10

Ok maybe I need to add more details, so sorry for that.

  • I’m using the DSL rules engine and manual files, so the GUI part is not for me.
  • The rule you are posting is what I would put into the main doc so thanks for that.
rule "Play a video"
when
    Item PlayVideo received command
then
    PlayURI.sendCommand("http://openhabian:8080/static/myvideo.mp4")
end
  1. To play a video, sendCommand a URI to some media. But it has to be a URI to the actual media, not a web page showing some media. If you right click and choose “save link as” you need to get the raw video or audio file. Not an html file or php file or some other web page.

Again thanks for that, since as you can see my knowledge is basic. Maybe this should be taken into account for the future of the project: do you want to become a niche programmers platform or do you want to open to enthusiasts and “normal” users?

And I completely disagree with your assertion that the example is the wrong one. It may not be your primary reason to use the Chromecast add-on, but I can assure you it is the primary use case most of us have for using the Chromecast add-on. And the “play a video” use case is so simple as to be all but worthless as an example.

Well, this would go into a subjective spiral but if someone wants to use a knife to unscrew instead of a screwdriver, it’s up to that person. A chromecast is primarily a video content/video mirroring streaming device that lets you send videos and audio to a TV. So it can do both things but the Binding can manage to make one work, and the “second” (which apparently is video) works only with local media. Its ok as far as you explain it somewhere.

And the “play a video” use case is so simple as to be all but worthless as an example.

Forget my question about being a niche or open community, it seems that you have chosen your path.

That’s assuming myvideo.mp4 was placed in /etc/openhab/html (i.e. $OH_CONF/html) and served up by openHAB itself.

I’m assuming that “served” by openhab itself means that the video must be in the same device acting as the OH server, right? If not… how do you make OH “serve” said video? Also, can I use Windows paths to tell it where the video is? sorry but me being a common user and this info not being available in the docs complicates things a bit.

As with any issue like this, filing an issue is a first step. But ultimately it won’t go very far unless and until you submit a PR to fix it too. Obviously those who wrote the add-on docs feel they are already adequate. I think they are adequate, though could definitely see a bit added about how the URI needs to point at the actual media, not a web page, and perhaps a list of supported media file formats too). So just saying “I don’t understand” isn’t going to go very far.

Thats going to be a little bit problematic at this side, you see… I don’t know how it works. Sorry but the dev of the binding or someone with experience like you seems more suitable for that task than me.

If we knew how to do better we would have done so already.

What can I say… I’m not blaming you for this, nor anyone. Just saying that there is opportunity to make things better, if you don’t like criticism well… just ignore this post and keep going.

11

There is absolutely nothing in that example that shows you anything about what the binding can be used for. If you don’t know when or how to send a command to an Item then you need to spend some more time with the Getting Started Tutorial, the Concepts section of the main docs and so on.

This example is really pointless. It doesn’t show you anything that is unique to the Chromecast binding. It doesn’t show you anything you shouldn’t already know how to do and is documented elsewhere. It doesn’t show you anything that isn’t already explained (though could be explained better) in the table of the Channels.

If there is going to be an example, it should show you something unique about the binding. If it doesn’t then there is no point to it.

No, it doesn’t only work with local media. It works with any URI, so long as the URI is pointing directly at a media file. It could be anywhere that is network accessible. But, I’ll say again, the URI has to be to the actual media, not a container web page like a YouTube URI points to (or Netflix, or Hulu, or the like).

Not must, but that use is supported. I showed a self contained example. Examples that do not have external dependencies are usually preferred. No where did I say that is the only way though. So I showed a case with the fewest amount of external dependencies which has openHAB serving up the media file itself. But anything that supports serving up media files by URI can be used, whether it’s locally hosted or an Internet web service.

No. As with any web server, openHAB can only serve up files in a specific folder. In this case, assuming OH is installed at c:\openhab it can only serve up files in c:\openhab\conf\html.

None of this is really specific to the binding. This is how web servers work. It’s really outside the scope of the Chromecast binding itself.

I’m sorry you find openHAB hard but the fact of the matter is home automation is hard. We can only do so much to make it better. We don’t have the man power to duplicate documentation that exists elsewhere. If you didn’t know to send a URI string as a command to the PlayURI Item, that’s not a failing of the Chromecast add-ons readme. That’s a failing of the docs over all, or your failure to read the docs. This is how all interactions with all bindings work in openHAB, which is why it’s in the general openHAB docs, not rewritten 350+ times in each and every binding doc. And that’s why the sendCommand example is worthless as an example. It doesn’t show anything that is unique to the Chromecast binding. It’s not informative. It only shows you something you should already know how to do from the main OH docs.

And in this case it’s even worse because it lead you to make conclusions (i.e. that the videos need to be locally hosted) that are not true.

12

I think your misunderstanding here, begins with Google’s poor semantic choices. You are correct A Chromecast is a device and that device plugs into a TV for (primarily) video streaming. Chromecast is a general streaming technology that is embedded in many devices, only some of which could be consider primarily video devices (e.g., my Google Home Minis don’t even have a screen for video but support chromecast streaming of audio. So, while YOUR device may be primarily about video streaming it is not reflective of the more general purpose of the chromecast technology and the binding should, and does, leverage all the technology has to offer. Rich’s points that the majority of chromecast binding users don’t emphasize the video abilities is not to say you are wrong for doing so but that your experience is actually more of an edge case.

Rich never said that video only works with local media, he just gave a local media example. In fact, above that he explicitly stated it will work with any media URI, which means local or remote. Being a beginner at these things is fine, we all started at that level. But if you don’t understand what a URI is, that is an easy thing for you to look up and gain some knowledge that will both help with your specific use case and push further up the OH experience ladder.

Frustration happens, we get it, but be careful here. There are few (no?) people on this forum who have put more of their blood, sweat, and tears into making this an open community welcoming to all user levels than Rich. An accusation such as this reflects far more upon the accuser and I don’t think any of us want that. Part of a community however is the expectation that everyone contributes. Those on this forum that help expect it to be a two-way street with effort coming from the other side to understand the help that’s being offered (see, for example, the section above about URIs).

13

  • OK I think I understand a little more now, Chromecast needs a URI which is a “published” video.

  • The fact that people wants to use one thing or another for different purposes is accepted and is fine. If I’m the only one trying to make video work, well I shouldn’t be considered a weirdo either. That is reflected on the absence of info in the docs too.
    As said, a knife can be used here to unscrew, but it was meant to cut things, it can do both. People here may use it to unscrew, that’s fine, but don’t tell me the knife was supposed to be used to unscrew instead of cutting, please.

I think your misunderstanding here, begins with Google’s poor semantic choices. You are correct A Chromecast is a device and that device plugs into a TV for (primarily) video streaming. Chromecast is a general streaming technology that is embedded in many devices, only some of which could be consider primarily video devices (e.g., my Google Home Minis don’t even have a screen for video but support chromecast streaming of audio. So, while YOUR device may be primarily about video streaming it is not reflective of the more general purpose of the chromecast technology and the binding should, and does, leverage all the technology has to offer. Rich’s points that the majority of chromecast binding users don’t emphasize the video abilities is not to say you are wrong for doing so but that your experience is actually more of an edge case.

So… where is my misunderstanding? is now google’s fault to advertise their product as they do? If people here wants to use it as an audio streaming device is all good and fine, but please don’t treat me like a dumb person if I want to use it for video and its not very well documented.

Frustration happens, we get it, but be careful here. There are few (no?) people on this forum who have put more of their blood, sweat, and tears into making this an open community welcoming to all user levels than Rich. An accusation such as this reflects far more upon the accuser and I don’t think any of us want that. Part of a community however is the expectation that everyone contributes. Those on this forum that help expect it to be a two-way street with effort coming from the other side to understand the help that’s being offered (see, for example, the section above about URIs).

I’m not frustrated, I know my limitations. I was asking for better info on the main docs so I can put the effort on my side and try to understand how things work. Without info and people telling me that “it’s my fault” well… I feel excluded, what can I say?.

14

Thanks for clarifying, I think I’m understanding a little more now.

15

That’s partially correct. I’d summarize it this way:

  1. The Chromecast binding can send audio or video files to a Chromecast device. The files need to be available on either the openHAB server in the html folder (so that they can be accessed from the built-in web server) or on the Internet in a publically-available way (meaning anyone can see them in a browser with no limitations).
  2. The Chromecast binding can not instruct a Chromecast device to start a specific app such as YouTube. Netflix, or iHeartRadio. That’s what I meant in my first message. That’s because openHAB isn’t actually interfacing with Google’s servers. In a way, it’s just treating your Chromecast as if it was at the other end of an HDMI cable.

I don’t think being an “edge case” means that you’re a “weirdo”. Let’s be careful about loading in negative language. I also don’t think anyone is trying to say you’re “at fault”. It’s just that you didn’t understand how the Chromecast binding works. That’s fine. Coming back to this conversation after a lot of back-and-forth, I do feel like you were suggesting things based on the misunderstanding. That’s where these discussions can sometimes get more difficult than they’re meant to be. In reality, everyone’s just trying to get on the same page.

Anyway, seems like there’s a shared understanding now, so let’s leave it there.

16

If that’s the feeling you are getting then that is not the intent.

I treat all criticisms seriously and do the best I can to address them the best way that I know how. Ultimately my goal is to get to something actionable. Something that we can actually change to make the situation better.

But nothing exists in isolation. There are knock on effects. We can’t just add a copy of basic openHAB documentation to each and every add-on’s docs. So anything that leads to “add more basic docs to the binding readme” is a no go. If we do it for the Chromecast add-on we have to do it for the remaining 350+ add-ons too. We simply can’t afford to do that and maintain that going forward. That’s why I’m so against this particular sendCommand example. It fits into the “generic here is how you do things in openHAB” category and not “here’s something you can do specifically with the Chromecast add-on” category.

So I’m trying to get to something we can do to improve the docs without unacceptable knock-on effects, or failing that to at least get you to the point where you can do what you are trying to do (if it’s possible).

I bet something with BasicAuth would work too using the https://username:password@url.path.com approach, though I’ve no way to test that.

17

That’s partially correct. I’d summarize it this way:

  1. The Chromecast binding can send audio or video files to a Chromecast device. The files need to be available on either the openHAB server in the html folder (so that they can be accessed from the built-in web server) or on the Internet in a publically-available way (meaning anyone can see them in a browser with no limitations).
  2. The Chromecast binding can not instruct a Chromecast device to start a specific app such as YouTube. Netflix, or iHeartRadio. That’s what I meant in my first message. That’s because openHAB isn’t actually interfacing with Google’s servers. In a way, it’s just treating your Chromecast as if it was at the other end of an HDMI cable.

ok… I will try to get a video URI and do some testing to see if I can make it work… worst case scenario would be to download the video I want and make it available locally. Rich’s rule as simple as it is, helped me to dissipate dubts I had.

18

If that’s the feeling you are getting then that is not the intent.

I treat all criticisms seriously and do the best I can to address them the best way that I know how. Ultimately my goal is to get to something actionable. Something that we can actually change to make the situation better.

But nothing exists in isolation. There are knock on effects. We can’t just add a copy of basic openHAB documentation to each and every add-on’s docs. So anything that leads to “add more basic docs to the binding readme” is a no go. If we do it for the Chromecast add-on we have to do it for the remaining 350+ add-ons too. We simply can’t afford to do that and maintain that going forward. That’s why I’m so against this particular sendCommand example. It fits into the “generic here is how you do things in openHAB” category and not “here’s something you can do specifically with the Chromecast add-on” category.

So I’m trying to get to something we can do to improve the docs without unacceptable knock-on effects, or failing that to at least get you to the point where you can do what you are trying to do (if it’s possible).

Ok I understand Rich. Maybe shortcuts can be added? I don’t know… most KB do that… for example:

“We have to make a rule to make this happen… (…)”
Link → How to make a rule

It really gets confusing sometimes, I learned most of what I know without bothering anyone, but sometimes I just cannot find the info or I get lost in the process.

There’s too much info to be processed for a normal user to get something working, I know, nobody is pointing me with a gun to use OH, but if I do is because I consider it the best alternative. I understand that you can feel bored of the same questions with your knowledge being superior but you must also understand that us (normal basic users) don’t have all that knowledge and sometimes make “obvious” questions (most of the time actually).

Saddly that´s the way it is, if invent a car but I push the users to understand mechanics, electricity, physics, hydraulics and electronics as a requisite… well… driving a car would be something for a few.

19

Well, we don’t have to make a rule to make this happen. You can set up the UI with a stock set of URIs and a selector. You can send a URI as a command to the REST API.

All you have to do is issue a command to the Item. There are lots of ways to do that and I’ve only listed three of them. Do we need to add that to all 350+ add-on readmes? And what about creating Links to the Items? And so on and so on?

The rule of thumb is all generic OH stuff goes in the docs. The add-on’s readme is specific to the add-on, and the readme does not repeat stuff that is in the main docs. Is that less convenient for some users? Yes. But it’s all that the few contributors to the docs can manage. And even adding links adds a huge maintenance work load all by themselves.

There is no other way to do it. This has been the one complaint since OH began over a decade ago. And thousands of man hours have been spent trying to make it easier to manage and to require less of the end users. But we are still dealing with over 350 unique and different technologies each of which have their own capabilities, quirks, limitations, problems, and sets of knowledge that need to be known and understood by the end users to use them successfully.

Home automation is hard. It requires learning a whole lot of stuff to get it right. It doesn’t matter what home automation software you use. The only way to make it easier is to limit what the system can do. That’s what most commercial offerings do. They are easier to use because they can’t do as much.

The way that openHAB tried to make the problem easier to handle is by providing layers of abstraction so that there is a base set of knowledge you can bring to bear no matter what the technology does. For example, to cause a device to do something in OH you must send a command to an Item. It doesn’t matter if that Item is linked to a Chomecast or a Zwave light switch. The concept is the same, sendCommand to cause something to happen. There are even a limited number of Item types to worry about.

These are the openHAB basics. These are the things the add-on readme, out of necessity, must assume you already know and understand how to do. And, if you look at your original post, they are things you already knew to do. So don’t cut yourself short. You already have a pretty good understanding of how to work with OH.

The root cause of your specific problem was misunderstanding what that URI sent as a command to PlayURI needed to point to. And I agree that it could be made more clear in the Chromecast docs what that URI needs to point to and I’d like to see a list of which types are supportable (AVI? RSTP from an IP camera? Ogg Vorbis?). That could probably be handled with a link to the Google Docs for the Chromecast API. But everything else was stuff you already knew. If you had used a compatible URL this thread would have never happened.

20

“We have to make a rule to make this happen… (…)”
Link → How to make a rule

Well, we don’t have to make a rule to make this happen. You can set up the UI with a stock set of URIs and a selector. You can send a URI as a command to the REST API.

I wasn’t talking about this topic, but the documentation page. It was an example that I came with to “offer” an idea to make the documentation more friendly (?)… I don’t know… I understand that things are complicated, I worked with pc users for about 13 years and I know how difficult it becomes sometimes.

About the rest… ok I´m not the one who has the rights to change anything, and I understand that as said no one is getting money out of this. If the docs can have more info, good… if they can’t well… there will be more like me here in the forums asking obvious stuff, but I suppose that you know that already and you are used to it.

I´ll do some testing with the info you all gave here and see if I can make it work, and if not, well… I will wait.

thanks