I misinterpreted your post – the Fire TV component used to work by sending REST commands to firetv-server, which is an http server that allows you to interact with a Python 2 environment running the firetv package. I thought that’s what you were referring to.
Once it works, I think the Hass.io ADB server addon will fix the connection issues that people encounter.
This is a great idea. @JeffLIrion i have been toying around with some ideas. Nothing put together yet. I have very little experience with Docker and hassio addons as well. @Picnic i want to add a feature like this to drop the adb connection from HA so it can be used else where. Also for current app state i use the aptoide api to return the friendly app names and icon png based off of package name. My though is the state to show the app instead of generic playing when in app… just thoughts i have come up with and trying to get time to make some process on it…
@Picnic and @chodyjones, the ability to disconnect and reconnect is an interesting idea, but I’m not sure how best to implement that. You’re welcome to submit a PR to either HA or my custom component!
@chodyjones, I don’t think HA would approve of using the app name as the status. But I believe the Android TV component (not yet merged) uses the app_id and app_name properties to do what you want.
I’ve tried using this component for my Toshiba Fire TV, and I’ve seen partial success using the adb-server method, as well as without using it, but both are unsatisfactory.
When not using the server, I get the general problems where it becomes unavailable for a large percentage of the time after initially working after startup for a few minutes.
When using an adb-server, the issue is that a lot of things don’t match up.
It pretty much sees the ‘playing’ state exclusively as the ‘paused’ state. I dug through the code and did some testing and found that there are always at least 1 or 2 wake-locks.
This is especially bizarre because this would seem to imply that it should always be in the “playing” state.
I’ve found that it enters the ‘playing’ state if I browse the hulu menu, but that’s it. Haven’t had a chance to manually query the wake-locks in that instance though.
The turn-on command also has no effect, though pressing the home-key with my own remote IS a valid way of turning on the TV.
I’m willing to write a PR but I’m looking for insight into how the “wake lock” system works.
Is there an alternative way to detect the playing state that is less fragile?
Could I save some nominal wake-lock count, and consider additional wake-locks above that the ‘playing’ state?
The latest version of the custom component will use the home key to turn on the Fire TV. However, you might need to delete the existing firetv folder(s) in the deps folder of your configuration directory so that the latest version of the package gets installed.
First off, are you using the ADB server addon? I haven’t yet received feedback that it works with the Fire TV component.
Using the latest version of the custom component, you can send ADB commands to your device and the results are logged at the INFO level. To be honest, I don’t really know how best to determine the current state. You could look at the androidtv.py component for some other commands to try out. Here is an example of how to send such a command.
I probably should have written up my previous investigation on this already, but this is indeed the proper way to handle the states (I was thinking about having a simple app to track the states and do push updates to homeassistant). The problem at that point was (it may have been a year since I looked at it last time) that many of the apps do not use the media session (my experiences on Kindle FireTV stick) for controlling even when the API has been there since Android 4.0.
Thanks for the info! I recall reading something similar, perhaps for the Android TV component: there is an API for determining playback state, but many apps don’t adhere to it.
I believe the Android TV component tries to accomplish this task of state detection by using info about the audio output. If you’re interested, you could look at the component that I’ve previously linked to or the thread in this forum.
My opinion is that it’s not reasonable to expect the component to always detect the correct state. (But if someone wants to try to achieve that, their efforts are certainly welcome!) I also don’t think that differentiating between playing, paused, and idle states is a big deal, at least not for my use cases. The component can detect whether it’s on/off, send basic commands (most importantly power on/off and play/pause), and launch apps. That’s good enough for me
Basic support is fine, I’m not arguing on that, however, having the ability to, e.g., control the lights based on the play state is somewhat popular application I just wanted to leave the note behind in case someone is digging already on the topic or wants to improve it, unfortunately I have personally no time to further it at this point.
I just posted this in two other threads, but here it is again.
Regarding the Fire TV component, this is already implemented in my custom component. I’m working on getting it integrated into the official component.
Configuration example:
media_player:
- platform: firetv
name: Fire TV
host: 192.168.0.111
adb_server_ip: 127.0.0.1
Comparing the Fire TV and Android TV components, I haven’t tried the Android TV component, but there are some device-specific tweaks and so I expect that each component will work better for its intended devices.