Flipper-IRDB: the community IR database for the Flipper Zero

What Flipper-IRDB actually is, and who it is for

Flipper-IRDB is a repository of infrared remote definitions, not a program you run. The README describes it as "a maintained collective of different IR files for the Flipper Zero". Each file is a plain-text .ir file containing named buttons and their recorded IR signals. The repository is organised as a set of top-level directories named after device types: ACs, TVs, SoundBars, Projectors, LED_Lighting, Fans, Heaters, Consoles, Cameras, Cable_Boxes, Streaming_Devices, Vacuum_Cleaners, and roughly forty more, plus a Universal_TV_Remotes folder and a _Converted_ folder.

The audience is narrow and specific. You need a Flipper Zero, and you need a device whose remote you have lost, broken, or never had. Someone who wants to turn on an old Dynex TV, an air conditioner from a rented flat, or a projector in a meeting room is the target user. Someone who wants to build an IR blaster on a Raspberry Pi is not: nothing here runs on a host computer, and the files are consumed by Flipper firmware.

The README also notes that maintainers, mostly amec0e, add individual entries to the Universal Remotes shipped in unleashed-firmware, which other firmware projects then adapt. So the repository feeds firmware-level features as well as individual users. That two-way relationship is the reason the naming conventions matter more here than in a typical file dump.

How the database is organised and how the files reach the Flipper

The data flow is deliberately simple. A contributor records signals on a Flipper, saves an .ir file, and places it in the directory tree following the pattern `Device Type` > `Device Brand` > `Device Series`. The maintainers ask for the `<brand>_<model>.ir` naming scheme, with capitalised model numbers. The README gives worked examples: `LG_55UN7300AUD.ir` is correct, while `LG_55UN7300AUD.txt` fails on extension, `lg_55un7300aud.ir` fails on capitalisation, and `tv.ir` is too generic.

Button names are also standardised, because the universal remotes are generated from these files. For audio and video devices the table lists names such as `Power`, `Vol_up`, `Vol_dn`, `Mute`, `Play_pause`, `Ok`, `Ch_next` and `Sleep`. Air conditioners use a different set: `Off`, `Cool_hi`, `Cool_lo`, `Heat_hi`, `Heat_lo`, `Dh`. LED lighting uses `Power_off`, `Power_on`, `Brightness_up`, `Brightness_dn` and colour names like `Red` and `Green`. A file that ignores the table may still work on your own Flipper, but it will not be picked up cleanly by the universal remote tooling.

The repository includes a `.fff-ir-lint.json` file at the top level, which indicates that some form of linting configuration exists for .ir files. The README does not document what the linter checks or how to run it, so treat that file as a signal that conventions are enforced somewhere in CI rather than as a documented tool.

There is no index, no manifest, and no search interface in the repository itself. Discovery means browsing directories on GitHub or in a local clone. For a collection of this size, that is the weakest part of the design.

Installing Flipper-IRDB and loading your first remote

There is nothing to compile. Installation means getting .ir files onto the Flipper's SD card. The README describes three methods and is explicit about which one to prefer: copying files directly to the SD card is called "the fastest and safest method", while QFlipper transfers "can take a long time" because of Flipper limitations. If you want the whole database on the device, the README strongly recommends the direct SD card route.

Start by cloning the repository, or download and extract the main branch archive.

git clone https://github.com/Lucaslhm/Flipper-IRDB.git

For the direct method, dismount the SD card from the Flipper, mount it on your computer, and copy the files you want into the `infrared/` folder on the card. Copy selectively rather than everything: the repository spans dozens of device-type directories, and you only need the brands you own. The README does not give a copy command, so use your file manager or your own shell command for the transfer.

If you prefer not to remove the card, connect the Flipper over USB-C, open QFlipper, confirm the status shows "Connected", and update the firmware before continuing. Then open the File Manager, select `SD Card`, navigate into the `infrared` folder, and drag the .ir files across. The third route uses the Flipper Mobile App: copy the .ir file to your phone, open the app, go to Connected > Options and enable Experimental Options, then use the File Manager under `ext > infrared` to upload the file.

Once the file is on the device, the README says the remote appears under Infrared > Saved Remotes on the Flipper Zero. Open it, pick a button such as `Power`, and point the Flipper at the device. If nothing happens, the file is probably for a different model in the same product line, which is the most common failure with this kind of collection.

The coverage problem: a database is only as good as its contributors

