IR Remote: an App with ready-made codes in per-device menus #15

Open
opened 2026-10-05 11:52:42 +00:00 by twisla · 0 comments
Owner

Idea

An infrared remote App:

  • Pick a device (the living-room TV, the projector, the air conditioner, the hi-fi), and you get a menu of its buttons: power, volume, input, channel and so on.
  • Press one, and the Cardputer sends the code from its IR LED.
  • The codes are pre-recorded files on the SD card, one per device, grouped by kind, so adding a device means copying a file.

(A consumer IR remote, like a TV's, not IrDA, the infrared data protocol.)

Why

  • One remote for everything in your pocket.
  • It replaces a lost remote, controls a hotel TV, or turns off a projector whose remote walked away.

What's known

  • Hardware.
    • The original Cardputer's IR LED is on GPIO 44. To be confirmed on the ADV, and checked against the Cap LoRa-1262's pins. It isn't in src/platform/pins.h yet, and nothing in the firmware uses IR.
    • There's no receiver, so it can't learn codes on its own.
    • Range is a few metres with a single LED. Aim matters.
  • Sending.
    • The ESP32-S3's RMT peripheral generates IR timings with a 38 kHz carrier (or 36 and 40 kHz) in hardware, with no CPU work during transmission.
    • Library options:
      • IRremoteESP8266: knows dozens of protocols (NEC, RC5, RC6, Sony SIRC, Samsung, the air-conditioner protocols…). LGPL-2.1, compatible with GPL-3.0.
      • Encode the common protocols ourselves and send raw timings for everything else. That's a smaller flash footprint.
  • The code library format.
    • Flipper Zero's .ir files are the best fit: plain text, one file per device, named buttons, each either a parsed protocol (NEC, address, command) or raw timings.
    • There's a large community collection (Flipper-IRDB) with thousands of devices. Its licence needs checking before we ship or recommend copying it.
    • LIRC's database is the other big source, in a different format.
    • Parsing .ir files is pure text work that can be host-tested.
  • Menus from files.
    • /ir/<kind>/<brand> <model>.ir (for example /ir/tv/Samsung UE40.ir) becomes a list of kinds, then devices, then buttons.
    • Common button names (Power, Vol_up, Ch_next) map to a tidy layout and to keyboard shortcuts.
    • A Favourites list sits at the top, for the devices you actually own.
  • Air conditioners send their whole state (mode, temperature, fan) in every code. A button list fits them poorly, so they may need their own screen later.
  • Learning codes. M5Stack's IR Unit (Grove, with send and receive) could add a receiver. Out of scope for a first version, but the file format should allow saving learned codes later.
  • Other integrations:
    • Lua Apps (#13) could get an ir.send(), for macros like "TV on, input HDMI 2, volume 20".
    • The Launcher grid (#9) gets a remote icon.

Questions for the design round

  1. Which code format: Flipper .ir, LIRC, or our own with an importer?
  2. Which library: IRremoteESP8266, or our own encoders for NEC, RC5, RC6, Sony and Samsung plus raw timings?
  3. Should the App ship with a starter set of codes on the card, depending on the licence, or does the user copy them in?
  4. Layout per device: a plain list of buttons, or a remote-like grid for common buttons (power, volume, channel, arrows, OK), with the keyboard mapped to them?
  5. Macros: sequences of codes with delays ("Movie night"), defined in a file?
  6. Should it support "universal remote" mode for a kind (try every TV power code in turn), as Flipper does? Useful for unknown devices, but slow.
  7. Should there be support for learning codes with an external receiver (Grove IR Unit), now or later?
  8. Air conditioners: a dedicated screen, or leave them out of the first version?

Related

src/platform/pins.h (add the IR pin), #9 (Launcher), #13 (Lua ir module), #3 (Files: opening .ir files).

## Idea An infrared remote App: - Pick a device (the living-room TV, the projector, the air conditioner, the hi-fi), and you get a menu of its buttons: power, volume, input, channel and so on. - Press one, and the Cardputer sends the code from its IR LED. - The codes are pre-recorded files on the SD card, one per device, grouped by kind, so adding a device means copying a file. (A consumer IR remote, like a TV's, not IrDA, the infrared data protocol.) ## Why - One remote for everything in your pocket. - It replaces a lost remote, controls a hotel TV, or turns off a projector whose remote walked away. ## What's known - **Hardware.** - The original Cardputer's IR LED is on GPIO 44. To be confirmed on the ADV, and checked against the Cap LoRa-1262's pins. It isn't in `src/platform/pins.h` yet, and nothing in the firmware uses IR. - There's no receiver, so it can't learn codes on its own. - Range is a few metres with a single LED. Aim matters. - **Sending.** - The ESP32-S3's RMT peripheral generates IR timings with a 38 kHz carrier (or 36 and 40 kHz) in hardware, with no CPU work during transmission. - Library options: - IRremoteESP8266: knows dozens of protocols (NEC, RC5, RC6, Sony SIRC, Samsung, the air-conditioner protocols…). LGPL-2.1, compatible with GPL-3.0. - Encode the common protocols ourselves and send raw timings for everything else. That's a smaller flash footprint. - **The code library format.** - Flipper Zero's `.ir` files are the best fit: plain text, one file per device, named buttons, each either a parsed protocol (`NEC`, address, command) or raw timings. - There's a large community collection (Flipper-IRDB) with thousands of devices. Its licence needs checking before we ship or recommend copying it. - LIRC's database is the other big source, in a different format. - Parsing `.ir` files is pure text work that can be host-tested. - **Menus from files.** - `/ir/<kind>/<brand> <model>.ir` (for example `/ir/tv/Samsung UE40.ir`) becomes a list of kinds, then devices, then buttons. - Common button names (`Power`, `Vol_up`, `Ch_next`) map to a tidy layout and to keyboard shortcuts. - A Favourites list sits at the top, for the devices you actually own. - **Air conditioners** send their whole state (mode, temperature, fan) in every code. A button list fits them poorly, so they may need their own screen later. - **Learning codes.** M5Stack's IR Unit (Grove, with send and receive) could add a receiver. Out of scope for a first version, but the file format should allow saving learned codes later. - **Other integrations:** - Lua Apps (#13) could get an `ir.send()`, for macros like "TV on, input HDMI 2, volume 20". - The Launcher grid (#9) gets a remote icon. ## Questions for the design round 1. Which code format: Flipper `.ir`, LIRC, or our own with an importer? 2. Which library: IRremoteESP8266, or our own encoders for NEC, RC5, RC6, Sony and Samsung plus raw timings? 3. Should the App ship with a starter set of codes on the card, depending on the licence, or does the user copy them in? 4. Layout per device: a plain list of buttons, or a remote-like grid for common buttons (power, volume, channel, arrows, OK), with the keyboard mapped to them? 5. Macros: sequences of codes with delays ("Movie night"), defined in a file? 6. Should it support "universal remote" mode for a kind (try every TV power code in turn), as Flipper does? Useful for unknown devices, but slow. 7. Should there be support for learning codes with an external receiver (Grove IR Unit), now or later? 8. Air conditioners: a dedicated screen, or leave them out of the first version? ## Related `src/platform/pins.h` (add the IR pin), #9 (Launcher), #13 (Lua `ir` module), #3 (Files: opening `.ir` files).
twisla added this to the H1 On-board hardware milestone 2026-10-05 20:14:10 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: twisla/roro9stack#15