Codes belong to remotes
There is no registry of infrared codes and no standard that says which number means volume up. The number you wrote down belongs to the remote that sent it, and a project built on it is built on that one piece of plastic.
What is standard and what is not
Two things are close to universal: a carrier near 38 kHz, and a header followed by bits coded in the lengths of marks and spaces. That is why one receiver hears almost every remote in the house. Everything above that is a maker's choice: how many bits, in what order, with what timing, meaning what.
sendNEC(address, command, repeats). Same carrier as the TK15 is tuned to, so this one is heard at full range.The carrier is a choice too
Sony uses 40 kHz and Philips 36; the TK15 is tuned to 38. It still hears them, because its response falls off gradually rather than stopping, but with less sensitivity and so less range. A Sony remote that works from the sofa may only work from the desk with this board, and nothing is broken.
Addresses and commands are not names
The library gives you an address and a command. The address names a
kind of device, and plain NEC has only 256 of them, so unrelated remotes share
addresses. The command names a key within that address: 0x16 is not "OK",
it is whatever key one maker wired to 22.
So if (command == 0x16) works with one remote. A second, identical-looking
remote from another batch may send something else, and there is no fix for
that: the protocol has no namespace.
What to do about it
Record, never guess. The key-code sketch is the only source of truth. Put the numbers in a comment at the top of your sketch, with the name of the remote they came from.
Match on the command when one remote is all that will ever point at the board. Keep a table when several should work.
Replay what will not decode. When the library says UNKNOWN, it still has
the exact marks and spaces it captured, and IrSender.sendRaw() plays them
back. In MicroPython, micropython_ir's ir_rx.acquire does the capturing.
The receiver at the far end only measures times, so it cannot tell.
When it does not work
Expected. Run the key-code sketch against the other remote and write its numbers down too. To accept both, keep a small table of address-and-command pairs, or match on the command alone and ignore the address.
IRremote carries about twenty decoders and names them all. Denon, JVC, LG, Kaseikyo and others share the 38 kHz carrier and differ only in timing, so a match is a real result, and the matching sendXxx function sends it back.
Air conditioners send their whole state, mode, temperature, fan and timer, in a hundred bits or more, with no shared standard. Capture the raw timings for each setting you want and replay those; nothing has to be decoded.
No. An app that controls a television does it over Wi-Fi or through its own infrared blaster, and the codes live inside the app or on a server. The receiver and the original remote are the way to get them.
A sketch that turns two buttons into a light switch and a dimmer, and why held buttons need deciding.
One button, one job →Edit this page — content/books/ir-receiver/codes-belong-to-remotes.mdx
Questions about this product
See what other owners have asked, and read their solutions.
This page covers several products. Choose yours to see the right discussions.
Discuss this article
Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.