remote_receiver: automation triggers (on_raw, on_nec, on_lg...) never fire on BK7238 (t1-3s)

[Krazubu]

Problem

On a BK7238 module (board t1-3s), remote_receiver correctly decodes and logs received IR signals via dump:, but the corresponding automation triggers (on_raw, on_nec, on_lg, etc.) never fire.

Configuration

bk72xx:
  board: t1-3s

remote_receiver:
  id: receiver
  pin:
    number: GPIO26
    inverted: true
    mode:
      input: true
      pullup: true
  dump: all
  on_lg:
    - logger.log: "TRIGGER FIRED"

Logs on button press

[I][remote.lg:053]: Received LG: data=0x20DF02FD, nbits=32

No TRIGGER FIRED line ever appears, even though the signal is clearly
decoded.

Why this doesn't look like a config issue

Tested with several different actions inside the trigger (local logger.log, homeassistant.event, mqtt.publish) and several protocols (on_raw, on_lg) — none of them ever fire, including the purely local logger.log action, which rules out a network/API-related cause. Also confirmed via esphome config that the compiled configuration is valid.

Environment

• ESPHome 2026.7.2, LibreTiny v1.13.0
• Board: t1-3s (BK7238)

[Robbe-B]

@Krazubu,
How do you even start flashing this ?
The LT-Chiptool doesn't seem to recognize the UF2 family when compiled via ESPHome.

[Krazubu]

Did the 1st UART backup+flash with lt-chiptool, also used BK7231GUIFlashTool, got no issue with either of the twos, uf2 format was recognised. After that, I did all updates through ESPHome OTA. Maybe your issue is part of the problem. I'm not sure all data / partitions is uploaded. Though some stuff is definitely uploaded, some things seem to not be updated like compile time. Also ESPHome keeps telling the firmware is not synced.

[kuba2k2]

If ltchiptool doesn't recognize the UF2, you can manually flash the "image_app.0x11000.rbl" file (something like that, mind the offset) to 0x11000 using ltchiptool (uncheck the "auto detect" box and manually specify settings: offset 0x11000, leave skip/length empty).

[Krazubu]

After digging the code, I couldn't find an explanation to this issue. Turns out the problem lies in the OTA. The update process goes well, but it seems that the firmware is in fact not updated (or used). After flashing the same fw using UART, everything worked instantly. So this issue can be marked as invalid, but maybe I should create another one, if the problem is not already known.

[Cossid]

Turns out the problem lies in the OTA.
maybe I should create another one, if the problem is not already known.

That means you either used the wrong board (unlikely since you're not using a generic, or you've misidentified it based on shape but not what was originally flashed to it), or you serial flashed OpenBeken prior, which replaced your bootloader, which is already a known issue, but nothing LibreTiny can solve. The only solution is to serial flash the original bootloader, and use the correct board for it.