programmable button_press & button_release

[armedad]

i'm trying to simulate how fastforward works on some services which is that tapping on fast forward jumps forward 10 secs. but press and hold for a couple seconds activate fastforward.

what i've done to work around it is this:

  fast_forward:
    icon: mdi:fast-forward
    tap_action:
      service: androidtv.adb_command
      service_data:
        entity_id: media_player.main_bedroom_fire_tv
        command: >-
          sendevent /dev/input/event4 4 4 786611 && sendevent /dev/input/event4
          1 208 1 && sendevent /dev/input/event4 0 0 0 && sendevent
          /dev/input/event4 4 4 786611 && sendevent /dev/input/event4 1 208 0 &&
          sendevent /dev/input/event4 0 0 0    
    hold_action:
      service: script.androidtv_send_command_pair
      service_data:
        entity_id: media_player.main_bedroom_fire_tv
        command1: >-
          sendevent /dev/input/event4 4 4 786611 && sendevent /dev/input/event4
          1 208 1 &&  sendevent /dev/input/event4 0 0 0
        delay: 3
        command2: >-
          sendevent /dev/input/event4 4 4 786611 && sendevent /dev/input/event4
          1 208 0 && sendevent /dev/input/event4 0 0 0

what i'd like to do is this:

  fast_forward:
    icon: mdi:fast-forward
    tap_action:
      service: androidtv.adb_command
      service_data:
        entity_id: media_player.main_bedroom_fire_tv
        command: >-
          sendevent /dev/input/event4 4 4 786611 && sendevent /dev/input/event4
          1 208 1 && sendevent /dev/input/event4 0 0 0 && sendevent
          /dev/input/event4 4 4 786611 && sendevent /dev/input/event4 1 208 0 &&
          sendevent /dev/input/event4 0 0 0    
    button_press:
      service: androidtv.adb_command
      service_data:
        entity_id: media_player.main_bedroom_fire_tv
        command: >-
          sendevent /dev/input/event4 4 4 786611 && sendevent /dev/input/event4
          1 208 1 &&  sendevent /dev/input/event4 0 0 0
    button_release:
      service: androidtv.adb_command
      service_data:
        entity_id: media_player.main_bedroom_fire_tv
        command: >-
          sendevent /dev/input/event4 4 4 786611 && sendevent /dev/input/event4
          1 208 0 && sendevent /dev/input/event4 0 0 0

[Nerwyn]

So if I'm understanding this correctly, this would add a new action hold_end_action. tap_action would trigger normally, then if the button is held down long enough (500 ms) hold_action will trigger, and then on, and then finally when the button is released hold_end_action will trigger?

[armedad]

for me, my preference would not be hold_end, although that would probably work. i'd like to catch the initial press down. the fire tv remote fires a sendevent right at the button press time, and a release event on the button press release. android then determines what to do with it. so my preference is to simulate exactly what the physical remote is doing. what you are suggesting on the hold_action would certainly work, as well, however it would have 2 downsides. imagine that prime video did the fast forward only when you held down the button for 1000ms. if the events fired on hold_action and on hold_end_action, then the user would need to hold down for 1500ms in order to achieve what the physical remote does in 1000ms. that make sense? sorry if my explanation is convoluted....

…

On Mon, Feb 5, 2024 at 3:56 PM Nerwyn ***@***.***> wrote: So if I'm understanding this correctly, this would add a new action hold_end_action. tap_action would trigger normally, then if the button is held down long enough (500 ms) hold_action will trigger, and then on, and then finally when the button is released hold_end_action will trigger? — Reply to this email directly, view it on GitHub <#58 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK7ZMORRXLXB7NEOCLS76OTYSFWTTAVCNFSM6AAAAABCZQNWCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRYGUZDQMBZGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Nerwyn]

That makes sense, it would just mean that you could not have hold start/end actions on the same button that has a tap action. We could also make it so that the hold_secs number that gets sent with the hold end action counts from the initial hold start event, so it counts up from 500 ms. That way you would still only need to hold for 1000 ms, but the initial hold start action wouldn't be sent until 500 ms.

I could possibly implement both, and make it so that hold_end_action triggers if hold_action or hold_start_action is initially triggered (as described in my first comment), and then if hold_start_action is defined it disables tap_action and hold_action.

[armedad]

yeah... in this particular case i'd have to choose.. not sure if you recall programming keyboards and virtual keys in the windows world, but this is like the high level sending vk_keys... vk_return, vk_a, etc. versus sending scan codes... if you're trying to automate entry into a text box, you'd do the vk_keys (which is like sending an "a") . but if you're trying to create a virtual keyboard, you really want to do the raw scan codes because you then actually simulate the keyboard and all the nuances.

…

On Mon, Feb 5, 2024 at 5:18 PM Nerwyn ***@***.***> wrote: That makes sense, it would just mean that you could not have hold start/end actions on the same button that has a tap action. We could also make it so that the hold_secs number that gets sent with the hold end action counts from the initial hold start event, so it counts up from 500 ms. That way you would still only need to hold for 1000 ms, but the initial hold start action wouldn't be sent until 500 ms. I could possible implement both, and make it so that hold_end_action triggers if hold_action or hold_start_action is initially triggered (as described in my first comment), and then if hold_start_action is defined it disables tap_action and hold_action. — Reply to this email directly, view it on GitHub <#58 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK7ZMOW5MKZSLOM2RBDLH33YSGAHLAVCNFSM6AAAAABCZQNWCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRYGYYDCMRQGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[armedad]

