Flashing and Configuring Micro IR Blaster (Ali 1005006823624599) with BK7231N

Question

Similar to many others, here is a small IR receiver/transmitter courtesy of atc1441 (though the one he posted about looks different). I bought this one in late 2024, seems to be still available for $7 on Ali, 1005006823624599 The whole device is just 38 mm diameter, 15 mm thick. It has a BK7231N...

divadiow · Accepted Answer

any different with the irRemoteESP version?

divadiow · Accepted Answer

from this post onwards - a bit of IR context and current known issues:

bkespoke · Answer

>>21573835
Now I'd like to ask for some help... the remote blaster above is working fine for my TV remote decoding various codes. But for my AC remote it simply doesn't work.
Summary of my frustrating questions in this AI discussion though I think the AI is dreaming up the build v1.18.130 and probably some other things.

I've tried turning on all the IR flags. Commands like set IRdebug 1 are not supported. Roughly the same messages come out on MQTT. All the forum posts on IR are quite old. I would be happy with some sort of RAW capture - I only want to send three commands for the AC (on-cool-lowfan-16C ; on-fan-lowfan ; off)

Is the (raw) buffer too small for this remote? Is there a nightly/alpha build that has the latest IR in it, or can you recommend a modification that I can build, that will receive this remote control?

Thank you!

With v1.18.110 the remote produces codes like this in the log:

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 IR_PulseDistance 0xD20 0xD0A 0 (48 bits)
Debug:IR:IR fire event took 0ms
Debug:IR:IR decode returned true, protocol 0
Debug:IR: Hash=0x0
Debug:IR:0 bits (incl. gap and start) received
Debug:IR:IR decode returned true, protocol UNKNOWN (0)
Info:IR:IR IR_UNKNOWN 0x0 0

My autoexec.bat:

startDriver SSDP
startDriver NTP
startDriver IR

My config:

{
  "vendor": "Tuya",
  "bDetailed": "0",
  "name": "Full Device Name Here",
  "model": "enter short model name here",
  "chip": "BK7231N",
  "board": "TODO",
  "flags": "32768",
  "keywords": [
    "TODO",
    "TODO",
    "TODO"
  ],
  "pins": {
    "7": "IRSend;0",
    "8": "IRRecv;0",
    "24": "WifiLED;0",
    "26": "Btn;0"
  },
  "command": "",
  "image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
  "wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
}

bkespoke · Answer

Thanks - that is quite different.Now I get something on every remote press.Unfortunately the data is different every time:info:ir:ir unknown ffffffff,0xf3963672,172info:ir:ir unknown ffffffff,0x8301fb23,172info:ir:ir unknown ffffffff,0x928f624f,172info:ir:ir unknown ffffffff,0xbeb94b2f,172info:ir:ir unknown ffffffff,0xc21ea93,172info:ir:ir unknown ffffffff,0xa620bed1,172info:ir:ir unknown ffffffff,0xc0311423,172info:ir:ir unknown ffffffff,0xf187fb6b,172info:ir:ir unknown ffffffff,0x981bd6be,172info:ir:ir unknown ffffffff,0x5019b230,172info:ir:ir unknown ffffffff,0xea55b743,172info:ir:ir unknown ffffffff,0xf561a712,172info:ir:ir unknown ffffffff,0x9b520955,172info:ir:ir unknown ffffffff,0x821ba9ff,172Occasionally when the signal is strong it will decode it as KELON168? but then the debug doesn't print out the decoded result (bad CRC?).Info:IR:Received AC code:KELON168Debug:IR:IR fire event took 0msInfo:IR:IR Unknown ffffffff,0x6CA9AFD2,172Info:IR:Received AC code:KELON168Debug:IR:IR fire event took 0msInfo:IR:IR Unknown ffffffff,0x41E59780,172Info:IR:Received AC code:KELON168Debug:IR:IR fire event took 0msInfo:IR:Received AC code:KELON168Debug:IR:IR fire event took 0msInfo:IR:IR Unknown ffffffff,0x7771B42A,172Turning on flag 14, I get this on MQTT 70,0x83060302000080000000000000810002000008000ACorresponding to this in the log:Info:IR:Received AC code:KELON168Info:IR:IR MQTT publish �A took 2msDebug:IR:IR fire event took 0msCould you suggest the next steps please?

