core icon indicating copy to clipboard operation
core copied to clipboard

events from keyboard_remote devices using symlinks are triggered with their real path

Open papaschloss opened this issue 2 years ago • 8 comments

The problem

I have a keyboard_remote device that uses a symlink (from configuration.yaml):

keyboard_remote:
  - device_descriptor: /dev/buttons/livingroom1
    type: 'key_up'
  - device_descriptor: /dev/buttons/livingroom2
    type: 'key_up'

And an automation rule that triggers when I hit a key on it, also using the symlink:

platform: event
event_type: keyboard_remote_command_received
event_data:
  device_descriptor: /dev/buttons/livingroom1
  key_code: 115

But when I hit a button on my keyboard to trigger the event, the trigger uses the real path of the event /dev/input/event## and so my automation doesn't trigger. This is from my home-assistant.log when I trigger it:

2023-01-30 21:26:29.468 DEBUG (Recorder) [homeassistant.components.recorder.core] Processing task: EventTask(event=<Event keyboard_remote_command_received[L]: key_code=115, type=key_up, device_descriptor=/dev/input/event8, device_name=AB Shutter3 Consumer Control>)

It works just fine if I use /dev/input/event# in the automation.

This is a big issue for me because I have multiple bluetooth input devices, and I can't control which event ID they get assigned, so I need to use my symlinks to distinguish between them. (I have udev rules in place to ensure the same device will always use the same symlink every time.)

Note that this happens no matter where I put the symlink. I tried symlinks in /dev/input but the hassio event always uses the event## path instead of with my symlink path. Also, I have two devices above in my config example, but it does the same even with one.

I'd try to fix this myself, but I'm not fluent in python, and the code was too foreign for me to decipher it. Let me know what else I can provide to help

What version of Home Assistant Core has the issue?

2023.1.7

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

keyboard_remote

Link to integration documentation on our website

https://www.home-assistant.io/integrations/keyboard_remote/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

papaschloss avatar Jan 31 '23 03:01 papaschloss

Hey there @bendavid, @lanrat, mind taking a look at this issue as it has been labeled with an integration (keyboard_remote) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of keyboard_remote can trigger bot actions by commenting:

  • @home-assistant close Closes the issue.
  • @home-assistant rename Awesome new title Change the title of the issue.
  • @home-assistant reopen Reopen the issue.
  • @home-assistant unassign keyboard_remote Removes the current integration label and assignees on the issue, add the integration domain after the command.

(message by CodeOwnersMention)


keyboard_remote documentation keyboard_remote source (message by IssueLinks)

home-assistant[bot] avatar Jan 31 '23 03:01 home-assistant[bot]

Hello @papaschloss,

I think I understand your issue, but unfortunately I think that this is a limitation of the underlying kernel and evdev library implementation. As far as the OS is concerned, the /dev/input/event* path is the real path for all events, and the symlinks are one way.

As an alternative, can you filter your events based on device_name instead of device_descriptor? This is what I use and it works very well.

lanrat avatar Jan 31 '23 06:01 lanrat

Thanks for the reply @lanrat . Unfortunately device_name doesn't work because I have multiple devices with the same name. As an alternative, is there a way to add a custom name to the keyboard_remote devices in configuration.yaml, then use that name in the automation?

papaschloss avatar Jan 31 '23 14:01 papaschloss

Another alternative... I know symlinks only go forward, but the keyboard_remote device is aware that it has a symlink. (There's special logic in the code to resolve symlinks when setting it up.) So if an event happens, could it check to see if any symlinks in the configuration resolve to the event path? Then trigger using that symlink.

papaschloss avatar Jan 31 '23 15:01 papaschloss

After thinking about this a bit more, it may be a breaking change to change the device_descriptor to show the symlink value, in case existing users have come to rely on the existing behavior.

As an alternative idea, what if each keyboard device could take an optional name parameter in the yaml config that would be included in each event? This way, if you manually add a unique name to the input device (from a symlink or not) it will also be included in the event data which you can use for filtering in automations.

Something like this:

integration config:

keyboard_remote:
- device_descriptor: '/dev/input/by-id/bluetooth-keyboard'
  type: "key_down"
  name: "Livingroom BT Keyboard"

Automation trigger:

automation:
  trigger:
    platform: event
    event_type: keyboard_remote_command_received
    event_data:
      key_code: 107
      type: key_down
      name: "Livingroom BT Keyboard"

  action:
    ....

Thoughts?

lanrat avatar Feb 01 '23 00:02 lanrat

Nice - that works for me. Happy to test it out when it's ready to use.

papaschloss avatar Feb 01 '23 03:02 papaschloss

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

bump.

I'm still slowly working on this.

lanrat avatar May 02 '23 04:05 lanrat

I have revisited this and decided that it is best to just update the device_descriptor i the event to that in the config file if using links. PR #94744

lanrat avatar Jun 16 '23 21:06 lanrat