Update ir remote

[vfonov]

Updated IR Remote library, added a new format for IRsend command.

• IR send and recieve are now handled by a port of IRremoteESP8266
• IRsend command now supports command in the format <protocol>,<number of bits decimal>,<data in hex>[,<repeats>]
• Recieving long (more then 64 bits) commands is supported
• Sending long (more then 64 bits) commands is not supported yet
• Special command for controlling AC is not functioning yet.
• Hopefully this addresses IRLibrary update! (MITSUBISHI_AC) is in IRremoteESP8266 library, but missing from ours #526

[openshwprojects]

Very good, is new commands format the same as in Tasmota? So now we can also receive the custom codes mentioned here?
#526

[openshwprojects]

It seems there is some kind of build issue on N platform. Did app binary size really grow that much?

[vfonov]

Very good, is new commands format the same as in Tasmota? So now we can also receive the custom codes mentioned here? #526

Not quite, right now there is support only for remote control codes that the new library can encode with length up to 64 bit, so this mode from Tasmota: https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_05_irremote_full.ino#L508 , to implement bigger codes and RAW mode we need to port more code from there.

[openshwprojects]

Why N build is so large?


Is there something N-specific?

[josephperry]

@openshwprojects Have you considered the approach that tasmota has taken? Enabling all features can exceed the available memory so multiple tasmota builds are available. Tasmota-ir, tasmota-knx, tasmota-sensors are builds which enable some features but disable others. A build like BK7231N-ir would include all ir and related features like mqtt but could exclude features like energy monitoring if that then fits into a BK7231N. An all-in-one build is most desirable but may not be practical for all memory consuming features.

[rodsmar]

Hey can i remove a lot of drivers to build an BK7231N image? I need three drivers only (LG, Samsung, Gree). How?

Otherwise, Tuya image has 2MB (size). Can i grow the image size?

[StayPirate]

I'll be glad to test this PR once the BK7231N image will be ready.

[StayPirate]

Hi folks, is there any update here?

[fragtion]

Besides the BK7231N image...

We still don't have working RAW protocol support (even with these pulls/commits), right? -- Is anyone working on this perhaps?
I guess I should just buy an ESP8266 and go with Tasmota so long 😭

[StayPirate]

Besides the BK7231N image...

We still don't have working RAW protocol support (even with these pulls/commits), right? -- Is anyone working on this perhaps? I guess I should just buy an ESP8266 and go with Tasmota so long sob

I have the same feeling, but some progress is already achieved thanks to @vfonov effort. Maybe it's just a matter of time before we can have a fully working IR module. As I stated before, I offer to do betatesting as soon as OpenBK7231N build is available.

[axlerose]

any news about the BK7231N ?

[openshwprojects]

I can look into it, if there are some people interested. But it's strange, I don't know how that library was able to bump flash usage so much.

I am testing T version, but it doesn't seem too stable yet:

[vfonov]

I disabled the module for AC control to make binary fit into BK7231N.

[avdmr]

Thank you for your work on this @vfonov! I can confirm the panasonic protocol now is working. For anyone who would like to try it, here is the direct link to the bins of @vfonov https://github.com/openshwprojects/OpenBK7231T_App/suites/12430550589/artifacts/661784343

It seems you deleted the Sony protocol, was there a specific reason for that? If it is not to much to ask I would suggest to make a build with everything accept the AC protocols so it would be suitable for a multimedia setup.

Thanks again.

[vfonov]

It seems you deleted the Sony protocol, was there a specific reason for that? If it is not to much to ask I would suggest to make a build with everything accept the AC protocols so it would be suitable for a multimedia setup.

