This is a pretty full featured Google Cast integration for Smartthings. Due to the limitations of ST it requires a permanent API application on your network, that bridges between ST and your Cast devices.
To get started, visit the project website:
Any device that runs node.js and has a fixed IP on your local network
Chromecast, ST Hub
Adds any Cast device as a music player
Full playback information and control
Visit the website for more
You still need the API
You can only cast DRM free content using the presets (due to the Cast protocols design, that will never change)
The API host (proxy) still needs a static IP address, will change soon
No, probably not. Only the Google Play Music or Pandora App can do that.
DRM free means that you just have a plain mp3 file/stream. Unless you can somehow get the mp3 or whatever URL from Google Play or Pandora, you cannot cast it. I’m not using these services, but I think they require sign in. Good rule of thumb is: if you cannot download it to a folder on your PC, you cannot cast it.
Interesting. I can cast Pandora from a Google Home to a Chromecast Audio device and/or group by voice command (i.e. Hey Google, play Classic Rock using Pandora on Living Room Chromecast), but I had to authorize the Home app to access my Pandora account in order to do this.
Yeah I know. Since Google owns the protocol, I guess they have a deal with the content providers to access there receiver apps.
Casting roughly works like that you have the sender (your mobile app) and the receiver (webapp executed on the Cast device). Since the receivers are web apps, they use the same kind of DRM they use on their web app for your browser. If you have the ID of the receiver app you can probably get it to launch on your chromecast (Pandora - Ready to cast screen). However everything after this point is up to Pandora, Spotify, Google. They’ll have some kind of login mechanism in place and one to authorize/start/control playback.
So even if you managed to reverse engineer one of these receiver’s it could break at any moment. And maybe it’s even illegal. And no, I’m not an expert on that topic, just what I’ve learned over the past couple of months. Really sorry to disappoint it just isn’t possible with the way the protocol is designed.
This is awesome @vervallsweg, I look forward to setting this up and playing with this at home.
From what I know of how Chromecast works, I definitely believe you that directly talking to the Chromecast from ST would not be possible today. Can you enumerate what things you believe would be minimally required to make this possible. For instance, I recently have worked on some improvements to mDNS/DNS-SD discovery in the hub that might be required to find the devices on the network (this is still in development and cloud work would also be required to make it useful). What are the other major items that would be required to make this application work without the Node.js proxy?
I didn’t even know ST supported mDNS, I thought only SSDP worked for now. If there really was mDNS support, device discovery could be handled directly from the hub, there’s not much magic to it. This would also remove the enormous dependencies for mdns in node.js. Chromecast used to respond to SSDP in Cast V1, but that is either not supported at all anymore or will be removed in the future.
The minimal requirements would be the ability to send TCP/UDP packages to a port directly (without the HTTP overhang) and protobuff support. According to the forum the first thing isn’t possible so I didn’t even bother trying to get protobuff to work. Someone who seems to have given up on his DTH already pointed out there might be undocumented protobuff support in ST, but I didn’t check.
I’ll look into adding device discovery from the hub directly in the next couple of days. Running everything of the hub would be great, but I can understand that direct connections to/from the hub may not be a great thing for security.
No, you are right about this. There is mDNS referenced in corners of the documentation but the existing implementation in the released cloud and hub code isn’t working. The work I referenced was done recently and is still quite a ways from being released (it would be release 19.x or 20.x as 18.x is already in testing now).
The hub actually only knows how to do fairly raw TCP/UDP connections, but it appears that there are limitations enforced in the cloud currently. As we revisit parts of LAN and give it some much-needed TLC, I will do what I can to push for allowing use cases beyond HTTP.
For Protocol Buffers, I doubt there will be any first-class support in the platform for it, but it should be possible to communicate with a device supporting protocol buffers so long as we provide a more raw socket at some layer. I’ve worked with various IDLs (including protocol buffers) and it is sometimes the generated code separates the packing/parsing of messages from the transmission internally which might provide some opportunity for reuse. No idea if this is the case for protocol buffers.
Sorry, can you clarify what does/doesn’t work in terms of getting the CC Speak to work? For instance, how would I make the CC say that “Motion is Detected”? I’m not familiar with the (defunct) Sonos apps, do you need a Sonos for that to work?
For years Sonos used to have custom apps for there speakers. ST at some point decided to make the methods, etc. Sonos was using the standard for music players. That’s why the Sonos apps worked with most other speakers. For voice notifications on speakers there used to be the Sonos ‘notify by sound’ app. A couple of months ago ST just pulled it from the marketplace and ‘replaced’ it with there own ‘Speaker companion’ app. I implemented the methods they require for voice notifications according to there documentation, but there new ‘replacment’ app just doesn’t recognize my DTH.
I did some testing and changed I believe the name and other stuff to Sonos and then I could select the speaker. However it just didn’t work. Since they don’t release there code I have no clue what to implement in order to work with their speaker companion.
If you’d like to install the old Sonos smartapps, they are still available on GitHub and as a template from the ST IDE. They let you create voice notifications on Cast devices, set the volume, etc.
So no need to buy Sonos speakers, just copy and paste the old source code into the IDE and you can install these apps again and voice notifications will work.
Just to clarify you can still cast from your phone or whatever to the Chromecasts. The DTH will then display ‘Plex’, the name, title and whatever is available from plex in the device page. See the screenshots of ‘Kitchen’ for that in the first post. You’ll be able to pause/play, set volume/mute, stop casting just like you’d with the Google Home app.
Casting only non DRM stuff just applies to the presets.
You own the content on your Plex server and they have a web interface that lets you stream from the browser. That means you should be able to somehow get a link to your movie or what you would like to set as a preset. As long as you have a media url like: http://myplexserver.lan/movies/greatestmovieever.mp4 that would play as a preset.
So it should be possible to set plex stuff as a preset, just probably takes some time to get a direct url to the content on your plex server.
Yep, seems like it’s the one.
I used the code from the STCommunity repo. If you go up two directories you’ll also see the other sonos smartapps and the bose soundtouch smartapp. The Bose one let’s you control the presets and play at a certain volume, every feature it offers works on the DTH.
So if I have a Chromecast audio device connected to my whole house speaker setup will I be able to use this Device handler in conjunction with the old Sonos notify smartapp to have the chromecast audio provide voice notifications? Just trying to make sure that I fully understand how this is going to work before setting it up.