The central limitation is coverage. Flipper-IRDB contains what people have recorded and submitted. A device that nobody has contributed is simply absent, and no amount of configuration will fix that. The README acknowledges the gap indirectly by pointing readers at a manual route: it notes that IR files are plain text and links to an external guide for making a remote by hand.

The naming scheme creates a second, subtler problem. Model numbers matter. An IR file for one LG TV model often works on others in the same series, but that is a property of the underlying protocol, not a guarantee the repository makes. The README does not state which files are cross-compatible, and the directory structure groups by brand and series rather than by protocol. You find out by trying.

The third issue is transfer cost. The README warns twice about this: QFlipper transfers take a long time depending on how many files you copy, and the mobile app route is presented as a per-file operation. Loading the entire database onto the Flipper through anything other than a card reader is impractical. This is a constraint of the device, not a defect in the repository, but it shapes how you should use the project.

Finally, button coverage varies per file. The naming table defines an ideal vocabulary, but nothing in the repository layout proves every file implements all of it. A remote with `Power` and `Vol_up` may have no `Sleep`.

Flipper-IRDB compared with the Flipper Zero firmware's own universal remotes

The obvious alternative is not another repository. It is the Universal Remotes already built into Flipper firmware, particularly unleashed-firmware. The difference in approach matters. A universal remote tries to cover many devices with one set of signals, often by cycling through candidate codes until the device responds. Flipper-IRDB is the opposite: one file per device, with named buttons that map to that device's actual remote.

The trade-off is precision against convenience. Universal remotes need no file management and no SD card access, but they can miss buttons and may not cover unusual devices at all. A specific .ir file from Flipper-IRDB gives you the exact button set, including things a universal remote would never include, such as `Brightness_up` on an LED strip or `Dh` on an air conditioner. The two are complementary: the README states that maintainers add entries to the universal remotes from this project, so the universal remotes are partly downstream of the database.

A second alternative is writing the .ir file yourself, which the README explicitly suggests for missing remotes. That is the correct answer when your device is absent, but it requires a working remote to record from, which defeats the purpose if the remote is lost.

Licence, maintenance and what upgrading costs you

The licence is CC0-1.0, which places contributed work in the public domain. The README states this as a condition of submitting: by submitting, you agree to license your work under CC0-1.0. It also carries an important carve-out, quoted directly: commits prior to 2319685 are not covered. That means older files in the repository may have a different provenance than newer ones. If you plan to redistribute the collection or embed it in a product, check the history of the specific files you take rather than assuming the whole tree is CC0. This is a factual boundary in the project's own documentation, not legal advice.

The repository is not archived, and the last push was on 2026-04-12. There are no releases, which is consistent with a project that ships files rather than versioned artifacts. Upgrading means pulling the branch again and re-copying files. There is no version number to pin, no changelog in the repository root, and no documented rollback path if a newly pulled file overwrites one you had customised. The README does not document rollback.

That is the real upgrade cost: because the repository is a moving branch, your local copy and the upstream copy diverge the moment you edit a file or add your own. Keep personal remotes in a separate folder on the SD card from the ones you copy out of the repository, so a refresh does not clobber them.

Contributing back, and why the naming rules are not optional

If you record a remote that is missing, the contribution path is a pull request. The README asks that device names follow `<brand>_<model>.ir` with capitalised model numbers, and that you add context as a comment inside the file: make, model, a link, or a short description. It gives a concrete example of the file header format, showing a comment line naming the device above the first `name: Power` entry.

The button naming table is the part contributors most often skip, and it is the part with downstream consequences. Because the universal remotes are generated from these files, a file using `PowerOn` instead of `Power_on`, or `Volume+` instead of `Vol_up`, will not slot into that pipeline even if it works perfectly on your own device. Following the table costs a few minutes and makes the file useful to everyone else.

There is no documented automated check that will reject a badly named file at submission time. The presence of `.fff-ir-lint.json` suggests some validation exists, but the README does not describe it, so a contributor cannot rely on CI to catch mistakes before review.

Editorial conclusion

Adopt Flipper-IRDB if you own a Flipper Zero, want infrared control of TVs, ACs, projectors or LED lighting, and are willing to copy files rather than install software. Do not adopt it expecting a searchable application, a build step, or coverage of devices nobody has contributed. Before relying on it, check that your exact model appears under the relevant device-type folder, and confirm the CC0-1.0 terms apply to the file you take: the README states that commits before 2319685 are not covered by that licence.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. Lucaslhm/Flipper-IRDB on GitHub
4. README