So, the only reason that I removed Sony for sending (and didn't include others) is because the command style SONY-address-command-nrepeats is not supported by the library:

OpenBK7231T_App/src/libraries/IRremoteESP8266/src/ir_Sony.cpp

Line 47 in 9b0cc66

void IRsend::sendSony(const uint64_t data, const uint16_t nbits,

because there is no notion of address for some reason, only the data.

But you should be able to send SONY commands using new syntax: SONY,nbits,0xDATA[,repeat] However, this might change in the future.

[avdmr]

It seems you deleted the Sony protocol, was there a specific reason for that? If it is not to much to ask I would suggest to make a build with everything accept the AC protocols so it would be suitable for a multimedia setup.

So, the only reason that I removed Sony for sending (and didn't include others) is because the command style SONY-address-command-nrepeats is not supported by the library:

OpenBK7231T_App/src/libraries/IRremoteESP8266/src/ir_Sony.cpp

Line 47 in 9b0cc66

void IRsend::sendSony(const uint64_t data, const uint16_t nbits,

because there is no notion of address for some reason, only the data.

But you should be able to send SONY commands using new syntax: SONY,nbits,0xDATA[,repeat] However, this might change in the future.

You're absolutely right. I was using the old formatting. Using the new syntax works perfectly. When capturing the codes from a remote, it shows the new syntax so my bad!

[DeDaMrAzR]

First 4 or 5 tries I have the same code received after that some completely different codes. This can also be repeated with holding a button.

[Hotelk52339]

Hello
Will there be support for Samsung AC and Pulse Distance? It's just that I just downloaded your build, but all my air conditioners are not supported :(

[p-hash]

Binaries for this PR are no longer stored on github. Can you re-run the actions?
I would like to test on BK7231T.

[Sablic]

Any chance for binaries to be rebuilt?

[openshwprojects]

let me see if i can trigger a rebuild

but this branch still needs a stability improvement

[OctoNezd]

What are the issues with stability? I am running this build since March (I think) and everything works fine for me. I use my blaster solely to emit, not receive though.

[arnonm]

Trying to join the bandwagon here, i rebuild the branch. Seeing that IRAC is not defined, I added
CPPDEFINES += -DENABLE_IRAC=1
to application.mk
Compiles fine, loaded on a S06 IR blaster, and it comes up fine on Safe mode. Any attempt to connect it to a working Wifi results in a hang.
Any suggestions on how to proceed or debug it further.

[vfonov]

Strange, this never happen on my setup.

Compiles fine, loaded on a S06 IR blaster, and it comes up fine on Safe mode. Any attempt to connect it to a working Wifi results in a hang. Any suggestions on how to proceed or debug it further.

The IRAC makes the binary quite big, so it doesn't fit on some devices, but adds support for recieving AC commands.I didn't get around making a proper port of the AC support , similar to https://github.com/crankyoldgit/IRremoteESP8266/tree/master/examples/Web-AC-control

[zain1144]

I compiled it for BK7231N, I have GREE AC. sometimes it recognize my remote as "Recieved AC code:GREE" and sometimes as "Recieved Unknown IR" but it doesn't show any code that I can use.
What is the issue here ?

[OctoNezd]

You would need to look into how struct for that AC is defined, here is how I implemented it for COOLIX codes using appdaemon: https://gist.github.com/OctoNezd/af1cc19c4c853b60884052d5d9fcb63e#file-coolixir-py.

I looked into https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/ir_Coolix.h for struct (or is it union? I dont know lowlevel terms properly) definition. I assume for gree you would have to look into https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/ir_Gree.h

[Onepamopa]

Why hasn't this been merged yet?

[openshwprojects]

@Onepamopa I've tried it with @DeDaMrAzR and it seems to give random codes instead of correct ones from time to time. Do you think it's stable enough for merge? Have you tried it for some time?

[openshwprojects]

@vfonov would it be possible to make it work.... alongside old IR library? And publish both binaries on each Github action? Sometihng like:
OBK-basic.nin and OBK-IR.bin?
Did you change anything outside the drv_ir.cpp and the (obviously) IR library?

[Onepamopa]

@Onepamopa I've tried it with @DeDaMrAzR and it seems to give random codes instead of correct ones from time to time. Do you think it's stable enough for merge? Have you tried it for some time?

I've seen this in the library's issues - related to timings most likely - in the case I've seen it the issues were on ESP32. Maybe worth a look?

[orthobots]

Hi everyone. Has a way to transmit RAW codes been implemented yet? Thanks!

[artin961]

Hello, does someone tried to implement tasmota style json commands?

[vfonov]

@vfonov would it be possible to make it work.... alongside old IR library? And publish both binaries on each Github action? Sometihng like: OBK-basic.nin and OBK-IR.bin? Did you change anything outside the drv_ir.cpp and the (obviously) IR library?

So, sorry for the late reply - didn't see this question.
I did change things only in drv_ir.cpp + addded all the files for the new IR library. I had to change it too , a lot, because some C++ features that it was relying on were not available on OpenBKT. I suppose it's possible to configure at compile time to use old drv_ir.cpp with old library or the new one.

[midevil]

Is it possible to get a binary from this PR? since it is not merged yet, and i really would like to use it on my useless AC1 AC to remote start heating.

[vfranchi]

I was able to build this pull request. I've re-enabled IRAC with @arnonm comment above. I'm seeing the stability issue trying to receive my Fujitsu remote code. But once I figured out the code, for example, for the AC shutdown. I tried sending it using the command

IRSend FUJITSU_AC,56,0x146300101002FD

But that's still unsupported, am I correct? Logs below:

Info:IR:IR Unknown ffffffff,0x436D0D35,58
Info:MQTT:Publishing val ffffffff,0x436D0D35,58 to obkB98AE30E/ir/get retain=0
Info:IR:IR MQTT publish IR Unknown ffffffff,0x436D0D35,58 took 3ms
Info:MQTT:Publishing val {"IrReceived":{"Protocol":"UNKNOWN","Bits":58,"Data":"0x436D0D35"}} to obkB98AE30E/RESULT retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkB98AE30E/ir/get
Info:IR:Recieved AC code:FUJITSU_AC
Info:IR:IRAC Model: 1 (ARRAH2E), Id: 0, Power: On, Mode: 1 (Cool), Temp: 22C, Fan: 3 (Low), Clean: Off, Filter: Off, 10C Heat: Off, Swing: 0 (Off), Command: N/A, Timer: Off
Info:MQTT:Publishing val 21,0x1463001010FE0930610103000000214A to obkB98AE30E/ir/get retain=0
Info:IR:IR MQTT publish ��A took 3ms
Info:MQTT:Publishing val {"IrReceived":{"Protocol":"FUJITSU_AC","Bits":128,"Data":"0x1463001010FE0930610103000000214A"}} to obkB98AE30E/RESULT retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkB98AE30E/ir/get
Info:IR:IR Unknown ffffffff,0xA77E0E8C,58
Info:MQTT:Publishing val ffffffff,0xA77E0E8C,58 to obkB98AE30E/ir/get retain=0
Info:IR:IR MQTT publish IR Unknown ffffffff,0xA77E0E8C,58 took 3ms
Info:MQTT:Publishing val {"IrReceived":{"Protocol":"UNKNOWN","Bits":58,"Data":"0xA77E0E8C"}} to obkB98AE30E/RESULT retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkB98AE30E/ir/get
Info:IR:Recieved AC code:FUJITSU_AC
Info:IR:IRAC Model: 1 (ARRAH2E), Id: 0, Power: On, Mode: 1 (Cool), Temp: 22C, Fan: 3 (Low), Clean: Off, Filter: Off, 10C Heat: Off, Swing: 0 (Off), Command: N/A, Timer: Off
Info:MQTT:Publishing val 21,0x1463001010FE0930610103000000214A to obkB98AE30E/ir/get retain=0
Info:IR:IR MQTT publish ��A took 6ms
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkB98AE30E/ir/get
Info:MQTT:Publishing val {"IrReceived":{"Protocol":"FUJITSU_AC","Bits":128,"Data":"0x1463001010FE0930610103000000214A"}} to obkB98AE30E/RESULT retain=0
Info:IR:Recieved AC code:FUJITSU_AC
Info:IR:IRAC Model: 1 (ARRAH2E), Id: 0, Power: Off, Command: N/A
Info:MQTT:Publishing val 21,0x146300101002FD to obkB98AE30E/ir/get retain=0
Info:IR:IR MQTT publish ��A took 2ms
Info:MQTT:Publishing val {"IrReceived":{"Protocol":"FUJITSU_AC","Bits":56,"Data":"0x146300101002FD"}} to obkB98AE30E/RESULT retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic obkB98AE30E/ir/get
Error:IR:IR can't send FUJITSU_AC: protocol 33 bits data 0x146300101002FD repeats 1
Info:CMD:[WebApp Cmd 'IRSend FUJITSU_AC,56,0x146300101002FD' Result] Bad argument

I have a CBU module, with BK7231N.

[openshwprojects]

Everyone can get binary from this PR easily, binaries are build per commit, please see tutorial:
https://www.elektroda.com/rtvforum/topic4033833.html

[cmuki]

Hello everyone!

For the last several days I am trying to compile this PR (using docker) in order to send Daikin codes to my A/C. In order for the binary to be small, I've removed all other protocols that I don't need (Samsung (not A/C), NEC and Daikin are left).

I've also modified the drv_ir_new to accommodate the changes, but to no avail. Interestingly, the Samsung and NEC TV protocols don't work as well and only get their protocol (without the payload) recognized when the button is repeated.

I've added the CPPDEFINES += -DENABLE_IRAC=1 line to application.mk and every time that I've tried to compile it I think I got everything right, but to no avail.

I've made a fork here with my changes and would be glad to receive some help and/or pointers. The project compiles successfully, but even the IR Receiving doesn't work.

Thank you in advance and thank you for the awesome work that's been done here!

Best regards,
cmuki