search

openshwprojects / OpenBK7231T_App

Open source firmware (Tasmota/Esphome replacement) for BK7231T, BK7231N, BL2028N, T34, XR809, W800/W801, W600/W601 and BL602
https://openbekeniot.github.io/webapp/devicesList.html
1.34k stars 228 forks source link

IRLibrary update! (MITSUBISHI_AC) is in IRremoteESP8266 library, but missing from ours #526

Open openshwprojects opened 1 year ago

openshwprojects commented 1 year ago

One user just made my realize that our IRLibrary is an older version and Tasmota has newer. @btsimonh , are you aware about that? Would you be able to update it? For example, MITSUBISHI_AC is missing from ours...

vfonov commented 1 year ago

So, the upstream library is https://github.com/crankyoldgit/IRremoteESP8266 ?

openshwprojects commented 1 year ago

@vfonov I think so... we did a little mistake while doing IRSupport with @btsimonh and most likely chosen an older one or something.

vfonov commented 1 year ago

Looks like the upstream library is actually https://github.com/Arduino-IRremote/Arduino-IRremote

btsimonh commented 1 year ago

yes, I think that was the one. It's kind of the root library for many of the IR implementations - but e.g. IRremoteESP8266 has had updates and mods - probably mainly because of Tasmota's use of it? The major challenge when porting it was getting C++ - now we have that, swapping over the library should not be too hard. The current library runs off a 20khz interrupt for both RX and TX.

openshwprojects commented 1 year ago

Any news or plans to do it?

I'm very busy these days (Youtube, BL602 OTA, teardowns, misc features, as you may see in commits history) but it would be really nice to have latest IR Libr working!

vfonov commented 1 year ago

I am trying to integrate with IRremoteESP8266, the interface is completely different from Arduino-IRremote though, so it is not very straightforward. Take a look: https://github.com/vfonov/OpenBK7231T_App/tree/IR_UPGRADE

openshwprojects commented 1 year ago

@vfonov any news on this? I am looking how far you've got

huh, they changed receive handling? The ISR is different... new version is different.

they changed so much: image

openshwprojects commented 1 year ago

The new IRRemote version seems to be using an interrupt instead of 50us timer. I am still investigating. I am trying to to somehow get it running.

vfonov commented 1 year ago

I managed to make a sender compiling, but it didn't really work with my TV so maybe I am missing something. https://github.com/vfonov/OpenBK7231T_App/tree/IR_UPGRADE - should compile and IRSend should work, but receiving is disabled for now.

openshwprojects commented 1 year ago

@vfonov I have based on your work, but I am unable to get receive working in spite of apparently running receive every 50us. I will push my code to separate branch today, maybe you can give some insights.

but to be more precise, the problem is that it seems the new version is using pin change interrupts and not 50us timer, and it's getting time from micros. I tried to simulate the change interrupt behaviour with timer and to plug old 50us interrupt directly but neither worked.

openshwprojects commented 1 year ago

@vfonov here are my changes: https://github.com/openshwprojects/OpenBK7231T_App/commits/ir_update_test p1 is just synced your changes, 1:1 p2 is enabling IRRecv, with two options for main function. https://github.com/openshwprojects/OpenBK7231T_App/commit/dcddf28bc1f71adccafe5bd0bc347ac21d6299d8 This: image is my attempt at old approach, but it seems they have changed it.

This: image is my attempt to mimic their "interrupt on pin change" behaviour, but ISR is polled every 50 us. I tried also 10us, but no luck.The "now" is used as timer instead of "micros()".

Both approaches receive random garbage when I press button on my remote.

openshwprojects commented 1 year ago

@btsimonh @vfonov ideas?

vfonov commented 1 year ago

So, it's impossible to have interrupt on pin change in bk7231 ?

openshwprojects commented 1 year ago

@vfonov well, something like that is used here: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_bl0937.c image the problem is IRQ_TRIGGER_FALLING_EDGE... When you look for that in SDK: https://github.com/openshwprojects/OpenBK7231T/search?q=IRQ_TRIGGER_FALLING_EDGE image it seems there is no way to.... trigger on both rising and falling edges. Those are not bit flags... hmm. You can choose only one or one, not both at once.

