Creating a Google Home / Chromecast Device Type and responses are getting lost

General Discussion
, , ,
1

So, I’ve already built what I needed but the problem is that when sending direct TCP packets to the devices, those packets get lost because, from what I gathered, ST doesn’t know how to parse it.

First, I need to be able to send data to TLS connection and parse the protobuf data that’s returned.

I’m assuming exposing the raw packets over the API is “scary” for the devs, but I think we can work out a compromise of sorts. TLS is basically HTTPS, but there’s no way to send raw TCP data to a HTTPS connection, only HTTP (unencrypted). We need the ability to send a packet using sendHubAction to an HTTPS server. Adding this feature would also allow FTPS support, since it works identically.

Second, it appears ST already has protobuf support as seen here: https://github.com/SmartThingsOSS/ratpack-protobuf

The messages that are sent to and from the Google Cast devices are basic text strings, but encoded in protobuf. So the second option would be something like a parseProtobuf() as part of a parsed LAN message and return a string.

If these two things can be available to developers in some way in the api (create TLS connection and tell ST to parse protobuf strings) then I can finish up my Device Type and not have to rely on any external hardware to trigger Google Cast devices. I actually don’t need the protoBuf parsing to do one way communication, but it would be nice to have some sort of two-way interaction (to get device status)

Thanks!

2

Can you manually set a hostname for the request? If so, a single Apache server may handle distribution of the packets to multiple clients if not, a single Apache server may be required per-chromecast.

Listen 80
<VirtualHost *:80>
 ServerName chromecast1
 ProxyPass https://my.chromecast.ip
 ProxyPassReverse https://my.chromecast.ip
</VirtualHost>