Irremoteesp8266: Midea code on Pioneer does not match capture or fully turn on

Created on 24 Nov 2020  Â·  16Comments  Â·  Source: crankyoldgit/IRremoteESP8266

Version/revision of the library used - 2.7.12

Expected behavior - MIdea code should match captured, and should have the same result on the unit.

Captured remote data - appeared to work correctly:
Protocol : MIDEA
Code : 0xA1A368FFFF45 (48 Bits)
Mesg Desc.: Type: 1 (Command), Power: On, Mode: 3 (Heat), Celsius: Off, Temp: 21C/70F, On Timer: Off, Off Timer: Off, Fan: 0 (Auto), Sleep: Off, Swing(V) Toggle: Off, Econo Toggle: Off, Turbo Toggle: Off, Light Toggle: Off
uint16_t rawData[199] = {4456, 4372, 592, 1560, 592, 486, 588, 1564, 590, 486, 588, 486, 594, 486, 588, 488, 588, 1560, 594, 1564, 588, 486, 588, 1564, 592, 486, 590, 486, 588, 488, 588, 1560, 594, 1560, 592, 486, 588, 1564, 592, 1560, 594, 486, 588, 1560, 592, 488, 588, 486, 594, 482, 588, 1564, 592, 1558, 594, 1560, 592, 1560, 592, 1558, 594, 1562, 590, 1562, 594, 1558, 594, 1560, 594, 1558, 594, 1564, 588, 1564, 588, 1564, 594, 1558, 594, 1560, 592, 1560, 594, 486, 590, 1562, 590, 488, 588, 492, 590, 486, 590, 1558, 594, 486, 590, 1558, 594, 5158, 4456, 4370, 594, 486, 588, 1560, 594, 486, 588, 1560, 594, 1558, 594, 1564, 588, 1564, 588, 492, 588, 488, 588, 1560, 592, 486, 590, 1560, 592, 1564, 592, 1560, 592, 488, 588, 488, 588, 1560, 592, 490, 586, 486, 590, 1562, 590, 486, 588, 1564, 592, 1560, 592, 1560, 592, 488, 588, 488, 590, 486, 590, 488, 588, 492, 586, 490, 588, 486, 590, 486, 588, 488, 588, 488, 588, 486, 588, 488, 588, 488, 588, 486, 588, 492, 588, 488, 588, 1560, 592, 488, 588, 1560, 594, 1558, 594, 1560, 594, 486, 588, 1564, 588, 518, 558}; // MIDEA A1A368FFFF45
uint64_t data = 0xA1A368FFFF45;

Protocol : MIDEA
Code : 0xA12368FFFFC5 (48 Bits)
Mesg Desc.: Type: 1 (Command), Power: Off, Mode: 3 (Heat), Celsius: Off, Temp: 21C/70F, On Timer: Off, Off Timer: Off, Fan: 0 (Auto), Sleep: Off, Swing(V) Toggle: Off, Econo Toggle: Off, Turbo Toggle: Off, Light Toggle: Off
uint16_t rawData[199] = {4454, 4372, 592, 1558, 594, 488, 588, 1564, 590, 486, 592, 484, 592, 482, 594, 486, 588, 1560, 594, 486, 588, 486, 590, 1558, 594, 486, 588, 488, 588, 486, 594, 1560, 592, 1560, 594, 486, 588, 1560, 592, 1564, 592, 482, 588, 1564, 594, 482, 592, 486, 590, 486, 588, 1560, 592, 1560, 592, 1564, 590, 1564, 592, 1560, 592, 1560, 592, 1564, 590, 1562, 594, 1558, 594, 1558, 594, 1564, 590, 1562, 594, 1560, 592, 1560, 592, 1564, 588, 1564, 592, 1558, 594, 1560, 592, 488, 588, 486, 588, 488, 592, 1560, 592, 488, 588, 1558, 594, 5158, 4454, 4376, 588, 490, 588, 1560, 594, 486, 588, 1560, 592, 1564, 588, 1564, 594, 1558, 594, 486, 590, 1562, 588, 1564, 594, 486, 588, 1558, 594, 1560, 594, 1562, 590, 486, 588, 488, 592, 1560, 594, 488, 588, 488, 588, 1558, 594, 486, 590, 1564, 592, 1560, 594, 1558, 594, 486, 588, 488, 588, 488, 588, 486, 590, 486, 588, 488, 588, 488, 588, 486, 588, 488, 588, 488, 592, 488, 588, 486, 588, 488, 588, 486, 590, 486, 590, 486, 588, 488, 588, 488, 588, 1564, 588, 1564, 594, 1560, 594, 486, 588, 1560, 592, 488, 588}; // MIDEA A12368FFFFC5
uint64_t data = 0xA12368FFFFC5;