What do you think?

Also... I still don't know why my hack is not working. A timing issue?

axlerose commented 1 year ago

Hi all, I'm also interested on this topic. For me is not clear if from the tasmota side the used library is https://github.com/crankyoldgit/IRremoteESP8266 or https://github.com/Arduino-IRremote/Arduino-IRremote

Based on the page https://tasmota.github.io/docs/Tasmota-IR/ appear that the used libray is the first one but there are different build of the firmware the main one that support only the IRSend command and the RC5, RC6 and NEC protocol only (https://tasmota.github.io/docs/Commands/#ir-remote) and the tasmota-ir that support the IRHVAC Command and manage all the IRremoteESP8266 protocol.

Are you working on manage also the IRHVAC command?

vfonov commented 1 year ago

Yes, once the new library is properly integrated that would be the idea to add control for HVAC

axlerose commented 1 year ago

If is useful I can support with test on bk7231n CBU module

vfonov commented 1 year ago

@vfonov here are my changes: https://github.com/openshwprojects/OpenBK7231T_App/commits/ir_update_test p1 is just synced your changes, 1:1 p2 is enabling IRRecv, with two options for main function. dcddf28 This: image is my attempt at old approach, but it seems they have changed it.

changing pinModeFast in drv_ir.cpp:110 seem to made it work:

void pinModeFast(unsigned char P, unsigned char V) {
    if (V == INPUT_PULLUP) {
        bk_gpio_config_input_pup((GPIO_INDEX)P);
    }
    else if (V == INPUT_PULLDOWN) {
        bk_gpio_config_input_pdwn((GPIO_INDEX)P);
    }
    else if (V == INPUT) {
        bk_gpio_config_input((GPIO_INDEX)P);
    }
    else if (V == OUTPUT) {
        bk_gpio_config_output((GPIO_INDEX)P);
    }
}

i.e now it uses bk_gpio_config_input instead of bk_gpio_config_input_pup

openshwprojects commented 1 year ago

Well, that's very good news if it works! I will check this out right away.

But if it works, it's all thanks to you, so can you just maybe open a pull request so you can officially become one of our contributors?

axlerose commented 1 year ago

How can I test the fix? on the branch ir_update_test tha last commit is of 3 days ago. I've also notice that for the IR component the HA config remain blank

openshwprojects commented 1 year ago

@vfonov are you sure that only this change makes IRRecv works? It's still not working for me, hmm

vfonov commented 1 year ago

So, I enabled DEBUG messages from the IRRecv and submodules, so now IR recieve dumps lots of info in debug console.

I tried only with two remotes : Panasonic and Fuji AC in both cases it can detect the correct remote model, but contents might not be correctly detected : Pressing Power button on Panasonic remote:

