Android TV 12 devices not working properly

[Dillton]

Hello.

After my Chromecast with Google TV received an update from Android 10 to Android 12 the state of the device is always only "off".
ADB commands seems to be working at least for me however the key states like idle, playing, paused, etc. does not. Automations depends on those.

This is common issue for Android 12 devices, other users already reported this in different threads for example:
home-assistant/core#80555
home-assistant/core#79154

@ollo69 recommends the issue should be opened here instead of HA/core as this problem is inside AndroidTV library.

@JeffLIrion Could you please check this issue?
If you need logs or something let me know I can collect and provide them once I am home.

[snp88]

Hi @Dillton

In readme of this repo owner said that he have no time to work on this project.
I would not expect any fix soon.
Someone from community need to check this.
I think if HA officially use this repo should be take care by HA ;) but this is only my dream for perfect world

[ollo69]

In readme of this repo owner said that he have no time to work on this project.

@JeffLIrion clear explain that he will not have time to work on fix, but PR are welcome. Anyone with some programming competence and a valid device for test can create PR on this repo, and I think that @JeffLIrion will found the time to review them. HA architecture is base on the fact that communication with devices are based on external and open source python library. This can be strength and weakness at the same time of this architecture, but that's it. I think that HA team will never work on external library, but this doesn't means that fix will not be implemented, this is just based on goodwill of the community.

[breakthestatic]

I think I might have found a fix for this already, but haven't had time to fully test & open a PR yet. It seems that the CMD_SCREEN_ON checks aren't sufficient for Android 12 on the Chromecast with Google TV. Adding a check for mScreenState=ON in the display output of dumpsys looks to correctly report the screen state, e.g.

CMD_SCREEN_ON = (
    "(dumpsys power | grep 'Display Power' | grep -q 'state=ON' || dumpsys power | grep -q 'mScreenOn=true' || dumpsys display | grep -q 'mScreenState=ON')"
)

From there, since the screen is on, the rest of the logic seems to work so far. But once again, I haven't tested everything yet, and also haven't regression tested other devices (e.g. my Nvidia Shield).

I recall reading up a bit on a major architectural shift for this project during the last major Android version bump, but am not sure specifically what changed to make it easier to add more device-specific commands (perhaps something to do with custom commands???)

In the long-run, it would seem better to have device profiles (something like ZWaveJS does I think) instead of a lot of if android version == TARGET_VERSION then command x, else command y". E.g. have a base profile with the most common/standard adb commands that each device profile entry would inherit from and override any specific commands necessary for that device/version combo. I'm not a Python dev though, so an undertaking like that might be a bit more for me to attempt.

[snp88]

I can help test this ;) I have valid device ;)

[breakthestatic]

I can help test this ;) I have valid device ;)

What type of install do you have? I'm running docker, so I had to shell into the container and manually make the edit to /usr/local/lib/python3.10/site-packages/androidtv/constants.py and restart the container afterwards. I'm not sure how different that would be for a supervised install (which I think also runs in a docker container?)

In any event, if you can get to that file in your install and change

python-androidtv/androidtv/constants.py

Lines 179 to 182 in b1425b1

	#: Determine if the device is on
	CMD_SCREEN_ON = (
	"(dumpsys power | grep 'Display Power' | grep -q 'state=ON' || dumpsys power | grep -q 'mScreenOn=true')"
	)

to the code snippet in my prior comment (here it is again):

CMD_SCREEN_ON = (
    "(dumpsys power | grep 'Display Power' | grep -q 'state=ON' || dumpsys power | grep -q 'mScreenOn=true' || dumpsys display | grep -q 'mScreenState=ON')"
)

That should be the extent of the fix. At that point, once the state is being correctly derived, it will be much easier to test other parts of the AndroidTV integration to see if further Android 12 changes are needed in addition to the device state.

[ollo69]

What type of install do you have? I'm running docker, so I had to shell into the container and manually make the edit to /usr/local/lib/python3.10/site-packages/androidtv/constants.py and restart the container afterwards

@breakthestatic, I suggest you to setup a HA dev environment as explained here. It's quite simple (it works with windows, linux or mac), will simplify your tests and will avoid to hack your default HA installation.

[breakthestatic]

