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?

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.

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.