Irremoteesp8266: Midea not decoding properly

[wizkidorg]

Version/revision of the library used

2.7.7

Expected behavior

Midea decoding more reliable

Actual behavior

currently it takes 5-10 tried to get it to decode, and sometimes after wards will decode properly for 5-10 successive then stops again.

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

Below are 2 outputs from the same value on remote control, just once with it actually decoding and the other where it fails to decode.
Expected:
Protocol : MIDEA
Code : 0xA1A072FFFF54 (48 Bits)
Mesg Desc.: Power: On, Mode: 0 (Cool), Celsius: Off, Temp: 27C/80F, Fan: 0 (Auto), Sleep: Off, Swing(V) Toggle: Off
uint16_t rawData[199] = {4716, 4116, 844, 1318, 818, 264, 782, 1376, 762, 314, 736, 342, 736, 340, 716, 362, 694, 1462, 682, 1476, 676, 408, 658, 1498, 644, 432, 628, 450, 616, 458, 610, 466, 606, 472, 592, 484, 586, 1566, 594, 1560, 584, 1572, 582, 494, 596, 478, 592, 1564, 584, 492, 584, 1568, 586, 1570, 586, 1568, 592, 1562, 590, 1566, 586, 1568, 586, 1566, 590, 1564, 598, 1556, 594, 1562, 590, 1558, 588, 1568, 590, 1564, 582, 1572, 594, 1560, 590, 1562, 586, 490, 594, 1562, 608, 470, 590, 1566, 584, 488, 594, 1562, 592, 488, 590, 482, 584, 5168, 4458, 4374, 588, 486, 590, 1566, 586, 488, 592, 1564, 584, 1568, 594, 1558, 596, 1556, 588, 488, 604, 472, 598, 1558, 596, 478, 594, 1562, 596, 1554, 590, 1566, 596, 1558, 590, 1562, 590, 1564, 592, 484, 598, 478, 586, 490, 592, 1562, 600, 1554, 590, 486, 600, 1556, 582, 490, 602, 476, 594, 482, 600, 474, 584, 492, 590, 486, 584, 492, 590, 486, 592, 486, 594, 484, 588, 488, 584, 492, 592, 484, 586, 492, 596, 480, 586, 490, 598, 1554, 588, 490, 590, 1564, 586, 490, 586, 1568, 588, 488, 592, 1560, 592, 1562, 600}; // MIDEA A1A072FFFF54
uint64_t data = 0xA1A072FFFF54;

Getting:
Protocol : UNKNOWN
Code : 0x9D743BAA (100 Bits)
uint16_t rawData[199] = {4718, 4116, 852, 1300, 854, 222, 852, 1302, 854, 222, 860, 218, 860, 218, 856, 222, 852, 1318, 816, 1342, 784, 294, 762, 1396, 736, 340, 730, 348, 708, 368, 704, 374, 678, 408, 668, 416, 646, 1506, 638, 1520, 626, 1524, 624, 452, 608, 470, 594, 1560, 586, 492, 584, 1568, 600, 1554, 596, 1558, 588, 1568, 598, 1554, 586, 1570, 582, 1568, 580, 1574, 588, 1568, 580, 1574, 578, 1574, 584, 1572, 582, 1572, 588, 1564, 594, 1560, 584, 1570, 600, 476, 592, 1560, 602, 478, 592, 1558, 600, 476, 600, 1556, 600, 476, 586, 488, 592, 5164, 4458, 4370, 596, 480, 594, 1560, 602, 474, 596, 1558, 588, 1564, 602, 1554, 600, 1554, 592, 484, 594, 484, 604, 1550, 594, 478, 592, 1562, 582, 1570, 588, 1568, 594, 1560, 584, 1570, 594, 1562, 596, 482, 586, 488, 586, 492, 592, 1560, 590, 1566, 598, 478, 590, 1564, 598, 478, 598, 478, 592, 486, 594, 484, 590, 484, 580, 496, 588, 490, 598, 476, 596, 482, 594, 484, 584, 490, 590, 486, 586, 492, 606, 470, 602, 476, 592, 486, 586, 1564, 594, 484, 598, 1554, 604, 474, 592, 1562, 584, 494, 596, 1560, 592, 1564, 594}; // UNKNOWN 9D743BAA

