Support for Fujitsu Remote AR-REW4E Unit: ASYG09KETA-B

[BillyAB]

Version/revision of the library used

2.7.16

Describe the bug

I would like to please request support for Fujitsu remote AR-REW4E - the AC Unit Model is ASYG09KETA-B

Spreadsheet and Remote Photo

Spreadsheet of code decoding https://drive.google.com/file/d/1fjsWo_svwjN5c7Q1KXlzSQetuaucmztj/view?usp=sharing
Non XLSX GSheet https://docs.google.com/spreadsheets/d/1KjFjIR5t2H42aRd-hv-SXi3-BNQVS5lQSXefCTy6r6c/edit?usp=sharing
Picture of Remote https://imgur.com/a/OtS5eFO

Decoding Information

LSB First decoding seems to be the way.

• Byte 0 = Checksum
• Byte 1 = 1st Nibble Low Outdoor Noise Mode. 2nd Nibble Set Time Command.
• Byte 2 = Minute (Time)
• Byte 3 = Day of Week Monday = 1, Sunday = 7
• Byte 4 = Hour (Time)
• Byte 5 = 1st Nibble Swing (0 = Off, 1 = On). 2nd Nibble Fan Speed (0 = Auto, 1 = High, 2 = Medium, 3 = Low, 4 = Quiet)
• Byte 6 = 1st Nibble Timer (Sleep Timer = 1, Off Timer = 2, On Timer = 3, On/Off Timer = 4). 2nd Nibble Mode (Auto = 0, Cool = 1, Dry = 2, Fan = 3, Heat = 4)
• Byte 7 = Temp (Power on add 1, Fahrenheit adds 2)
• Byte 8-12 = Static
• Byte 13 = Remote controller custom code (A=00 B=10 C=20 D=30)
• Byte 14-15 = Static

Checksum Calculation

To calculate the checksum, it is the sum of LSB Bytes 1 to 7. This sum is then subtracted from 207, which is then Modulo to 256.

=DEC2HEX(MOD(207-SUM(HEX2DEC(**BYTES 1 to 7**)),256),2)

Non State Buttons

There are a couple of buttons that do not send the state, and just send the button press, these are:

• Economy Button
• Set Louvre Button
• Powerful Button
• Power Off

These are covered on the "Normal Function Buttons" tab on the spreadsheet

If I can provide you with any more information, just let me know.

[crankyoldgit]

Spreadsheet of code decoding https://drive.google.com/file/d/1fjsWo_svwjN5c7Q1KXlzSQetuaucmztj/view?usp=sharing

Could you please convert that to a standard Google "Sheets" document, rather than just an xlsx file in future.

Decoding Information

LSB First decoding seems to be the way.

Mostly correct. For Fujitsu, we store it in a array where the bytes are LSBF, but the order of the bytes is "first byte received is Byte[0], last byte received is Byte[15], eg. The checksum is the last byte.

Could you please use the IRrecvDumpV2 or V3 programs to capture the data please, it should detect it as FUJITSU correct, but have the wrong model info/settings etc? That's more useful to me to convert/program up the support as I have to have it co-exist with the existing Fujitsu protocols.

For example:
Your 6th row (0x1A202003210001503109FE1010006314) would be 0x1463001010FE0931500100210320201A or

uint8_t state[16] = {0x14, 0x63, 0x00, 0x10, 0x10, 0xFE, 0x09, 0x31, 0x50, 0x01, 0x00, 0x21, 0x03, 0x20, 0x20, 0x1A};

which btw, will be detected as FUJITSU with settings description of:
Model: 1 (ARRAH2E), Power: On, Mode: 1 (Cool), Temp: 21C, Fan: 0 (Auto), Clean: Off, Filter: Off, Swing: 0 (Off), Command: N/A, Timer: Off
That byte ordering is what all the existing Fujitsu models use, and to be supported, yours will use it too.

When you've recaptured/converted your spreadsheet to use that format (pref the state[] one rather than one huge hex string) I'll try to work out he differences between your model and the others.

On the plus side, your model is using the same checksum format etc and possible shares some of the other settings with other models, so there might be less work involved.

Let me know when you've done all that, and I'll take another look. Sorry for the extra work.

[crankyoldgit]

• Byte 7 = Temp (Power on add 1, Fahrenheit adds 2)