What type of install do you have? I'm running docker, so I had to shell into the container and manually make the edit to /usr/local/lib/python3.10/site-packages/androidtv/constants.py and restart the container afterwards

@breakthestatic, I suggest you to setup a HA dev environment as explained here. It's quite simple (it works with windows, linux or mac), will simplify your tests and will avoid to hack your default HA installation.

I already have that set up but am not sure how to make the needed change since it's in this library, not HA core. To test the fix, I was already using the dev env, but still manually changing the python-androidtv file in site-packages.

[Dillton]

I can help test this ;) I have valid device ;)

What type of install do you have? I'm running docker, so I had to shell into the container and manually make the edit to /usr/local/lib/python3.10/site-packages/androidtv/constants.py and restart the container afterwards. I'm not sure how different that would be for a supervised install (which I think also runs in a docker container?)

In any event, if you can get to that file in your install and change

python-androidtv/androidtv/constants.py

Lines 179 to 182 in b1425b1

	#: Determine if the device is on
	CMD_SCREEN_ON = (
	"(dumpsys power | grep 'Display Power' | grep -q 'state=ON' || dumpsys power | grep -q 'mScreenOn=true')"
	)

to the code snippet in my prior comment (here it is again):

CMD_SCREEN_ON = (
    "(dumpsys power | grep 'Display Power' | grep -q 'state=ON' || dumpsys power | grep -q 'mScreenOn=true' || dumpsys display | grep -q 'mScreenState=ON')"
)

That should be the extent of the fix. At that point, once the state is being correctly derived, it will be much easier to test other parts of the AndroidTV integration to see if further Android 12 changes are needed in addition to the device state.

Evening. I can also help with testing with my Chromecast and so far I can say this seems to be the trick, thank you.
Modifyed my container and did some real life usage:

I will keep it modifyed like that and see.
@breakthestatic Do you need some specific testing?

[ihrapsa]

I can confirm that this fixes the issue for me too (CCwGTV Android TV 12). Thanks!

[snp88]

Hi All

i looking this path on my instance
/usr/local/lib/python3.10/site-packages/androidtv/constants.py

But i cannot find it

first of all i don't have python 3.10 folder i have only 3.9
also don't have folder site-packages
i have only dist-packages

My installation is on virtual machine and up to date

[ihrapsa]

Hi All

i looking this path on my instance /usr/local/lib/python3.10/site-packages/androidtv/constants.py

But i cannot find it

first of all i don't have python 3.10 folder i have only 3.9 also don't have folder site-packages i have only dist-packages

My installation is on virtual machine and up to date

If it's Hass os in a VM you need to access home assistant core docker container shell.
docker exec -it $(docker ps -f name=homeassistant -q) bash

[Dillton]

@breakthestatic Found an additional problem so there might be needed additional modification of the code.
The device goes off for 10 seconds sometimes as you can see on screen below:

[breakthestatic]

@breakthestatic Found an additional problem so there might be needed additional modification of the code. The device goes off for 10 seconds sometimes as you can see on screen below:

Not saying you are definitely wrong about needing some additional fixes, but I recall seeing behavior like this with the Nvidia Shield recently as well. I believe the integration polls the device every 10 seconds, so perhaps there is some logic that defaults the playing state to off if an individual poll result fails?

So far I haven't seen this myself on the Chromecast, but I have also not done much testing. I'll see if I can reproduce it if/when I have some spare time over the next few days. Also, if you are somewhat familiar w/ ADB as well, you could manually set up an ADB session on another computer and see if mScreenState actually changes its value during the time periods that HA is reporting it to be off.

[breakthestatic]

Just a quick follow-up regarding the intermittent off state... I ran through several states over the past ~ 45minutes (idle to standby, then playing through a full episode in Plex, back to idle after the episode ended & back to playing once the next episode started):

Once again, I'm not really familiar with the actual functionality of this library beyond the basic ADB commands used to determine state, but it seems like the off state is only set in a single place:

python-androidtv/androidtv/androidtv/base_androidtv.py

Lines 112 to 114 in b1425b1

	# Check if device is off
	elif not screen_on or current_app == "off":
	state = constants.STATE_OFF