Another variant (adjusted temp down by 1 degree)
Expected:
Protocol : MIDEA
Code : 0xA1A071FFFF57 (48 Bits)
Mesg Desc.: Power: On, Mode: 0 (Cool), Celsius: Off, Temp: 26C/79F, Fan: 0 (Auto), Sleep: Off, Swing(V) Toggle: Off
uint16_t rawData[199] = {4602, 4250, 716, 1434, 704, 376, 692, 1462, 680, 402, 658, 424, 646, 434, 626, 454, 614, 1538, 618, 1538, 596, 482, 588, 1562, 592, 486, 582, 494, 582, 496, 588, 486, 584, 494, 584, 492, 580, 1572, 580, 1572, 592, 1562, 588, 488, 584, 492, 590, 490, 580, 1572, 592, 1560, 588, 1568, 580, 1572, 586, 1570, 588, 1564, 580, 1574, 596, 1558, 588, 1568, 598, 1554, 594, 1558, 588, 1568, 604, 1546, 600, 1554, 592, 1560, 598, 1556, 598, 1558, 584, 494, 586, 1564, 588, 488, 588, 1566, 592, 484, 592, 1562, 594, 1562, 594, 1560, 592, 5160, 4458, 4372, 604, 472, 590, 1566, 584, 492, 584, 1570, 580, 1576, 588, 1564, 592, 1558, 580, 500, 588, 488, 586, 1566, 584, 492, 604, 1550, 586, 1568, 596, 1558, 598, 1556, 596, 1558, 596, 1558, 592, 484, 586, 490, 582, 496, 588, 1566, 592, 1560, 582, 1574, 586, 490, 578, 498, 586, 490, 578, 500, 588, 488, 584, 494, 588, 488, 580, 494, 582, 494, 594, 484, 592, 486, 580, 496, 590, 486, 586, 492, 582, 496, 582, 492, 592, 484, 590, 1564, 588, 488, 588, 1568, 582, 494, 588, 1566, 582, 494, 588, 490, 586, 490, 582}; // MIDEA A1A071FFFF57
uint64_t data = 0xA1A071FFFF57;

Frequently decoded as:
Protocol : UNKNOWN
Code : 0x802C6E48 (100 Bits)
uint16_t rawData[199] = {4714, 4114, 856, 1300, 856, 216, 864, 1298, 850, 220, 860, 218, 854, 222, 850, 234, 818, 1350, 784, 1372, 764, 316, 730, 1428, 726, 350, 718, 360, 696, 380, 698, 386, 676, 400, 676, 406, 658, 1502, 630, 1524, 622, 1530, 616, 464, 612, 464, 608, 466, 598, 1556, 592, 1562, 594, 1558, 588, 1566, 604, 1550, 606, 1550, 598, 1556, 594, 1562, 594, 1562, 580, 1572, 586, 1568, 590, 1566, 592, 1562, 592, 1564, 600, 1552, 592, 1562, 582, 1576, 598, 478, 598, 1558, 580, 496, 600, 1554, 602, 476, 586, 1566, 604, 1552, 590, 1564, 586, 5170, 4460, 4372, 586, 488, 584, 1570, 588, 490, 594, 1560, 596, 1560, 590, 1564, 592, 1558, 588, 490, 584, 492, 592, 1562, 592, 484, 590, 1564, 590, 1564, 580, 1574, 598, 1558, 586, 1566, 586, 1568, 596, 482, 596, 478, 580, 496, 596, 1560, 586, 1568, 598, 1556, 598, 482, 586, 488, 598, 480, 580, 498, 600, 476, 590, 488, 590, 486, 586, 492, 596, 480, 578, 496, 588, 488, 602, 478, 590, 484, 582, 494, 596, 480, 586, 492, 584, 490, 588, 1566, 582, 496, 590, 1562, 586, 492, 586, 1564, 592, 486, 590, 486, 586, 490, 592}; // UNKNOWN 802C6E48