You're going to have to describe what every bit in that byte does.
Currently we have it mapped as the high nibble (4 most significant bits) + 16 is the temp in Celsius. e.g. 0x00 is 16C, 0x10 is 17C etc.
and the least significant bit of the byte is the Power status. e.g. 0x00 is Power off, 0x01` is Power on etc.

What the library doesn't yet have mapped is the 3 bits between the Temp and the Power bits.
i.e. 0b0000xxx0
Your spread sheet has them changing a lot, well technically only two bits 0b0000xx00. You need to explain what those bits are/do/etc.

[BillyAB]

Hi David,

Thanks, and no worries at all about the extra work.

Could you please convert that to a standard Google "Sheets" document, rather than just an xlsx file in future.

Apologies, Google sheets natively supports editing xlsx now, however it appears not to like it when they are shared with only comment access, it has now been converted to a native GSheet and the link updated. https://docs.google.com/spreadsheets/d/1KjFjIR5t2H42aRd-hv-SXi3-BNQVS5lQSXefCTy6r6c/edit?usp=sharing

Could you please use the IRrecvDumpV2 or V3 programs to capture the data please, it should detect it as FUJITSU correct, but have the wrong model info/settings etc? That's more useful to me to convert/program up the support as I have to have it co-exist with the existing Fujitsu protocols.

I have used a formulae to convert the existing codes to a uint8_t state[16] and these are now in column AF

I am having an issue getting the IRrecvDump to consistently recognise it as Fujitsu, some commands it does (albeit the wrong mesg desc) but more often than not I am getting it as unknown hence doing it like this originally and using the python tool to convert the raw to the LSB Hex.

Library   : v2.7.16

Protocol  : UNKNOWN
Code      : 0x8383D7DE (130 Bits)
uint16_t rawData[259] = {3220, 1700,  354, 446,  380, 448,  380, 1296,  352, 446,  382, 1296,  354, 448,  380, 448,  378, 446,  382, 1296,  352, 1296,  354, 448,  378, 446,  380, 446,  382, 1294,  354, 1270,  380, 448,  380, 446,  380, 448,  380, 446,  380, 450,  378, 448,  380, 446,  380, 448,  380, 448,  380, 448,  380, 450,  376, 450,  380, 448,  378, 1298,  352, 448,  378, 448,  380, 448,  380, 448,  378, 450,  378, 450,  378, 448,  378, 1296,  354, 446,  382, 446,  380, 448,  378, 448,  380, 1296,  352, 1296,  354, 1296,  354, 1272,  376, 1272,  378, 1296,  354, 1294,  354, 1296,  354, 446,  380, 448,  378, 1296,  354, 448,  378, 448,  378, 448,  380, 446,  380, 1272,  378, 446,  380, 450,  378, 448,  378, 1296,  354, 1296,  354, 446,  380, 448,  378, 448,  378, 446,  382, 446,  380, 1296,  354, 1296,  354, 446,  380, 1296,  354, 446,  380, 446,  380, 446,  380, 1294,  354, 448,  380, 448,  380, 448,  380, 448,  380, 446,  380, 448,  380, 446,  380, 448,  380, 446,  380, 446,  380, 448,  380, 446,  380, 448,  380, 448,  380, 446,  380, 1296,  352, 446,  380, 1296,  354, 446,  380, 448,  380, 448,  380, 1296,  354, 448,  378, 448,  380, 446,  380, 446,  382, 446,  380, 446,  382, 446,  380, 1272,  378, 446,  380, 446,  382, 1294,  354, 446,  382, 1294,  354, 446,  382, 446,  382, 446,  380, 448,  380, 448,  380, 448,  380, 448,  378, 1296,  354, 446,  382, 446,  380, 1296,  354, 446,  382, 1296,  354, 446,  382, 1294,  354, 446,  382, 446,  380, 446,  382};  // UNKNOWN 8383D7DE

In regards to Byte 7 or Byte 8 as it is when in the correct state order, I will have a look into the bitmapping of it and try to figure out what it is doing, and report back once I have something.

[crankyoldgit]

I am having an issue getting the IRrecvDump to consistently recognise it as Fujitsu, some commands it does (albeit the wrong mesg desc) but more often than not I am getting it as unknown hence doing it like this originally and using the python tool to convert the raw to the LSB Hex.

That's because your signal/capture is a bit on the poor side (and if you use the Remote ID thing it won't recognise it with the currently released library). i.e. You've got some values in your rawData that are out of spec for the protocol.
That could be cause by a number of issues (see FAQ and Troubleshooting guide).

Anyway, I've tweaked the library a bit to make it capture your above signal and handle capturing when you change the Remote's Identifier ID 0-3/A-D etc.

Please download & try out branch AR-REW4E: https://github.com/crankyoldgit/IRremoteESP8266/tree/AR-REW4E
That's where I'll be doing development to support your A/C. I think I've worked out a bit to differentiate your model from all the others. It's not implemented yet, as I need to see all the updated data. But that's a main starter, so we can handle your odd/different setting configs.

[BillyAB]

Cheers, I'll download and stick that one in.
I'm using the remote predominately in the default A (0) mode anyway, It was more curiosity for what changed when changing the remote mode. Not something I actually envisaging needing support for myself.

What data are you wanting from me, the temperature stuff?
Happy to help where I can, but Arduino/C++ is not my usual development language.

[crankyoldgit]

What data are you wanting from me, the temperature stuff?

Yep. That's the starting place for me. Decoding/explaining what each bit of your "Temp bin" column. i.e. What it does, how it works, what effects it has.
Also, you probably need to map out the full temp range in Fahrenheit too.

Oh and the calc/formula for generating the "displayed" temp from the temp in the byte/binary.

[BillyAB]

Fab, that update looks to be consistently reading it as a FUJITSU_AC ARRAH2E

Mode, Fan, Swing, Econ, Powerful, Outside Quiet, Set Louvre and Remote Code all seem to be recognised correctly, just looks to be the Temp (as we know) and the 10degree heat button it is not happy with at the moment

I'll try and get my head around the temperature byte and figure out what's going on.

Thanks :-)

[BillyAB]

So, I think I have got to the bottom of the Temp Byte.
I've updated the "Byte 8 (Temp Calcs)" sheet in the spreadsheet with the info.

The last 2 bits are the Power flag as you said the others use, and the temperature unit ie F or C

Where the least significant bit is labelled as bit 8 and the most significant bit is labelled as bit 1.

• Bit 8 (lsb) = Power - 1= PowerOn
• Bit 7 = Temperature Unit - 0 = Celsius, 1 = Fahrenheit

Now this is where things get interesting, as what the remaining 6 bits do/how they convert depend on the temperature unit.

Celsius Bit 7 = 0

Bit 6 is the half degree flag i.e. 1=half degree, 0=whole degree
Then the 5 most significant bits (bits 1-5) + 8 (+ 0.5 if the half flag is set) = temp in C
IF(bit6="1") THEN (5MSB)+8.5 ELSE (5MSB)+8

Fahrenheit Bit 7 = 1

This is slightly simpler. In that it is the 6 most significant bits (bits 1-6) + 44 = temp in F

Summary

• Bit 8 (LSB) = Power - 1= PowerOn
• Bit 7 = Temperature Unit - 0 = Celsius, 1 = Fahrenheit
• Bit 6 = Half Flag C / 1 F
• Bit 5 = 1 C / 2 F
• Bit 4 = 2 C / 4 F
• Bit 3 = 4 C / 8 F
• Bit 2 = 8 C / 16 F
• Bit 1 (MSB) = 16 C / 32 F

I hope that makes sense.

[crankyoldgit]

Does your AC/remote have a clean, & filter settings?

[crankyoldgit]

and does it have horizontal fan swing control?

[BillyAB]

No clean or filter settings that I can see, and no horizontal swing or control, just the standard vertical swing/control.

There is a photo of the remote and all it’s buttons linked in the original post, if you need it.

[crankyoldgit]

I've just updated that branch. It should now detect your model number correctly (I hope), and handle the temperature (inc. half deg C, and Fahrenheit)

Please download and try it out. Let me know what does/doesn't work etc etc.

[BillyAB]

Thanks for that :-)
I've downloaded and tried that, it is detecting most things now as the Model: 6 (ARREW4E)
New tab in spreadsheet for testing (but I'll list the findings below) save you trying to understand that sheet.

• All Fahrenheit temps list correctly
• Remote ID/Custom Code detected correctly
• Mesg Desc when using Celsius doesn't show the half degrees just the full degree i.e. 18.5 on the remote shows as 18 in the Mesg Desc.
• 10 Degree Heat Button detected as Model 5 ARRY4 lists wrong Mode, Temp and model.
• Low Outdoor Noise listed as Model: 3 (ARREB1E) - Wrong Temp but detected outdoor quiet.
• Swing On: detected as Model: 6 (ARREW4E) - shows no swing info. However, if used in conjunction with outdoor quiet (mesg desc lists as Model: 3 (ARREB1E)) the swing info is decoded correctly.
• Power off listed as Model 1 (ARRAH2E) (assuming because its just a button press/identical code)
• Step Swing listed as Model 1 (ARRAH2E) (again assuming because its just a button press/identical code)
• Powerful listed as Model: 3 (ARREB1E) (again assuming because its just a button press/identical code)
• Economy listed as Model: 3 (ARREB1E) (again assuming because its just a button press/identical code)

I also tried the power on fujitsu example, and it turns on my unit, however the unit itself has no temperature display (only the display on the IR Remote) that is going to make it difficult to know if it is set to the right temperature for example.
The status lights on the AC are also lacking (good for looks, not great for this), there is only power on/ir recieving, Economy & Timer

[crankyoldgit]

• Mesg Desc when using Celsius doesn't show the half degrees just the full degree i.e. 18.5 on the remote shows as 18 in the Mesg Desc.

Should be fixed now.

10 Degree Heat Button detected as Model 5 ARRY4 lists wrong Mode, Temp and model.

Can you please provide the state[] code for that here? I haven't added support for the 10deg thing yet. (Its not a high priority)

• Power off listed as Model 1 (ARRAH2E) (assuming because its just a button press/identical code)
• Step Swing listed as Model 1 (ARRAH2E) (again assuming because its just a button press/identical code)
• Powerful listed as Model: 3 (ARREB1E) (again assuming because its just a button press/identical code)
• Economy listed as Model: 3 (ARREB1E) (again assuming because its just a button press/identical code)

Correct. But can you please again, supply the corresponding state[] codes for those modes/settings here. I'll check to see if they can be differentiated in any way.

I've also fixed being able to set Powerful/Econo for your model too.

• Swing On: detected as Model: 6 (ARREW4E) - shows no swing info. However, if used in conjunction with outdoor quiet (mesg desc lists as Model: 3 (ARREB1E)) the swing info is decoded correctly.

I've added displaying of swing stuff to ARREW4E, let me know how that goes. (Untested thus far) Again, please supply the state[] line so I can verify/test it.

I've committed a bunch of fixes to that branch (as per above) that should address a number of issues. Please download & re-test etc. Fingers crossed some of them work correctly.

[BillyAB]

Thanks for this, apologies for the delay getting back to you, hectic week.
(You'll have to let me know how I can buy you some beers or coffees)

The half degrees are now showing as expected.

I've put all the state codes/byte breakdowns in the spreadsheet in the tab called 'Further Testing 2021-04-10'

Can you please provide the state[] code for that here? I haven't added support for the 10deg thing yet. (Its not a high priority)

10 Degree Heat:
uint8_t state[16] = {0x14, 0x63, 0x10, 0x10, 0x10, 0xFE, 0x09, 0x31, 0x69, 0x0B, 0x00, 0x23, 0x06, 0x23, 0x20, 0xEF};
So it looks like the Mode Nibble (Byte 9) for this mode is B, it also sends the previous set temp in this case 21 with the power on bit set

Correct. But can you please again, supply the corresponding state[] codes for those modes/settings here. I'll check to see if they can be differentiated in any way.

Power Off:
Remote ID A uint8_t state[7] = {0x14, 0x63, 0x00, 0x10, 0x10, 0x02, 0xFD};
Remote ID B uint8_t state[7] = {0x14, 0x63, 0x10, 0x10, 0x10, 0x02, 0xFD};

Step Swing:
Remote ID A uint8_t state[7] = {0x14, 0x63, 0x00, 0x10, 0x10, 0x6C, 0x93};
Remote ID B uint8_t state[7] = {0x14, 0x63, 0x10, 0x10, 0x10, 0x6C, 0x93};

Powerful:
Remote ID A uint8_t state[7] = {0x14, 0x63, 0x00, 0x10, 0x10, 0x39, 0xC6};
Remote ID B uint8_t state[7] = {0x14, 0x63, 0x10, 0x10, 0x10, 0x39, 0xC6};

Eco:
Remote ID A uint8_t state[7] = {0x14, 0x63, 0x00, 0x10, 0x10, 0x09, 0xF6};
Remote ID B uint8_t state[7] = {0x14, 0x63, 0x10, 0x10, 0x10, 0x09, 0xF6};

For all the non state/button press sends, the remote ID is still using byte 2.

I've added displaying of swing stuff to ARREW4E, let me know how that goes. (Untested thus far) Again, please supply the state[] line so I can verify/test it.

Swing: - It is now being detected correctly with the right model shown, but I've included the state code below
uint8_t state[16] = {0x14, 0x63, 0x10, 0x10, 0x10, 0xFE, 0x09, 0x31, 0x50, 0x01, 0x10, 0x23, 0x06, 0x57, 0x20, 0xCE};

[crankyoldgit]

I think I've worked out & implemented the 10C Heat mode/setting correctly in the latest commit to that branch. It overlaps with the "Clean" setting on some other models. Please download & test away.

I checked the other short message/states. They appear to be identical across all models. So, nothing I can do to detect your model info from them.

Hopefully, that's the last of the changes for your AR-REW4E model. Thanks for all the data & testing etc.

[BillyAB]

Thanks again for this.

Right, (this is my bad apologies) I haven't been able to test the sending properly as I was waiting for my other ESP to arrive to have a sender and a receiver, only the receiving until today. (other than very briefly the power on example with the aircon unit itself other day)

The state based sending (other than the 10deg heat) all look to be working as expected and sending the right data. However the static sends none of them seem to work.

From modifying the TurnOnFujitsuAC I've managed to get the following findings.

ac.setCmd(kFujitsuAcCmdTurnOff);
IR Code Sent: 0x14630010100209
---Should Be: 0x146300101002FD

ac.setCmd(kFujitsuAcCmdStepVert);
IR Code Sent: 0x14630010106C09
---Should Be: 0x14630010106C93

ac.setCmd(kFujitsuAcCmdEcono);
IR Code Sent: 0x14630010100909
---Should Be 0x146300101009F6

ac.setCmd(kFujitsuAcCmdPowerful);
IR Code Sent: 0x14630010103909
---Should Be: 0x146300101039C6

In all of these it looks like an issue with the last byte, I don't know if that's some kind of checksum generation that incorrectly generating for these static codes.

10 Degree Heat
So it looks to be mostly there, just 1 byte that seems to be incorrect.
Is is sending
uint8_t state[16] = {0x14, 0x63, 0x00, 0x10, 0x10, 0xFE, 0x09, 0x31, 0x81, 0x0B, 0x31, 0x00, 0x00, 0x00, 0x20, 0xF2};
When it should be more like
uint8_t state[16] = {0x14, 0x63, 0x10, 0x10, 0x10, 0xFE, 0x09, 0x31, 0x69, 0x0B, 0x00, 0x23, 0x06, 0x23, 0x20, 0xEF};
Byte 10 Looks wrong, should be 0x00 not 0x31

[crankyoldgit]

I've fixed the "short" code issue (I missed something in the checksum calc.), and the "Byte 10" issue with 10 Degree Heat (I guess neither of us noticed it sets/requires the Fan to be in Auto mode, and the Swing to be Off).

Download & try it out again please.

[crankyoldgit]

Ping @BillyAB Have you had a chance to test out the improvements?

[BillyAB]

Apologies @crankyoldgit I’ve not had chance this week, it’s my plan for tomorrow (Saturday)

[crankyoldgit]

No worries. The PR is just pending your confirmation now. ;-)

[BillyAB]

Hi @crankyoldgit

I've tested several combinations of the normal long codes and all seems good, my unit is reacting in the way you would expect (given it has no display), I've also tested the short codes applicable to my model and they now seem to be working as we'd expect :-)

Thanks again for you work on this, and do let me know how I can buy you a beer (or coffee)!

[crankyoldgit]

now seem to be working as we'd expect :-)

Excellent. Thanks for confirming.

do let me know how I can buy you a beer (or coffee)!

If you're ever in Brisbane, Australia I'll take you up on that beer, as long as you have one too!

[crankyoldgit]

FYI, the changes mentioned earlier have been included in the latest release of the library.