[SharpAC] A903: The reported temperature is always 2 degrees lower than what is shown on the remote control

[Stonos]

Version/revision of the library used

v2.8.2

Describe the bug

I have a Sharp CRMC-A724JBEZ remote control, and I'm using IRremoteESP8266 to decode its IR stream. When I use IRrecvDumpV3 all the reported values seem normal, except for the temperature which is always 2 ℃ lower than what is shown on the remote control (for example if the remote control shows 18 ℃, then IRrecvDumpV3 shows 16 ℃.

To Reproduce

Decode the message of a CRMC-A724JBEZ AC remote control.

Example code used

IRrecvDumpV3

Expected behaviour

The decoded temperature should be the same as the one shown on the remote control.

Output of raw data from IRrecvDumpV2.ino or V3 (if applicable)

Setting the temperature to 18 ℃ (the lowest that the remote can go) + cooling mode:

Protocol  : SHARP_AC
Code      : 0xAA5ACF1001312210088004F411 (104 Bits)
Mesg Desc.: Model: 3 (A903), Power: On, Mode: 2 (Cool), Temp: 16C, Fan: 2 (Auto), Swing(V): 0 (N/A), Turbo: Off, Ion: On, Light: -, Clean: Off
uint16_t rawData[211] = {3814, 1864,  496, 448,  494, 1394,  494, 450,  494, 1394,  494, 450,  492, 1394,  494, 452,  492, 1398,  490, 454,  490, 1398,  490, 454,  488, 1398,  490, 1398,  490, 456,  488, 1400,  498, 448,  496, 1392,  496, 1390,  498, 1390,  496, 1390,  498, 448,  496, 450,  496, 1392,  496, 1392,  494, 450,  494, 452,  492, 454,  490, 454,  490, 1398,  490, 456,  488, 456,  496, 448,  496, 1392,  496, 448,  494, 450,  492, 452,  492, 452,  490, 454,  488, 456,  488, 458,  496, 1392,  496, 448,  496, 450,  494, 450,  492, 1394,  494, 1394,  494, 452,  492, 454,  490, 454,  488, 1398,  490, 456,  488, 456,  498, 448,  496, 1392,  496, 448,  494, 452,  492, 452,  492, 454,  490, 454,  490, 456,  488, 1400,  488, 456,  496, 448,  496, 450,  494, 450,  492, 452,  492, 454,  490, 1398,  490, 454,  488, 456,  488, 458,  496, 448,  494, 450,  494, 450,  492, 452,  490, 454,  490, 454,  488, 456,  488, 458,  496, 1392,  496, 448,  494, 450,  494, 1394,  494, 452,  492, 452,  492, 452,  490, 456,  488, 456,  498, 448,  496, 448,  496, 1392,  496, 450,  494, 1394,  494, 1394,  492, 1394,  494, 1394,  494, 1394,  492, 452,  492, 452,  490, 454,  490, 1398,  490, 456,  488, 456,  498, 448,  496};  // SHARP_AC
uint8_t state[13] = {0xAA, 0x5A, 0xCF, 0x10, 0x01, 0x31, 0x22, 0x10, 0x08, 0x80, 0x04, 0xF4, 0x11};

Setting the temperature to 32 ℃ (the highest that the remote can go) + heating mode:

Protocol  : SHARP_AC
Code      : 0xAA5ACF100F312110088004F4C1 (104 Bits)
Mesg Desc.: Model: 3 (A903), Power: On, Mode: 1 (Heat), Temp: 30C, Fan: 2 (Auto), Swing(V): 0 (N/A), Turbo: Off, Ion: On, Light: -, Clean: Off
uint16_t rawData[211] = {3850, 1828,  522, 422,  522, 1366,  522, 422,  522, 1368,  520, 424,  518, 1368,  518, 426,  518, 1370,  518, 428,  526, 1362,  526, 420,  524, 1364,  524, 1364,  524, 420,  522, 1364,  524, 422,  520, 1366,  522, 1366,  522, 1366,  522, 1366,  522, 424,  520, 424,  518, 1368,  520, 1368,  518, 428,  526, 418,  524, 420,  524, 420,  522, 1364,  522, 422,  520, 424,  520, 426,  518, 1370,  518, 1370,  518, 1370,  518, 1370,  518, 428,  526, 418,  526, 420,  524, 422,  522, 1366,  522, 424,  520, 424,  520, 424,  518, 1370,  518, 1370,  518, 426,  526, 418,  526, 1362,  526, 418,  524, 420,  522, 422,  520, 424,  520, 1368,  520, 424,  518, 426,  528, 418,  526, 420,  524, 420,  524, 422,  522, 1366,  520, 424,  520, 424,  518, 426,  528, 418,  526, 418,  524, 420,  524, 1364,  524, 422,  522, 422,  520, 424,  520, 426,  518, 428,  526, 418,  524, 420,  524, 422,  522, 422,  522, 424,  488, 456,  518, 1370,  518, 426,  496, 448,  526, 1362,  526, 420,  494, 452,  490, 452,  522, 424,  520, 426,  498, 448,  526, 418,  526, 1362,  496, 448,  526, 1362,  524, 1362,  494, 1394,  524, 1364,  524, 1362,  496, 448,  492, 452,  522, 424,  488, 456,  488, 456,  518, 1370,  518, 1370,  498};  // SHARP_AC
uint8_t state[13] = {0xAA, 0x5A, 0xCF, 0x10, 0x0F, 0x31, 0x21, 0x10, 0x08, 0x80, 0x04, 0xF4, 0xC1};