I Created the Midea object - and the ac.toString() shows the same state functions - power on shown below:
Type: 1 (Command), Power: On, Mode: 3 (Heat), Celsius: Off, Temp: 21C/70F, On Timer: Off, Off Timer: Off, Fan: 0 (Auto), Sleep: Off, Swing(V) Toggle: Off, Econo Toggle: Off, Turbo Toggle: Off, Light Toggle: Off
IR Code: 0x68FFFF65

The raw data does not match the data captured, however MIDEA decodes it as the same.

I also have the power off
captured - Code : 0xA12368FFFFC5 (48 Bits)
From Midea object - IR Code: 0x68FFFFE5

I tried both of the Midea generated codes on my Pioneer Mini Split.

The Midea generated power off does power off the unit
The Midea generated power on appears to turn on the power - but only partially - the vent opens but the fan never turns on.

I have been through the code, and while a majority of the details are still over my head, this appears to be some small bug. They should not be decoded the same if they are not the same message.

Thanks

Pending Confirmation

Most helpful comment

What is the exact model number of th AC and the remote? (Just so we can get this documented correctly)

All 16 comments

captured - Code : 0xA12368FFFFC5 (48 Bits)
From Midea object - IR Code: 0x68FFFFE5

The second value you have there is truncated to 32 bits. Are you saving the result of IRMideaAC::getRaw() to a uint32_t per chance? or printing it via Serial.print(ac.getRaw());. Arduino's printing routines don't handle uint64_ts.
Hence I suggest you use uint64ToString() or serialPrintUint64() in https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/IRutils.h#L22-L25

FWIW, IRMideaAC::getRaw() _does_ return a 64bit integer. See:
https://github.com/crankyoldgit/IRremoteESP8266/blob/102facd1bf966d656df4e040d7c3889327a526e0/src/ir_Midea.h#L169

I used the suggested serialPrintUint64 - thanks - it shows more that is off.

Here is the code snippet for the printstate sub and the output - I have a T11 temp sensor also on this.

void printState() {
// Display the settings.
Serial.println("Media A/C remote is in the following state:");
Serial.printf(" %s\n", ac.toString().c_str());
// Display the encoded IR sequence.
uint64_t ir_code = ac.getRaw();
Serial.print("IR Code: 0x");
//for (uint64_t i = 0; i < 48; i++)
// Serial.printf("%02X", ir_code[i]);
serialPrintUint64(ir_code,16);

Serial.println();
}

Type: 1 (Command), Power: On, Mode: 3 (Heat), Celsius: Off, Temp: 21C/70F, On Timer: Off, Off Timer: Off, Fan: 0 (Auto), Sleep: Off, Swing(V) Toggle: Off, Econo Toggle: Off, Turbo Toggle: Off, Light Toggle: Off
IR Code: 0xA18368FFFF65
Read sensor:
Temperature (oF): 68.00
Sending IR command to A/C ...
Media A/C remote is in the following state:
Type: 1 (Command), Power: Off, Mode: 3 (Heat), Celsius: Off, Temp: 21C/70F, On Timer: Off, Off Timer: Off, Fan: 0 (Auto), Sleep: Off, Swing(V) Toggle: Off, Econo Toggle: Off, Turbo Toggle: Off, Light Toggle: Off
IR Code: 0xA10368FFFFE5

I used the examples and did irsend.sendMidea(0xA1A368FFFF45); and got the behavior I expected from the unit - it turned on and started working

I used the examples and did irsend.sendMidea(0xA1A368FFFF45); and got the behavior I expected from the unit - it turned on and started working

I'm confused. What is the problem now exactly? Or is this all sorted now?

The Midea library properly decoded the signal from the remote, however it did not re-encode the same message back to the same RAW when the message was created using the Midea structure, and the RAW that was encoded did not perform the correct function.

The code that did not function correctly was created using the below snippet to change the default values to match the values of the decoded message I captured from the remote
ac.setPower(true); // on ac.setMode(kMideaACHeat); ac.setFan(kMideaACFanAuto); ac.setTemp(desired_temp); // 70F if nothing else changes

I could understand the raw signal being different, it the code worked on the mini split because there are probably unused bits.

The issue here is that the re-encoded message did not have the same function as the captured one, and the library viewed them as the same message.

I still don't understand the details of what you're saying.

Can give a small code example of what you're trying to do, and what "correct functions" that are not "performed".

Sorry - I was updating the message as you typed