Looking at this piece of code, it seems that only two things can trigger it, either an incorrect screen_on value or when the current_app is set to off. I'm still not 100% sure if a failed poll could return what is eventually interpreted as an incorrect screen_on state. I tried faking it by pulling my ethernet cable for ~20 seconds, but HA correctly interpreted that as "unavailable" in that case (not off as is seen in your screenshot), so it seems unlikely that a dropped poll can cause it. That leaves either a truly incorrect reading of screen state (i.e if, for some reason your mScreenState isn't ON for that particular poll response), or an invalid current_app.

There's a bit more logic surrounding the state of current_app that I wasn't able to fully step through, but it seems like you could get a bad state via the custom state detection logic. Do you know what app was running when you saw this (and do you possibly have any custom state detection rules configured)? Without being able to reproduce this myself, & not having deep-enough knowledge of this library (or language for that matter 😆), I'm not sure how much further I could get with this.

[ihrapsa]

I was about to report this intermittent off state as well. For context I was watching HotD on hbomax 😅 and got some automations triggered based on the off state a couple of times. I'll try to reproduce it again although it seemed to be rather random.

[Dillton]

@breakthestatic Really does not matter which application I think. I was watching youtube and netflix yesterday and with both the same behaviour. Sometimes also state changed to standby even when it should be playing.

[breakthestatic]

Not really sure what's going on there :( My two Chromecasts have been very consistent with their state reporting since putting in the fix.

In Twitch, I noticed that whenever the stream goes from actively playing to buffering (doesn't happen often, but still), the state switches from playing to idle, so perhaps some of the logic I noted in my prior comment (the stuff concerning the app-specific state & fallback detection rules) is the cause. I believe at the bottom of base_androidtv.py, there's a single extra location where state is not explicitly set to pre-determined values (besides a couple app-specific rules for Bell Fibe & VRV, whatever those are):

python-androidtv/androidtv/androidtv/base_androidtv.py

Lines 208 to 210 in b1425b1

	# Get the state from `audio_state`
	elif audio_state != constants.STATE_IDLE:
	state = audio_state

It seems that condition is rather open-ended, in that as long as none of the app-specific rules above it trigger, and there is no media_session_state, it will try to get the overall state from the current audio state (as long as it isn't idle). If audio_state is off, that could also seemingly lead to what you guys are seeing.

Maybe you could try adding extra logging at the bottom to see what all the various state variables look like at the time the problem occurs (i.e. put it right before line 228 in base_androidtv.py):

_LOGGER.debug("screen_on: %s", screen_on)
_LOGGER.debug("current_app: %s", current_app)
_LOGGER.debug("media_session_state: %s", media_session_state)
_LOGGER.debug("audio_state: %s", audio_state)

[pejotigrek]

a side-question @breakthestatic : did you reinstall/re-add your CCwGTV in HomeAssistant? I can see that the firmware shows "12" - mine CCwGTV upgraded itself over the night [probably - yesterday it was Android 10, today it's 12, and I didn't do anything ;)] but it still shows "10" in the firmware info in HA. of course all my automations stopped working [and I was using different ones according to which app is running with what state], but I'm too afraid to fiddle "with system" or try your hot fixes. I'll just wait patiently :)

also I've noticed that service androidtv.adb_command with command GET_PROPERTIES - doesn't give any new response, it just shows something old, not changed according to current state. it probably won't help you, but I didn't wanted to come here only with questions :)

[breakthestatic]

Hey @pejotigrek, I didn't reinstall my Chromecast, but I have both reloaded the integration, as well as completely restarted HA. I'm not sure which (or both) of those might have updated the firmware version, but I would definitely be sure that you are seeing the updated version before doing further debugging. When my Chromecast was updated to 12 (already said fw12 in HA), doing the GET_PROPERTIES call correctly populated the adb_response (just with the incorrect screen_on state).

[pejotigrek]

Hey @pejotigrek, I didn't reinstall my Chromecast, but I have both reloaded the integration, as well as completely restarted HA. I'm not sure which (or both) of those might have updated the firmware version, but I would definitely be sure that you are seeing the updated version before doing further debugging. When my Chromecast was updated to 12 (already said fw12 in HA), doing the GET_PROPERTIES call correctly populated the adb_response (just with the incorrect screen_on state).

ok checked now, reloading did the trick! thanks! :) also looks like GET_PROPERTIES was populated with updated info, but as I am away from home [which is empty right now] - I'll check the whole feedback little bit later [I assume that wakelocks etc. should work good].
thank you!

