## Description:
More fixes flagged by pylint 2 that don't hurt to have before the actual pylint 2 upgrade (which I'll submit soon).
## Checklist:
- [ ] The code change is tested and works locally.
- [x] Local tests pass with `tox`. **Your PR cannot be merged unless tests pass**
* Add device_descriptor and device_name to keyboard event
This allows automations to identify which device has generated the
keypress. This is especially useful for bluetooth remotes to control different
devices.
* Remove line breaks
* Fix
* Allow using more than one keyboard remote
This sets up one thread per keyboard remote, listening for events.
* Remove enclosing block in keyboard_remote
* Remove unnecessary semantic check for keyboard_remote
* Update keyboard_remote.py
I added a couple of events: keyboard_remote_connected and keyboard_remote_disconnected, useful to trigger some action (for example: play a sound)
I changed the way the component refers to the keyboard: not by "descriptor", but by name.
The fact is that the udev system doesn't always give a name link in /dev/input/by-id folder and the actual /dev/input/eventX file changes automatically.
For example, if I had my keyboard on /dev/input/event13 and then it disconnected, if something else connects to the system it will get the first input file available, that is /dev/input/event13. If the keyboard then reconnects, it will get /dev/input/event14, thus breaking the configuration.
Now it searches every time for the right input file.
The problem might be that, in case of ha upgrade, the pre-existing configuration won't work. I thing there are some guidelines here, but I am not sure.
I think it's inevitable: the initial idea to use a /dev/input/by-id/ symbolic link was good, but unfortunately it doesn't seem to work with bluetooth devices.
I haven't updated the documentation yet: I'm waiting for some ok about the change in configuration key names.
* Update keyboard_remote.py
That should do the trick.
You are right: device names can be duplicated, thus they're not reliable in case of multiple devices. Unfortunately, the only other information available is the physical address, even more complicated.
But in case you have just one keyboard remote of same model, the name works just fine. I'll put it in the documentation which, once the code is approved, I will promptly update.
* Update keyboard_remote.py
* Update keyboard_remote.py
* Update keyboard_remote.py
* Unwrap logger error
* Update keyboard_remote.py
I changed os.path.isFile() to os.path.exists: as far as I know isFile doesn't work with device files. At least on my Ubuntu it wasn't working.
Then I added some error control in case the keyboard disconnects: with bluetooth keyboards this happen often due to battery saving. Now it reconnects automatically when the keyboard wakes up.
We could fire an event to hass when the keyboard connects-disconnects, maybe I'll do this later.
We should also manage errors due to permissions problems on the device file, or at least give some info in the docs about how to allow HA to grab control over an system input file.
I'm sorry if my coding isn't up to some standard practice I'm not aware of: I'm new to HA and to python itself, I'm just trying to be of help.
Gianluca
* Update keyboard_remote.py
I changed some other few things.
Not the component gets loaded even if the keyboard is disconnected. When it connects, it starts to fire events when keys are pressed.
I also added a sleep(0.1) that reduces a lot the load on the CPU, but without many consequences on key pressed detection.
Ville Skyttä
glenn20
BryanJacobs
Daniel Schaal
Fabian Affolter
Gianluca Barbaro
deisi