divadiow · Answer

hmm, not really sure what next. I have not had any experience with the irRemoteESP version. I wonder if powersave can have an effect on it like with standard ir version. Do you have powersave 1 set?

bkespoke · Answer

Thanks again. Powersave does seem to have an impact but it was off.

I have powersave 0 (I tried powersave 1, then the powersave messages appear everywhere in the logs, which I haven't seen before. Powersave 1 also causes a known-good remote to read garbage, while powersave 0 it decodes something most of the time.

Interesting, the odd times it fails to decode the working remote, the hex values are just garbage.

Hex values from my AC remote are always garbage, no pattern.

But asking about the very occasional successful decodes, they all say:
Info:IR:Received AC code:KELON168
for any button on the remote. Whereas with the working TV remote I get various codes.
Does this mean it's just an accidental decode?

divadiow · Answer

hmm. not sure. poking @p.kaczmarek2 and @DeDaMrAz who I think co-authored the irESP variant

bkespoke · Answer

So I solved it, at least for my current application, with the help of an IR receiver diode, logic analyzer and Gemini AI.
The "LG" is using a TCL type IR control board which sends three 56-bit NEC-style PDM codes, separated by 8 ms gaps.
Openbeken buffer is too small for such a long code, which is why I couldn't receive it. It also can't send all three in a row, but it turns out only the first code is really needed!

Here are some codes that work for my LG portable unit, model number LP0731WSB remote control part number DG11J1-99
* Cooling, Low Fan, 16 C setpoint: IRSend NEC,48,0xC160C0400000 (unit only goes down to 18)
* Cooling, High Fan, 20 C setpoint: IRSend NEC,48,0xC16080440000
* Fan only, Low fan: IRSend NEC,48,0xC160C02E0000
* Power toggle: IRSend NEC,48,0xC160E0440000
( the last one will turn it off, but also turn it on with settings Cool, Low fan, 20 C, so to be sure of turning it off, you'd have to send another code and then the power toggle)

More from Gemini:
Key Observations on How Your AC's Protocol Works
Byte 3 (0x80 vs. 0xC0): With Low Fan, Byte 3 was 0xC0 (11000000). With High Fan, it changed to 0x80 (10000000). This confirms that the second bit of Byte 3 controls the Fan Speed.
Byte 4 (0x44 vs. 0x40): Your base 16°C Cooling command used 0x40. Adding 2°C to get 18°C incremented Byte 4 by 0x04 ($0\text{x}40 + 0\text{x}04 = 0\text{x}44$). This means you can likely calculate other temperatures mathematically (e.g., 20°C would be 0x48, 22°C would be 0x4C, etc.). This last part turns out to be wrong, but byte 4 does control the temperature setting.

A few raw decodes are attached.

bkespoke · Answer

Solved for my air conditioner.

[Solved] Flashing and Configuring Micro IR Blaster (Ali 1005006823624599) with BK7231N

BK7231N pinout and flashing notes for micro IR blaster

BK7231N pinout and flashing notes for micro IR blaster

AC remote still decodes as unknown pulse-distance code

AC remote still decodes as unknown pulse-distance code

Post #3

Intermittent KELON168 decode with bad CRC

Intermittent KELON168 decode with bad CRC

Post #5

Occasional KELON168 decodes suggest accidental IR detection

Occasional KELON168 decodes suggest accidental IR detection

Post #7

Post #8

Decoded LG AC protocol and working IR commands

Decoded LG AC protocol and working IR commands

Post #10

Didn't find an answer? Ask Artificial Intelligence (AI)

Topic summary