[pejotigrek]

ok, tested, my adb_response isn't correctly populated. from the whole feedback line:
{'screen_on': False, 'awake': True, 'audio_state': None, 'wake_lock_size': 2, 'current_app': None, 'media_session_state': None, 'audio_output_device': None, 'is_volume_muted': None, 'volume': None, 'running_apps': None, 'hdmi_input': None} only the wake_lock_size changes with different integers [1-4] depending on what streaming app is used and what state it is.
I suppose it's because I didn't made any changes to the python files.

[breakthestatic]

Yeah, I believe that most of the values are dependent on screen_on being correctly populated. Regrettably, without others contributing to debugging their specific issues, not sure when this will get fixed. I can definitely open a PR for the change, but I'm not sure it will get merged with several people still reporting abnormal state.

[chatziko]

I'm also affected by this. I applied the CMD_SCREEN_ON fix and restarted HA, everything seems to be working fine (thanks @breakthestatic). The state is reported correctly, and a few automations I have the rely on the app_id attribute and androidtv/adb_command look good (although I didn't do any extensive testing).

Let me know if you want me to test anything specific.

If the change works for some people and is unlikely to break anything, maybe it's worth releasing it so that others can test more easily without having to manually to edit code inside containers.

[pejotigrek]

If the change works for some people and is unlikely to break anything, maybe it's worth releasing it so that others can test more easily without having to manually to edit code inside containers.

maybe I'm too naive, but I guess that it won't be worse than "not working" as it is without fixes, so yeah, release would be cool :)

but maybe there's an relatively easy way to put it as custom integration - just for testing? so it could be checked without fiddling within dockers?

[Dillton]

Not really sure what's going on there :( My two Chromecasts have been very consistent with their state reporting since putting in the fix.