Debug:IR:1296
Debug:IR: - 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:934
Debug:IR: <= 
Debug:IR:1250
Debug:IR: <= 
Debug:IR:1558
Debug:IR:Matching MARK 
Debug:IR:500
Debug:IR: vs 
Debug:IR:432
Debug:IR: + 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:361
Debug:IR: <= 
Debug:IR:500
Debug:IR: <= 
Debug:IR:603
Debug:IR:Matching SPACE 
Debug:IR:400
Debug:IR: vs 
Debug:IR:1296
Debug:IR: - 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:934
Debug:IR: <= 
Debug:IR:400
Debug:IR: <= 
Debug:IR:1558
Debug:IR:Matching MARK 
Debug:IR:500
Debug:IR: vs 
Debug:IR:432
Debug:IR: + 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:361
Debug:IR: <= 
Debug:IR:500
Debug:IR: <= 
Debug:IR:603
Debug:IR:Matching SPACE 
Debug:IR:400
Debug:IR: vs 
Debug:IR:432
Debug:IR: - 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:286
Debug:IR: <= 
Debug:IR:400
Debug:IR: <= 
Debug:IR:478
Debug:IR:Matching MARK 
Debug:IR:450
Debug:IR: vs 
Debug:IR:432
Debug:IR: + 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:361
Debug:IR: <= 
Debug:IR:450
Debug:IR: <= 
Debug:IR:603
Debug:IR:Matching SPACE 
Debug:IR:1250
Debug:IR: vs 
Debug:IR:1296
Debug:IR: - 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:934
Debug:IR: <= 
Debug:IR:1250
Debug:IR: <= 
Debug:IR:1558
Debug:IR:Matching MARK 
Debug:IR:500
Debug:IR: vs 
Debug:IR:432
Debug:IR: + 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:361
Debug:IR: <= 
Debug:IR:500
Debug:IR: <= 
Debug:IR:603
Debug:IR:Matching SPACE 
Debug:IR:1250
Debug:IR: vs 
Debug:IR:1296
Debug:IR: - 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:934
Debug:IR: <= 
Debug:IR:1250
Debug:IR: <= 
Debug:IR:1558
Debug:IR:Matching MARK 
Debug:IR:500
Debug:IR: vs 
Debug:IR:432
Debug:IR: + 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:361
Debug:IR: <= 
Debug:IR:500
Debug:IR: <= 
Debug:IR:603
Debug:IR:Matching SPACE 
Debug:IR:1250
Debug:IR: vs 
Debug:IR:1296
Debug:IR: - 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:934
Debug:IR: <= 
Debug:IR:1250
Debug:IR: <= 
Debug:IR:1558
Debug:IR:Matching MARK 
Debug:IR:500
Debug:IR: vs 
Debug:IR:432
Debug:IR: + 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:361
Debug:IR: <= 
Debug:IR:500
Debug:IR: <= 
Debug:IR:603
Debug:IR:Matching SPACE 
Debug:IR:1250
Debug:IR: vs 
Debug:IR:1296
Debug:IR: - 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:934
Debug:IR: <= 
Debug:IR:1250
Debug:IR: <= 
Debug:IR:1558
Debug:IR:Matching MARK 
Debug:IR:450
Debug:IR: vs 
Debug:IR:432
Debug:IR: + 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:361
Debug:IR: <= 
Debug:IR:450
Debug:IR: <= 
Debug:IR:603
Debug:IR:Matching SPACE 
Debug:IR:400
Debug:IR: vs 
Debug:IR:1296
Debug:IR: - 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:934
Debug:IR: <= 
Debug:IR:400
Debug:IR: <= 
Debug:IR:1558
Debug:IR:Matching MARK 
Debug:IR:450
Debug:IR: vs 
Debug:IR:432
Debug:IR: + 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:361
Debug:IR: <= 
Debug:IR:450
Debug:IR: <= 
Debug:IR:603
Debug:IR:Matching SPACE 
Debug:IR:400
Debug:IR: vs 
Debug:IR:432
Debug:IR: - 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:286
Debug:IR: <= 
Debug:IR:400
Debug:IR: <= 
Debug:IR:478
Debug:IR:Matching MARK 
Debug:IR:500
Debug:IR: vs 
Debug:IR:432
Debug:IR: + 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:361
Debug:IR: <= 
Debug:IR:500
Debug:IR: <= 
Debug:IR:603
Debug:IR:Matching SPACE 
Debug:IR:1250
Debug:IR: vs 
Debug:IR:1296
Debug:IR: - 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:934
Debug:IR: <= 
Debug:IR:1250
Debug:IR: <= 
Debug:IR:1558
Debug:IR:Matching MARK 
Debug:IR:450
Debug:IR: vs 
Debug:IR:432
Debug:IR: + 
Debug:IR:50
Debug:IR:. 
Debug:IR:Matching: 
Debug:IR:361
Debug:IR: <= 
Debug:IR:450
Debug:IR: <= 
Debug:IR:603
Info:IR:Decoded PANASONIC - Address: 16388 Value: 
Info:IR:16825533 (48 bits) Raw (100)
vfonov commented 1 year ago

