I wonder if someone is working (if it’s possible) on supporting the remote that comes with Chromecast with Google TV? I don’t know if it’s possible to know about events from the remote as it communicates directly with the Chromecast dongle through Bluetooth (plus some IR commands if one chooses to).
I am mostly interested in knowing if I can detect power events, as I can’t get CEC to do what I want through my Denon 3312 to allow the remote power button to turn my projector on and off through CEC and switch to the Chromecast input (Denon and Epson’s docs about CEC are abysmal). But I could definitely script that if I could get some events and state from the remote and Chromecast.
I’d watch github for someone to post a Python proof of concept to sniff the BT messages from the remote and reverse engineer the protocol. Once you have that you can write a script that uses that to push the events to openHAB where openHAB can act upon them.
My understanding is that the BT binding in openHAB only supports presence detection.
If you want to tackle something like this yourself, you might be able to use the bleson library. You can see an example of a script I wrote (based on another script) to sniff the BT temp and humidity readings from Govee 5072 sensors. All the BTLE messages received get processed so you could print them all out and look for the ones from the Chromecast remote (assuming it uses BTLE which makes sense that it would).
Another idea would be to read these (or other) events from Android (like with Tasker) and send the status to openHAB via REST.
I don’t know if Tasker works on Android TV and which events you can trigger on.
But I also read there is an App that can change the behavior of the remote buttons.That might help as well.
Support for the Chromecast remote might be a question for @cweitkamp (and a good question at that), but I wonder if it’s even necessary.
Whenever the Chromecast is active, the Idling channel is OFF. I use this to trigger rules that tell my Harmony Hubs to turn on/off the devices attached to the respective Chromecasts.
@Frenchman, when you’re in the menu system for the new Chromecast are there any updates to the Idling, appName, or appID channels? On older Chromecasts, Idling goes to ON whenever there’s no active stream, but I’m not sure what’ll happen now that it has a user interface.
I am very much interested in a solution for controlling my Android/Google TV (Shield TVs) with an OpenHab Binding over network (not Bluetooth!).
As far as I understand, devices are discoverable over service broadcast, then a handshake is needed and they are controllable.
As an example one might take a look Android app “Shield Remote” or Google TV remote. Both are working with my Shield TVs.
I actually don’t know how to reverse engineer or implement the protocols.
google-tv-pairing-protocol.jar
NSD (Network Service Discovery).
Maybe someone can create something useful with this.
I am afraid I cannot help very much. I neither own a Google TV nor a remote for it. Additionally it will be hard to add much more new features to the Chromcast binding because it depends on an external library which uses v2 of Googles Cast API. AFAIK this API version has been replaced by a new version some time ago. Thus we in general have to think about a redesign of the whole binding to support the new Cast API.
So I played a bit with it and anything done through the remote isn’t visible through the Chromecast. This probably is because the apps by default are Google TV (Android TV) Android apps. So if you start Netflix and watch something, you don’t see the media title changing etc. Of course if you cast from your phone, then the Cast apps (which are just Web apps) run and changes can be observed through the Chromecast items.
If you want to tackle something like this yourself, you might be able to use the bleson library. You can see an example of a script I wrote (based on another script) to sniff the BT temp and humidity readings from Govee 5072 sensors. All the BTLE messages received get processed so you could print them all out and look for the ones from the Chromecast remote (assuming it uses BTLE which makes sense that it would).
How did you wire this all? I see that thread. Did you sniff BT events (is BT that insecure?) and then posted on an MQTT queue for openHAB to consume? I am new at all of this… but I can learn . Especially with examples. Would MQTT be necessary, and simpler than, say, triggering something over the REST API? (At least as a first step.)
Darn, that’s too bad. I was hoping that Idling would change when you’re using the Google TV interface, but it makes sense that the Google TV interface isn’t invoking any cast functions.
I was planning to pick one of these up to replace my 1st-gen CC, but I might save a few bucks and just get the 3rd-gen instead.
I was planning to pick one of these up to replace my 1st-gen CC, but I might save a few bucks and just get the 3rd-gen instead.
The Google TV UI is great. And you can still Cast from your phone etc. Rumor has it that it’s going to be $39 for the holidays. At that price I’d get that one. It’s also more future proof in that it supports 4K and HDR (but not Stadia yet), for less than the Ultra.
Plus once you have it, you may be motivated to figure out how to detect button presses .
I just double checked Idling and it’s not used apparently. I turned the Chromecast off: nothing. Turned back on: nothing. Turned the screen saver/ambient mode on: nothing. Of course that channel comes from the binding, which as one you said uses a third party library, so who knows if anything could be detected using a newer library?
Many years ago (2016 I think) I needed a way to send commands to a relay attached to a RPi in my garage to open the garage doors. I also had reed sensors that report the open/closed state of the garage doors. So I wrote a Python script I call sensor_reporter that runs on the RPi and reports the sensor states and triggers the relay when it receives messages. Over the years I and others have continued to improve and add to it so it now supports all sorts of BT stuff, DHT sensors, executing command line commands, Amazon Dash buttons, etc. Some of this is duplicative of what is already built into OH but I wrote them before OH had those capabilities, or there are other reasons why I don’t want to do it on the OH server itself.
For the Govee BT stuff, I found an example on GitHub that was actually written for Home Assistant that parsed out the readings from the BT messages. So I took that as an example and adapted it work as a sensor in sensor_reporter.
Basically yes. Unless the device goes through some effort to encrypt the messages BTLE broadcasts can be sniffed by anyone. I can’t claim credit for figuring that stuff out though, as I said, I had an example to work from. The “posted on an MQTT [topic]” part is already built into sensor_reporter. That is based on code I originally wrote five years ago (recently refactored).
MQTT has some advantages that make me choose it over other options most of the time. In particular the LWT and careful use of retained messages and the fact that it’s a standard not tied to any specific home automation system makes it very powerful. But sensor_reporter has another openHAB communicator that uses the openHAB REST API and SSE feed to send/receive Item states. However, because of the dynamic nature of the Govee add-on, I don’t have a good way to use that communicator with it so for now MQTT is the only choice for that specific sensor.
I wrote sensor_reporter to be modular so I only have to figure out how to do things once. So it has a core that is reused by everything. Communicators are independent so with the one exception it doesn’t matter what sensor_reporter uses to send and receive messages. Thus, to add a new capability to it just requires figuring out that new capability and all the rest (loading the configuration file, figuring out how to send and receive messages, running as a service, handling signals from the OS, thread management, etc.) is already done for you.
There are other programs on github that do this too, but mine was first.
The openHAB Android app has integration with Tasker so no need to mess with MQTT or the REST API directly. But if you didn’t/couldn’t install the openHAB app, you can also use the REST APi directly. See Triggering Items Using openHAB 2's REST API from Tasker for one of several tutorials.
With the AutoInput plugin to Tasker it’s possible to scrape the currently running app’s UI and extract information. For awhile I had a profile that would scrape my estimated arrival time and send an SMS to my wife when I started my commute home. Assuming these can all run and interact with the apps required it might work.
Plus once you have it, you may be motivated to figure out how to detect button presses .
I’m currently in a “nothing’s broken, don’t fix it” mood with openHAB, and thus haven’t started playing around with OH3. A new chromecast would be nice to have, but they go on sale so regularly that I’m in no rush and not worried about future-proofing. I might care more if I ever upgrade my 2013 TV.
I just double checked Idling and it’s not used apparently. I turned the Chromecast off: nothing. Turned back on: nothing. Turned the screen saver/ambient mode on: nothing. Of course that channel comes from the binding, which as one you said uses a third party library, so who knows if anything could be detected using a newer library?
Idling turns on when a chromecast isn’t being used, so I wonder what would happen if you left it alone for awhile in ambient mode. Saying that, I think you’re probably right that it’s no longer in use with the new Google TV interface and the newer API that we’re not using.
I could try to side load Tasker on the Chromecast, yes… It may even have a chance to detect powering off before being killed and fire off a quick message
@christoph_wempe’s suggestion of Button Mapper could work for your purposes, in concert with the Tasker and openHAB apps sideloaded onto your Chromecast. You could set up Tasker to send commands to OH, and then use Button Mapper to trigger the Tasker routine from the remote.
. Especially with examples. Would MQTT be necessary, and simpler than, say, triggering something over the REST API? (At least as a first step.)