Steps to reproduce the behavior

Press Power button on remote multiple times. (keeping all other settings same)

Example code used

IRrecvDumpV2 & V3.

Circuit diagram and hardware used (if applicable)

ESP32 connected to VS1838B decoder, with breakout that provides 120ohm pullup, and directly using enableirin(true) to set esp32 internal pullup's
Have used GPIO 12 and 13.
Set kCaptureBufferSize to 2048 also, even though never got any overflow errors.

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

YES

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

No.

Other useful information

Tried the following also:
kMideaTolerance = 50 , this helps it decode more often, but still randomly.

[crankyoldgit]

The raw data you provided has values that are very inconsistent. Something is very wrong with your circuit/environment/or receiver module.

I suspect it's a combination of the last two.
The VS1838b is cheap and reportedly performs poorly. (Read https://www.analysir.com/blog/2014/12/08/infrared-receiver-showdown-tsop34438-vs-vs1838b-winner-revealed/) I'd strongly suggest trying a "better" IR receiving module.

[wizkidorg]

Ok thank you. I been going crazy trying to figure out the cause. I will close this issue.

[crankyoldgit]

FYI, you can also try playing around with the noise_floor parameter of IRrecv::decode()

See the API docs here: https://crankyoldgit.github.io/IRremoteESP8266/doxygen/html/classIRrecv.html#aeaa5c07a8b46f8fbb982f996cc1f9f4b

Looking at the raw data again, you'd probably need to to set it to around 200-300usecs to account for what might be going on.

I'd adjust your tolerance to something less than 50% too.

But yes, ultimately, it appears that IR receiver module exemplifies the phrase "You get what you pay for". i.e. Try a better one, or try it when it's dark and cool. (according to the article I linked).

Alternatively, it may operate better at 5V, but you are using an ESP32, and they DO NOT like 5V inputs. (i.e. magic smoke)

[wizkidorg]

After switching IR Receiver, I have MUCH better success in decoding. I think it was related to the IR receiver. It still intermittently doesn't but now its 1 out of 20-30 (or more) decodes. So all is good, I was worried my remote was doing something weird. I will have to submit a new request for the LED button on the remote though, it does something weird. When pressed the code decodes it as turning off the device, I think the LED function is some strange bit mask that flips a lot of bits to turn off the LED panel.

Thank you again for looking into it!

[crankyoldgit]

Congrats. You've inspired me to add a point about this particular demodulator to the FAQ.
See https://github.com/crankyoldgit/IRremoteESP8266/wiki/Frequently-Asked-Questions#Help_Im_getting_very_inconsistent_results_when_capturing_an_IR_message_using_a_VS1838b_IR_demodulator

[NiKiZe]

Alternatively, it may operate better at 5V, but you are using an ESP32, and they DO NOT like 5V inputs. (i.e. magic smoke)

Before anything else, do not trust the below, always check yourself....
VS1838B Should have open pull down, any pull up should be external, which means you should never have any voltage directly out from that pin (again don't trust me and check your specific, possible bad clone reciever output)
Having a 1K series resistor from the output pin to ESP input pin should limit the current enough for it to be ok for a quick test. (But again there is no guarantees, so only use this as a last resort kind of thing for testing, and be prepared for a dead ESP)

[wizkidorg]

Yes I tried using it with the supplied break out which has a pull-up onboard and the sensor directly. Both have the same issue, after switching the receiver 99% of my issues went away. I also tried another receiver but that is a pure 5v only version which requires much more to work with an ESP32.

I didn't think these IR receivers were so widely unpredictable from device to device. If not using a well known manufacturer your mileage may vary.

Sorry to say though, the version I am using (that works very well) doesn't have any markings on it, so i'm not sure what model it is.