ok, I updated logging a little bit, using resultToHumanReadableBasic from the IRremoteESP8266 now. See https://github.com/vfonov/OpenBK7231T_App/tree/ir_update_test Also, reverted to use INPUT with pullup ( https://github.com/vfonov/OpenBK7231T_App/blob/ir_update_test/src/driver/drv_ir.cpp#L640 ) If you use just INFO logging level, here is what happens with two remotes:

Panasonic Power button:

Info:IR:Protocol  : RC6
Code      : 0x1 (1 Bits)
Info:IR:Protocol  : UNKNOWN
Code      : 0xB900E290 (50 Bits)
Info:IR:Protocol  : UNKNOWN
Code      : 0x149D4439 (50 Bits)
Info:IR:Protocol  : PANASONIC
Code      : 0x40040100BCBD (48 Bits)
Info:IR:Protocol  : UNKNOWN
Code      : 0x37AE80DB (50 Bits)
Info:IR:Protocol  : RC6
Code      : 0x1 (1 Bits)

Fujitsu AC power button several times:

Info:IR:Protocol  : PANASONIC
Code      : 0x40040100BCBD (48 Bits)
Info:IR:Protocol  : UNKNOWN
Code      : 0xAFC10602 (50 Bits)
Info:IR:Protocol  : RC6
Code      : 0x3 (2 Bits)
Info:IR:Protocol  : FUJITSU_AC
Code      : 0x1463001010FE (48 Bits)
Info:IR:Protocol  : FUJITSU_AC
Code      : 0x146300101002 (48 Bits)
Info:IR:Protocol  : FUJITSU_AC
Code      : 0x1463001010FE (48 Bits)
Info:IR:Protocol  : FUJITSU_AC
Code      : 0x146300101002 (48 Bits)
Info:IR:Protocol  : FUJITSU_AC
Code      : 0x1463001010FE (48 Bits)
Info:IR:Protocol  : RC6
Code      : 0x3 (2 Bits)
Info:IR:Protocol  : FUJITSU_AC
Code      : 0x1463001010FE (48 Bits)
vfonov commented 1 year ago

