This is a submission for the GitHub Finish-Up-A-Thon Challenge
What I Built
So what is this? Doesn't look like an API 👁️👁️
Tossed The TV Kept the Remote (TTVKTR) is a simple solution to the common problem of ending up with leftover Infrared(IR) Remotes from appliances long after the appliances are gone. They should be trivially easy to use with whatever you want, instead of ending up in landfills.
After finding an old Apple TV Remote in the archives (my attic) i realized there wasn't any quick and easy way to let me use it on my HTPC.
Now you see where the name came from...
This isn't as niche a problem as I've made it sound though, those "presentation clickers" that you can buy for waaay too much money online are the same thing. Except you've just added one more "thing that turns into e-waste the moment you lose the dongle" to your collection.
So, armed with a copilot subscription, I had to take things into my own hands.....
A browser-based editor for assigning remote buttons to keys, media controls, or custom actions.
One physical remote can switch between several layers, so the same buttons do different things in different modes.
Layer-aware customizable RGB lighting that changes color per mode, giving clear visual feedback.
Support for multi-step or chorded inputs, including modifier combinations, repeated presses, and chained actions.
Demo
You can even bind a button to:
Win+R -> Spotify.exe -> Enter
To open Spotify using any IR remote you having lying around the house.
Table of Contents
- So what is this?
- Demo
- How?
- It's been done before right?
- Eh.. I'll do it later (The Before)
- But after I threw a bit of Github Copilot sauce at it....(The After)
How?
The TTVKTR uses a Raspberry Pi Pico (RP2040) and an IR receiver to read the codes sent by almost any commercial IR remote and maps them to USB Human Interface Device (HID) commands like Vol + , Play/Pause, or even custom combos.
The PlatformIO VSCode extension allows seamless integration with AI agents like Github Copilot to make firmware development as easy as the web stuff (sometimes).
The Raspberry Pi Pico communicates with the WebApp over WebSerial, a Chromium exclusive feature that enables websites to communicate with hardware directly.
The Raspberry Pi Pico uses the RP2040 a nifty MCU that has native USB support for dirt-cheap.
Almost all appliance remotes use an infrared LED to transmit encoded values that act as the "codes" for the receiver.
Now I can flash any number of devices ONCE and program them in seconds for every remote I find around the house. Making combos is easy and each remote can have "Layers" indicated by the RGB LED on the RP2040 itself.
I also get a quick drag-to-edit layout that I can use to have a better visual representation of the button on the remote I'm actually trying to map.
It's been done before right? Right????
I was surprised that this didn't exist already. An IR remote reader is one of the things any hobbyist tests out when they first get started.
There have been attempts like this one by wagiminator and Adafruit's pIRkey but they both need you to weave in and out of code just to paste in a string, and any complex behaviors are up to you. I wanted a way to quickly map the remote buttons to keys and combos like VIA based keyboards, AFAIK this is the only solution that removes that last bit of friction.
So some time ago, I pulled an XKCD 927 and built another less-code-but-not-really solution, and called it a day. Drop in a JSON with the IR codes and you're good to go. Then I got caught up with a different project and you know how it goes....
Then I saw the Github Finish-Up-A-Thon post and it reminded me of someone who has many incomplete weekends projects that could be complete if they just put in a few more hours, so here I am.
The Comeback Story
Eh.. I'll do it later (The Before)
Let's just say once I got the bare minimum working, I got.... distracted.
The repository existed, I could use my Apple Remote and that was about it. The settings were simply a json file you dropped onto the Raspberry Pi Pico's storage partition. That's not bad but it also requires some manual legwork that doesn't make it any better than the solutions I pointed out before.
This is how editing the buttons looked like before (not very pretty)
{
"ir": {
"modeChangeCode": "0xC40387EE",
"receivePin": 1,
"handleRepeat": true,
"repeatInitialDelayReports": 5
},
"led": {
"pin": 16,
"keyboardModeColor": "0x290118",
"consumerModeColor": "0x012329",
"brightnessPercent": 10
},
"modes": [
{
"name": "Layer 1",
"slots": [
{"irCode": "0xC40A87EE", "type": "keyboard", "key": "0x61"},
{"irCode": "0xC40C87EE", "type": "keyboard", "key": "0x62"},
{"irCode": "0xC40987EE", "type": "consumer", "key": "0x00B5"}
]
},
{
"name": "Layer 2",
"slots": [
{"irCode": "0xC40687EE", "type": "consumer", "key": "0x00B6"},
{"irCode": "0xC45C87EE", "type": "keyboard", "key": " "}
]
}
]
}
The firmware was there, but it was very much a proof-of-concept.
My Experience with GitHub Copilot
But after I threw a bit of Github Copilot sauce at it.... (The After)
Before
After
Instead of having to record the codes in the serial console and copy them over manually, just click "learn" and press the button on the IR remote.
The old version required you to still flash the Raspberry Pi for the smallest of changes like layer colors, now you can see those changes reflected live.
Layouts and Layers simplify the "what was this again?" that happened when you looked at the json by itself. Now you can spot a distinct IR remote simply by its button layout.
Complex commands like the spotify opener script simply weren't a thing before, now you can bind an IR button to whatever you want.
I don't like working with UI. Just never been a "gotta center this div with my own two hands" kinda guy. Github Copilot let me get the UI stuff done without me having to do any div-centering. A few choice prompts about how I wanted the app to look, what it did and how the protocol should work and I had a functional GUI up and running.
"Add a freely editable button layout where I can drag around the IR code buttons and persist them on the device as relative positions. Layouts are GUI helpers and do not interact with the layer:code mappings so they do not need to be parsed, store them as a web-serial serializable representation".
This is what editing buttons looked like a few prompts later
Adding features, sliders and toggles in the UI was equally simple, some of the firmware functions were also just as trivial and refactoring was a breeze.
Top comments (0)