Sendevent commands on Google TV

Configuration
1

Hi all,

First time posting so apologies for any errors.

Basically I am trying to control my ‘Chromecast with Google TV’ from home assistant. I have used the ADB basic commands using the commands like ‘UP’ but its delay is too long to really be a good experience so I am trying to use the send event command.

I have learned the ‘UP’ send event command for my chromecast and tried to put it into a button but there is no sign that it is triggering or sending.

This is the output from the learn send event command:

Output from service 'learn_sendevent' from media_player.google_tv_master_bedroom: 'sendevent /dev/input/event4 4 4 786498 && sendevent /dev/input/event4 1 103 1 && sendevent /dev/input/event4 0 0 0 && sendevent /dev/input/event4 4 4 786498 && sendevent /dev/input/event4 1 103 0 && sendevent /dev/input/event4 0 0 0'

This is how I played out the button code:

type: button
tap_action:
  action: call-service
  service: androidtv.adb_command
  service_data:
    entity_id: media_player.google_tv_master_bedroom
    command: >-
      'sendevent /dev/input/event4 4 4 786498 && sendevent /dev/input/event4 1
      103 1 && sendevent /dev/input/event4 0 0 0 && sendevent /dev/input/event4
      4 4 786498 && sendevent /dev/input/event4 1 103 0 && sendevent
      /dev/input/event4 0 0 0'
  target: {}
show_name: false
icon: mdi:chevron-up

If anyone could tell me what I am doing wrong, id really appreciate it.

Thanks

2

I would like to know too! Did you find the answer?

3

I want to know if you were able to solve this :slight_smile: I am in same situation…

4

This is my example:

                      action: call-service
                      service: androidtv.adb_command
                      service_data:
                        command: >-
                          sendevent /dev/input/event3 4 4 786498 && sendevent
                          /dev/input/event3 1 103 1 && sendevent
                          /dev/input/event3 3 40 0 && sendevent
                          /dev/input/event3 3 42 1 && sendevent
                          /dev/input/event3 0 0 0 && sendevent /dev/input/event3
                          4 4 786498 && sendevent /dev/input/event3 1 103 0 &&
                          sendevent /dev/input/event3 3 40 1 && sendevent
                          /dev/input/event3 3 42 0 && sendevent
                          /dev/input/event3 0 0 0

REmember though these are hardware specific. So don’t just copy mine.

You shouldn’t have quotes around the events if they are on a multi-line like that…

It should look like this:

    command: >-
      sendevent /dev/input/event4 4 4 786498 && sendevent /dev/input/event4 1
      103 1 && sendevent /dev/input/event4 0 0 0 && sendevent /dev/input/event4
      4 4 786498 && sendevent /dev/input/event4 1 103 0 && sendevent
      /dev/input/event4 0 0 0
5

I’m trying to use sendevent as well as the normal input commands are painfully slow.

However I get a adb_response: sendevent: /dev/input/event3: Permission denied.

I have enabled the ADB bridge and also enabled USB debugging. Is there anything else to be enabled for sendevent to work?

@calisro, you seem to have this working on your installation. Is the response time using sendevent acceptable and comparable to the actual hardware remote?

6

It’s pretty darn fast. It’s not quite hardware buttons. But it’s good enough that I don’t notice the lag really and makes the ha remotes usable.

7

Oh cool. So I have to get this to work. Any ideas what this permission error could be?

8

What version of android? I’ll guess android Q.

9

Here are the details of my device

image
image678×686 74.2 KB

10

not sure. I use a shield that I have stopped updates on. I’m guessing the latest version that google limited this. I’ll guess you can see SELinux denied entries on logcat/dmesg

11

Ooh, trying to decipher this…

Are you saying you essentially built your own device? On a Pi or similar? Where did you get the image/source from?

To debug the current setup how would I access the logs? Also are you the Python ADB implementation or the ADB server (Android TV - Home Assistant)?

12

No? I just use a nvidia shield which I haven’t updated to the latest version of android.

adb logcat

yes

13

Oh ok. The Nvidia shield as quite a bit more expensive from memory…

To use adb logcat I need to register on the Google Developer site (Android TV with Google Cast  |  Google Developers)?

You’re using python ADB right?

14

I am not sure how you access it on your device but i dont think you need to register for anything. If you’re getting permission denied, i doubt you’re going to change that without downgrading.

15

I wanted to use the ‘adb logcat’ but that probably requires me to login to the Chromecast device. I’m way over my comfort level and understanding here…

While you may be right that all this just leads to the same outcome; i.e. a confirmation of what we already know it’ll be interesting to confirm. Also a search on downgrading firmware didn’t really yield anything useful so far.

Not going great so far :slight_smile:

EDIT: Managed to install ADB and Fastboot++ on my laptop and connect to the device. Per what you expected I have these sendevent errors in the adb logcat

09-19 22:56:55.520 16438 16438 W sendevent: type=1400 audit(0.0:341): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0
09-19 22:57:06.472 16553 16553 W sendevent: type=1400 audit(0.0:342): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0
09-19 22:57:15.284 16667 16667 W sendevent: type=1400 audit(0.0:343): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0
09-19 22:57:20.872 16727 16727 W sendevent: type=1400 audit(0.0:344): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0
09-19 22:57:30.072 16790 16790 W sendevent: type=1400 audit(0.0:345): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0
09-19 23:10:24.652 21820 21820 W sendevent: type=1400 audit(0.0:376): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0
09-19 23:10:29.752 21880 21880 W sendevent: type=1400 audit(0.0:377): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0
09-19 23:10:32.780 21966 21966 W sendevent: type=1400 audit(0.0:378): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0
09-19 23:10:34.988 21990 21990 W sendevent: type=1400 audit(0.0:379): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0
09-19 23:13:55.408 23192 23192 W sendevent: type=1400 audit(0.0:380): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0
09-19 23:14:02.284 23267 23267 W sendevent: type=1400 audit(0.0:381): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0
09-19 23:14:11.200 23366 23366 W sendevent: type=1400 audit(0.0:382): avc: denied { write } for name="event3" dev="tmpfs" ino=100396 scontext=u:r:shell:s0 tcontext=u:object_r:input_device:s0 tclass=chr_file permissive=0

Of course I have no idea what this means and whether this is indeed solvable with a lower firmware version.

Not sure what’s the most appropriate next course of action. Might register this as a GitHub issue

16

Yeah it’s what you said. Android 10 has introduced this SELinux policy that stops these commands.

I have been trying to find a solution to downgrade to A9 but no luck for weeks. So I’m stuck as noone ever downgrades :slight_smile: and trying to find a device that still runs A9 seems impossible…