So, maybe there is a bug in the code putting raw bits values into the buffer, before the IRrecv::decode actually decodes them? OR maybe we just need to adjust noise_floor parameter for IRrecv::decode ( see https://github.com/vfonov/OpenBK7231T_App/blob/ir_update_test/src/libraries/IRremoteESP8266/src/IRrecv.cpp#L549 )

vfonov commented 1 year ago

I figured it out, there is a need to have a timeout for the complete message . The latest version seem to capture messages i.e with FUJI AC remote temperature up:

Info:IR:Protocol  : FUJITSU_AC
Code      : 0x1463001010FE0930700400000000203C (128 Bits)

and it also decodes it into a human readable form:

Info:IR:Model: 1 (ARRAH2E), Id: 0, Power: On, Mode: 4 (Heat), Temp: 22C, Fan: 0 (Auto), Clean: Off, Filter: Off, 10C Heat: Off, Swing: 0 (Off), Command: N/A, Timer: Off
openshwprojects commented 1 year ago

@vfonov great progress, I will try now that build from your fork: https://github.com/vfonov/OpenBK7231T_App/actions/runs/4276802203 hmm it recognizes samsung remote: image but is it decoded correctly? Let me compare with my video (it's the same remote as in video) https://www.youtube.com/watch?v=KU0tDwtjfjw&ab_channel=Elektrodacom hmm in the video from the past I had results like 0x707 Ax09 0 but maybe it's just matter of the formatting... image

vfonov commented 1 year ago

At least it correctly decodes parameters of my Fujitsu AC remote - with temperature and power mode

vfonov commented 1 year ago

So, I fixed a bug in sending and it seem to be working. Although I currently made only a subset of protocols: RC5,RC5,NEC,PANASONIC,JVC,SAMSUNG,LG

openshwprojects commented 1 year ago

Let me check... your fork vs current release. Button right: image image

Button left: image image

Very nice, maybe even better than the current release... just please do formatting. The current release is getting some random noise received as RC5, distance, but your version is stable.

I will test more soon

openshwprojects commented 1 year ago

What is the last value, 1 or 0? Is it "repeats"? It seems to be always 1 in the new version

axlerose commented 1 year ago

So, I fixed a bug in sending and it seem to be working. Although I currently made only a subset of protocols: RC5,RC5,NEC,PANASONIC,JVC,SAMSUNG,LG

Thanks a lot how can i manage also the other Protocol I'm interested on the CARRIER_AC

vfonov commented 1 year ago

What is the last value, 1 or 0? Is it "repeats"? It seems to be always 1 in the new version

Yes, it's repeats. I think some change of logic is need to actually count repeated codes. Also, we would need to come up with a alternative protocol , as some ir codes do not follow format address, function, nr repeats .

vfonov commented 1 year ago

So, I fixed a bug in sending and it seem to be working. Although I currently made only a subset of protocols: RC5,RC5,NEC,PANASONIC,JVC,SAMSUNG,LG

Thanks a lot how can i manage also the other Protocol I'm interested on the CARRIER_AC

So, I didn't enable any of the AC protocols yet. To properly support them we would need to implement a new command protocol. I suggest taking it from MQTT server implementation here: https://github.com/crankyoldgit/IRremoteESP8266/blob/master/examples/IRMQTTServer/IRMQTTServer.ino

Then for Carrier AC,this protocol will work : https://github.com/vfonov/OpenBK7231T_App/blob/ir_update_test/src/libraries/IRremoteESP8266/src/ir_Carrier.h

openshwprojects commented 1 year ago

We are trying to keep Tasmota standard, and I think that Tasmota has some kind of "raw" IR message system for handling events.

vfonov commented 1 year ago

Another way integrates with homeassistant

fragtion commented 1 year ago

Hi all

Thnx for continued good work on this firmware

Is there any way currently to send a RAW IR signal, rather than using an existing protocol? Some A/C units use proprietary protocols so it would really help to be able to send the RAW timings (with fairly large buffer to support some longer signals). It's possible on Tasmota, so hopefully it should be a relatively simple patch?

Received signal shows in log as "IR_PulseDistance" and there does not seem to be a way to TX, right?

Another user who encountered this issue before me: https://www.elektroda.com/rtvforum/viewtopic.php?p=20416701#20416701

Sending with Tasmota using SetOption58 1: https://github.com/arendst/Tasmota/issues/2116#issuecomment-440716483

I guess in the meanwhile I'll need to stick to my raspberry pi solution !

vfonov commented 1 year ago

Tasmota uses the same underlying Library for ir signal handling, do if somebody could take raw pulse sequence handling from there and transplant it here, it will work. There is is an issue with c++ standard Library implementation on openbkt though, it's doesn't seem to work, so if tasmota uses <alorithm> or <string> it will have to be rewritten

openshwprojects commented 1 year ago

I don't think that formatting binary data to string can be a problem. It should be very easy.

Okay, so it the base library (as replacement to our old one) now functional? Will we use any functionality if we do the port now?

If the base is ready, then please open pull request @vfonov and do the honors. Great job!

We will finalize MQTT and tasmota style support later.

sstefanov commented 1 year ago

... it seems there is no way to.... trigger on both rising and falling edges. Those are not bit flags... hmm. You can choose only one or one, not both at once.

What do you think?

Also... I still don't know why my hack is not working. A timing issue?

I found in Tyua tuya_pin_irq_init() they have TUYA_PIN_MODE_IN_IRQ_RISE_FALL, but I don't know if it's applicable to BK7231. https://developer.tuya.com/en/docs/iot/Peripherals-and-examples?id=Kbe2xnoymxzjw#title-4-tuya_pin_irq_init() https://developer.tuya.com/en/docs/iot-device-dev/GPIO?id=Kakbmhjfl59hd#title-11-tuya_pin_mode_t

Another idea is after rising edge interrupt set next interrupt to falling edge and vice versa. I'm not sure if it is possible at all.

vfonov commented 1 year ago

I found in Tyua tuya_pin_irq_init() they have TUYA_PIN_MODE_IN_IRQ_RISE_FALL, but I don't know if it's applicable to BK7231. https://developer.tuya.com/en/docs/iot/Peripherals-and-examples?id=Kbe2xnoymxzjw#title-4-tuya_pin_irq_init() https://developer.tuya.com/en/docs/iot-device-dev/GPIO?id=Kakbmhjfl59hd#title-11-tuya_pin_mode_t

Another idea is after rising edge interrupt set next interrupt to falling edge and vice versa. I'm not sure if it is possible at all.

So, right now this is not an issue for capturing IR, timer based method seem to be working

btsimonh commented 1 year ago

I looked at edge triggering, but it goes through about three layers of API if you call thier API - we'd need to get right to the actual registers to flip the edge bit raw to be quick. Also would need to figure out how to read a raw clock.... Where I stopped was when I realised that it still did not help with sleep - the edge trigger can wake us from sleep, but waking apparently takes ages, and messes with all the registers - so it seems a LOT of work to enable wake from sleep in order to capture IR. (and I stopped because my N based IR recv device bricked badly....) The timer based version does take a lot of CPU - but it does work as long as the device is on full power all the time.

dungeon77 commented 1 year ago

Hi. Sorry to write here, but I didn't find a better option. Tell me, please, can I count on the connection of the IR protocol for my air conditioner? I found its support only in tasmota-ir, the protocol is called GOODWEATHER. But I can't flash Tasmota to the Tuya chip yet (I can't). I passed Openbecken on my lamp, but the IR receiver does not accept any codes from the air conditioner remote control, even the fact of the received signal is missing. Although other remotes work fine. I will be happy to help if you need any help. Thank you in advance, I'm really waiting for an answer

vfonov commented 1 year ago

So, https://github.com/openshwprojects/OpenBK7231T_App/pull/723 integrates the same version of IR decode library as Tasmota into OpenBK, and it supports goodweather AC ( https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/ir_Goodweather.h ) but there are a few remaining issues:

  1. support for AC decoding seem to take too much binary space, so resulting binary doesn't fit into flash of BK7231N (2Mb)
  2. the actual protocol for sending and receiving IR-related messages needs to be ported from Tasmota ( https://tasmota.github.io/docs/Tasmota-IR/ )
  3. IR decoding seem to be sometimes glitchy, needs to be debugged : https://github.com/openshwprojects/OpenBK7231T_App/pull/723#issuecomment-1510383129
fragtion commented 1 year ago

Wouldn't it make more sense to just support RAW IR patterns than trying to support all these proprietary protocols? Then anyone can get any device to work in theory, even if it means they need to put more work than usual, but at least every device could theoretically work, and the impact on ROM size would be small, consistent, and futureproof. Then some major protocols like NEC could be included but with all due respect what is GOODWEATHER or Mitsubishi.. that should be removed in favour of RAW support if you ask me

vfonov commented 1 year ago

that should be removed in favour of RAW support if you ask me

Ok, can you implement that?

fragtion commented 1 year ago

that should be removed in favour of RAW support if you ask me

Ok, can you implement that?

If that was easy for me I'd have done it already

axlerose commented 1 year ago

So, #723 integrates the same version of IR decode library as Tasmota into OpenBK, and it supports goodweather AC ( https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/ir_Goodweather.h ) but there are a few remaining issues:

  1. support for AC decoding seem to take too much binary space, so resulting binary doesn't fit into flash of BK7231N (2Mb)
  2. the actual protocol for sending and receiving IR-related messages needs to be ported from Tasmota ( https://tasmota.github.io/docs/Tasmota-IR/ )
  3. IR decoding seem to be sometimes glitchy, needs to be debugged : Update ir remote #723 (comment)

Thanks for everything I think the only solution is to proceed as tasmota that have a specific build for AC IR that correctly fit on the flash dimension but have a minor set of other function/plugin