ARRPF4E needs setting of the "unknown" bit in ir_Fujitsu

[rescalda]

Version/revision of the library used

2.8.6

Describe the bug

For the new (?) Fujitsu ARRPF4E remote the bit named unknown in FujitsuProtocol union must be set, otherwise the AC machine doesn't react to any IR commands. The most similar model I found is ARREW4E that does not set that bit. Of course, one single line on top of checkSum function seem to solve my problem and I am happy with it but makes the library not-standard. I just would like to inform.

To Reproduce

Not much to say here: just send any long command and the bit 0x20 is not set. AC machines that work with ARRPF4E don't like this!

Example code used

ac.begin();					
ac.setModel(ARREW4E);			
ac.setSwing(kFujitsuAcSwingOff);
ac.setMode(kFujitsuAcModeFan);
ac.setFanSpeed(kFujitsuAcFanQuiet);
ac.setTemp(21);  // 24C
ac.setOutsideQuiet(false);		
ac.setCmd(kFujitsuAcCmdTurnOn);

Sent: 14 63 00 10 10 fe 09 31 69 03 04 00 00 00 00 5f

Expected behaviour

Sent: 14 63 00 10 10 fe 09 31 69 03 04 00 00 00 20 3f

Output of raw data from [IRrecvDumpV2.ino]

See above: the problem is very easy well documented without a dump!

What brand/model IR demodulator are you using?

N/A

Circuit diagram and hardware used (if applicable)

N/A

I have followed the steps in the [Troubleshooting Guide]

N/A

Has this library/code previously worked as expected for you?

No.

Other useful information

The problem, as stated before, is not a BUG but the lack of support of new AC Models and the related Remote. I HOPE I will not have real problems: I am just at the first stages of development. The first impression is that ARREW4E is 99% compatible.

[NiKiZe]

You could initialize the ac class with a reset from your remote to set the bit.

And we DO want a dump, not least to create proper test case for any implementation doing this.

[rescalda]

You could initialize the ac class with a reset from your remote to set the bit.
What?

[rescalda]

I think you absolutely didn't understand what I am talking about!
There is a SKETCH, running on an ESP8266, compiled using your library. The SKETCH is supposed to SEND IR commands to an AC machine trough an IR LED connected (via a resistor) to the ESP pin 4.

The remote can send commands to the AC machine as well, but it cannot in any way do something to the library or the ESp itself!

YOUR problem, if you want to have a library compatible even with newer machines that use newer remotes, is to SET (in the cose) a bit that you have labeled as "unknown" and you set only for other models of remote, but not for ARREW4E that is the most compatible with ARRPF4E.

If you like, you have all the elements to fix it, if you don't like, you will keep a library incompatible with those new remotes!
I have my patch but I am also considering to totally remove a huge library and work at a lower level: faster and lighter.

[NiKiZe]

Sorry to hear that attitude.
If you use the packet, which you claim to be correct, even tho only one bit has changed, missing the checksum(?) to set the initial state of the ac class, the internal state would have the bit set. This would be a workaround without modifying the library.

Instead of "absolutely didn't understand what I am talking about" you could have asked about a clearification.

I do wonder how you did figure out which bit was different, and even which protocol to use, without dumping the original remote. But what I suggested (as a non library change workaround) only requires the state to be set in code, not by the remote. Maybe that is an understandable explanation.