Irremoteesp8266: Suggestion for enhanced Midea Library (Coolix library) setSensorTemp not recognized by AC

[fraschizzato]

I'm trying to add some commands to Midea library, but at this time I can't really understand how.
Tried to pass the single command modifying the Swing command but without success.

The commands are related to the follow_me function. The goal is to use an esp to send room temperature to the ac, acting as remote thermostat.
I've grabbed a lot of data and get it work with arduino (IRremote library) and attiny85.

The tipical messages is: 0xBA45 (address) and 0xD22D0EF1 (message)
The address is always the same, message is for half Room Temperature and the other half Temperature Setted.

In that case:
Byte1 (D2) is room temperature 18°C - Hex conversion of the Decimal RoomTemp+192
Byte2 (2D) is complementar value of Byte1 --> So FF-D2 =2D --> FF-Byte1 = Byte 2
Byte3 (0E) is Temperature setting and Mode --> first nibble is temperature accordingly to the midea table, second nibble is the mode accordingly the same table
Byte4 (F1) the same as byte2 but for byte 3

The setting in the message does not affect the ac operational mode, so if the messages says 30°C Cool but the AC is at 17°C Heat it will remain 17°C Heat.

The Remote used is a RG57A7/BGEF - The AC is a Kaysun (Midea). Other working remotes with the device are RG57A6/BGEFU1 and RG57B/BGE (the one supplied with the AC but without FollowMe function - however the AC supports It)

All the grabbed data is in this google sheet: https://docs.google.com/spreadsheets/d/1f4dTW9s5U7kJhvi8UtJVX93kKzXYAMLAMR5qrxaTaxc/edit?usp=sharing

The messages are used also if FollowMe Function is not enabled in the AC (If I enable the function in another room and then put the remote back the ac starts using remote temperature as ambient temp).

Remote RG57A7/BGEF was used because the messages logic seems to be more simple to understand.

The remote sends a message every 2 minutes, after 7 minutes without messages the AC unit starts using it's own room temperature, a new message will restart the follow me mode.

In the link, in "MyTable" sheet there's a list of all tested commands 0 to 40°C
The other sheet are all the grabbed data with mode/temp/special function for each remote, also with some decoding.

As the variety of commands (and remotes) it could be usefull to add a generic send to the Midea Library that accepts byte data. Something like the ir_AC library from that fork of IRremote (https://github.com/marceloburegio/Arduino-IRremote)

I've made a simple sender with esp-01 but the data sended is not working - checked with arduino receiver and messages are not the ones I send. I don't think is an hardware fault but it would be great If someone can post a working circuit schematic.
I was Using GPIO2 and TSAL6400, tried with/without 2n2222 transistor and/or different resistor.
Also the signal is too low and I can't reach distance over 1meter (neither the "bad" message can be received). Original remote does flawlessly about 7-8 meters (not tested over - end of the room XD)
The room temperature is achieved with DS18B20 using RX-Pin that I didn't use.
Any help is apreciated, thanks in advance.

[crankyoldgit]

As the variety of commands (and remotes) it could be usefull to add a generic send to the Midea Library that accepts byte data.

That already exists. See: https://crankyoldgit.github.io/IRremoteESP8266/doxygen/html/classIRsend.html#a37d91b3a77b36509abdc53e2fec20a67

I'll look at the rest of the issue later when I get some spare time.

[crankyoldgit]

I've made a simple sender with esp-01 but the data sended is not working - checked with arduino receiver and messages are not the ones I send. I don't think is an hardware fault but it would be great If someone can post a working circuit schematic.

If you checked the Wiki page(s) for this project, you would have found: https://github.com/crankyoldgit/IRremoteESP8266/wiki/ESP01-Send-&-Receive-Circuit#sender

[fraschizzato]

Ok, many thanks, I will give a try in the next days to give a feedback.
Sorry, I've seen the wiki but I've missed the circuit part, thanks for linking that.
Probably the problem in transmission is related to the "instability" of GPIO0-2, I will try with GPIO-3.
Same for sendMidea, I was thinking that some conversion were made as the sended message was received differently, so the problem could be the hardware.
Only a question about sendMidea: using previous example, the command would be sendMidea( 0xBA45D22D0EF1, 48, 1) or I have to add the zero's like the hardcoded swing mode, so it will be sendMidea( 0x0000BA45D22D0EF1, 48, 1)? Obviously passing data as uint64_t.
Thanks

[crankyoldgit]

Only a question about sendMidea: using previous example, the command would be sendMidea( 0xBA45D22D0EF1, 48, 1)

That should work, assuming you want to send it with a _single_ repeat. i.e. two messages.
Otherwise just sendMidea(0xBA45D22D0EF1); will work. The default is 48 bits, and no repeats.
e.g.

const uint16_t kMideaBits = 48;
const uint16_t kNoRepeat = 0;
const uint16_t kMideaMinRepeat = kNoRepeat;

If the hexadecimal code (0xBA45D22D0EF1) is what IRrecvDumpV2-3 reported, then yes, that value should work.

[fraschizzato]

Yes, the data is from IRrecvDump but from a forked version on IRremote that supports 48bit. That shows 0xBA45 as address and the rest as data. I suppose that's a trick to send 48bit message without full modification of the library. Sending that data (with IRremote) works. And probably all my problems with IRremoteESP8266 were from GPIO0-2 Issue.
I will give a feedback soon.

[crankyoldgit]

Yes, the data is from IRrecvDump but from a forked version on IRremote that supports 48bit.

I can't speak for someone else's library. They may have a different bit order for how they construct the message. So, only if you capture it with this library can you be sure. But hey, try it. Good luck.

[fraschizzato]

Ok, thanks, I've made a mistake considering both library as the same.
Here the first catch with ESP board and IRremoteESP8266 library:

16:06:29.303 -> Protocol  : COOLIX
16:06:29.303 -> Code      : 0xBA576E (24 Bits)
16:06:29.303 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 2 (Med), Temp: 21C, Zone Follow: Off, Sensor Temp: 23C
16:06:29.350 -> uint16_t rawData[199] = {4418, 4344,  550, 1622,  524, 520,  550, 1622,  540, 1606,  530, 1616,  524, 520,  550, 1620,  524, 520,  550, 520,  550, 1622,  524, 520,  574, 498,  550, 522,  550, 1622,  522, 522,  550, 1622,  524, 520,  552, 1620,  524, 520,  550, 1622,  524, 520,  550, 1622,  524, 1622,  522, 1622,  524, 1620,  522, 520,  552, 1622,  524, 522,  550, 1622,  522, 520,  550, 520,  552, 520,  550, 520,  550, 1622,  522, 1622,  524, 520,  550, 1622,  524, 1620,  522, 1622,  524, 520,  552, 1622,  522, 522,  550, 520,  550, 1622,  524, 520,  552, 520,  552, 520,  550, 1622,  522, 5182,  4392, 4370,  550, 1594,  550, 522,  548, 1594,  552, 1592,  552, 1592,  552, 518,  578, 1568,  576, 494,  578, 496,  576, 1568,  578, 494,  552, 518,  578, 492,  554, 1590,  552, 520,  578, 1566,  578, 492,  578, 1566,  578, 494,  578, 1566,  580, 494,  578, 1564,  578, 1566,  580, 1564,  580, 1564,  580, 490,  580, 1566,  580, 492,  578, 1566,  580, 492,  580, 492,  580, 492,  580, 490,  580, 1566,  578, 1566,  578, 492,  580, 1564,  580, 1564,  580, 1564,  580, 492,  578, 1566,  580, 492,  580, 494,  578, 1564,  578, 494,  580, 492,  578, 492,  578, 1566,  578};  // COOLIX BA576E
16:06:29.443 -> uint64_t data = 0xBA576E;

The unit is recognized as Coolix with only 24 bit data. Follow me temperature is already reported! Unfortunatly Zone Follow remains off also if enabled.
Now I'm waiting first FollowMe messages and then make a try on transmission.

I'm using a NodeMCU v1 because with ESP-01 (tried gpio 0-2-3) I always get strange data, didn't know why. It's like something other happen on the gpio (Ir receiver led keeps blinking "randomly"). In my experience that the first time with a similiar issue with esp01.

Next follow_up (probably for closing the issues) will be about transmission and confirmation of support for that remote and AC unit (Kaysun) midea Based (recognized as Coolix)

Meanwhile, here the message from Follow Me Mode, recognized correctly.

16:12:39.384 -> Protocol  : COOLIX
16:12:39.384 -> Code      : 0xBAD76E (24 Bits)
16:12:39.384 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 6 (Zone Follow), Temp: 21C, Zone Follow: Off, Sensor Temp: 23C
16:12:39.431 -> uint16_t rawData[199] = {4418, 4346,  550, 1622,  524, 520,  550, 1622,  522, 1622,  524, 1622,  524, 522,  550, 1620,  546, 500,  550, 522,  550, 1622,  524, 520,  550, 520,  550, 522,  550, 1620,  550, 496,  550, 1622,  526, 1620,  548, 1598,  524, 522,  550, 1622,  526, 518,  550, 1622,  524, 1620,  524, 1620,  548, 498,  550, 522,  550, 1620,  524, 520,  550, 1622,  524, 520,  574, 498,  550, 520,  550, 522,  550, 1620,  538, 1608,  548, 496,  550, 1622,  524, 1620,  524, 1620,  550, 496,  550, 1622,  548, 496,  550, 522,  550, 1622,  548, 498,  550, 522,  550, 520,  552, 1620,  526, 5182,  4418, 4344,  576, 1594,  550, 496,  550, 1620,  550, 1594,  550, 1596,  550, 496,  576, 1594,  526, 520,  574, 498,  550, 1620,  526, 520,  574, 498,  550, 520,  552, 1620,  550, 496,  550, 1620,  548, 1594,  528, 1618,  526, 520,  550, 1620,  526, 520,  576, 1594,  526, 1618,  552, 1592,  550, 496,  574, 498,  552, 1618,  528, 520,  550, 1618,  528, 520,  574, 496,  552, 522,  572, 498,  548, 1620,  526, 1618,  550, 496,  574, 1596,  524, 1598,  548, 1618,  524, 524,  548, 1598,  548, 522,  550, 524,  548, 1598,  546, 526,  546, 526,  544, 524,  548, 1596,  548};  // COOLIX BAD76E
16:12:39.524 -> uint64_t data = 0xBAD76E;

[fraschizzato]

Ok, all command works with Coolix integration, except for the one I need... The setSensorTemp is not accepted/used by the AC. It seems does nothing, probably i'm doing something wrong. Here the code I use and tested ok with on/off, mode, setTemp, etc.

#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>
#include <ir_Coolix.h>

const uint16_t kIrLed = 4;  // ESP8266 GPIO pin to use. Recommended: 4 (D2).
IRCoolixAC ac(kIrLed);  // Set the GPIO to be used to sending the message.

void setup() {
  ac.begin();
  Serial.begin(115200);
}

void loop() {
  Serial.println("Sending...");

  // Set up what we want to send. See ir_Coolix.cpp for all the options.
  ac.setFan(kCoolixFanZoneFollow);
  ac.setSensorTemp(17);
#if SEND_COOLIX
  // Now send the IR signal.
  ac.send();
  Serial.println("Sended");
#else  // SEND_COOLIX
  Serial.println("Can't send because SEND_ARGO has been disabled.");
#endif  // SEND_COOLIX

  delay(60000);
}

In the other end the message sent appear correct:

17:59:31.264 -> Protocol  : COOLIX
17:59:31.264 -> Code      : 0xBAD1C8 (24 Bits)
17:59:31.264 -> Mesg Desc.: Power: On, Mode: 2 (Auto), Fan: 6 (Zone Follow), Temp: 25C, Zone Follow: Off, Sensor Temp: 17C
17:59:31.264 -> uint16_t rawData[199] = {4670, 4452,  582, 1662,  552, 526,  582, 1658,  552, 1658,  554, 1658,  552, 526,  582, 1658,  530, 550,  582, 524,  582, 1658,  552, 524,  582, 526,  582, 526,  558, 1682,  550, 526,  582, 1658,  552, 1658,  528, 1684,  552, 526,  582, 1660,  526, 550,  582, 524,  560, 548,  556, 1684,  528, 550,  558, 548,  582, 1658,  526, 550,  558, 1684,  526, 1684,  526, 1684,  528, 552,  556, 1684,  526, 1684,  526, 550,  558, 550,  556, 1684,  526, 552,  556, 550,  556, 552,  556, 552,  556, 550,  554, 1686,  524, 1686,  526, 552,  556, 1658,  554, 1656,  554, 1656,  582, 5214,  4742, 4376,  590, 1622,  590, 518,  588, 1622,  590, 1622,  588, 1624,  586, 520,  588, 1622,  588, 520,  586, 520,  586, 1624,  586, 522,  584, 520,  586, 520,  588, 1624,  586, 522,  586, 1626,  586, 1626,  584, 1626,  584, 522,  584, 1628,  582, 524,  582, 524,  584, 524,  584, 1628,  584, 524,  582, 524,  582, 1628,  582, 524,  580, 1630,  580, 1630,  580, 1630,  580, 528,  580, 1632,  578, 1632,  578, 528,  580, 528,  578, 1632,  578, 528,  578, 530,  578, 530,  578, 530,  576, 528,  580, 1632,  578, 1632,  578, 530,  576, 1636,  552, 1660,  574, 1636,  550};  // COOLIX BAD1C8
17:59:31.353 -> uint64_t data = 0xBAD1C8;

Here the original remote one:

16:12:39.384 -> Protocol  : COOLIX
16:12:39.384 -> Code      : 0xBAD76E (24 Bits)
16:12:39.384 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 6 (Zone Follow), Temp: 21C, Zone Follow: Off, Sensor Temp: 23C
16:12:39.431 -> uint16_t rawData[199] = {4418, 4346,  550, 1622,  524, 520,  550, 1622,  522, 1622,  524, 1622,  524, 522,  550, 1620,  546, 500,  550, 522,  550, 1622,  524, 520,  550, 520,  550, 522,  550, 1620,  550, 496,  550, 1622,  526, 1620,  548, 1598,  524, 522,  550, 1622,  526, 518,  550, 1622,  524, 1620,  524, 1620,  548, 498,  550, 522,  550, 1620,  524, 520,  550, 1622,  524, 520,  574, 498,  550, 520,  550, 522,  550, 1620,  538, 1608,  548, 496,  550, 1622,  524, 1620,  524, 1620,  550, 496,  550, 1622,  548, 496,  550, 522,  550, 1622,  548, 498,  550, 522,  550, 520,  552, 1620,  526, 5182,  4418, 4344,  576, 1594,  550, 496,  550, 1620,  550, 1594,  550, 1596,  550, 496,  576, 1594,  526, 520,  574, 498,  550, 1620,  526, 520,  574, 498,  550, 520,  552, 1620,  550, 496,  550, 1620,  548, 1594,  528, 1618,  526, 520,  550, 1620,  526, 520,  576, 1594,  526, 1618,  552, 1592,  550, 496,  574, 498,  552, 1618,  528, 520,  550, 1618,  528, 520,  574, 496,  552, 522,  572, 498,  548, 1620,  526, 1618,  550, 496,  574, 1596,  524, 1598,  548, 1618,  524, 524,  548, 1598,  548, 522,  550, 524,  548, 1598,  546, 526,  546, 526,  544, 524,  548, 1596,  548};  // COOLIX BAD76E
16:12:39.524 -> uint64_t data = 0xBAD76E;

Tested a second remote (working with the same AC unit).
It' recognized as MIDEA by dumpV3 - So i've started trying with Midea integration.
Library seems to not support follow Me messages, tipical messages about FollowMe are:

Follow Me On
18:09:13.819 -> Protocol  : MIDEA
18:09:13.819 -> Code      : 0xA4A347FF15B1 (48 Bits) 
Follow Me Message 21°C
18:12:09.846 -> Protocol  : MIDEA
18:12:09.846 -> Code      : 0xA4A3477F1673 (48 Bits)
Follow Me Message 22°C
A4A3477F1772
FollowMe Message 25°C
A4A3477F1A7B
FollowMe Message 24°C
A4A3477F1979

The moving part (last 2 byte) is:
First byte = Temp celsius + 1 (so dec of that byte minus 1 is the room temp)
Second byte is CRC of the whole packet, accordingly to the midea google sheet (linked in the Midea cpp)
Fixed part (as assumed before) must be the mode/tempSet

First declared issues (not corresponding data sent/received) is still there.
If i send using ac.sendMidea(0xA4A3477F1979); i get on the receiver side:

18:48:40.218 -> Protocol  : UNKNOWN
18:48:40.218 -> Code      : 0x2800A054 (50 Bits)
18:48:40.218 -> uint16_t rawData[99] = {4466, 4522,  550, 1726,  532, 572,  574, 1698,  550, 554,  574, 556,  572, 1700,  550, 556,  572, 554,  572, 1698,  550, 552,  578, 1696,  552, 554,  576, 552,  574, 554,  572, 1700,  550, 1698,  550, 554,  574, 1698,  550, 578,  550, 556,  574, 552,  576, 1696,  552, 1696,  574, 1674,  552, 552,  576, 1674,  574, 1696,  554, 1696,  552, 1696,  580, 1646,  602, 1668,  552, 1672,  604, 548,  580, 548,  578, 550,  578, 1646,  606, 1644,  604, 548,  580, 548,  580, 1644,  604, 548,  580, 1644,  604, 1642,  606, 1644,  606, 1642,  604, 548,  584, 542,  582, 1650,  606};  // UNKNOWN 2800A054

Curiosity: I've tried freezing both remotes, they still sends data at 0°C (not grabbed with IRremoteESP8266 library but with IR remote). Same about over 30°C. So also Colix integration (that fixes limit between 16-30°C) is not completely true.

[crankyoldgit]

not grabbed with IRremoteESP8266 library but with IR remote

Can you please make it clear in your reports/data when you are NOT using our library?

The raw data you collected (UNKNOWN 2800A054) is only half of a MIDEA message.

I've verified that _our_ library is correctly sending a full length MIDEA message via sendMidea() and that it also can decode that sent message too. See: https://github.com/crankyoldgit/IRremoteESP8266/commit/1ba5a68cbc66d3b6170318c95fd5ff207fb0fbf2

[fraschizzato]

Yes, sorry. Last two posts are with Your library only. For sending and receiving i'm using two esp8266 board (wemos clone), both with Your library, one with the sending sketch above (modified version of the argo example) and the other with IRreceiveDumpV3 or V2.
The message from the second remote is correctly reported as midea (0xA4A3477F1979), if I try to send the same data with esp, the receiver (same used for remote) receives only the UNKNOWN data.
thanks for your time.

[crankyoldgit]

if I try to send the same data with esp, the receiver (same used for remote) receives only the UNKNOWN data.

Please post your code for that. You haven't provided that. As far as I can tell via my own testing, irsend.sendMidea(0xA4A3477F1979); is doing exactly the right thing. I suggest you re-check your code.

[fraschizzato]

Here the code, I've seen now the error...

#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>
#include <ir_Midea.h>

const uint16_t kIrLed = 4;  // ESP8266 GPIO pin to use. Recommended: 4 (D2).
IRsend ac(kIrLed);  // Set the GPIO to be used to sending the message.

void setup() {
  ac.begin();
  Serial.begin(115200);
}

void loop() {
  Serial.println("Sending...");

  // Set up what we want to send. See ir_Coolix.cpp for all the options.
#if SEND_COOLIX
  // Now send the IR signal.
  ac.sendMidea(0xA4A3477F1979);
  Serial.println("Sended");
#else  // SEND_
  Serial.println("Can't send because SEND_ARGO has been disabled.");
#endif  // SEND_COOLIX

  delay(60000);
}

The fault I suppose is inif SEND_COOLIX , now I think It has to be SEND_MIDEA
I will give a try and probably the sendMidea issues is my fault, have to check if the data does the followMe trick.

However I can't understand why with Coolix Integration works flawlessly with all commands but not with the setSensorTemp
data sended from the remote is the same of the esp (checked as mentioned before) but the AC doesn't get that.
Thanks

[fraschizzato]

Corrected code now works, device responds correctly. Final report is:

My Device KaysunAC works with Coolix Integration for all commands except FollowMe mode (setSensorTemp()), data is sended correctly but AC does not respond about that. Remote used for tests is RG57A7/BGEF

My Device also works correctly with Midea Integration for all commands, excpept FollowMe that is not implemented (more data below). The FollowMe code from the remote, if replied to the device, works and sets AC room temperature to sended value). Remote used for tests is RG57A6/BGEFU1.