What brand/model IR demodulator are you using?

V38238

Circuit diagram and hardware used (if applicable)

WeMos D1 Mini

I have followed the steps in the Troubleshooting Guide & read the FAQ

Yes

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

First time using it

Other useful information

I changed the following: https://github.com/crankyoldgit/IRremoteESP8266/blob/c0117617b91cb2d108940522df1ec6d580771f5f/src/ir_Sharp.h#L95

to:

const uint8_t kSharpAcMinTemp = 17;  // Celsius

and this solved my issue. However, I haven't tried transmitting yet, and this probably breaks other Sharp AC remotes.

[NiKiZe]

Do you have model of the unit as well?

To get this working, as you mention, we need a way to know which remote it is. Usually MinTemp should be the lowest value, in your case it should be 18. Now that is how it generally is in AC implementations.

Could you try and find any bits in the message that is unique to this remote? Also does it work to controll the unit from code?

[Stonos]

Do you have model of the unit as well?

It's a Sharp AY-XP12HR.

Could you try and find any bits in the message that is unique to this remote?

Any tips on how I could do that? Unfortunately I don't have access to another A903 remote that works correctly in order to compare, but I can grab a few more dumps if that would be helpful.

Also does it work to controll the unit from code?

I tried it, and it seems that it accepted the code. However, I'm not sure if the temperature was set correctly, since the unit does not have a display.

[crankyoldgit]

Great. Github or Chrome seems to have eaten my huge reply the other day.

The short version (from memory) is we need to find a difference in protocol messages to work out how to tell them apart.

Here's what we know of the message structure: https://github.com/crankyoldgit/IRremoteESP8266/blob/cdacb95d9e7124e2ffddeb36595583324101e614/src/ir_Sharp.h#L43-L84

I've already checked what we use for model differentiation, and the existing bits/checks don't work. So we need to find a something else in the areas of the message structure that are currently unused/undocumented. Currently the least significant two bits of the most significant nibble of state[7]/Byte 7. i.e. 0x00xx0000 All our code so far produced by the library have those bits set to: 0b00 while yours is set to 0b01 i.e. state[7] is 0x10.

Can you confirm all of the messages from your remote have those bits the same? The rest of that byte (state[7]) is used for the timer settings.

[Stonos]

Unfortunately no, state[7] is not always 0x10. It seems to be change whenever I use specific functions such as power on/off, turbo mode, ion on/off, etc.

I'm attaching logs where I pressed a lot of buttons: SharpAC_logs.txt

By the way, I found out that I cannot enable heating mode (it would enable the fan mode instead). Turns out it's due to this: https://github.com/crankyoldgit/IRremoteESP8266/blob/cdacb95d9e7124e2ffddeb36595583324101e614/src/ir_Sharp.cpp#L469-L479

[crankyoldgit]

Okay, than we/you need to find another way of telling it's a different model from the state[] code alone. e.g. See if you can find any consistent bits or pattern etc that differ from: https://github.com/crankyoldgit/IRremoteESP8266/blob/cdacb95d9e7124e2ffddeb36595583324101e614/src/ir_Sharp.cpp#L287-L289 and the protocol structure I listed earlier. (Pref. in some section we haven't documented a use for/of.) That will allow us consistently tell the models apart. When we have that, I can write the code to adjust/handle your specific model.

[NiKiZe]

Any luck finding an alternative byte that can help identify the remote?

[Stonos]

Sorry for the late response.

Unfortunately I wasn't able to find a unique pattern for this remote control. I ended up modifying the source code in order to make it report correct values for my remote control.

I'm still not 100% sure that transmitting works correctly this way, but I think it's fine, because the transmitted signal is also picked up by the IR receiver, and the decoded values are what was transmitted.