ayavilevich / evdev2hass

MIT License
9 stars 2 forks source link

Tiny Wireless Keyboard doesn't show key presses or any events #1

Closed ThatProgrammerr closed 2 months ago

ThatProgrammerr commented 2 months ago

This is the output. I'm running the python script directly, not the docker image. The same keyboard receiver plugged directly into my Home Assistant machine has no problems seeing the keyboard information.

I decided to use this to extend the range at which the keyboard can be used.

My current HA config for keyboard control

keyboard_remote:
  device_descriptor: '/dev/input/event3'  # Adjusted to match your keyboard's event descriptor
  type: "key_down"
  emulate_key_hold: true
  emulate_key_hold_delay: 0.25
  emulate_key_hold_repeat: 2.0

Example Event Output from Receiver on HA Machine

  event_type: keyboard_remote_command_received
data:
  key_code: 72
  type: key_down
  device_descriptor: /dev/input/event3
  device_name: 2.4G Mouse
origin: LOCAL
time_fired: "2024-08-10T22:47:24.671813+00:00"
context:
  id: 01J4Z7K8QZDHM5BXEV66FJF0Y5
  parent_id: null
  user_id: null

Command

 python3 evdev2hass.py -t KEY_REMOVED -e http://10.0.0.66:8123/api/ -d /dev/input/event4

Output of this script

root@ha-relay:~/evdev2hass# python3 evdev2hass.py -t KEY_REMOVED -e http://10.0.0.66:8123/api/ -d /dev/input/event4
Grabbing device /dev/input/event4, name "2.4G Mouse", phys "usb-3f980000.usb-1.4/input1"
{('EV_SYN', 0): [('SYN_REPORT', 0), ('SYN_CONFIG', 1), ('SYN_MT_REPORT', 2), ('?', 4)], ('EV_KEY', 1): [(['BTN_LEFT', 'BTN_MOUSE'], 272), ('BTN_RIGHT', 273), ('BTN_MIDDLE', 274), ('BTN_SIDE', 275), ('BTN_EXTRA', 276), ('BTN_FORWARD', 277), ('BTN_BACK', 278), ('BTN_TASK', 279)], ('EV_REL', 2): [('REL_X', 0), ('REL_Y', 1), ('REL_HWHEEL', 6), ('REL_WHEEL', 8), ('REL_WHEEL_HI_RES', 11), ('REL_HWHEEL_HI_RES', 12)], ('EV_MSC', 4): [('MSC_SCAN', 4)]}
ThatProgrammerr commented 2 months ago

Sorry for the issue. After almost giving up, I realised there was a test file, so I tried it and realised that my receiver for my mini keyboard has multiple events, which I guess in this case meant that the event showing in lsusb was not the event that the keyboard events were actually being sent on. I'm going to close this out now, but I hope this helps someone in the future.

/dev/input/event2 2.4G Mouse usb-3f980000.usb-1.2/input0
/dev/input/event3 2.4G Mouse usb-3f980000.usb-1.2/input1
/dev/input/event4 2.4G Mouse usb-3f980000.usb-1.2/input1
/dev/input/event5 2.4G Mouse Consumer Control usb-3f980000.usb-1.2/input1
/dev/input/event6 2.4G Mouse System Control usb-3f980000.usb-1.2/input1