BK7231N IR raw code capture issue on firmware 1.18.110 – missing debug commands, empty MQTT data

User question

I'm still struggling to get some raw IR codes.
The bk7231N device GPIOs are correctly configured as it receives some IR information.
Built on Jun 4 2025 10:35:45 version 1.18.110 but not a nightly or alpha.
commands like set IrDbg 1 do not work. nor does set system.ir.debug 2 of set system.ir.rawdata 1. They just return this error:
Info:CMD:[WebApp Cmd 'set IrDbg 1' Result] Unknown command

The device receives the IR remote but only says this:
Debug:IR:IR decode returned true, protocol 1
Debug:IR: Raw-Data=0x0
Debug:IR: 48 bits
Debug:IR: LSB first
Debug:IR:IR decode returned true, protocol PulseDistance (1)
Info:IR:IR MQTT publish IR_PulseDistance 0xD21 0xD0A 0 (48 bits) took 4ms
Debug:IR:IR fire event took 0ms

I've enabled some flags 14, 15, 22 to print raw IR, including to MQTT.
But on MQTT I also get empty IR raw data, like this:
{"IrReceived":{"Protocol":"PulseDistance","Bits":48,"Data":"0x0"}}
{"IrReceived":{"Protocol":"UNKNOWN","Bits":0,"Data":"0x0"}}

Does this build not include the correct IR drivers? I see in the code repository there are three different IR drivers, drv_ir.cpp, drv_ir2.cpp and drv_ir_new.cpp.
Or is the remote code possibly so long that it doesn't fit in the buffers? Should I build it myself, with different parameters, or is there a known good build that supports IR better?

Artificial Intelligence Response

Direct answer to the question

• Your device is receiving IR (the logs prove the ISR and decoder are running), but the firmware you flashed was built without the IR “raw capture / debug” command handlers. That’s why set IrDbg 1 and the system.ir.* commands return “Unknown command”, and why MQTT shows Data:"0x0" even though a PulseDistance frame was seen.
• 48-bit is not “too long” by itself; empty (0x0) payloads typically mean the build didn’t publish raw timings and/or the decoder couldn’t form a valid data word from the capture. Very long AC-style frames can overflow default buffers, but that produces truncation rather than a clean 0x0 in most stacks.
• Fix: update to a current OpenBeken build and enable the IR driver with raw timing output; if you still need longer frames, build with a larger raw buffer. As of Nov 25, 2025 the latest release is 1.18.219 and includes BK7231N binaries. (github.com)

Key points

• “Unknown command” means those command handlers weren’t compiled into that binary, not that your pins are wrong.
• Your log’s “PulseDistance (1)” with Data=0 hints a fallback decode without a usable data word.
• For AC remotes or long frames, increase the raw capture buffer if you self-compile.
• Disable power save while learning IR (PowerSave 0), or you may miss short bursts. (elektroda.com)

Detailed problem analysis

• What the log shows

  • IR decode returned true, protocol PulseDistance (1): The receiver GPIO is correct; the edge-capture ISR filled a timing buffer; a generic pulse-distance decoder matched the waveform family. The “48 bits, LSB first” lines are a decoder’s interpretation, not proof a 48‑bit value was successfully assembled.
  • Raw-Data=0x0 and MQTT Data:"0x0": In your build, only the “decoded” field is published. With the raw/timing publisher disabled, the JSON lacks the raw timing array, so when the high-level decode fails to form a value you see 0x0.

• Why your commands are “Unknown”

  • OpenBeken ships multiple features behind compile-time switches to keep binaries small. If the IR debug component isn’t linked, CLI handlers like IrDbg or system.ir.rawdata are absent and the shell returns Unknown command. That’s consistent with a “minimal” release build. The current releases page shows one BK7231N binary per tag; there is no separate “_IR” flavor listed at the moment, so you must either use a release where IR debug is included by default or self-compile with IR debug/raw enabled. (github.com)

• Drivers and buffers

  • The repository carries several IR implementations and evolution over time; current builds typically use the newer receive path capable of raw capture and protocol decoding. When dealing with AC remotes, the raw timing sequence can be a few hundred marks/spaces. That exceeds many default buffers in common IR libraries unless configured larger. IRremoteESP8266’s own troubleshooting notes suggest raising the receive buffer to 512 (or more) for AC codes—useful guidance for any IR stack. (github.com)
  • Practical implication: if your target remote is an A/C or a fan with long state frames, increase OpenBeken’s raw-capture buffer at build time; otherwise, some decoders will either fail to produce a value or publish truncated data.

• Non-firmware contributors to “0x0”

  • Power save: CPU throttling can drop edges; disable during learning (PowerSave 0). (elektroda.com)
  • Hardware: ensure you use a demodulating 38 kHz receiver (e.g., TSOP/VS1838 class), not a bare photodiode; check orientation and supply decoupling. Community how‑tos for assigning IRRecv/IRSend roles confirm typical pin use and that a reboot is sometimes needed after role changes. (elektroda.com)

Current information and trends

