I’m one of those folks living on borrowed time with my Harmony Hub Remote, and I’ve been looking for awhile for something to replace it. After trying a couple of vended hardware solutions, I finally gave up and decided to do something to use the little RF remote that came with my Vero 4k+. It’s one of those remotes that pairs with a USB key and is basically just a HID keyboard.
My final solution uses an Adafruit RP2040 USB Host Feather with an Airlift Featherwing (for WiFi) to grab the keypress code from the remote, figure out if it’s a short or long press, and then send that via MQTT to a sensor in HA. The code and physical build instructions are available here:
I also did a version of this to run on a Raspberry Pi. I actually did this one first but didn’t like it as much (it depends on a Python module that isn’t really being maintained anymore). It’s easier to setup than the RP2040 version though:
This is similar in concept to the project mentioned here, although mine does all the short/long press logic in the script rather than HA:
That requires you to have access to a USB port on the device on which you are running HA. I’m running it on a Synology NAS in Docker, and it requires hacky things to get a driver running that will allow you to pass the USB device to the Docker container. Also, my NAS is nowhere near where I need the remote. As in I doubt even the RF signal from the remote would make it to the key.
Every time I thought about adding it that way, I kept finding posts talking about how you needed to do a bunch of stuff to load a driver on the Synology. I’m now realizing those posts were talking about adding Zwave/Zigbee sticks. I went ahead and gave your suggestion a whirl (plus the other things that were mentioned in the documentation for the keyboard remote integration, and I was able to see my dongle. A quick test shows my NAS is actually in range for the remote, so I took another look at things.
It took awhile for me to realize that my remote is reporting on two different events, but I did manage to get something working. And I found another post that helped me setup a binary sensor for key press/release that made it easy to integrate into the HA work I’d already done (including figuring out short/long press). If I had a second remote for another room the keyboard remote integration might not be an option (unless I add a USB hub to the NAS), but that’s a problem to solve the day I actually have two TVs in the house.
Anyway, I added this option to the docs on the Ardunio code I wrote:
You might have noticed, in the post of mine that I linked above, that I went the extra mile to mimic the Harmony “activities” concept with a (rough) custom component of mine.
Have you or @koying had any problems with some buttons not being recognized? I have that Airmouse remote and media controls don’t appear to be recognized when I connect the USB dongle directly to my PI4 running Home Assistant. When I have it connected to a dedicated raspberry PI most of the keys are recognized just fine. I send them to HA with a webhook but I wanted to remove the extra dedicated raspberry PI from the equation if possible to hopefully get a better experience.
keyboard_remote:
device_descriptor: “/dev/input/event0” # 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
device_descriptor: “/dev/input/event1” # 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
device_descriptor: “/dev/input/event2” # 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
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
I’m probably using the same remote you are (MX3 Air Mouse). For me, /dev/input/by-id/usb-4037_2.4G_Composite_Devic-event-kbd is for the normal keys and /dev/input/by-id/usb-4037_2.4G_Composite_Devic-event-if01 is for the media keys. There are two other inputs for mouse related functionality that I don’t use.
Thanks, in theory the way I did it should have worked based on my interpretation of the docs. In practice your way works much better though. My remote is supposed to have a microphone. It would be extremely cool if we can get that working with assist one day.
I’m using a button sequence to set what “virtual mode” my remote is in. I designated a button on the front of the remote as a shift key. If I hit shift then press the up key on the remote I’m in “TV” mode. UP + Left = Light mode. Shift + Right is media mode. The remotes virtual mode is saved in a helper on my system an announced by a media player when switched. I printed small labels to show my advanced features such as buttons 1-3 are favorite playlists for people in my home when the remote is in media mode. In light mode the volume button can turn lights up and down.
I also managed to find undocumented IR codes for my Fire TV so the IR buttons map directly to my favorite TV services. This remote is pretty cool when paired to Home Assistant.
EDIT: The dang thing was working great and the same keys stopped working again even though i didn’t change anything. It also assigns key_id: 240 to random keys at random times.
EDIT2: Mine is an MX3 with microphone and it strangely shows this exact device id twice. I even used a string comparator to double check. /dev/input/by-id/usb-2.4G_Composite_Device_MIC-Wireless_Device-event-if03
I’m going to try the MX3 version of this remote that doesn’t have a microphone to see if it’s more reliable.
