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 :-)