crankyoldgit / IRremoteESP8266

Infrared remote library for ESP8266/ESP32: send and receive infrared signals with multiple protocols. Based on: https://github.com/shirriff/Arduino-IRremote/
GNU Lesser General Public License v2.1
3k stars 833 forks source link

Added support for Fujitsu 264 bit A/C remote protocol #2030

Open shimmy-void opened 1 year ago

shimmy-void commented 1 year ago

This change provides support for the Fujitsu's 264 bit A/C remote protocol:

This also includes the unit tests code which passes every test including using real example patterns. I also checked every function was working properly with the actual equipment in my room.

There is, however, one problem in the protocol: Some commands ("Toggle Sterilization" (0x1463001010FE09C160030000FC9F0041) and "Outside Quiet On/Off" (0x1463001010FE09C140000000FFBF0041, 0x1463001010FE09C140010000FFBF0041)) use the same state patterns with the previous Fujitsu AC's protocol (ARRAH2E), but have different meanings. So, when users try to decode these commands as Fujitsu 264 bit AC protocol, the IRrecv::decode() function recognizes it is the previous Fujitsu AC's some other command. If you have any advice to solve this problem, I will fix it and commit it.

I hope this change can contribute to the community and help Fujitsu A/C users enjoy the IR remote control.

NiKiZe commented 1 year ago

Thanks for adding additional support. There seems to be something wrong with the branch, could you please rebase your branch on current master and force push? We do not expect to see any docygen changes in pull requests, other than when it is a PR for a new release.

To handle the different messages/conflicts there is models for remotes that can and probably needs to be used in this case?

shimmy-void commented 1 year ago

Thank you for your comment, and sorry for messing up. I am almost a novice at working with this kind of open-source project. I have just followed this process: Merging your Pull Request, but I did not need to change doxygen documentation, README, and version management files, did I?

The conflict seems to happen against the model of ARRAH2E. But for all of the previous Fujitsu AC model users, there is no problem. The problem happens when future users of this protocol want to decode their actual IR signal using the function IRsend::decode() because its decoding part (decodeFujitsuAC264()) is implemented after the previous Fujitsu's one (decodeFujitsuAC()) at IRrecv.cpp. So, even though it receives FUJITSU_AC264 protocol signal, the decode() function detects it as FUJITSU_AC protocol. Its output will be like:

Protocol  : FUJITSU_AC
Code      : 0x1463001010FE09C160030000FC9F0041 (128 Bits)
Mesg Desc.: Model: 1 (ARRAH2E), Id: 0, Power: On, Mode: 3 (Fan), Temp: 22C, Fan: 0 (Auto), Clean: Off, Filter: Off, 10C Heat: Off, Swing: 0 (Off), Command: N/A, Timer: Off

instead of

Protocol  : FUJITSU_AC264
Code      : 0x1463001010FE09C160030000FC9F0041 (128 Bits)
Mesg Desc.: Command: Sterilization

Sending signal functions properly, and the above conflict happens only when receiving 3 commands: Toggle Sterilization, Outside Quiet On, and Outside Quiet Off. So, this might not be so big problem if future users just ignore it, but might be confused with the result.

hldh214 commented 8 months ago

I can confirm that this PR works on my AS-AH363N, which also has a remote control labeled AR-RLB2J. Thank you for your efforts.