btw, that is also why i wouldn't do a hold_start and hold_end. i'd do button_press and button_release in the case that i had initially with the adb_command/sendevent case, the right thing happens... the fast press/release gets interpreted by android as a tap. and if there's a big gap of time between the press and the release, it interprets it as a hold/release

…

On Mon, Feb 5, 2024 at 5:26 PM chee ***@***.***> wrote: yeah... in this particular case i'd have to choose.. not sure if you recall programming keyboards and virtual keys in the windows world, but this is like the high level sending vk_keys... vk_return, vk_a, etc. versus sending scan codes... if you're trying to automate entry into a text box, you'd do the vk_keys (which is like sending an "a") . but if you're trying to create a virtual keyboard, you really want to do the raw scan codes because you then actually simulate the keyboard and all the nuances. On Mon, Feb 5, 2024 at 5:18 PM Nerwyn ***@***.***> wrote: > That makes sense, it would just mean that you could not have hold > start/end actions on the same button that has a tap action. We could also > make it so that the hold_secs number that gets sent with the hold end > action counts from the initial hold start event, so it counts up from 500 > ms. That way you would still only need to hold for 1000 ms, but the initial > hold start action wouldn't be sent until 500 ms. > > I could possible implement both, and make it so that hold_end_action > triggers if hold_action or hold_start_action is initially triggered (as > described in my first comment), and then if hold_start_action is defined > it disables tap_action and hold_action. > > — > Reply to this email directly, view it on GitHub > <#58 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AK7ZMOW5MKZSLOM2RBDLH33YSGAHLAVCNFSM6AAAAABCZQNWCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRYGYYDCMRQGI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[Nerwyn]

So button_press and button_release would replace the normal tap/double/hold actions if they're configured for a button?

[armedad]

generally yes. I don't know if someone might find a reason to also use those events, but in traditional keyboard implementations one would choose one or the other.

…

On Mon, Feb 5, 2024, 8:02 PM Nerwyn ***@***.***> wrote: So button_press and button_release would replace the normal tap/double/hold actions if they're configured for a button? — Reply to this email directly, view it on GitHub <#58 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK7ZMOUNVQQ2VJDGHLJAKX3YSGTNXAVCNFSM6AAAAABCZQNWCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRYG42DKNZYGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Nerwyn]

This should be working in the latest beta. Can you try installing it and a command like this?

custom_actions:
  fast_forward:
    icon: mdi:fast-forward
    momentary_start_action:
      action: call-service
      service: androidtv.adb_command
      data:
        entity_id: media_player.main_bedroom_fire_tv
        command: >-
          sendevent /dev/input/event4 4 4 786611 && sendevent /dev/input/event4
          1 208 1 &&  sendevent /dev/input/event4 0 0 0
    momentary_end_action:
      action: call-service
      service: androidtv.adb_command
      data:
        entity_id: media_player.main_bedroom_fire_tv
        command: >-
          sendevent /dev/input/event4 4 4 786611 && sendevent /dev/input/event4
          1 208 0 && sendevent /dev/input/event4 0 0 0

You can also include HOLD_SECS in the service call data value if possible for momentary end actions.

[Nerwyn]

@armedad still waiting for your feedback

[armedad]

hey! sorry, was out of town. will check it out tonight!

…

On Thu, Feb 22, 2024 at 3:03 PM Nerwyn ***@***.***> wrote: Assigned #58 <#58> to @armedad <https://github.com/armedad>. — Reply to this email directly, view it on GitHub <#58 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK7ZMOQTC3UL4TOUL7IFCHDYU7FEFAVCNFSM6AAAAABCZQNWCWVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRHA4TONZQGA4DCMA> . You are receiving this because you were assigned.Message ID: ***@***.***>

[armedad]

i've got to be doing something wrong. i'm not getting the start and end action events being triggered at all.

i've got this. only tap_action triggers. if i remove tap_action it complains to me of not having an entity for send_command.

note that i put volume up/down/mute just for testing... it helps me see exactly what's happening.

fast_forward: icon: mdi:fast-forward tap_action: service: webostv.button service_data: entity_id: media_player.great_room_lgtv button: VOLUMEUP momentary_start_action: service: webostv.button service_data: entity_id: media_player.great_room_lgtv button: VOLUMEUP momentary_end_action: service: webostv.button service_data: entity_id: media_player.great_room_lgtv button: MUTE

it feels as if i don't even have the new version on, however i am getting this:

and i did a reboot of home assistant just in case.

i've opened up the .js file in config\www\community.... and i see "momentary_end_action" in the js, so i believe i've got it downloaded.

can you see an issue with the above?

[Nerwyn]

It's probably a caching issue in your browser like with the keyboard. Can you try clearing it (or the HA app cache) and trying again?

[armedad]

you were right. was a caching issue. works great! thank you!!

…

On Fri, Feb 23, 2024 at 12:24 AM Nerwyn ***@***.***> wrote: It's probably a caching issue in your browser like with the keyboard. Can you try clearing it (or the HA app cache) and trying again? — Reply to this email directly, view it on GitHub <#58 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK7ZMOV4SIJ33Z6CXWF5PJDYVBG2DAVCNFSM6AAAAABCZQNWCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRQHEYDMNBTGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Nerwyn]

Great! If it's all good I'll work on the final release later.

[Nerwyn]

Added in 3.4.0