void heat_on() {
power_on= true;
ac.setPower(true); // on
ac.setMode(kMideaACHeat);
ac.setFan(kMideaACFanAuto);
ac.setTemp(desired_temp); // 70F if nothing else changes
}

  • the above snippet sets the ac object to what should be the correct state when it gets printed to the serial monitor

void TurnHeatOn() {
Serial.println("Sending IR command to A/C ...");
#if SEND_MIDEA
irsend.sendMidea(0xA1A368FFFF45); // I have to send the captured raw code here because ac.send(); does not turn on the AC
#else // SEND_MIDEA
Serial.println("Can't send because SEND_MIDEA has been disabled.");
#endif // SEND_MIDEA
printState();
}

void unit_off() {
ac.setPower(false); // off
//this is the only thing I care about here
}

the unit_off function works, in that the ac.send() will turn the unit off

It appears your remote / Aircon requires a bit to be set that we don't currently set. It's an unknown "bit" as such. i.e. We don't know what it does, and we've pretty much only ever seen it set to 0 / Off.
See Line 70 of :
https://github.com/crankyoldgit/IRremoteESP8266/blob/904eb3e99b91c2f9542f93a40ae35354d01609d0/src/ir_Midea.h#L67-L72
Your 0xA1A368FFFF45 value has that bit set to 1.
i.e. _0xA1A368FFFF45_ vs _0xA18368FFFF65_ (where 0xA is _0b1010_ & 0x8 is _0b1000_)
As your unit doesn't respond, it could be some model/brand specific thing, or a special bit to handle the case where there are multiple A/C units & remotes so the can operate independently. That is all complete speculation. I just don't know if there is some other setting or something different about your remote, or A/C etc.

If you can work out what that bit is/does, then I can/will add support for what ever feature it does/controls and allow it to be set independently.

However, in the meantime, you can trick the IRMideaAC class object to set this bit in a number of ways:

  1. Before you first use the IRMideaAC class object (e.g. ac), perform ac.setRaw(0xA1A368FFFF45); and then perform your ac.setMode(), ac.setTemp(), ac.setFan() operations. It should set that single bit correctly for you, as it will remember it from the setRaw() call.
    or
  2. Perform ac.setRaw((1ULL<<37) | ac.getRaw()); before you alter the class object, or just before you send it via ac.send(). This basically just forces that bit to be 1 for any value already in the class object. Like option _1._ above, you probably only need to do that once.

Note: Any call to ac.stateReset() will cause that bit to be reset to 0, and any call to ac.setRaw() may do the same depending on the value supplied.

Thanks for the help! - I will try that later, but considering you identified the bit - it should work great.
I have 4 different Pioneer units on 2 multi unit condensers, and they all run on the same remotes. The Pioneer remote is standard, so the code sent their units does not make a distinction between the multi system units. I guess it is possible that the bit is important for multi units, but not on singles., but that is just a guess since people have apparently used the code on other Pioneer units

What is the exact model number of th AC and the remote? (Just so we can get this documented correctly)

I guess it is possible that the bit is important for multi units, but not on singles., but that is just a guess since people have apparently used the code on other Pioneer units

Probably a good guess, but not strong enough to convince me to add a setMulti() function, as well ... it could be something else. ¯\_(ツ)_/¯

12K BTU indoor wall mounted WS012GMFI22HLD
18K BTU indoor wall mounted WS018GMFI22HLD
18K BTU Flex mount UB018GMFILCFHD ** this is the one I am testing on since it is in my office space. They all have interchangeable remotes though

12K BTU indoor wall mounted WS012GMFI22HLD
18K BTU indoor wall mounted WS018GMFI22HLD
18K BTU Flex mount UB018GMFILCFHD ** this is the one I am testing on since it is in my office space. They all have interchangeable remotes though

I'm guessing they are the Pioneer Model numbers for the A/C units, what are the model numbers for the remotes?

RG66B6(B)/BGEFU1

I can collect more commands to confirm this if it would help. Otherwise, I think I have the code I absolutely need for my project!

I can collect more commands to confirm this if it would help. Otherwise, I think I have the code I absolutely need for my project!

If you can work out if there is some setting/switch on the remote that changes that single bit, that would be great. Otherwise I think we are done for now. If you find anything else odd etc, just create a new issue.

I did some more research, that bit _might_ be used with the clock/timer(s) etc. But it's not conclusive.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ayavilevich picture ayavilevich  Â·  7Comments

mariusmotea picture mariusmotea  Â·  7Comments

wahibmichael picture wahibmichael  Â·  4Comments

bwint picture bwint  Â·  4Comments

jlhavens picture jlhavens  Â·  7Comments