The FM mode is listed in the google-sheet from cpp (https://docs.google.com/spreadsheets/d/1TZh4jWrx4h9zzpYUI9aYXMl1fYOiqu-xVuOOMqagxrs/edit?usp=sharing)
I think temperature data is in °F, in my case it's in °Celsius, So that
0xA482407F174D is setTemp 17°C and roomTemp 22°C (Auto mode-fan Auto)
0xA482487F1644 is setTemp 22°C and roomTemp 21°C (Auto mode-fan Auto)
Where Byte4 is Room Temperature in the form HEX2DEC(Byte4)-1

Thanks for the support, hope that can be helpfull for full integration

[crankyoldgit]

My Device KaysunAC works with ...

Any chance you can provide us with the Model number for the actual Kaysun A/C so we can add it to the list of supported devices?

[crankyoldgit]

Where Byte4 is Room Temperature in the form HEX2DEC(Byte4)-1

Can you elaborate/expand on this please?
Your spreadsheet data for Byte4 (https://docs.google.com/spreadsheets/d/1TZh4jWrx4h9zzpYUI9aYXMl1fYOiqu-xVuOOMqagxrs/edit#gid=1191265844&range=P:Q)
Indicates that the Follow Me is in the Fahrenheit scale.
e.g.

0xA482407F174D is setTemp 17°C and roomTemp 22°C (Auto mode-fan Auto)

So Byte[4] would be 0x17, and according to your sheet that would be 56 (decimal) 56°F in Celsius is 13.33°C, which is a long way off your suggested 22°C in the text above.

[fraschizzato]

AC Unit is "Kaysun Casual CF".

Addititional remote working with this is RG57B/BGE (the one supplied with the device), correctly reported from Your library as Coolix

Byte[4], converting 17 from hex to dec gives me 23, that's 1 more of display °C (22)
same for other grabs: 1A from hex to dec gives me 26, that's 1 more of display °C (25)

That's not my sheet, is the one listed in the ir_Midea.cpp from your library, I've supposed that it's for °F and so I've listed some data messages in °C to explain how I suppose it works.

[crankyoldgit]

AC Unit is "Kaysun Casual CF".

Thanks. I'll update that it supports it under Coolix in a moment.

Byte[4], converting 17 from hex to dec gives me 23, that's 1 more of display °C (22)
same for other grabs: 1A from hex to dec gives me 26, that's 1 more of display °C (25)

Ah. Okay. I get it now. I was confused, obviously.
So, what are the minimum and maximum values for the "room" (sensor) temp based on your analysis?
I'm guessing a value of 0x00 in Byte[4] would be 0°C. Correct? If so, what's the maximum room/sensor temp you've been able to generate?

This is the range we currently allowed for/assumed:

const uint8_t kCoolixSensorTempMin = 16;  // Celsius
const uint8_t kCoolixSensorTempMax = 30;  // Celsius

[fraschizzato]

Have to re-test with your library but as per assumption 0°C would be 0x01 So decimal would be 1 and minus one it will be 0.

I have to take some dump with your library to confirm that, but (testing with the other lib) I've seen that the device goes down and still trasmit at 0°C. For max temp I have to test it (max reached was 27°C but "limited by the environment"), I haven't found a secure way to heat the remote without damaging it. I suppose that 30 to 50°C can be reached
Any idea about? For 0 i've put the remote in the fridge XD.

The actual grabbed data is the following:

FollowMe Temp | FollowMe message
21 | A4A3477F1673
25 | A4A3477F1A7B
24 | A4A3477F1979
22 | A4A3477F1772
22 | A482407F174D

17°C packet was created manually and it works.

Before tomorrow I can add other values (down to 0°C), and, if a good way is found, also values over 25.

[crankyoldgit]

Na, that's fine. If you've recorded an approx 1-2°C or similar, I'll take your word for it. It probably bottoms out at 0°C. That seems supportable.
Max temp. yeah, don't go melting your remote. I'll set it to 63°C (i.e. 0x3F / 0b111111).

_Hmmm_. Actually. Looking at the structure of the message again. We've got some overlap.
Currently for Coolix, we've got the Sensor Temp using these bits (a bit mask of 0xF00) i.e. 8th to the 11th (inclusive) _least significant_ bits of the message code, 4 bits long. And the Fan speed control has a bit mask of 0x7000. i.e. 12th to the 14th (inclusive) _least significant_ bits of the message code, 3 bits long. There is no way to fit more "Sensor" temp values than the current 16 (4 bits) in that space, because otherwise we start over-writing the fan speed control location(s).

So we should collect _real_ readings from the remote while it's sensor temp is (well) below 16°C, and above 32°C to confirm what it's really doing. i.e. How it's packing in more that 16 values (4bits) into a 4 bit space, or for us to work out if there is something special we don't understand about these "sensor" messages.

[crankyoldgit]

Any idea about? For 0 i've put the remote in the fridge XD.

To get values over 25C, maybe put the remote in a ziplock bag (to keep it water proof-ish) and hold it safely above a boiling kettle?!?! i.e. Steam is 100C, so be careful etc. Don't need a value that high of course. 34C or higher should give us the data we need. Or near a heater/fireplace .. or _high_ over a candle etc. Or an oven that set very low? Often they can be set to ~40C.

Just be careful, and don't damage your remote. ;-)

[fraschizzato]

wait wait, I think we are confused, unfortunatly we are talking about two different remotes that uses two different protocols:

This data:

FollowMe Temp | FollowMe message
21 | A4A3477F1673
25 | A4A3477F1A7B
24 | A4A3477F1979
22 | A4A3477F1772
22 | A482407F174D

and the considerations about HEX to DEC is related only to the Midea protocol.
Probably the overlapping is avoided by the fact that FollowMe Messages have starting byte at0xA4 instead of "normal" messages that are starting with 0xA1. In fact, the overlapping would be constant if we watch at the °F data (that starts as listed, from 62°F to 86°F)

---

The coolix remote sends the same data that I can send via your Library, the fact is not the data itself but that the AC is not using that (tell me if I had to clarify, with my limited english I'm probably not always comprensible)
I've seen a little difference in raw data but I don't think it can be the issue (The other commands works, so can't be a general timing issue)

---

Now both remotes are in fridge (XD) next post will cointain data from both remotes at different sub16°C values.
Next step are temperature over 32°C, I've found the simpliest and easiest way to heat the remote (i'm feeling dumb about this, XD), place the remote near the AC that now I'm using in heat mode...

[fraschizzato]

I will made two posts to avoid confusion:

This is FollowMe data about Midea protocol

|Midea Temp From Remote Screen | Midea Message | Byte 5 | TEST Midea HEX2DEC(Byte5)-1|
|-- | -- | -- | --|
|0 - MIN | 0xA482467F015D | 01 | 0|
|4 | 0xA482467F0559 | 05 | 4|
|7 | 0xA482467F0854 | 08 | 7|
|9 | 0xA482467F0A57 | 0A | 9|
|11 | 0xA482467F0C50 | 0C | 11|
|13 | 0xA482467F0E53 | 0E | 13|
|14 | 0xA482467F0F52 | 0F | 14|
|15 | 0xA482467F104C | 10 | 15|
|16 | 0xA482467F114D | 11 | 16|
|17 | 0xA482467F124F | 12 | 17|
|18 | 0xA482467F134E | 13 | 18|
|25 | 0xA482467F1A47 | 1A | 25|
|28 | 0xA482467F1D41 | 1D | 28|
|30 | 0xA482467F1F42 | 1F | 30|
|31 | 0xA482467F206C | 20 | 31|
|33 | 0xA482467F226F | 22 | 33|
|33 | 0xA482467F226F | 22 | 33|
|35 | 0xA482467F2468 | 24 | 35|
|37 | 0xA482467F266B | 26 | 37|
|37-MAX | 0xA482467F266B | 26 | 37|

Test was always with Mode Auto - Fan Auto - SetTemp 23°C

[fraschizzato]

That's the Coolix protocol grab.

|Coolix Temp From Remote Screen | Coolix Message | Byte 2 | TEST Coolix HEX2DEC(Byte2)-192|
|-- | -- | -- | --|
|0 - MIN | 0xBAC04A | C0 | 0|
|5 | 0xBAC54A | C5 | 5|
|8 | 0xBAC84A | C8 | 8|
|10 | 0xBACA4A | CA | 10|
|12 | 0xBACC4A | CC | 12|
|14 | 0xBACE4A | CE | 14|
|15 | 0xBACF4A | CF | 15|
|16 | 0xBAD04A | D0 | 16|
|17 | 0xBAD14A | D1 | 17|
|18 | 0xBAD24A | D2 | 18|
|19 | 0xBAD34A | D3 | 19|
|26 | 0xBADA4A | DA | 26|
|27 | 0xBADBDE | DB | 27|
|29 | 0xBADDDE | DD | 29|
|30 | 0xBADEDE | DE | 30|
|32 | 0xBAE0DE | E0 | 32|
|34 | 0xBAE2DE | E2 | 34|
|36 | 0xBAE4DE | E4 | 36|
|37 | 0xBAE5DE | E5 | 37|
|40 | 0xBAE8DE | E8 | 40|
|44 | 0xBAECDE | EC | 44|
|46 | 0xBAEEDE | EE | 46|
|50 - MAX | 0xBAF2DE | F2 | 50|

From 0 to 26 - Set Mode was Auto , fan Auto, setTemp 24°C
From 27 to 50 - Set Mode was Heat, fan Auto, setTemp 24°C

The most of the grabbed data from both remote was saved in that txt file https://drive.google.com/file/d/1xuPcXIQRbwZgwuclgjMhuv_OMf-1vTpb/view?usp=sharing

My Google sheet was updated with a sheet named "Kaysun FollowMe" with data from both remotes and some calc to check logic. https://docs.google.com/spreadsheets/d/1f4dTW9s5U7kJhvi8UtJVX93kKzXYAMLAMR5qrxaTaxc/edit#gid=2046371997

In Coolix values are from C0 to F2 rappresenting 0 to 50°C linearly
In Midea values are from 01 to 26 rappresenting 0 to 37°C linearly

Max temp for Midea is 37°C
Max temp for Coolix is 50°C

Hope it helps, thanks

Ah, as I've get both remotes aftermarket they have different label printed on:
The Coolix one RG57A7/BGEF is branded "KASTRON Inverter" (so probably also that AC are supported)
The Midea one RG57A6/BGEFU1 is branded "MrCool"

[crankyoldgit]

@fraschizzato Ahh. Thanks ever so much for pointing out where I was going wrong, and thanks for the data and clarifications. P.S. Your English is fine. It's just I can be thick some times. ;-) Plus, text isn't the greatest way to communicate some times.

I'm going to try to focus on fixing/improving MIDEA first. When that's working to what you need, then move on to the COOLIX protocol. To that end, I've created a new branch (https://github.com/crankyoldgit/IRremoteESP8266/tree/kaysun) that adds _some_ support for your "FollowMe" feature thing.
Can I please get you to download and test it out? I also need you to collect some sensor data when the remote is in Fahrenheit mode to make sure we know what it does there as the A/C class object supports both C & F operations.

As it stands, the latest commit to that branch should decode the Sensor/FollowMe temps in C. It does NOT yet handle the 0xA4 vs 0xA1 bit yet. I want some more data from you before I try decoding/guessing what that byte actually does.
I suspect it's a normal message, but the bits might also control if the A/C beeps etc. i.e. It needs some more experimentation/data.

[fraschizzato]

Here first °F data (tell me if more is needed)

|Fahrenheit | Message | Byte 5|
|-- | -- | --|
|82 | 0xA482607F3353 | 33|
|81 | 0xA482607F3252 | 32|
|78 | 0xA482607F2F45 | 2F|
|76 | 0xA482607F2D47 | 2D|
|75 | 0xA482607F2C46 | 2C|
|74 | 0xA482607F2B43 | 2B|

There will be an obvious overlapping with Celsius data, probably the distinction between two units is based on setTemp value.
In Fahrenheit mode 62°F is the lowest temperature can be set and it's Byte3 0x60 (at setTemp 79°F Byte3 is 0x71, so is linear)
In Celsius mode 30°C is the maximun temperature can be set and it's Byte3 0x4D (at setTemp 23°C is 0x46, so it's linear)

I suppose that any setTemp over a certain limit says to the AC if it's °F or °C - in that case every byte3 over 0x4D can't be Celsius (but didn't know if different remotes have same limit). Ideally, as setTemp must be in a known limited range it can be "caged" between fixed values.

PS. Byte1 0xA4 seems to be always fixed in FollowMe messages, Byte2 changes with Mode/Fan change (0x82 Auto/Auto , 0xA0 Cool/Auto, 0x90 Cool/Speed2), Byte3 is setTemp, Byte5 is roomTemp, Byte6 is CRC, Byte4 (0x7F) seems to be FollowMe "status". So Byte1 0xA4 means "FollowMe message", then Byte4 is "kind of message" where 0x7F is Update,0xFF is On and 0x3F is Off.
Note: AC uses Update message also if function was not activated (tested by entering FollowMe mode in the remote without let the AC unit know - other room)
Note2: setTemp/mode/fan in follow me messages does not affect unit operation (So, if unit is in heat-speed2-17°C it remains like this also if followMe message sends auto-auto-20°C

Next Post with test results of Kaysun branch

[crankyoldgit]

Thanks for the new data. I think I've corrected it to handle Sensor Temps in Fahrenheit now. Feel free to download that branch again and test.

then Byte4 is "kind of message" where 0x7F is Update,0xFF is On and 0x3F is Off.

So, to confirm I (don't :) understand it correctly before I write code to support it.

• 7F is _"this is a message from the remote telling you that the temp at the remote is Blah. Probably don't make a beep or anything because that would be annoying every few mins"_.
• 3F is _"Go back to normal operation mode before I set you into FollowMe mode, oh and probably make a beep so the user knows I got the message"_.
• FF is _"Use the SensorTemp to adjust your operation mode (if set), oh, and probably make a beep to let the user know I got the message"_.

Note: FF is also the value used in typical _"user mashing buttons on the remote to control the A/C"_ mode messages. i.e. Non-FollowMe mode. e.g. When 0xA1 is used at the start.

Is that correct? If not, what am I getting wrong/missing with respect to that 4th byte?

[fraschizzato]

Exactly, also about the "beep". About followMe the AC and Remote Logic is that:
Remote sends temp every 2 or 3 minutes (if received the unit use that)
If the device don't get a new message in 7 minutes the AC unit start using its own temp
A new message will force the AC to use Remote Temp.
Note: In previous tests (but have to recheck) too many FollowMe messages (in short time) will cause the unit to not use this. I've previously found that 1 minute is enough to not trigger that behavor.

Now I'm testing the branch supplied bevore. Actually I can confirm working: on/off, all modes (auto/heat/cool/dry/fan). Follow me seems not working and it beeps (when the attended is not). For other function I have to check if I missed something in my test code, here the one I'm watching now (commented code is working):

#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>
#include <ir_Midea.h>

const uint16_t kIrLed = 4;  // ESP8266 GPIO pin to use. Recommended: 4 (D2).
IRMideaAC ac(kIrLed);  // Set the GPIO to be used to sending the message.

void setup() {
  ac.begin();
  Serial.begin(115200);
  //ac.on(); //OK default °F
  //ac.off(); //OK
  ac.setUseCelsius(true);
  //ac.setMode(kMideaACHeat);
  //ac.setTemp(17);
  //ac.send();
  //Serial.println("Heat 17");
  //delay(15000);
  ac.setTemp(25);
  ac.send();
  Serial.println("Heat 25");
  delay(15000);
  ac.setTemp(30);
  ac.send();
  Serial.println("Heat 30");
  delay(15000);
  ac.setFan(kMideaACFanLow);
  ac.send();
  Serial.println("Fan Low");
  delay(15000);
  ac.setFan(kMideaACFanMed);
  ac.send();
  Serial.println("Fan Med");
  delay(15000);
  ac.setFan(kMideaACFanHigh);
  ac.send();
  Serial.println("Fan High");
  delay(15000);
  ac.setFan(kMideaACFanAuto);
  ac.send();
  Serial.println("Fan Auto");
  delay(15000);
  ac.setSleep(true);
  ac.send();
  Serial.println("Sleep ON");
  delay(15000);
  ac.setSleep(false);
  ac.send();
  Serial.println("Sleep OFF");
  delay(15000);
  ac.setSwingVToggle(true);
  ac.send();
  Serial.println("Swing ON");
  delay(15000);
  ac.setSwingVToggle(false);
  ac.send();
  Serial.println("Swing OFF");
  delay(15000);
  ac.setEconoToggle(true);
  ac.send();
  Serial.println("Eco ON");
  delay(15000);
  ac.setEconoToggle(false);
  ac.send();
  Serial.println("Eco OFF");
  delay(15000);
  //ac.setMode(kMideaACFan);
  //ac.send();
  //Serial.println("Fan Mode");
  //delay(15000);
  //ac.setMode(kMideaACCool);
  //ac.send();
  //Serial.println("Cool Mode");
  //delay(15000);
  //ac.setMode(kMideaACDry);
  //ac.send();
  //Serial.println("Dry Mode");
  //delay(15000);
  //ac.setMode(kMideaACAuto);
  //ac.send();
  //Serial.println("Auto Mode");
  //delay(15000);
  ac.setSensorTemp(37,true);
  ac.send();
  Serial.println("FollowMe 37");
  delay(60000);
  ac.setSensorTemp(0,true);
  ac.send();
  Serial.println("FollowMe 0");
  delay(60000);
  ac.setSensorTemp(17,true);
  Serial.println("FollowMe 17");
  ac.send();
  //delay(60000);
  //ac.off();
  //ac.send();
  //Serial.println("Off - End");

}

void loop() {
} 

Note that first test was a single run of that code (so nothing was commented)

[fraschizzato]

Mid-report about working feature:

• ON/OFF
• All Modes (Heat, Cool, Dry, Fan, Auto)
• All Fan Speed (Min,Med,Max,Auto)
• All Temp Settings (Tested 17 - 25 - 30)
• Sleep Mode (on/off)

Not Working:

• Swing (I will catch packet from remote)
• Follow Me (Device starts Timer Mode! XD)
• Eco Mode (Can't test - Not supported by the AC and Remotes)

Not implemented (I will post data about that):
-Turbo Mode (used to reach desidered temp in less time)
-Led (used to switch on/off AC display)
-Self-Clean (not supported by my AC but provided by the remote)
-Timer ON (delay on start device)
-Timer OFF (delay on stop device)

For the last two it makes some time because there's a "time" variable (selectable by multiple press)

Sorry for multiple posts but doing multiple task in the same time is the only way to provide all informations without confusing and not reminding things

[fraschizzato]

0xA18248FFFF54 - Swing toggle ON/OFF from library
0xA202FFFFFF7E - Swing mode ON/OFF on remote (note the starting byte at 0xA2
0xA201FFFFFF7C - "Direct" command - allow to move manually the "swing vertical things". Each press will move the (sorry) "things that is moving when swing" by a little (to direct the air flow)

0xA209FFFFFF74 - Turbo Mode ON/OFF

0xA208FFFFFF75 - LED Mode ON/OFF (switch on/off AC "screen" and beeps)

`` - Self-Clean - Not supported by my device, no ir signal when pressed (checked also with camera) - Only printed on button :-)

Follow Me:
ac.setSensorTemp(37,true); produces 0xA18248FF26A3, so 0xA1 instead of 0xA4, 0x3F 0xFF 0x7F not as stated above. I think that 0x7F must be the default (as the device uses that temp - without beeping - also if function is enabled or disabled)

Timer ON - Step 0,5 hour until 9,5 hours and then step by 1. Moving byte is 5, step between 0,5 value is 2 and betwen 1 value is 4, latest value disables timer.

|Message | Hour Delay | Descr | Byte 5|
|-- | -- | -- | --|
|0xA1A34DFF8121 | 0,5 | Half Hour | 81|
|0xA1A34DFF8322 | 1 |   | 83|
|0xA1A34DFF8526 | 1,5 |   | 85|
|0xA1A34DFF8724 | 2 |   | 87|
|0xA1A34DFF892E | 2,5 |   | 89|
|0xA1A34DFF8B2C | 3 |   | 8B|
|0xA1A34DFF8D2A | 3,5 |   | 8D|
|0xA1A34DFF8F28 | 4 |   | 8F|
|0xA1A34DFF913E | 4,5 |   | 91|
|0xA1A34DFF933C | 5 |   | 93|
|0xA1A34DFF953A | 5,5 |   | 95|
|0xA1A34DFF9738 | 6 |   | 97|
|0xA1A34DFF9936 | 6,5 |   | 99|
|0xA1A34DFF9B34 | 7 |   | 9B|
 | | .... | Until 9,5 step is 0,5 |  |
|0xA1A34DFFA704 | 10 | From 10 step is 1 | A7|
|0xA1A34DFFAB0C | 11 |   | AB|
|  | ... |   |  |
|0xA1A34DFFDB54 | 23 |   | DB|
|0xA1A34DFFDF50 | 24 |   | DF|
|0xA1234DFFFFE0 | 0 | OFF - Disable Timer | FF|

Timer OFF - same logic as above but moving byte is Byte 4 (the rest of the message is the same). Also changes off command.

|Message | Hours | Descr | Byte 4|
|-- | -- | -- | --|
|0xA1A34D81FF21 | 0,5 |   | 81|
|0xA1A34D83FF22 | 1 |   | 83|
 | | ... |   |  |
|0xA1A34D8BFF2C | 3 |   | 8B|
|  | ... |   |  |
|0xA1A34DA7FF04 | 10 |   | A7|
|0xA1A34DABFF0C | 11 |   | AB|
|  | ... |   |  |
|0xA1A34DDFFF50 | 24 |   | DF|
|0xA1A34DFFFF60 | 0.0 | OFF | FF|

I think timer starts with0xA1 because is a delayed start/stop so it's regarding on/off and not function (as per logic curiosity)

0xA212FFFFFF6E "Silence FP" key on remote - AC does nothing - didn't know who-where-why-when and how :-)

Didn't know why "wrong" follow me messages produces Timer mode on device (messages are different, maybe other mappings)
EDIT: Maybe because byte2 0xA3 is Heat/fanAuto Mode in remote messages and 0x82 is Auto/Auto (not noticed the difference because during tes device was already in Auto/Auto.

I think (hope XD) that's all. I think that MIDEA didn't know about all this stuff XD
Thank for your time and your support

[crankyoldgit]

Thanks for the data. Just getting back to this issue now.

0xA202FFFFFF7E - Swing mode ON/OFF on remote (note the starting byte at 0xA2
0xA201FFFFFF7C - "Direct" command - allow to move manually the "swing vertical things". Each press will move the (sorry) "things that is moving when swing" by a little (to direct the air flow)
0xA209FFFFFF74 - Turbo Mode ON/OFF
0xA208FFFFFF75 - LED Mode ON/OFF (switch on/off AC "screen" and beeps)

I have a theory, 0xA2 at the start means "Swing" in some context. Is it possible that you tested/captured the Turbo and LED messages with "Swing" being something other that the initial default state?
Alternative theory is 0xA2 is a "This is a special (non-basic operation) mode setting message". e.g. Swing or Direct or Turbo or LED

Looking at the options for the first byte:
0xA1 = 0b10100001 = Normal operation (i.e. if the last bit is 1)
0xA2 = 0b10100010 = Special (or it could be "swing") operation (i.e. if the second last bit is 1)
0xA4 = 0b10100100 = Follow Me operation (i.e. if the third last bit is 1)

Does the data you've collected match that?

[crankyoldgit]

P.S. Lets not worry about timers for now, unless they change the first byte some how. :)

[fraschizzato]

for 0xA1 the assumption is correct. A1 commands covers (ON/OFF,Mode,Temp,Timer and Sleep)

for 0xA2 i think is any other command, the only "command" that not match with this is "Sleep".

About that i've found that sleep command also "rewrites" ac operation mode. (example: AC in heat mode, remote switched to cool without the AC known, remote used to set "sleep mode" --> the AC goes to Cool Mode). So, I think it must be considered like an operational mode instead of a command.

All commands starting with 0xA2 were verified and confirmed (nothing to do with other modes, tested starting from fresh unit).

Till now 0xA4 is only for "FollowMe" function that has unique features.

---

Another approach can be about command content: 0xA1 and 0xA4 had vars (mode-temp), 0xA2 no. So only examining first byte the software can know if it's a "one shot" command (and had to search it's feature in a "functions array") or the command has to be "dismounted" to get all vars.

[crankyoldgit]

Okay, thanks for the info/analysis. I work on implementing setting the first byte for the 0xA1 & 0xA4 cases initially, and lets see how we go from there.

[crankyoldgit]

I've updated the branch (https://github.com/crankyoldgit/IRremoteESP8266/tree/kaysun) to support setting & reporting the message type. (i.e. first byte) and setting 0x7F for Follow Me etc.

Use the function IRMideaAC::setType() to do so.
This should allow you to construct your required messages (I think). Let me know etc.

[fraschizzato]

Follow Me Confirmed to Work. Following sketch used for test (commented out code is already tested as Working):

#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>
#include <ir_Midea.h>


const uint16_t kIrLed = 3;  // ESP8266 GPIO pin to use. Recommended: 4 (D2).
IRMideaAC ac(kIrLed);  // Set the GPIO to be used to sending the message.

void setup() {
  ac.begin();
  ac.setUseCelsius(true);
  //ac.setMode(kMideaACHeat);
  //ac.setTemp(24,true);
  //ac.send();
  delay(60000);
  ac.setType(kMideaACTypeFollow);
  ac.setSensorTemp(16,true);
  ac.send();
  delay(60000);
  ac.setSensorTemp(37,true);
  ac.send();
  delay(60000);
  ac.setSensorTemp(0,true);
  ac.send();
}

void loop() {
}

16°C - 37°C - 0°C Tested and working on my AC Unit

Tell me if You need more tests (also for other functions).

Only a suggestion: for setSensorTemp I think that setType(kMideaACTypeFollow) must be hard-coded in the function instead of the need of specification in end-user code. It's the only way/only need about this. So I think that "setType(followMe)" and "setType(Normal)" must be (at top and at bottom) of setSensorTemp Function.

[crankyoldgit]

Only a suggestion: for setSensorTemp I think that setType(kMideaACTypeFollow) must be hard-coded in the function instead of the need of specification in end-user code.

Done. My bad. I thought for some reason I had a captured (i.e. real remote message) that started with 0xA1 and had a sensor temp value in it. Thus it needed to be separate. I checked the data I had, and that didn't exist. So, I've done as you've suggested. It's now built in to the setSensorTemp() & setEnableSensorTemp() functions in the latest update to that branch.

[crankyoldgit]

I've added support for the On & Off timer(s) to that branch. Please download and test that they work as expected.

I think that leaves Turbo and Led toggling to go for Midea. Correct?

[fraschizzato]

I will try all tomorrow.
Didn't know (didn't checked) if also swing/direct were already implemented/corrected.
If both are working (i will check) the last steps are Turbo and Led (note that all four commands are in the same category 0xA2).

[crankyoldgit]

Yep. Swing toggle and Econo toggle is already supported.

[crankyoldgit]

Turbo & Light toggling should now also be supported in that branch too.

[fraschizzato]

Both Timers Confirmed to Work:

  ac.setOnTimer(30);
  ac.send();
  delay(15000);
  ac.setOnTimer(60);
  ac.send();
  delay(15000);
  ac.setOnTimer(12*60);
  ac.send();
  delay(15000);
  ac.setOnTimer(24*60);
  ac.send();
  delay(15000);
  ac.setOnTimer(0);
  ac.send();
  delay(15000);
  ac.setOffTimer(30);
  ac.send();
  delay(15000);
  ac.setOffTimer(60);
  ac.send();
  delay(15000);
  ac.setOffTimer(12*60);
  ac.send();
  delay(15000);
  ac.setOffTimer(24*60);
  ac.send();
  delay(15000);
  ac.setOffTimer(0);
  ac.send();
  delay(15000);

"0" minutes used to switch OFF

---

Sleep Confirmed to Work:

  ac.setSleep(true);
  ac.send();
  delay(15000);
  ac.setSleep(false);
  ac.send();
  delay(15000);

---

Led, Turbo and Swing doesn't produce desidered output: (all commands are followed by ac.send();)

ac.setLightToggle(false); produces 0xA18248FFFF54 instead of 0xA208FFFFFF75 (same for True)
ac.setSwingVToggle(false); produces 0xA18248FFFF54 instead of 0xA202FFFFFF7E (same for true)
ac.setTurboToggle(false); produces 0xA18248FFFF54 instead of 0xA209FFFFFF74 (same for true - in arduinoIDE command is not "orange" colored)

I think that there's something wrong in 0xA2 implementation (or I'm wrong using that)

---

Direct command is not implemented 0xA201FFFFFF7C - It allow to move the wing "manually" setting a specified position by multiple press.

[crankyoldgit]

Those toggle commands should produce more than 1 message. A "normal" command message, then the "special" message.

[fraschizzato]

Original Remote produces only one message (here the Swing as example)

23:56:33.411 -> Timestamp : 000027.561
23:56:33.411 -> Library   : v2.7.11
23:56:33.411 -> 
23:56:33.411 -> Protocol  : MIDEA
23:56:33.411 -> Code      : 0xA202FFFFFF7E (48 Bits)
23:56:33.411 -> Mesg Desc.: Type: 2 (Special), Swing(V) Toggle: Off, Econo Toggle: On, Turbo Toggle: Off, Light Toggle: Off
23:56:33.411 -> uint16_t rawData[199] = {4384, 4362,  548, 1618,  522, 520,  550, 1620,  522, 520,  548, 520,  550, 520,  550, 1618,  522, 520,  548, 522,  548, 520,  550, 520,  548, 520,  550, 520,  550, 520,  550, 1620,  522, 520,  550, 1618,  522, 1618,  522, 1620,  522, 1620,  522, 1618,  522, 1618,  522, 1618,  522, 1618,  522, 1618,  522, 1620,  524, 1618,  522, 1620,  522, 1618,  522, 1618,  522, 1618,  522, 1620,  522, 1620,  522, 1620,  520, 1620,  522, 1618,  522, 1620,  524, 1618,  522, 1620,  522, 1618,  522, 520,  550, 1620,  522, 1620,  522, 1620,  522, 1618,  522, 1620,  522, 1618,  522, 520,  550, 5174,  4384, 4362,  550, 522,  548, 1592,  550, 520,  550, 1592,  550, 1590,  552, 1588,  552, 520,  550, 1590,  552, 1590,  550, 1590,  552, 1590,  550, 1590,  550, 1590,  552, 1590,  550, 518,  552, 1588,  552, 518,  552, 520,  552, 518,  552, 518,  552, 518,  550, 520,  578, 492,  576, 492,  552, 518,  552, 518,  552, 518,  552, 518,  550, 518,  552, 518,  550, 518,  552, 518,  552, 520,  576, 492,  552, 518,  552, 518,  576, 494,  576, 494,  552, 518,  550, 518,  580, 1562,  552, 518,  552, 518,  550, 520,  556, 514,  550, 518,  552, 518,  552, 1590,  578};  // MIDEA A202FFFFFF7E
23:56:33.504 -> uint64_t data = 0xA202FFFFFF7E;

Here the only one produced by the library:

00:00:27.217 -> Timestamp : 000261.398
00:00:27.217 -> Library   : v2.7.11
00:00:27.217 -> 
00:00:27.217 -> Protocol  : MIDEA
00:00:27.217 -> Code      : 0xA18248FFFF54 (48 Bits)
00:00:27.217 -> Mesg Desc.: Type: 1 (Command), Power: On, Mode: 2 (Auto), Celsius: On, Temp: 25C/77F, On Timer: Off, Off Timer: Off, Fan: 0 (Auto), Sleep: Off, Swing(V) Toggle: Off, Econo Toggle: Off, Turbo Toggle: Off, Light Toggle: Off
00:00:27.265 -> uint16_t rawData[255] = {4480, 4508,  578, 1680,  574, 578,  550, 1696,  550, 576,  548, 578,  550, 576,  550, 578,  548, 1674,  574, 1696,  550, 576,  550, 576,  550, 576,  550, 576,  550, 576,  550, 1672,  574, 578,  548, 576,  552, 1672,  574, 576,  552, 574,  550, 1668,  578, 574,  576, 552,  576, 550,  576, 1644,  578, 1670,  576, 1668,  604, 1642,  606, 1642,  604, 1638,  606, 1642,  606, 1642,  608, 1638,  608, 1638,  606, 1640,  606, 1640,  604, 1642,  606, 1640,  574, 1672,  576, 1672,  576, 576,  576, 1644,  602, 552,  574, 1646,  574, 580,  548, 1670,  576, 554,  570, 556,  572, 5590,  4518, 4450,  574, 552,  574, 1672,  574, 552,  574, 1672,  574, 1674,  570, 1674,  574, 1672,  574, 556,  572, 554,  574, 1672,  572, 1674,  572, 1674,  572, 1676,  570, 1674,  572, 556,  570, 1678,  572, 1674,  570, 556,  570, 1674,  570, 1676,  570, 556,  570, 1676,  568, 1678,  568, 1680,  542, 582,  568, 558,  570, 556,  568, 558,  544, 582,  568, 556,  570, 556,  570, 558,  568, 558,  568, 556,  558, 568,  568, 558,  568, 558,  568, 558,  568, 558,  568, 560,  542, 1702,  568, 558,  568, 1678,  568, 580,  548, 1700,  546, 580,  546, 1702,  520, 1726,  546, 5632,  4458, 4512,  518, 1728,  518, 608,  518, 1730,  518, 608,  516, 610,  540, 588,  520, 1726,  540, 588,  522, 604,  540, 586,  522, 606,  540, 586,  540, 586,  542, 584,  542, 586,  516, 1730,  540, 1708,  540, 1706,  540, 1708,  540, 1708,  538, 1732,  514, 1734,  514, 1734,  488, 1784,  464, 1784,  436, 1838,  408};  // MIDEA A18248FFFF54
00:00:27.405 -> uint64_t data = 0xA18248FFFF54;

code used is:

  ac.setSwingVToggle(true);
  ac.send();

[crankyoldgit]

I've added a bigger gap between MIDEA messages. i.e. added a decent trailing gap of 100ms+. That should hopefully make the device and IRrecvDumpVx see the two messages as separate.

The library won't send a _single_ message for those, because a user could do something like:

ac.setMode(kMideaACCool);
ac.send();
delay(10000);
ac.setMode(kMideaACHeat);
ac.setSwingVToggle(true);
ac.send();  // Here it needs to send two messages. One to change the mode, the other to change the swing etc.

The library can't tell the intention of the user, and it tries not to assume knowledge of the existing A/C state where possible.
It can't be smart and say _"oh, don't send the command state again because we've already sent it"_ because we (library) doesn't know why the user has requested it. Maybe they want a re-transmission due to interference etc.

I've also added setSwingVStep() (aka. Direct) but you have to #define KAYSUN_AC true etc.
Turns out there are multiple brands using the MIDEA protocol, and they use different "special" commands for each brand/model.
e.g. the "default" SwingVToggle, is actually your Kaysun's "Direct"/Step.

You can view the latest commit for the chaos it's introduced :-) https://github.com/crankyoldgit/IRremoteESP8266/commit/7875b7a2a8bc20ea773465fa29e1d252c97740f1

Please download and check it out.

[fraschizzato]

Ok, it makes sense. But as the "special" function are independent from device state I'd rather prefer that they can be sended without changing/confirmig device state (personal opinion). In a case where also uart/cloud is used, operational states were issued by that, and only not supported function are issued via IR (like FollowMe and Led). But I understand that It will be different from "standard" library use and can generate confusion in user that didn't know what happen in the "back".

Tomorrow I will give the entire test (waiting daylight if something goes wrong). I hope the gap let the device and the "dump" receiver get both messages (because also the AC doesn't see them).

Correct consideration about #define KAYSUN_AC, I can say that both remotes (Mr.Cool and Kaysun) had the "direct" button
I suppose that there are also hidden features.

Really great job! Thanks

[crankyoldgit]

One option is to add a sendSwingVToggle() function, that does just that, for those that really want to send a single message.
But you can do that with a sendMidea() call anyway. /shrug.

[fraschizzato]

Exactly, I've already done that via sendMidea()

Led is working
Turbo is working

But if defined #define KAYSUN_AC true id ir_Midea.h I get:

ir_Midea.cpp: In member function 'bool IRMideaAC::isSwingVStep() const':

ir_Midea.cpp:349:28: error: 'kMideaACStepVStep' was not declared in this scope
   return _.remote_state == kMideaACStepVStep;

[crankyoldgit]

D'oh! Thanks. I'll fix it tomorrow. Replacing it with kMideaACSwingVStep should fix it.

[crankyoldgit]

Fixed in the latest commit to the branch. Also fixed a minor bug with the decoding of the "Step" setting.

[fraschizzato]

All confirmed to work. For other users: Uncommenting #define KAYSUN_AC true in ir_Midea.h it will allow to use the swing/direct commands mentioned above.

Great job!

[crankyoldgit]

FYI, the changes mentioned above have now been included in the new v2.7.12 release of the library.

[crankyoldgit]

Now that v2.7.12 has been put to bed, I'll start on the Coolix side of this Issue shortly.

[fraschizzato]

Ok, let me know what you need. As I remember the first problem was in FollowMe Mode: data packet seems to be sended correctly (checked via Dump sketch and compared to the remote one) but (and didn't know why) not used by the AC unit. Then I think that, probably, some commands must be implemented (Direct,Turbo,Sleep,Led,etc).

[crankyoldgit]

Okay. I tried implementing a "sensor temp" on Coolix that ranges from 0-50C .. but that takes up 6 bits of space. Which overlaps with the Fan bit range (by 1 bit)
(Data from your earlier comment: https://github.com/crankyoldgit/IRremoteESP8266/issues/1318#issuecomment-722658664)

So something in that "area" needs to be worked out if your data is correct.
e.g.
Your data suggests there is 6 bits of data for the sensor temp. i.e. 50C = 0x32 = 0b110010
The sensor temp bits start at 9th bit (from the Least significant side) this 9 + 6 = 15. So the 15th Least Significant Bit (LSB) will be the start of the "Fan" bits, which takes up 3 bits. Currently we have the "Fan" starting on the 14th LSB.
i.e. the masks are:
0b000000000000111100000000 for the _existing_ Sensor Temp setting &
0b000000000011111100000000 for the _proposed_ Sensor Temp setting &
0b000000001110000000000000 for the existing Fan setting.
You can see the overlap.

I'm fairly sure the fan bits are in the correct space, but there is some existing "oddness" with how it's done.

How sure are you that it goes up to 50C?
If it only went up to 30C i.e. 0x1E it would be only 5 bits. We have plenty of data that indicates a value of 0x1F is the "ignore" or Sensor Temp disabled value for other devices.

[fraschizzato]

https://github.com/crankyoldgit/IRremoteESP8266/issues/1318#issuecomment-722658664 This data is directly from remote, maybe there's a "flag" telling the unit that it's only a FollowMe Message (like the 0xA4 in Midea Protocol). Basically the AC unit didn't need to know Temp/OpMode/FanMode in that kind of messages. As it seems the "FM temperature report" doesn't neither follow the "strange" temperature schema, it seems linear. Note that last byte in the linked comment changes from 4A to DE when operating mode was changed (had to switch to Heat mode from Auto Mode - and as I remember that switch also causes different unit approach about fan mode). Also moving from this https://github.com/crankyoldgit/IRremoteESP8266/issues/1318#issuecomment-721829757 seems that FMmode (mentioned as ZoneFollow) the "flag" is the FanMode (6). Probably that (assumed) FanMode hides something different from the stated till now.

[crankyoldgit]

There is a special ZoneFollow/Sensor bit:
https://github.com/crankyoldgit/IRremoteESP8266/blob/a56c88b741dbe79ff85a488e7341dbb305120946/src/ir_Coolix.h#L45-L46

Earlier reports of the Sensor had an offset of +16C to a 00 value i.e. 0 == 16C, 1 == 17C

This is the original user-derived analysis of the protocol.
If you can provide a better analysis that covers/matches their observations I'm happy to use it/re-work the code.
See issue https://github.com/crankyoldgit/IRremoteESP8266/issues/484

I can see their x bit being an extra bit of the sensor/zf temp. i.e. 5 bits instead of 4.

[fraschizzato]

I will take a look in next days (from direct grabs), as first see I can suppose that the "x" bit is part of the temperature and the difference between messages is made by "op"

[fraschizzato]

Here the grabbed data https://docs.google.com/spreadsheets/d/1kPc2pyFwBD93j4EM-LOSMrTx3g0QxciL2MsnUekY5w8/edit?usp=sharing

Decoding is at really early stage, but as I can see the "overlapping" is avoided from the first byte that is different. Second Nibble changes in FollowMe Mode (and other direct commands)

There's also the Timer ON/OFF but not mapped.

Firstly all FollowMe Messages starts with 0xBA and modes ones with 0xB2 now I'm searching a path for all messages.
At this stage "Direct" command isn't recognized as Coolix, it's the only one not recognized. Here the grab:

18:51:39.085 -> Timestamp : 002124.406
18:51:39.085 -> Library   : v2.7.11
18:51:39.085 -> 
18:51:39.085 -> Protocol  : UNKNOWN
18:51:39.085 -> Code      : 0xB0473CC8 (50 Bits)
18:51:39.085 -> uint16_t rawData[99] = {4386, 4366,  546, 1622,  520, 522,  548, 1622,  496, 1646,  520, 524,  548, 522,  548, 1622,  522, 522,  548, 520,  550, 1620,  520, 522,  548, 522,  546, 1622,  496, 1646,  522, 520,  526, 1646,  520, 522,  548, 522,  524, 546,  550, 520,  550, 1620,  498, 1644,  520, 1622,  522, 1622,  520, 1620,  522, 1620,  524, 1618,  524, 1618,  524, 520,  550, 520,  550, 522,  550, 518,  552, 1618,  524, 1618,  524, 1618,  524, 520,  550, 520,  550, 520,  550, 520,  550, 520,  552, 516,  552, 518,  550, 522,  550, 1618,  526, 1616,  524, 1618,  524, 1618,  524, 1618,  550};  // UNKNOWN B0473CC8

[crankyoldgit]

You're UNKNOWN "Direct" message appears to have underlying data that matches the COOLIX patterns. e.g. Byte followed by inverted Byte. three times. For a total of 24bits.

So without looking into it deeply (finding the errant time entry), I'm guessing it's a transient timing issue/fault. i.e. Try again.

[fraschizzato]

Probably a misanderstanding, all data grabbed from that button is not recognized, here some grabs from different distance, angle, etc.:

17:07:08.119 -> IRrecvDump is now running and waiting for IR input on Pin 4
17:07:12.972 -> Timestamp : 000004.941
17:07:12.972 -> Library   : v2.7.11
17:07:12.972 -> 
17:07:12.972 -> Protocol  : UNKNOWN
17:07:12.972 -> Code      : 0xB0473CC8 (50 Bits)
17:07:12.972 -> uint16_t rawData[99] = {4386, 4362,  548, 1620,  522, 520,  550, 1620,  522, 1620,  522, 520,  548, 522,  548, 1620,  522, 522,  548, 522,  548, 1620,  522, 522,  548, 520,  550, 1620,  522, 1620,  520, 520,  550, 1620,  522, 520,  550, 520,  548, 522,  548, 518,  550, 1620,  520, 1620,  522, 1620,  522, 1620,  522, 1620,  520, 1620,  520, 1620,  522, 1618,  522, 520,  548, 522,  548, 522,  548, 522,  548, 1620,  520, 1620,  520, 1620,  522, 520,  548, 522,  546, 522,  546, 522,  548, 522,  548, 522,  548, 522,  548, 520,  548, 1622,  520, 1622,  520, 1620,  520, 1622,  520, 1620,  520};  // UNKNOWN B0473CC8
17:07:13.019 -> 
17:07:13.019 -> 
17:07:15.091 -> Timestamp : 000007.041
17:07:15.091 -> Library   : v2.7.11
17:07:15.091 -> 
17:07:15.091 -> Protocol  : UNKNOWN
17:07:15.091 -> Code      : 0xB0473CC8 (50 Bits)
17:07:15.091 -> uint16_t rawData[99] = {4384, 4364,  548, 1620,  522, 520,  548, 1620,  522, 1620,  520, 522,  550, 520,  548, 1620,  522, 520,  550, 520,  550, 1620,  522, 520,  548, 520,  548, 1620,  522, 1620,  520, 520,  548, 1620,  520, 522,  548, 520,  550, 520,  548, 520,  548, 1620,  522, 1620,  522, 1620,  522, 1620,  522, 1618,  522, 1618,  522, 1618,  522, 1620,  520, 522,  546, 522,  548, 522,  548, 522,  548, 1620,  522, 1620,  520, 1620,  522, 520,  550, 522,  548, 520,  548, 522,  548, 522,  548, 520,  548, 520,  574, 496,  548, 1620,  520, 1620,  522, 1620,  522, 1620,  520, 1622,  520};  // UNKNOWN B0473CC8
17:07:15.138 -> 
17:07:15.138 -> 
17:07:17.730 -> Timestamp : 000009.679
17:07:17.730 -> Library   : v2.7.11
17:07:17.730 -> 
17:07:17.730 -> Protocol  : UNKNOWN
17:07:17.730 -> Code      : 0xB0473CC8 (50 Bits)
17:07:17.730 -> uint16_t rawData[99] = {4392, 4356,  550, 1616,  552, 494,  550, 1614,  526, 1614,  526, 520,  550, 544,  526, 1614,  528, 518,  548, 546,  526, 1614,  524, 522,  548, 538,  532, 1616,  524, 1616,  550, 496,  548, 1616,  552, 496,  548, 520,  550, 544,  524, 544,  526, 1614,  526, 1616,  524, 1616,  552, 1588,  552, 1588,  550, 1590,  550, 1590,  552, 1566,  574, 520,  552, 516,  526, 544,  524, 520,  550, 1616,  552, 1590,  552, 1590,  550, 520,  552, 518,  526, 518,  576, 494,  550, 520,  572, 520,  550, 520,  528, 542,  552, 1588,  526, 1614,  526, 1590,  550, 1616,  526, 1614,  528};  // UNKNOWN B0473CC8
17:07:17.776 -> 
17:07:17.776 -> 
17:07:20.040 -> Timestamp : 000011.980
17:07:20.040 -> Library   : v2.7.11
17:07:20.040 -> 
17:07:20.040 -> Protocol  : UNKNOWN
17:07:20.040 -> Code      : 0xB0473CC8 (50 Bits)
17:07:20.040 -> uint16_t rawData[99] = {4384, 4362,  548, 1620,  522, 520,  548, 1622,  520, 1620,  520, 522,  546, 522,  548, 1620,  520, 522,  546, 522,  548, 1620,  522, 522,  522, 546,  548, 1622,  520, 1620,  520, 522,  548, 1622,  520, 524,  546, 524,  546, 522,  546, 524,  522, 1644,  520, 1620,  520, 1622,  522, 1620,  520, 1620,  520, 1622,  520, 1620,  522, 1620,  522, 522,  548, 522,  548, 520,  550, 520,  548, 1620,  520, 1620,  522, 1618,  522, 520,  548, 524,  548, 520,  550, 520,  548, 522,  546, 522,  548, 522,  548, 520,  548, 1620,  522, 1620,  520, 1620,  520, 1620,  520, 1620,  522};  // UNKNOWN B0473CC8
17:07:20.087 -> 
17:07:20.087 -> 
17:07:22.727 -> Timestamp : 000014.707
17:07:22.727 -> Library   : v2.7.11
17:07:22.727 -> 
17:07:22.727 -> Protocol  : UNKNOWN
17:07:22.727 -> Code      : 0xB0473CC8 (50 Bits)
17:07:22.774 -> uint16_t rawData[99] = {4384, 4362,  548, 1620,  498, 546,  522, 1644,  496, 1644,  520, 522,  548, 522,  524, 1644,  522, 520,  548, 520,  526, 1642,  522, 522,  550, 520,  550, 1618,  522, 1620,  520, 522,  550, 1620,  522, 518,  524, 548,  522, 546,  548, 522,  548, 1620,  522, 1618,  522, 1620,  522, 1618,  520, 1620,  520, 1620,  520, 1620,  522, 1620,  522, 522,  546, 522,  546, 522,  548, 522,  548, 1620,  522, 1618,  522, 1620,  522, 520,  548, 520,  548, 520,  550, 522,  548, 520,  548, 522,  548, 520,  550, 520,  548, 1618,  524, 1616,  524, 1616,  522, 1620,  524, 1616,  522};  // UNKNOWN B0473CC8
17:07:22.819 -> 
17:07:22.819 -> 
17:07:24.992 -> Timestamp : 000016.968
17:07:24.992 -> Library   : v2.7.11
17:07:24.992 -> 
17:07:24.992 -> Protocol  : UNKNOWN
17:07:24.992 -> Code      : 0xB0473CC8 (50 Bits)
17:07:24.992 -> uint16_t rawData[99] = {4382, 4366,  546, 1622,  518, 526,  546, 1620,  496, 1644,  520, 524,  546, 524,  546, 1620,  520, 520,  548, 524,  524, 1644,  520, 524,  546, 522,  524, 1646,  520, 1620,  498, 546,  524, 1644,  522, 520,  548, 522,  546, 524,  548, 522,  548, 1620,  520, 1620,  522, 1620,  520, 1620,  522, 1620,  522, 1620,  524, 1618,  522, 1618,  522, 522,  548, 522,  548, 522,  548, 520,  550, 1618,  522, 1618,  524, 1618,  522, 520,  550, 520,  550, 520,  550, 520,  524, 544,  548, 522,  550, 520,  550, 520,  548, 1620,  522, 1618,  522, 1620,  522, 1618,  522, 1618,  524};  // UNKNOWN B0473CC8
17:07:25.085 -> 
17:07:25.085 -> 

Watching the actual Coolix integration it seems fine about the rest. Can't find an issue about "overlapping", like the "special function" buttons the FollowMe has a specific pattern.

The fact about the timing can be the reason why FollowMe messages generated by the library dind't work on the AC.
Here the two grabs https://github.com/crankyoldgit/IRremoteESP8266/issues/1318#issuecomment-721829757 tell me if you need more

[crankyoldgit]

Okay, I found the problem decoding the "Direct" messages. Not a timing error at all. See https://github.com/crankyoldgit/IRremoteESP8266/commit/85c5b4dac37df5fd5ac3d9a5cf9ac4865ad30ced for details.
It seems "Direct" is an odd-one-out message w.r.t. the Coolix protocol. i.e. No repeat.
Btw. What does this "Direct" button actually do?

Please download & test branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/Kaysun_Coolix
I'll be using this branch going forward for the Coolix changes for this Issue, as we work them out.

[fraschizzato]

I will test it tomorrow.
"Direct" is the same as Midea one. It moves the swing a bit at each press (to move it in a fixed position)

[crankyoldgit]

Branch has been updated to report that message code as a "Step" command, and added set/get functions for that.

[fraschizzato]

About "Step":
This is the message produced by the remote and recognized by the AC:

19:30:52.808 -> Protocol  : COOLIX
19:30:52.808 -> Code      : 0xB20FE0 (24 Bits)
19:30:52.808 -> Mesg Desc.: Power: On, Swing(V): Step
19:30:52.808 -> uint16_t rawData[99] = {4384, 4362,  548, 1620,  520, 522,  548, 1620,  520, 1620,  522, 522,  546, 522,  548, 1620,  520, 522,  548, 522,  548, 1622,  520, 520,  548, 520,  548, 1622,  520, 1620,  520, 522,  548, 1620,  520, 522,  548, 522,  546, 522,  546, 524,  548, 1620,  522, 1618,  520, 1622,  520, 1622,  520, 1620,  522, 1620,  520, 1620,  520, 1622,  520, 522,  548, 522,  548, 520,  548, 522,  548, 1620,  522, 1620,  520, 1620,  522, 520,  550, 522,  548, 520,  548, 524,  546, 522,  546, 524,  546, 524,  548, 522,  548, 1618,  522, 1620,  522, 1618,  522, 1618,  522, 1618,  522};  // COOLIX B20FE0
19:30:52.855 -> uint64_t data = 0xB20FE0;

This is the message generated by the library but that didn't work with the device ac.setSwingVStep();

19:31:17.735 -> Protocol  : COOLIX
19:31:17.735 -> Code      : 0xB20FE0 (24 Bits)
19:31:17.735 -> Mesg Desc.: Power: On, Swing(V): Step
19:31:17.735 -> uint16_t rawData[199] = {4708, 4412,  554, 1686,  526, 550,  556, 1684,  528, 1684,  526, 554,  554, 552,  554, 1686,  526, 556,  552, 554,  554, 1684,  526, 552,  554, 552,  556, 1686,  526, 1684,  502, 578,  554, 1686,  526, 554,  554, 552,  554, 552,  556, 552,  556, 1682,  528, 1684,  528, 1684,  526, 1686,  526, 1686,  526, 1686,  526, 1686,  526, 1684,  502, 576,  554, 554,  556, 552,  554, 552,  556, 1686,  502, 1708,  528, 1684,  526, 552,  554, 550,  556, 554,  554, 552,  554, 556,  554, 552,  556, 552,  556, 552,  554, 1684,  526, 1684,  526, 1686,  526, 1684,  526, 1684,  526, 5246,  4704, 4412,  558, 1682,  530, 552,  554, 1682,  530, 1680,  554, 528,  556, 548,  582, 1656,  530, 550,  582, 524,  558, 1682,  556, 552,  556, 524,  556, 1680,  532, 1680,  530, 550,  584, 1654,  558, 524,  582, 526,  582, 524,  584, 548,  558, 1652,  558, 1652,  560, 1650,  560, 1654,  560, 1650,  560, 1650,  562, 1626,  586, 1650,  562, 546,  560, 546,  564, 542,  564, 546,  562, 1624,  588, 1620,  590, 1624,  590, 542,  566, 542,  566, 542,  564, 542,  564, 544,  562, 546,  564, 542,  562, 544,  566, 1618,  590, 1622,  588, 1622,  590, 1622,  616, 1596,  592};  // COOLIX B20FE0
19:31:17.828 -> uint64_t data = 0xB20FE0;

About FollowMe (Zone Follow):

The library message (that is not working) is at room temp 19°C - Heat Mode etc ac.setSensorTemp(19);

19:41:52.677 -> Protocol  : COOLIX
19:41:52.677 -> Code      : 0xBAB34C (24 Bits)
19:41:52.677 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 5 (Auto), Temp: 24C, Zone Follow: Off, Sensor Temp: 19C
19:41:52.677 -> uint16_t rawData[199] = {4672, 4436,  584, 1654,  530, 550,  582, 1656,  556, 1654,  530, 1682,  558, 522,  584, 1654,  534, 548,  584, 522,  586, 1652,  560, 520,  584, 526,  582, 548,  556, 1654,  558, 550,  558, 1654,  560, 1650,  558, 524,  584, 1652,  560, 1652,  560, 546,  562, 546,  558, 1652,  562, 1652,  562, 546,  562, 1648,  564, 544,  562, 544,  560, 1626,  588, 1626,  584, 544,  564, 546,  562, 544,  562, 1646,  566, 544,  562, 544,  562, 1646,  568, 1618,  588, 544,  564, 544,  564, 1620,  588, 544,  564, 1620,  594, 1616,  592, 542,  564, 544,  562, 1620,  618, 1594,  592, 5206,  4736, 4380,  584, 1628,  584, 552,  554, 1628,  582, 1630,  582, 1630,  582, 528,  578, 1630,  580, 528,  578, 528,  580, 1630,  580, 528,  580, 528,  580, 528,  580, 1630,  580, 526,  580, 1632,  580, 1630,  580, 528,  580, 1630,  580, 1632,  580, 528,  578, 528,  578, 1632,  580, 1634,  576, 530,  576, 1634,  578, 530,  576, 530,  576, 1634,  552, 1658,  578, 528,  552, 558,  550, 556,  552, 1660,  550, 556,  576, 532,  550, 1660,  574, 1636,  550, 556,  576, 532,  550, 1660,  576, 532,  574, 1636,  552, 1660,  554, 554,  548, 558,  576, 1636,  550, 1662,  548};  // COOLIX BAB34C
19:41:52.770 -> uint64_t data = 0xBAB34C;

The Message from the remote is (at same temp 19°C):

19:46:27.849 -> Protocol  : COOLIX
19:46:27.849 -> Code      : 0xBAD34E (24 Bits)
19:46:27.849 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 6 (Zone Follow), Temp: 24C, Zone Follow: Off, Sensor Temp: 19C
19:46:27.896 -> uint16_t rawData[199] = {4384, 4364,  574, 1592,  550, 496,  548, 1618,  526, 1616,  526, 1616,  550, 496,  548, 1618,  524, 522,  548, 520,  548, 1618,  526, 520,  548, 522,  548, 522,  548, 1616,  526, 520,  550, 1616,  550, 1592,  540, 1600,  550, 494,  550, 1616,  526, 520,  548, 520,  548, 1616,  526, 1616,  524, 522,  548, 522,  550, 1616,  526, 520,  548, 1618,  526, 1616,  526, 520,  548, 520,  550, 520,  548, 1618,  550, 496,  548, 522,  548, 1616,  550, 1592,  550, 1592,  530, 514,  548, 1616,  526, 520,  548, 1618,  526, 1616,  526, 520,  548, 522,  548, 520,  548, 1618,  526, 5174,  4384, 4364,  548, 1616,  526, 522,  548, 1616,  550, 1590,  526, 1616,  526, 520,  550, 1616,  528, 520,  548, 520,  548, 1616,  528, 518,  550, 522,  548, 522,  574, 1590,  528, 520,  548, 1616,  526, 1614,  528, 1614,  528, 520,  550, 1616,  526, 520,  554, 516,  548, 1616,  526, 1616,  526, 520,  550, 522,  548, 1614,  552, 496,  548, 1614,  526, 1616,  526, 522,  548, 522,  546, 524,  546, 1618,  524, 524,  544, 524,  546, 1616,  524, 1616,  524, 1616,  526, 524,  546, 1618,  526, 522,  546, 1616,  524, 1618,  526, 522,  546, 524,  544, 524,  546, 1596,  548};  // COOLIX BAD34E
19:46:27.990 -> uint64_t data = 0xBAD34E;

Apparently The B in byte 2 has to be D (also tested with other ranges, apparently there's a Decimal "38" difference between the values)

Didn't know if a celsius/fahrenheit issues, I haven't found how to switch measure on that remote RG57A7/BGEF

All other things seems working fine

[crankyoldgit]

When using "Step", can you try sending it with ac.send(0); please?

[fraschizzato]

  ac.setSwingVStep();
  ac.send(0);

Works correctly

---

This FollowMe Message is generated setting ac.setFan(kCoolixFanZoneFollow) before sending sensor temperature

21:00:13.058 -> Protocol  : COOLIX
21:00:13.058 -> Code      : 0xBAD34C (24 Bits)
21:00:13.058 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 6 (Zone Follow), Temp: 24C, Zone Follow: Off, Sensor Temp: 19C
21:00:13.105 -> uint16_t rawData[99] = {4770, 4344,  592, 1620,  594, 540,  566, 1616,  594, 1620,  592, 1618,  590, 546,  562, 1620,  592, 546,  566, 542,  560, 1622,  590, 544,  564, 544,  560, 546,  560, 1624,  588, 548,  560, 1624,  586, 1624,  588, 1624,  586, 524,  584, 1624,  588, 522,  584, 524,  582, 1624,  584, 1628,  586, 522,  582, 550,  558, 1624,  586, 526,  578, 1626,  584, 1626,  586, 524,  582, 526,  582, 526,  580, 1628,  584, 524,  582, 524,  582, 1628,  582, 1630,  582, 524,  584, 524,  582, 1630,  580, 526,  584, 1628,  586, 1626,  582, 524,  582, 526,  580, 1628,  582, 1630,  582};  // COOLIX BAD34C
21:00:13.153 -> uint64_t data = 0xBAD34C;

The D problem seems related to this. But now I see an E
Tested both with ac.send(); and ac.send(0); (the grab is with 0)
It seems that changes only the last Byte 0xBAD34E (remote) and 0xBAD34C library

[crankyoldgit]

I've updated the branch so you shouldn't need to ac.send(0) for the "step" command.
Please test etc.

I'll try looking into the rest of it later today/tonight.

[fraschizzato]

Ok, tomorrow I will test.

For FollowMe last byte I think that the problem is in last two bit. Also as reported here (https://github.com/crankyoldgit/IRremoteESP8266/issues/484) in FollowMe Messages last two bit are 10 instead of 00
In that way the known modes vs FollowMe Modes:
|Normal | Mode | FollowMe |
|-|-|-|
|11 00| Heat | 1110|
|10 00| Auto |1010|
|01 00| Fan/Dry |0110|
|00 00| Cool |0010|

[crankyoldgit]

I've added setting the 2nd last bit (2nd least significant bit) to Zone Follow's control, to the branch. Let me know how it goes.

[fraschizzato]

All confirmed working:

• Step Command works with ac.send(); without the need of ac.send(0);
• Follow Me Messages now are correct and fully working. Keep Note that correct message is created only if also correct fan mode is selected: ac.setFan(kCoolixFanZoneFollow);

In receiver is always reported Zone Follow: Off also if enabled. Now we know that last two bits of mode and fanMode can determine if FollowMe message is sent. But I don't think that report is necessary. By following the logic of "the library has to know the state without assuming anything" the followMe is very difficult to track: there's no way to know if device receives/uses remote data (only way is by cloud/uart key)
Keep in mind that multiple FollowMe Messages causes the unit to refuse (not use) them. A safe spacing is 1 minute between each FollowMe update message. So the "re-send everything" way is not praticable in that case

Here the test code fully working:

#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>
#include <ir_Coolix.h>


const uint16_t kIrLed = 4;  // ESP8266 GPIO pin to use. Recommended: 4 (D2).
IRCoolixAC ac(kIrLed);  // Set the GPIO to be used to sending the message.

void setup() {
  ac.begin();
  ac.setMode(kCoolixHeat);
  ac.setTemp(24);
  ac.send();
  delay(30000);
  ac.setSwingVStep();
  ac.send();
  delay(15000);
  ac.setSwingVStep();
  ac.send();
  delay(15000);
  ac.setFan(kCoolixFanZoneFollow);
  const uint8_t temp = 19;
  ac.setSensorTemp(temp);
  ac.send();
  delay(60000);
  ac.setSensorTemp(22);
  ac.send();
  delay(60000);
  ac.setSensorTemp(30);
  ac.send();
  delay(60000);
}

void loop() {

}

Tell me if "timer on" and "timer off" mappings are needed.
As per clarification about use: TimerON will turn ON the ac after the selected time (posticipate ON), TimerOFF will turn OFF the AC after the selected time (planned OFF). They can be configured both at the same time to have a "ON window" by setting (as example) ON after 2 hours and OFF after 5 Hours = Running 3 hours after a wait of 2

[crankyoldgit]

Okay. Thanks for the confirmation and feedback.

I'll look at setting the ZoneFollow fan mode when ZoneFollow/Sensor Temp is set. And potentially reversing it when it's cleared/unset etc.

As for Timers, they are really a low priority. But if you want to do the analysis, I can try to implement it somehow.

[crankyoldgit]

I should have improved ZoneFollow/FollowMe/SensorTemp etc setting and detection.
You hopefully shouldn't need to call ac.setFan(kCoolixFanZoneFollow); when setting the SensorTemp.

Let me know how it goes etc.

[fraschizzato]

Sorry for the delay.
Latest commit doesn't produces desidered output, without setting ac.setFan(kCoolixFanZoneFollow); i get:

14:00:21.225 -> Protocol  : COOLIX
14:00:21.225 -> Code      : 0xBAB34E (24 Bits)
14:00:21.225 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 5 (Auto), Temp: 24C, Zone Follow: Off, Sensor Temp: 19C
14:00:21.225 -> uint16_t rawData[199] = {4674, 4434,  594, 1618,  592, 542,  562, 1622,  618, 1594,  594, 1618,  590, 542,  566, 1616,  598, 542,  596, 512,  592, 1592,  594, 540,  596, 512,  594, 512,  594, 1592,  592, 540,  568, 1616,  622, 1590,  622, 512,  596, 1590,  618, 1590,  624, 512,  594, 512,  596, 1588,  618, 1594,  616, 518,  592, 1590,  622, 514,  594, 512,  594, 1590,  622, 1588,  622, 514,  594, 514,  594, 514,  592, 1592,  620, 514,  592, 514,  596, 1586,  624, 1588,  620, 1590,  624, 512,  594, 1590,  620, 514,  596, 1588,  620, 1590,  624, 512,  590, 516,  592, 514,  592, 1590,  620, 5178,  4772, 4348,  616, 1596,  588, 544,  588, 1594,  590, 1620,  592, 1618,  588, 546,  564, 1620,  618, 518,  562, 546,  560, 1624,  614, 520,  564, 544,  560, 546,  558, 1624,  588, 546,  560, 1624,  588, 1624,  588, 548,  558, 1626,  584, 1626,  584, 550,  556, 552,  556, 1626,  584, 1628,  584, 528,  578, 1628,  582, 528,  578, 528,  580, 1630,  582, 1628,  580, 528,  580, 526,  580, 528,  578, 1630,  582, 524,  578, 530,  580, 1630,  580, 1630,  580, 1630,  582, 528,  580, 1630,  580, 528,  580, 1632,  578, 1632,  578, 528,  578, 530,  578, 530,  578, 1632,  578};  // COOLIX BAB34E
14:00:21.319 -> uint64_t data = 0xBAB34E;

It seems that ignores the "fanMode" implementation.
Comparison using ac.setFan(kCoolixFanZoneFollow);

14:05:59.090 -> Protocol  : COOLIX
14:05:59.090 -> Code      : 0xBAD34E (24 Bits)
14:05:59.090 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 6 (Zone Follow), Temp: 24C, Zone Follow: Off, Sensor Temp: 19C
14:05:59.138 -> uint16_t rawData[199] = {4776, 4340,  622, 1590,  624, 512,  594, 1588,  620, 1592,  622, 1588,  594, 540,  594, 1590,  594, 542,  592, 516,  594, 1590,  618, 516,  564, 542,  592, 516,  564, 1620,  592, 542,  564, 1620,  620, 1592,  592, 1618,  594, 542,  576, 1608,  592, 542,  592, 516,  562, 1622,  590, 1620,  590, 546,  560, 548,  560, 1622,  590, 546,  558, 1624,  590, 1622,  588, 548,  558, 550,  558, 548,  560, 1622,  590, 548,  558, 548,  560, 1622,  588, 1624,  586, 1626,  584, 524,  586, 1624,  586, 524,  582, 1626,  584, 1628,  582, 528,  580, 524,  582, 524,  582, 1630,  584, 5214,  4730, 4386,  554, 1658,  578, 528,  580, 1632,  578, 1632,  578, 1634,  578, 528,  578, 1632,  552, 556,  580, 528,  552, 1658,  552, 556,  578, 528,  578, 530,  552, 1660,  564, 542,  552, 1662,  578, 1634,  552, 1660,  552, 556,  576, 1636,  550, 558,  550, 556,  550, 1660,  550, 1662,  576, 532,  550, 558,  576, 1636,  550, 556,  550, 1660,  578, 1634,  552, 556,  550, 558,  550, 556,  550, 1662,  550, 558,  550, 556,  550, 1662,  548, 1662,  548, 1664,  548, 560,  548, 1664,  548, 560,  548, 1664,  548, 1664,  546, 562,  546, 562,  546, 560,  546, 1666,  544};  // COOLIX BAD34E
14:05:59.230 -> uint64_t data = 0xBAD34E;

---

About Timers: Data seems to not being recognized by the library, here some grabs of Timers ON and OFF, at this stage I can't decode the message logic.

14:08:54.849 -> Timestamp : 000722.393
14:08:54.849 -> Library   : v2.7.12
14:08:54.849 -> 
14:08:54.849 -> Protocol  : UNKNOWN
14:08:54.849 -> Code      : 0x1C0BDB58 (100 Bits)
14:08:54.896 -> uint16_t rawData[199] = {4388, 4356,  548, 1618,  522, 520,  548, 1618,  522, 1616,  524, 520,  550, 520,  548, 1618,  522, 520,  548, 522,  548, 1616,  548, 496,  548, 520,  548, 1618,  522, 1618,  548, 494,  550, 1616,  522, 1618,  524, 520,  550, 1616,  544, 1596,  548, 1592,  524, 1616,  524, 1616,  548, 1592,  524, 520,  548, 1618,  524, 520,  548, 520,  548, 520,  548, 520,  548, 520,  548, 520,  548, 520,  548, 1618,  524, 518,  550, 520,  548, 1618,  524, 1616,  548, 1592,  524, 1616,  548, 496,  546, 522,  548, 520,  552, 518,  548, 520,  548, 522,  548, 522,  550, 1616,  524, 5170,  4382, 4360,  574, 1590,  524, 522,  548, 1616,  524, 1614,  524, 520,  548, 522,  548, 1616,  524, 518,  550, 520,  548, 1616,  526, 520,  548, 520,  550, 1616,  524, 1616,  526, 520,  548, 1616,  524, 1616,  548, 496,  548, 1616,  550, 1590,  524, 1614,  526, 1614,  550, 1592,  524, 1616,  548, 496,  548, 1616,  548, 496,  548, 520,  572, 498,  548, 522,  572, 498,  546, 522,  570, 500,  546, 1616,  548, 496,  570, 498,  548, 1616,  524, 1616,  524, 1616,  528, 1612,  548, 496,  550, 520,  572, 496,  572, 496,  548, 522,  546, 522,  548, 522,  548, 1616,  552};  // UNKNOWN 1C0BDB58
14:08:54.989 -> 
14:08:54.989 -> 
14:09:10.840 -> Timestamp : 000738.356
14:09:10.840 -> Library   : v2.7.12
14:09:10.840 -> 
14:09:10.840 -> Protocol  : UNKNOWN
14:09:10.840 -> Code      : 0x653B54F8 (100 Bits)
14:09:10.840 -> uint16_t rawData[199] = {4382, 4364,  546, 1620,  520, 522,  546, 1620,  520, 1620,  522, 522,  548, 522,  546, 1620,  522, 520,  550, 520,  548, 1618,  522, 520,  546, 524,  546, 1620,  522, 1618,  520, 522,  550, 1618,  522, 1618,  522, 522,  546, 1618,  522, 1618,  522, 1618,  522, 1620,  522, 1618,  524, 1616,  524, 518,  550, 1618,  550, 494,  550, 520,  550, 518,  550, 518,  552, 518,  550, 518,  548, 520,  550, 1616,  520, 522,  552, 518,  550, 1616,  524, 1616,  526, 1614,  524, 1616,  526, 518,  578, 492,  576, 492,  550, 518,  550, 518,  560, 508,  550, 1616,  526, 1614,  554, 5138,  4416, 4328,  584, 1584,  558, 512,  556, 1584,  556, 1562,  580, 512,  556, 514,  556, 1560,  580, 512,  556, 514,  556, 1562,  580, 512,  556, 512,  554, 1562,  580, 1584,  558, 512,  556, 1584,  556, 1584,  556, 514,  556, 1584,  556, 1586,  556, 1584,  556, 1584,  556, 1562,  576, 1586,  556, 514,  558, 1560,  580, 512,  556, 512,  558, 512,  556, 512,  556, 512,  558, 512,  558, 512,  556, 1584,  558, 510,  558, 512,  556, 1582,  556, 1560,  582, 1584,  554, 1562,  584, 510,  556, 514,  558, 510,  558, 512,  558, 510,  556, 512,  558, 1558,  582, 1558,  582};  // UNKNOWN 653B54F8
14:09:10.933 -> 
14:09:10.933 -> 
14:09:17.998 -> Timestamp : 000745.545
14:09:17.998 -> Library   : v2.7.12
14:09:17.998 -> 
14:09:17.998 -> Protocol  : UNKNOWN
14:09:17.998 -> Code      : 0x18EAA908 (100 Bits)
14:09:18.046 -> uint16_t rawData[199] = {4384, 4358,  550, 1620,  522, 520,  550, 1618,  524, 1618,  522, 520,  548, 522,  548, 1618,  522, 522,  548, 522,  548, 1618,  524, 520,  548, 520,  548, 1618,  548, 1592,  524, 520,  550, 1618,  548, 1592,  524, 518,  550, 1618,  524, 518,  550, 520,  550, 520,  548, 520,  550, 1616,  526, 518,  552, 1616,  524, 520,  550, 1616,  524, 1618,  524, 1616,  524, 1616,  524, 518,  550, 520,  548, 1616,  524, 520,  550, 518,  548, 1618,  522, 1618,  520, 522,  548, 518,  550, 520,  548, 522,  548, 522,  548, 522,  550, 520,  548, 522,  548, 1620,  522, 1618,  522, 5174,  4382, 4360,  548, 1620,  520, 520,  550, 1618,  522, 1618,  520, 522,  548, 520,  548, 1620,  522, 520,  546, 522,  548, 1620,  522, 520,  548, 522,  546, 1620,  522, 1620,  526, 518,  576, 1590,  552, 1588,  554, 492,  576, 1588,  554, 492,  576, 516,  554, 516,  554, 516,  556, 1584,  556, 514,  554, 1586,  556, 514,  554, 1584,  554, 1586,  554, 1562,  578, 1562,  580, 514,  554, 516,  554, 1584,  554, 514,  556, 514,  556, 1584,  556, 1564,  576, 514,  556, 514,  554, 514,  556, 514,  554, 516,  556, 514,  552, 516,  556, 514,  554, 1560,  580, 1586,  554};  // UNKNOWN 18EAA908
14:09:18.137 -> 
14:09:18.137 -> 
14:09:36.313 -> Timestamp : 000763.861
14:09:36.313 -> Library   : v2.7.12
14:09:36.313 -> 
14:09:36.313 -> Protocol  : UNKNOWN
14:09:36.313 -> Code      : 0x814236B0 (100 Bits)
14:09:36.360 -> uint16_t rawData[199] = {4384, 4360,  550, 1618,  524, 518,  550, 1616,  524, 1616,  524, 520,  550, 520,  550, 1614,  524, 518,  554, 518,  550, 1616,  524, 520,  550, 518,  552, 1614,  524, 1616,  528, 516,  552, 1614,  552, 1588,  528, 516,  552, 1614,  552, 492,  552, 518,  552, 516,  578, 490,  554, 1612,  554, 490,  552, 1614,  552, 492,  578, 1588,  528, 1614,  552, 1588,  554, 1588,  552, 518,  554, 516,  554, 1586,  554, 492,  576, 492,  576, 1588,  554, 1586,  554, 490,  580, 516,  552, 516,  554, 1586,  552, 492,  578, 1586,  550, 1588,  554, 1586,  552, 1586,  554, 1588,  554, 5138,  4416, 4328,  582, 1584,  556, 514,  556, 1562,  580, 1582,  556, 514,  554, 516,  556, 1584,  556, 512,  558, 512,  556, 1584,  556, 514,  554, 514,  554, 1562,  578, 1564,  580, 512,  556, 1586,  556, 1584,  556, 514,  556, 1584,  558, 512,  558, 512,  556, 514,  556, 514,  556, 1584,  556, 514,  556, 1584,  556, 514,  556, 1582,  556, 1584,  556, 1584,  558, 1560,  580, 514,  556, 512,  556, 1584,  558, 512,  554, 514,  556, 1586,  556, 1562,  578, 514,  556, 514,  558, 512,  556, 1584,  558, 512,  560, 1556,  584, 1580,  560, 1558,  580, 1560,  582, 1558,  582};  // UNKNOWN 814236B0
14:09:36.453 -> 
14:09:36.453 -> 
14:09:48.054 -> Timestamp : 000775.587
14:09:48.054 -> Library   : v2.7.12
14:09:48.054 -> 
14:09:48.054 -> Protocol  : UNKNOWN
14:09:48.054 -> Code      : 0x948006A8 (100 Bits)
14:09:48.054 -> uint16_t rawData[199] = {4382, 4362,  548, 1620,  522, 520,  546, 1620,  522, 1618,  524, 520,  548, 520,  550, 1618,  522, 522,  548, 520,  550, 1618,  522, 520,  550, 520,  548, 1618,  524, 1616,  524, 522,  548, 1616,  522, 1618,  524, 522,  548, 1616,  524, 1616,  550, 1590,  524, 1616,  524, 1616,  524, 1616,  526, 518,  550, 1616,  524, 518,  578, 492,  550, 518,  552, 520,  550, 520,  550, 520,  550, 518,  552, 1614,  526, 518,  552, 520,  576, 1588,  526, 1614,  526, 1614,  526, 518,  550, 516,  578, 1590,  526, 520,  548, 1616,  526, 1614,  526, 518,  550, 1614,  552, 1588,  528, 5166,  4418, 4328,  582, 1564,  580, 512,  556, 1558,  582, 1584,  556, 514,  556, 512,  558, 1582,  558, 512,  554, 516,  552, 1564,  580, 512,  556, 514,  556, 1584,  556, 1584,  556, 514,  556, 1562,  580, 1584,  556, 514,  556, 1584,  556, 1562,  578, 1584,  558, 1560,  578, 1562,  580, 1584,  556, 514,  554, 1586,  556, 514,  556, 514,  556, 514,  558, 512,  554, 514,  556, 514,  554, 516,  556, 1584,  556, 512,  556, 514,  556, 1586,  554, 1586,  554, 1586,  556, 514,  556, 512,  558, 1582,  556, 514,  556, 1560,  580, 1558,  582, 512,  584, 1530,  582, 1558,  582};  // UNKNOWN 948006A8
14:09:48.193 -> 
14:09:48.193 -> 
14:09:54.037 -> Timestamp : 000781.554
14:09:54.037 -> Library   : v2.7.12
14:09:54.037 -> 
14:09:54.037 -> Protocol  : UNKNOWN
14:09:54.037 -> Code      : 0x41D575D0 (100 Bits)
14:09:54.037 -> uint16_t rawData[199] = {4384, 4360,  546, 1620,  524, 520,  548, 1618,  520, 1620,  524, 520,  548, 520,  548, 1618,  524, 520,  548, 522,  548, 1620,  522, 520,  548, 522,  546, 1618,  524, 1616,  524, 522,  548, 1616,  524, 1618,  524, 518,  550, 1618,  524, 1616,  522, 1618,  524, 1618,  522, 1618,  524, 1616,  524, 518,  550, 1616,  524, 522,  550, 518,  550, 518,  550, 546,  524, 520,  550, 520,  546, 522,  548, 1618,  524, 520,  548, 546,  524, 1616,  526, 1614,  526, 1616,  552, 492,  552, 520,  576, 1588,  526, 1614,  552, 1588,  526, 1616,  550, 1590,  526, 1614,  552, 1590,  552, 5140,  4416, 4328,  584, 1584,  556, 514,  556, 1584,  554, 1586,  554, 516,  554, 514,  554, 1586,  556, 514,  558, 512,  558, 1584,  556, 514,  556, 514,  554, 1562,  578, 1584,  556, 514,  554, 1586,  556, 1586,  554, 514,  554, 1562,  578, 1562,  578, 1586,  554, 1564,  580, 1584,  556, 1584,  558, 512,  556, 1584,  556, 514,  556, 514,  554, 516,  554, 514,  556, 514,  556, 514,  556, 514,  556, 1584,  556, 514,  556, 514,  554, 1562,  578, 1586,  554, 1584,  556, 514,  556, 514,  556, 1560,  580, 1560,  578, 1562,  580, 1562,  580, 1560,  582, 1558,  582, 1558,  582};  // UNKNOWN 41D575D0
14:09:54.130 -> 

[crankyoldgit]

Sorry for the delay.
Latest commit doesn't produces desidered output, without setting ac.setFan(kCoolixFanZoneFollow); i get:

14:00:21.225 -> Protocol  : COOLIX
14:00:21.225 -> Code      : 0xBAB34E (24 Bits)
14:00:21.225 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 5 (Auto), Temp: 24C, Zone Follow: Off, Sensor Temp: 19C
14:00:21.225 -> uint16_t rawData[199] = {4674, 4434,  594, 1618,  592, 542,  562, 1622,  618, 1594,  594, 1618,  590, 542,  566, 1616,  598, 542,  596, 512,  592, 1592,  594, 540,  596, 512,  594, 512,  594, 1592,  592, 540,  568, 1616,  622, 1590,  622, 512,  596, 1590,  618, 1590,  624, 512,  594, 512,  596, 1588,  618, 1594,  616, 518,  592, 1590,  622, 514,  594, 512,  594, 1590,  622, 1588,  622, 514,  594, 514,  594, 514,  592, 1592,  620, 514,  592, 514,  596, 1586,  624, 1588,  620, 1590,  624, 512,  594, 1590,  620, 514,  596, 1588,  620, 1590,  624, 512,  590, 516,  592, 514,  592, 1590,  620, 5178,  4772, 4348,  616, 1596,  588, 544,  588, 1594,  590, 1620,  592, 1618,  588, 546,  564, 1620,  618, 518,  562, 546,  560, 1624,  614, 520,  564, 544,  560, 546,  558, 1624,  588, 546,  560, 1624,  588, 1624,  588, 548,  558, 1626,  584, 1626,  584, 550,  556, 552,  556, 1626,  584, 1628,  584, 528,  578, 1628,  582, 528,  578, 528,  580, 1630,  582, 1628,  580, 528,  580, 526,  580, 528,  578, 1630,  582, 524,  578, 530,  580, 1630,  580, 1630,  580, 1630,  582, 528,  580, 1630,  580, 528,  580, 1632,  578, 1632,  578, 528,  578, 530,  578, 530,  578, 1632,  578};  // COOLIX BAB34E
14:00:21.319 -> uint64_t data = 0xBAB34E;

It seems that ignores the "fanMode" implementation.
Comparison using ac.setFan(kCoolixFanZoneFollow);

14:05:59.090 -> Protocol  : COOLIX
14:05:59.090 -> Code      : 0xBAD34E (24 Bits)
14:05:59.090 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 6 (Zone Follow), Temp: 24C, Zone Follow: Off, Sensor Temp: 19C
14:05:59.138 -> uint16_t rawData[199] = {4776, 4340,  622, 1590,  624, 512,  594, 1588,  620, 1592,  622, 1588,  594, 540,  594, 1590,  594, 542,  592, 516,  594, 1590,  618, 516,  564, 542,  592, 516,  564, 1620,  592, 542,  564, 1620,  620, 1592,  592, 1618,  594, 542,  576, 1608,  592, 542,  592, 516,  562, 1622,  590, 1620,  590, 546,  560, 548,  560, 1622,  590, 546,  558, 1624,  590, 1622,  588, 548,  558, 550,  558, 548,  560, 1622,  590, 548,  558, 548,  560, 1622,  588, 1624,  586, 1626,  584, 524,  586, 1624,  586, 524,  582, 1626,  584, 1628,  582, 528,  580, 524,  582, 524,  582, 1630,  584, 5214,  4730, 4386,  554, 1658,  578, 528,  580, 1632,  578, 1632,  578, 1634,  578, 528,  578, 1632,  552, 556,  580, 528,  552, 1658,  552, 556,  578, 528,  578, 530,  552, 1660,  564, 542,  552, 1662,  578, 1634,  552, 1660,  552, 556,  576, 1636,  550, 558,  550, 556,  550, 1660,  550, 1662,  576, 532,  550, 558,  576, 1636,  550, 556,  550, 1660,  578, 1634,  552, 556,  550, 558,  550, 556,  550, 1662,  550, 558,  550, 556,  550, 1662,  548, 1662,  548, 1664,  548, 560,  548, 1664,  548, 560,  548, 1664,  548, 1664,  546, 562,  546, 562,  546, 560,  546, 1666,  544};  // COOLIX BAD34E
14:05:59.230 -> uint64_t data = 0xBAD34E;

I think you're not using the latest version of that branch. My tests indicate it's working as inspected. See https://github.com/crankyoldgit/IRremoteESP8266/commit/44ef381359d673ac747edd764197b0a3bce5d275 for how I tested/verified it.

I can also tell you're using an old version of that branch because it's listing "Zone Follow: Off" which was fixed a few commits back. i.e. I think you need to update, and rebuild your both your sender and decoder binaries.

As for the timer messages. They (unfortunately) don't follow the Coolix protocol's integrity check, which is a byte, followed by the same byte but inverted.

e.g.
The message that is marked as _"UNKNOWN 948006A8"_ decodes to:
0xDA7202FDB24D (LSB first) (when using tools/auto_analyse_raw_data.py)

0xDA inverted is 0x25, but the next byte is 0x72. i.e. Integrity check fails.
0x02 inverted is 0xFD, which does match the next byte, 0xFD.
0xB2 inverted is 0x4D, which does match the next byte, 0x4D.

Thus, we can't decode it as COOLIX nor can sendCOOLIX() send as it contains more than _24_ bits (kCoolixBits) of info and not in the correct structure.

If we want to add native ability to send & decode these Coolix-like messages to the library, we will have to add it under a different protocol. Honestly, I think it will be a mess to shoe-horn support for them into the IRCoolixAC class. I.e. I'm against it. ;)
I can add a COOLIX-LIKE protocol for decoding and sending them, but as mentioned here and elsewhere, Timers are pretty much the lowest priority as you're better controlling the device by sending an IR message at the correct time, rather than telling the A/C in advance. This gives far better timing control and functionality etc.

[fraschizzato]

I think the same about timers, if it was easy (like in Midea) it would be a feature, but at this stage is a loss of time.
My receiver uses the old library version but in the sender I have the lastest Coolix branch. I will redo a test from a clean environment.

[crankyoldgit]

Hopefully your rebuild went well, as per the unit test example I added, the following should build/send your 0xBAD34E code:

  IRCoolixAC ac(kGpioUnused);
  ac.setPower(true);
  ac.setMode(kCoolixHeat);
  ac.setTemp(24);  // C
  ac.setSensorTemp(19);  // C
  ac.send();

[fraschizzato]

Confirmed working. Here the code and the result.

#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>
#include <ir_Coolix.h>


const uint16_t kIrLed = 4;  // ESP8266 GPIO pin to use. Recommended: 4 (D2).
IRCoolixAC ac(kIrLed);  // Set the GPIO to be used to sending the message.

void setup() {
  ac.begin();
  ac.setMode(kCoolixHeat);
  ac.setTemp(24);
  ac.send();
  delay(30000);
  //ac.setFan(kCoolixFanZoneFollow);
  const uint8_t temp = 19;
  ac.setSensorTemp(temp);
  ac.send();
  delay(60000);
  ac.setSensorTemp(22);
  ac.send();
  delay(60000);
  ac.setSensorTemp(30);
  ac.send();
  delay(60000);
}

void loop() {

}

17:13:30.863 -> IRrecvDump is now running and waiting for IR input on Pin 4
17:13:35.643 -> Timestamp : 000004.854
17:13:35.643 -> Library   : v2.7.12
17:13:35.643 -> 
17:13:35.643 -> Protocol  : COOLIX
17:13:35.643 -> Code      : 0xB2BF4C (24 Bits)
17:13:35.643 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 5 (Auto), Temp: 24C, Zone Follow: Off, Sensor Temp: Off
17:13:35.690 -> uint16_t rawData[199] = {4690, 4448,  558, 1684,  558, 548,  558, 1654,  558, 1630,  560, 572,  558, 550,  556, 1632,  588, 554,  558, 550,  532, 1678,  532, 574,  556, 550,  558, 1628,  584, 1626,  584, 548,  560, 1624,  590, 1622,  590, 544,  560, 1626,  584, 1626,  588, 1650,  560, 1650,  562, 1622,  586, 1626,  590, 542,  562, 1622,  590, 544,  562, 544,  564, 542,  564, 544,  564, 542,  564, 546,  564, 542,  564, 1620,  590, 544,  562, 544,  566, 1646,  564, 1620,  592, 542,  564, 542,  566, 1618,  592, 542,  566, 1618,  592, 1618,  594, 540,  566, 540,  564, 1620,  616, 1596,  592, 5208,  4764, 4354,  588, 1624,  586, 548,  558, 1626,  584, 1624,  588, 548,  556, 550,  556, 1626,  586, 550,  556, 552,  556, 1628,  584, 550,  556, 552,  556, 1626,  584, 1628,  582, 552,  552, 1632,  582, 1630,  580, 528,  580, 1630,  580, 1632,  580, 1630,  580, 1632,  580, 1630,  580, 1634,  580, 528,  578, 1634,  578, 528,  580, 528,  578, 528,  578, 530,  578, 528,  580, 528,  578, 530,  578, 1632,  578, 528,  580, 528,  578, 1632,  578, 1632,  578, 528,  578, 530,  578, 1632,  578, 530,  578, 1634,  578, 1634,  552, 556,  576, 532,  550, 1660,  552, 1660,  576};  // COOLIX B2BF4C
17:13:35.782 -> uint64_t data = 0xB2BF4C;
17:13:35.782 -> 
17:13:35.782 -> 
17:14:05.939 -> Timestamp : 000035.142
17:14:05.939 -> Library   : v2.7.12
17:14:05.939 -> 
17:14:05.939 -> Protocol  : COOLIX
17:14:05.939 -> Code      : 0xBAD34E (24 Bits)
17:14:05.939 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 6 (Zone Follow), Temp: 24C, Zone Follow: On, Sensor Temp: 19C
17:14:05.986 -> uint16_t rawData[199] = {4706, 4412,  556, 1684,  528, 578,  530, 1656,  554, 1684,  526, 1684,  528, 578,  554, 1656,  528, 582,  528, 580,  528, 1682,  528, 580,  528, 578,  526, 580,  528, 1682,  530, 552,  554, 1684,  528, 1684,  528, 1682,  530, 552,  556, 1680,  530, 578,  554, 552,  530, 1656,  554, 1656,  582, 550,  532, 576,  538, 1650,  578, 552,  532, 1656,  582, 1628,  586, 548,  534, 572,  558, 550,  558, 1628,  584, 548,  558, 548,  558, 1626,  586, 1626,  586, 1626,  586, 546,  562, 1622,  586, 548,  562, 1622,  588, 1622,  590, 544,  564, 544,  564, 540,  566, 1622,  588, 5206,  4770, 4350,  590, 1622,  590, 544,  588, 1596,  588, 1622,  588, 1624,  588, 546,  558, 1626,  586, 550,  558, 550,  556, 1626,  588, 548,  558, 548,  558, 548,  558, 1626,  582, 552,  558, 1628,  584, 1628,  582, 1630,  582, 552,  552, 1632,  580, 528,  578, 528,  578, 1630,  582, 1632,  580, 528,  578, 528,  578, 1630,  580, 528,  582, 1628,  580, 1632,  580, 528,  580, 528,  578, 526,  580, 1632,  580, 528,  578, 530,  580, 1630,  580, 1632,  578, 1632,  578, 530,  578, 1634,  578, 528,  552, 1660,  576, 1634,  576, 530,  552, 556,  576, 530,  554, 1658,  578};  // COOLIX BAD34E
17:14:06.079 -> uint64_t data = 0xBAD34E;
17:14:06.079 -> 
17:14:06.079 -> 
17:15:06.228 -> Timestamp : 000095.432
17:15:06.228 -> Library   : v2.7.12
17:15:06.228 -> 
17:15:06.228 -> Protocol  : COOLIX
17:15:06.228 -> Code      : 0xBAD64E (24 Bits)
17:15:06.228 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 6 (Zone Follow), Temp: 24C, Zone Follow: On, Sensor Temp: 22C
17:15:06.274 -> uint16_t rawData[199] = {4710, 4410,  584, 1654,  532, 576,  556, 1630,  580, 1654,  532, 1656,  580, 550,  556, 1654,  558, 550,  534, 572,  560, 1626,  584, 548,  560, 546,  560, 548,  560, 1650,  560, 548,  558, 1628,  584, 1626,  588, 1624,  584, 548,  562, 1622,  588, 546,  562, 1624,  586, 1626,  586, 546,  562, 544,  564, 542,  562, 1624,  590, 544,  564, 1620,  590, 544,  566, 542,  564, 1624,  590, 542,  564, 1618,  592, 542,  592, 516,  564, 1620,  590, 1622,  590, 1620,  590, 546,  564, 1620,  590, 542,  586, 1600,  588, 1620,  592, 544,  562, 544,  588, 518,  588, 1594,  618, 5182,  4734, 4382,  584, 1626,  584, 550,  554, 1628,  582, 1630,  580, 1630,  582, 530,  576, 1630,  582, 528,  582, 526,  580, 1630,  582, 526,  578, 528,  580, 528,  578, 1630,  580, 528,  582, 1632,  576, 1634,  580, 1630,  580, 526,  580, 1632,  578, 528,  576, 1634,  580, 1632,  552, 556,  580, 528,  576, 530,  578, 1632,  578, 530,  578, 1632,  578, 530,  578, 528,  578, 1636,  578, 530,  578, 1634,  550, 556,  554, 554,  576, 1634,  576, 1636,  550, 1660,  550, 558,  550, 1660,  552, 556,  552, 1660,  552, 1660,  552, 556,  576, 532,  560, 546,  576, 1636,  562};  // COOLIX BAD64E
17:15:06.366 -> uint64_t data = 0xBAD64E;
17:15:06.366 -> 
17:15:06.366 -> 
17:16:06.535 -> Timestamp : 000155.721
17:16:06.535 -> Library   : v2.7.12
17:16:06.535 -> 
17:16:06.535 -> Protocol  : COOLIX
17:16:06.535 -> Code      : 0xBADE4E (24 Bits)
17:16:06.535 -> Mesg Desc.: Power: On, Mode: 3 (Heat), Fan: 6 (Zone Follow), Temp: 24C, Zone Follow: On, Sensor Temp: 30C
17:16:06.535 -> uint16_t rawData[199] = {4706, 4410,  560, 1680,  528, 552,  556, 1682,  532, 1680,  530, 1680,  530, 576,  530, 1682,  530, 578,  530, 576,  530, 1682,  530, 578,  530, 552,  556, 574,  530, 1682,  532, 574,  558, 1654,  556, 1656,  530, 1680,  560, 546,  560, 1628,  582, 1652,  560, 1650,  560, 1626,  586, 546,  560, 546,  560, 546,  562, 1624,  586, 546,  562, 544,  564, 544,  562, 546,  560, 1650,  562, 548,  562, 1622,  590, 544,  562, 544,  564, 1648,  564, 1622,  588, 1620,  592, 544,  566, 1620,  592, 540,  566, 1618,  616, 1596,  588, 544,  564, 542,  566, 540,  566, 1618,  594, 5206,  4764, 4354,  586, 1626,  584, 550,  556, 1626,  584, 1628,  582, 1628,  582, 552,  554, 1630,  580, 530,  578, 528,  578, 1628,  582, 528,  578, 528,  580, 528,  578, 1630,  580, 528,  580, 1632,  580, 1632,  580, 1632,  580, 528,  578, 1630,  578, 1634,  578, 1632,  578, 1634,  578, 528,  580, 528,  580, 528,  578, 1634,  578, 528,  578, 528,  578, 530,  576, 530,  578, 1634,  576, 530,  560, 1652,  550, 556,  576, 532,  576, 1634,  576, 1636,  550, 1660,  556, 552,  550, 1660,  550, 556,  576, 1636,  550, 1660,  550, 556,  550, 556,  550, 556,  552, 1660,  550};  // COOLIX BADE4E
17:16:06.629 -> uint64_t data = 0xBADE4E;
17:16:06.629 -> 
17:16:06.629 -> 

I think that now all the work is done.
It was a real pleasure
Thanks

[crankyoldgit]

@fraschizzato Thanks for the confirmation. Sorry it took so long to resolve it all.

[crankyoldgit]

FYI, the changes mentioned above have now been included in the new v2.7.13 release of the library.