OpenBK7231T_App
OpenBK7231T_App copied to clipboard
openshwprojects
Update ir remote
Updated IR Remote library, added a new format for IRsend command.
- IR send and recieve are now handled by a port of IRremoteESP8266
-
IRsendcommand 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 #526
Very good, is new commands format the same as in Tasmota? So now we can also receive the custom codes mentioned here? https://github.com/openshwprojects/OpenBK7231T_App/issues/526
It seems there is some kind of build issue on N platform. Did app binary size really grow that much?
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.
Is there something N-specific?
@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.
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?
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 😭
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.
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:
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.
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:
https://github.com/openshwprojects/OpenBK7231T_App/blob/9b0cc66a7ba18de151b3db532041f4004a96b796/src/libraries/IRremoteESP8266/src/ir_Sony.cpp#L47 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.
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-nrepeatsis not supported by the library:https://github.com/openshwprojects/OpenBK7231T_App/blob/9b0cc66a7ba18de151b3db532041f4004a96b796/src/libraries/IRremoteESP8266/src/ir_Sony.cpp#L47 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!
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.
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 :(
Binaries for this PR are no longer stored on github. Can you re-run the actions? I would like to test on BK7231T.
let me see if i can trigger a rebuild
but this branch still needs a stability improvement
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.
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.
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
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 ?
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 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?
@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 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?