Adapted from the original OpenSourceSDRLab store blog. Original source: https://opensourcesdrlab.com/blog/detail/flipper-zero-and-now-infrared-over-cli

The most useful way to approach Flipper Zero infrared features is to drop the "magic gadget" mindset.

Flipper Zero is not a universal opener for doors, gates, or cars. What it does offer is a practical way to learn how an infrared-controlled system behaves, how a protocol is structured, and where the limits are. That is the difference between a toy workflow and a professional workflow.

If a system cannot be opened casually with a low-cost handheld device, that is often a sign that the system is doing its job. Understanding that early saves time and leads to better testing habits.

Start with the protocol, not with hype

Before sending anything, answer three basic questions:

  1. Is the target actually using infrared?
  2. Which protocol family does it appear to use?
  3. Do you need to capture a real remote, search a database, or test commands manually?

That small amount of protocol awareness makes the rest of the process much easier. It also makes it obvious when a target is simply out of scope for this workflow.

Basic IR constraints

The original article highlights a practical boundary: not every remote that a casual user calls a "remote control" is an infrared target.

  • Typical consumer IR remotes operate with an infrared carrier around 36 kHz to 40 kHz.
  • Some remotes that users assume are IR are actually using radio.
  • If the target is not IR, an IR database will not help.

That sounds simple, but it is the step many people skip.

Why IR databases matter

A good IR database turns guesswork into a structured search process. If the original remote is missing, damaged, or hard to identify, a community-maintained database is often the fastest starting point.

Useful Flipper-compatible IR repositories include:

They overlap heavily, and updates tend to propagate across the forks over time. In practice, that means you can search all three, compare file coverage, and then test on hardware you own or are authorized to manage.

For many everyday devices, that is enough. There is no magic involved, just a database, a protocol family, and careful testing.

A concrete example: Dualtron lighting

The original post used a Dualtron lighting remote as an example. Searching the IR database for dualtron leads to a file such as Dualtron_Victor_Handlebar_Lights.ir.

That file exposes a useful starting point:

name: POWER
type: parsed
protocol: NEC
address: 00 00 00 00
command: 07 00 00 00

This gives you the two most important clues immediately:

  • Protocol: NEC
  • Address: 00

That matters because NEC is a well-known format. It uses an address field and a command field, with inverse values included for error checking. Once you know one valid command exists, you can reason about nearby command values instead of probing blindly.

Why the CLI workflow is still valuable

A command-line workflow forces clarity. You are no longer treating the remote file as a black box; you are reasoning about:

  • the protocol family
  • the address space
  • the command space
  • the cost of iterating through possible values

For an 8-bit command field, the search space is manageable. A simple test loop can step through candidate commands while you watch the hardware response under controlled conditions.

#!/bin/bash
for command in {0..255}; do
  hexcmd=$(printf "%02X" "$command")
  echo "Sending ir tx NEC 00 $hexcmd to /dev/ttyACM0"
  printf "ir tx NEC 00 %s\r\n" "$hexcmd" >> /dev/ttyACM0
  sleep 5
done

That script does five useful things:

  1. iterates from 0 to 255
  2. converts the loop counter into a two-digit hexadecimal command value
  3. prints the active command so you know what is being tested
  4. sends the command to the Flipper serial device
  5. pauses between attempts so the test remains observable and controllable

Understand the search space before you start

This is where protocol knowledge saves real time.

If the command field is only 8 bits wide, there are 256 possible values. Even with a short delay between attempts, that is a practical experiment. If the command field is 16 bits wide, the search space grows to 65,536 values. That stops being a quick test and starts becoming an impractical brute-force exercise.

When a protocol becomes too large for manual observation, the right answer is often not "keep going." The right answer is to change strategy:

  • find better documentation
  • capture a real remote
  • narrow the command family
  • stop when the remaining search space is unreasonable

That is the real lesson from the original article.

Final takeaway

Flipper Zero infrared workflows are strongest when they are grounded in protocol literacy, realistic expectations, and repeatable testing.

The better you understand how a target system communicates, the faster you can decide whether:

  • a database lookup is enough
  • a manual test loop is justified
  • or the current path is simply the wrong tool for the job

That is a much better story than "press a button and hope."