• Latest stable builds: As of Nov 25, 2025, OpenBeken release 1.18.219 is the newest tag with BK7231N assets (QIO/UG/RBL). If you’re on 1.18.110 from June 2025, you’re several releases behind; update first and retest before self‑compiling. (github.com)
• Raw MQTT payloads and long frames: Tasmota solved payload bloat via compact raw encodings; similar strategies (or larger buffers) are typically needed to carry long AC frames reliably over MQTT in any firmware. (tasmota.github.io)
• IR libraries continue to emphasize bigger receive buffers and “trust the raw data” guidance for long/unknown protocols—helpful if you decide to build OpenBeken with extended capture. (github.com)

Supporting explanations and details

• How “0x0” happens with a working receiver
  • Think of the stack as two stages: (1) time-stamped marks/spaces (raw capture), (2) protocol‑specific decode that tries to interpret those timings into a value. Your build seems to run stage (2) but doesn’t expose stage (1) over the console/MQTT. If the decoder can’t map the capture to a known format or the capture is partial, the “value” is 0x0.
• Why RAW matters in your situation
  • For unknown protocols or ACs, raw timings let you: (a) confirm full capture (no truncation), (b) replay via IRSendRaw to validate transmit, and (c) share captures to add/extend protocol support later. IRremoteESP8266 documents that AC protocols regularly exceed default raw buffers, hence the recommendation to enlarge them during troubleshooting. (github.com)

Ethical and legal aspects

• Reproducing your own remote’s IR signals for personal use is generally lawful in the U.S. Use reasonable IR LED drive currents and observe eye‑safety guidance; excessive IR output can be hazardous. Always follow product safety norms for LED/laser emission.

Practical guidelines

• Before you rebuild

  1. Update to latest stable and retest
     • Flash OpenBK7231N_…_1.18.219 (matching your flash method: QIO/UG/RBL). After reboot:
     • Verify your pin roles: one pin = IRRecv, optionally another = IRSend. (github.com)
     • Disable power save during learning: PowerSave 0. (elektroda.com)
     • Increase log verbosity; then point a known TV remote (NEC/Samsung) at the sensor to confirm a non‑zero decode appears. If those decode but your target remote still yields 0x0, you’re likely facing a long/unknown protocol.
  2. Check which IR commands exist in your build
     • In the web console, try help Ir or cmdlist. If IrDbg and system.ir.rawdata exist, enable them; if they don’t, your binary lacks the debug/raw publisher and you’ll need a different build (or to self‑compile).
  3. MQTT payload size
     • If raw timings appear but your broker/client truncates them, consider using a broker/topic that permits larger payloads or a compact encoding (concept similar to Tasmota’s raw compact). (tasmota.github.io)

• If you need to self‑compile

  • Enable the IR receive driver with raw timing capture and increase the raw buffer (e.g., from ~128 entries to 512–1024 entries) to accommodate AC‑class messages. The principle mirrors IRremoteESP8266’s recommendation to raise buffer sizes for AC protocols. (github.com)
  • Build, flash, verify that raw arrays (positive/negative microsecond durations) now print in console and/or MQTT.

• Validation workflow after you see RAW

  1. Capture: Press a single key; confirm a complete Raw array (~200–700 timings for many ACs).
  2. Replay: Use IRSendRaw with the captured array; confirm the target reacts.
  3. Optimize: If replay is flaky, confirm correct carrier (typically 38 kHz) and drive current; add a transistor stage for the IR LED if needed.

Possible disclaimers or additional notes

• Release notes do not currently list a separate “IR-flavored” BK7231N artifact; capabilities can vary by tag. If your updated release still lacks IrDbg/system.ir.* handlers, self‑compiling is the dependable path to get raw capture.
• Some remotes use multi‑frame or stateful protocols; a single press can send multiple bursts. You may need to capture the entire sequence to replay faithfully. IRremoteESP8266 docs highlight this behavior and recommend trusting raw captures while diagnosing. (github.com)

Suggestions for further research

• Track OpenBeken releases and issues for IR receive/send notes and command coverage; latest tag with BK7231N assets is 1.18.219. (github.com)
• If you plan to add protocol support, the IRremoteESP8266 wiki has excellent guidance on capturing and analyzing long/AC protocols; the same analysis strategies apply if you’re extending OpenBeken’s decoders. (github.com)
• Hardware references and community examples of IRRecv/IRSend role assignment and pinouts are collected in teardown/how‑to threads. (elektroda.com)

Brief summary

• Your BK7231N is wired correctly; your logs show active IR receive. The problem is the build: it lacks IR raw/debug command handlers, so you see Unknown command and 0x0 payloads.
• Update to a current release first; if the build still lacks raw capture, compile with IR raw enabled and a larger buffer. Disable power save while learning and validate with a simple, short-protocol remote; for AC‑class frames, increasing the buffer is often essential. (github.com)

If you want, I can walk you through a minimal self‑build that turns on raw capture and sets a 1024‑entry timing buffer, and then help verify the signal path with a short known remote before moving to your target remote.

Disclaimer: The responses provided by artificial intelligence (language model) may be inaccurate and misleading. Elektroda is not responsible for the accuracy, reliability, or completeness of the presented information. All responses should be verified by the user.