Linuxinput binding and mouse capture

As discussed with the binding creator @t-8ch in the old github page, I tried to configure with this binding a remote that works as a keyboard/mouse.
Some buttons are the right and left mouse click, so I ask him the possibility to capture also the mouse button.

As a workaround, until mouse buttons will be available, I’m using a bash script that use “evtest” to capture inputs and to send to an item these values, if anyone else is interested!

Ciao

Link to the original ticket: could not find channel · Issue #5 · t-8ch/binding-linuxinput · GitHub

Fixed in [linuxinput] Handle all kinds of buttons by t-8ch · Pull Request #10730 · openhab/openhab-addons · GitHub

If you want I can upload a version of the binding with the fix applied.
Which version of OpenHAB are you using?

Amazing =)
I’m still using 2.5.9!

Here is a build for 2.5.12: https://github.com/t-8ch/binding-linuxinput/releases/download/bugfixes/org.openhab.binding.linuxinput-2.5.12.jar
It should also work with 2.5.9.

Thank you very much for your work! Sadly my openhab JUST NOW has some problem and i can’t uninstall-reinstall bindings…

Probably because the addon repository for 2.5 has been shut down recently.
You should be able to directly put the .jar into the addons folder manually.

Hello,

Thanks for this plugin. Im having an issue while trying to use it to interface a generic wireless remote/keyboard combo. Issue is described below.

Linux Input Binding is erroring out on Thinghelper call due to duplicate/unamed channel names in keyboard
Openhab version 3.3 running on Raspberry-Pi3B+.

Im trying to use a a 2.5Ghz keyboard/remote combo with media control keys and qwerty keyboard. My goal is to build a universal remote control for home theater system built around openhab. This device created 3 events for keyboard [/dev/input/event*] and I could successfully get 2 of them working “Things”. But for the /dev/input/event2 which receives the media key events from the keyboard, the plugin creates below error and goes OFFLINE.
I have double checked the Linux permissions and they are all same for all events. Also I could capture the keypress events using evtest running as user openhabian for /dev/input/event2.

java.lang.IllegalArgumentException: Duplicate channels linuxinput:input-device:consumer:keypresses#null
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:152) ~[?:?]
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:128) ~[?:?]
at org.openhab.core.thing.binding.builder.ThingBuilder.withChannels(ThingBuilder.java:86) ~[?:?]

Using evtest I captured the key bindings for this device and it turns out that the device has left few key codes unmapped as shown below. I suspect that ThingHelper call is setting EnsureUniqeChannels, and this is creating the above error. i.e While creating the channels , the unmapped keycodes comes up as duplicated channels. I have no way to access the driver of the wireless keyboard to enumerate all keycodes. I believe one possible way to fix this issue would be to update the binding to call ThingHelper with EnsureUniqeChannels set to false. I might be completely wrong!.

Event code 583 (KEY_ASSISTANT)
Event code 584 (?)
Event code 585 (?)
Event code 586 (?)
Event code 592 (KEY_BRIGHTNESS_MIN)

Is it possible to update this binding to ignore duplicate channels? . Or may be add a setting to the addon to ignore duplicate channels may be?.

Another possibility is to rebuild the libudev library to ignore unnamed channels.

Let me know if any other debug information is needed.

I have been breaking my head to get this setup working. I believe this fix would help many users to use cheap generic wireless keyboards with openhab . Thank you for developing this plugin. Greatly appreciate a fix.

Hi @anoop,

thanks for reporting this. The problem should be fixed with [linuxinput] handle keys not known by libevdev by t-8ch · Pull Request #13632 · openhab/openhab-addons · GitHub

In the future please try to open a new thread for new issues instead of hijacking an old one.
Also if I fail to respond feel free to ping me (also via other channels)

1 Like

The fix is now merged to main.
You can either wait for 3.4 to be released, use one of the next 3.4 SNAPSHOT/milestone builds or use this fixed version for 3.3: [linuxinput] handle keys not known by libevdev by t-8ch · Pull Request #13632 · openhab/openhab-addons · GitHub

1 Like

Hi Thomas,

Thank you verymuch for the fix. Im planning to pull the build over the weekend and do some testing. Meanwhile I wrote a shell script that captures the keys using evtest and relay the codes to Openhab3 using REST calls. Getting this addon working will make my setup cleaner. Thanks again for the fix.

Btw, I thought it would be better to keep everything related to this addon in the same thread. Sorry for hijacking the existing thread. Will open an new thread in the future.

Anoop