In Twitch, I noticed that whenever the stream goes from actively playing to buffering (doesn't happen often, but still), the state switches from playing to idle, so perhaps some of the logic I noted in my prior comment (the stuff concerning the app-specific state & fallback detection rules) is the cause. I believe at the bottom of base_androidtv.py, there's a single extra location where state is not explicitly set to pre-determined values (besides a couple app-specific rules for Bell Fibe & VRV, whatever those are):

python-androidtv/androidtv/androidtv/base_androidtv.py

Lines 208 to 210 in b1425b1

	# Get the state from `audio_state`
	elif audio_state != constants.STATE_IDLE:
	state = audio_state

It seems that condition is rather open-ended, in that as long as none of the app-specific rules above it trigger, and there is no media_session_state, it will try to get the overall state from the current audio state (as long as it isn't idle). If audio_state is off, that could also seemingly lead to what you guys are seeing.
Maybe you could try adding extra logging at the bottom to see what all the various state variables look like at the time the problem occurs (i.e. put it right before line 228 in base_androidtv.py):

_LOGGER.debug("screen_on: %s", screen_on)
_LOGGER.debug("current_app: %s", current_app)
_LOGGER.debug("media_session_state: %s", media_session_state)
_LOGGER.debug("audio_state: %s", audio_state)

Hi @breakthestatic I just added extra logging and will watch some movie today so hopefully we will learn something more about the states.

EDIT1: So far HA is not able to load the integration with added logging.
EDIT2: Solved, cant use tabs only spaces in editor, oh my...

[Dillton]

Not really sure what's going on there :( My two Chromecasts have been very consistent with their state reporting since putting in the fix.
In Twitch, I noticed that whenever the stream goes from actively playing to buffering (doesn't happen often, but still), the state switches from playing to idle, so perhaps some of the logic I noted in my prior comment (the stuff concerning the app-specific state & fallback detection rules) is the cause. I believe at the bottom of base_androidtv.py, there's a single extra location where state is not explicitly set to pre-determined values (besides a couple app-specific rules for Bell Fibe & VRV, whatever those are):

python-androidtv/androidtv/androidtv/base_androidtv.py

Lines 208 to 210 in b1425b1

	# Get the state from `audio_state`
	elif audio_state != constants.STATE_IDLE:
	state = audio_state

It seems that condition is rather open-ended, in that as long as none of the app-specific rules above it trigger, and there is no media_session_state, it will try to get the overall state from the current audio state (as long as it isn't idle). If audio_state is off, that could also seemingly lead to what you guys are seeing.
Maybe you could try adding extra logging at the bottom to see what all the various state variables look like at the time the problem occurs (i.e. put it right before line 228 in base_androidtv.py):

_LOGGER.debug("screen_on: %s", screen_on)
_LOGGER.debug("current_app: %s", current_app)
_LOGGER.debug("media_session_state: %s", media_session_state)
_LOGGER.debug("audio_state: %s", audio_state)

Hi @breakthestatic I just added extra logging and will watch some movie today so hopefully we will learn something more about the states.

EDIT1: So far HA is not able to load the integration with added logging. EDIT2: Solved, cant use tabs only spaces in editor, oh my...

@breakthestatic Ok got some logs, you can check below.
When state changes to off:
2022-10-28 21:09:19.164 DEBUG (MainThread) [androidtv.androidtv.base_androidtv] screen_on: False
2022-10-28 21:09:19.165 DEBUG (MainThread) [androidtv.androidtv.base_androidtv] current_app: None
2022-10-28 21:09:19.165 DEBUG (MainThread) [androidtv.androidtv.base_androidtv] media_session_state: None
2022-10-28 21:09:19.165 DEBUG (MainThread) [androidtv.androidtv.base_androidtv] audio_state: None

When state changes to standby:
2022-10-28 21:07:09.204 DEBUG (MainThread) [androidtv.androidtv.base_androidtv] screen_on: True
2022-10-28 21:07:09.204 DEBUG (MainThread) [androidtv.androidtv.base_androidtv] current_app: None
2022-10-28 21:07:09.204 DEBUG (MainThread) [androidtv.androidtv.base_androidtv] media_session_state: None
2022-10-28 21:07:09.204 DEBUG (MainThread) [androidtv.androidtv.base_androidtv] audio_state: None

Seems like no data available at that time?

[breakthestatic]

Hmm, so it seems likely the actual dumpsys response is incorrect when the problem occurs. The only extra logic that is performed before it gets to the state logic is an inversion. The actual ADB command performs a silent grep for the commands, which returns a 0 exit code when found (meaning it found one of the screen on strings), and an exit code of 1 when the grep fails. Since normal boolean logic treats 0 as false and 1 as true, there's a bit of code that flips the adb command response and returns 1 if the screen is on and 0 if it's off:

python-androidtv/androidtv/constants.py

Lines 72 to 73 in b1425b1

	# echo '1' if the previous shell command was successful, echo '0' if it was not
	CMD_SUCCESS1_FAILURE0 = r" && echo -e '1\c' || echo -e '0\c'"

Are you familiar with ADB at all? If so, perhaps you could set up an ADB connection to your Chromecast, and then either set up an automation to alert you when the media player's state changes to off and immediately issue the following command in your ADB shell (using whatever filename/location you want to output to):

adb shell dumpsys display > debug.log

or run a small loop that automatically saves the output every N seconds, e.g. (sorry for my likely poor shell scripting abilities):

while sleep 5; do date >> debug.log && adb shell dumpsys display >> debug.log; done

From there you can open the file and inspect all the various display state info at the time HA saw the errant state to see if maybe mScreenState isn't ON, and if that's the case, if there's another parameter that could be targeted instead.

[Dillton]

@breakthestatic Got the logs when HA sees OFF however mScreenState is ON in logs. You can check if you find something else.
debug.log
debug2.log

[breakthestatic]

Were these just manual dumps after noticing the player status switching to off? If that's the case (and even with the logging loop) there is a chance that the single call was different than one that occurred just before it.

@ollo69 or @JeffLIrion, are you familiar with the flow of data from the ADB commands in constants.py through to the HA state? I'm trying to see if we can get the raw data that ADB returns to determine if the ADB state is incorrect, or if it's something further downstream. I believe that it's something later on, or perhaps some different (but related) ADB call that is failing, but I'm not very well-versed in this and without being able to reproduce it myself, am having a hard time trying to get any data to help debug.

[Dillton]

Were these just manual dumps after noticing the player status switching to off? If that's the case (and even with the logging loop) there is a chance that the single call was different than one that occurred just before it.

Yes manual right after state changed. I didn't managed to get the loop work and had very little time this weekend so at least I got the manual log however I will take a look at the loop in the following days.

[VoyteckPL]

Hello, when this can be implemented into HA?

[Victor4X]

Hello, when this can be implemented into HA?

I'll make a PR with the mentioned CMD_SCREEN_ON change.

I have confirmed that this works to regain get_properties() functionality, but there are probably still changes that need to be made to address the dropout issues people are having: #323 (comment)

I am not running this in HASS, as I wanted to have a good development environment, so I cannot confirm whether or not I see the dropout-issue. I will do some more testing on this today, however.

[partymike]

Is anyone able to provide a method to update the [python-androidtv/androidtv/constants.py] on hassio.core, the home assistant command line ext doesn't provide access and I don't think ha docker bash command works here?

[Victor4X]

Is anyone able to provide a method to update the [python-androidtv/androidtv/constants.py] on hassio.core, the home assistant command line ext doesn't provide access and I don't think ha docker bash command works here?

This specifically refers to Home Assistant OS setups, which might not be what you want

https://developers.home-assistant.io/docs/operating-system/debugging has instructions for ssh'ing into the supervisor, but they require physically inserting a USB drive into the host. Afterwards you can probably exec into the homeassistant docker container as mentioned here: https://community.home-assistant.io/t/editing-component-files-in-hassio/24273/6
(I think this might reset after a reboot though?)

There might be a way of doing it with custom components, but I haven't looked into it.

[Tamas-Toth-ebola]

Is anyone able to provide a method to update the [python-androidtv/androidtv/constants.py] on hassio.core, the home assistant command line ext doesn't provide access and I don't think ha docker bash command works here?

Sorry but I'm a bit confused. Do you refer HASSIO or HA - Core installation (throught Docker)? With the latter you can outsource the whole androidtv folder to a Docker volume, and therefore you can modify everything in it with permanens results. If you use HASSIO as an integrated solution that could be a 'bit' different.

[Victor4X]

Regarding the dropping out issue, I've been running a script that just calls the same update() method as HA every 5 seconds, and logging the returned properties. In a little over three hours of running with various different applications running on an Android TV 12 Chromecast, it didn't report the screen to be off a single time, nor did anything else look out of place.
This indicates that the problem might have something to do with what HA does with the data once it receives it, and not so much with what the component is actually getting from the Android TV.

I'll have to dig a little deeper to figure out what might be going on, but if anyone else experiencing the dropout issue could post some more information of how often it happens, and during what kind of operation, then that would be great.

edit: a lot more is going on when polling than I initially realized, so an actual HA connection might actually be easier.

[gxgani]

I've also noticed that you cannot control volume from the UI Slider/Automation for CCwGTV w/ Android 12. I use a home assistant docker based and androidtv volume is mapped to repo's latest code. Although controlling volume from Vol- Vol+ UI button works!

[TRusselo]

android 12 /google TV still broken on my home assistant core install Nov 30 update.
always shows OFF state.
power button does control device, but state never changes state in home assistant.

[TRusselo]

looks like we are waiting for home-assistant to bump python-androidtv

[chatziko]

Most likely @JeffLIrion needs to publish a new pypi release before HA can bump it. The last one is still 0.0.69:

https://pypi.org/project/androidtv/#history

Afterwards a simple PR needs to be opened in home-assistant/core, like this one:

https://github.com/home-assistant/core/pull/80407/files

[rs443]

Most likely @JeffLIrion needs to publish a new pypi release before HA can bump it. The last one is still 0.0.69:

androidtv 0.0.70 seems to be released just a few hours ago: https://pypi.org/project/androidtv/0.0.70/

[chatziko]

Just made a PR:
home-assistant/core#83707

[VoyteckPL]

Hi when can we expect this fix in HA officially?

[chatziko]

Hi when can we expect this fix in HA officially?

The PR is merged and scheduled for 2022.12.2, so likely in the following days.

[VoyteckPL]

Just one more thing I noticed. State detection is delayed around 5 seconds. I also have google cast integration when there is no or very little delay. For example when switching from youtube to main launcher it is update after some time which is bad for automations based on this state.

[benrjunk]

Just one more thing I noticed. State detection is delayed around 5 seconds. I also have google cast integration when there is no or very little delay. For example when switching from youtube to main launcher it is update after some time which is bad for automations based on this state.

Use this automation to increase updating frequency to every 2 seconds. Also disable automatic updating in the integration settings

`alias: Update AndroidTV
description: ""
trigger:

• platform: time_pattern
  seconds: /2
  condition: []
  action:
• service: homeassistant.update_entity
  data: {}
  target:
  entity_id:
  - media_player.basement_tv
  - media_player.familyroomtv
  mode: single
  `

[VoyteckPL]

Thanks man. It works. Kinda... Even when setting to 1 sec. I get delay around 3 seconds ☹️

[VoyteckPL]

Google Cast integration has immediate reaction.

[Dillton]

Thanks man. It works. Kinda... Even when setting to 1 sec. I get delay around 3 seconds ☹️

Hi. I think you can try use the action below in automation if it will be faster instead of homeassistant.update_entity.
service: androidtv.adb_command
data:
command: GET_PROPERTIES
target:
entity_id: media_player.chromecast_google_tv

[VoyteckPL]

Unfortunately that didn't help.

[hermanho]

After I have updated the HA with this fixing, the device status will be reported as "off" sometimes when I browse the thumbnails in Netflix or during video playing in YouTube. It impacts the automation trigger.

[TRusselo]

i find it much better since the HA update. play/pause has been great in YouTube.
still broken for Emby. I might contact them.

[markwiese]

i find it much better since the HA update. play/pause has been great in YouTube. still broken for Emby. I might contact them.

I found I had to update the state detection rule for Emby to the below. Works fine, now, however, my Chromecast still gets detected as being "off" sometimes. That's nothing to do with Emby, though.

[{"playing": {"wake_lock_size": 2}}, {"paused": {"wake_lock_size": 1}}]

[TRusselo]

i find it much better since the HA update. play/pause has been great in YouTube. still broken for Emby. I might contact them.

I found I had to update the state detection rule for Emby to the below. Works fine, now, however, my Chromecast still gets detected as being "off" sometimes. That's nothing to do with Emby, though.

[{"playing": {"wake_lock_size": 2}}, {"paused": {"wake_lock_size": 1}}]

I love the sound of what you are saying... but have no idea where to put that code. i dont know of a "state detection rule" to edit

[markwiese]

i find it much better since the HA update. play/pause has been great in YouTube. still broken for Emby. I might contact them.

I found I had to update the state detection rule for Emby to the below. Works fine, now, however, my Chromecast still gets detected as being "off" sometimes. That's nothing to do with Emby, though.
[{"playing": {"wake_lock_size": 2}}, {"paused": {"wake_lock_size": 1}}]

I love the sound of what you are saying... but have no idea where to put that code. i dont know of a state detection rule to edit

In HA, go to Integrations, select the Android TV instance and click Configure. In the screen that pops up, you can select New Rule at the bottom and then click Submit. That will allow you to enter the app ID for Emby along with the state detection rule I provided.

[TRusselo]

i find it much better since the HA update. play/pause has been great in YouTube. still broken for Emby. I might contact them.

I found I had to update the state detection rule for Emby to the below. Works fine, now, however, my Chromecast still gets detected as being "off" sometimes. That's nothing to do with Emby, though.
[{"playing": {"wake_lock_size": 2}}, {"paused": {"wake_lock_size": 1}}]

I love the sound of what you are saying... but have no idea where to put that code. i dont know of a state detection rule to edit

In HA, go to Integrations, select the Android TV instance and click Configure. In the screen that pops up, you can select New Rule at the bottom and then click Submit. That will allow you to enter the app ID for Emby along with the state detection rule I provided.

I had to input, [{"playing": {"wake_lock_size": 3, "wake_lock_size": 4}}, {"paused": {"wake_lock_size": 2, "wake_lock_size": 1}}]
it works.
if i reopen the rule it says
[{"playing": {"wake_lock_size": 4}}, {"paused": {"wake_lock_size": 1}}]
either way, its working. THANK YOU SO MUCH.
this [POST] had a bunch of configs
THIS DOC. was helpful for figuring out syntax, the ADB commands, reponses to get it working.

regardless mark, thank you so much,
THIS POST, has code that allows me to turn on Hue Sync via Hue Essentials when Emby starts playing. (you just fixed. thankyou)