Irremoteesp8266: recv unknown encoding!

[win32cpp]

Unknown encoding: 265BCC7E (50 bits)
Raw (100): {8898, 4418622, 1620624, 482622, 482540, 564618, 490620, 506598, 506598, 508588, 518622, 1620600, 1620596, 1620542, 1676620, 1602622, 1616600, 1618600, 1618616, 1606624, 504622, 482600, 504586, 520624, 504600, 506598, 504542, 564620, 1602620, 1618600, 1618624, 1592588, 1632626, 1618624, 1592624, 1594542, 564620, 514596, 504626, 480600, 504614, 494622, 504598, 506600, 1618540, 1676626, 1616602, 1616600, 1616542, 1678636};
DEPRECATED: Please use IRrecvDumpV2.ino instead!
Decoded NEC: FFFFFFFFFFFFFFFF (0 bits)
Raw (4): {8876, 2232620};
DEPRECATED: Please use IRrecvDumpV2.ino instead!

//
i test via Arduino-IRremote library - it can detect correct code - but this library in ESP8266 detect Unknown encoding and unvalid code. the valid code is : 807FC03F

[crankyoldgit]

As the output suggests, you should try IRrecvDumpV2.ino

However, I'm fairly sure you've got a more fundamental problem.
The values detected there (e.g. 4418622, 1620624, ...) equate to 4.4 seconds, and 1.6 seconds respectively. That's three orders of magnitude (1000 times) higher than expected. i.e. I'd expect values in the range of < 10000. Typically in the 500-1000's.

Try the Troubleshooting Guide.

As the IR module was working on your arduino board. It may be a 5V module. You probably need to power it from the 5V pin (Vcc etc on D1 mini/NodeMCU boards)

[win32cpp]

Thanks
Yes - the receiver module is 5 volts. But using Arduino with voltages 3.3 and 5, both codes are correct. I also started and tested the WiFi module with 5 volts - unfortunately I got the previous results.....

[crankyoldgit]

I don't know what to say, other than try a different board perhaps?
What version of the library are you using btw?

[win32cpp]

I tested the results using another transmitter remote - unfortunately the codes are different:
On Code:
250200D39 (35 bits)
Raw (74): {9022, 4440722, 1588720, 486696, 510718, 1588720, 1586698, 1606700, 530682, 522674, 1612718, 508696, 1590694, 1608700, 530696, 510676, 530696, 510672, 532696, 486696, 508718, 486696, 510696, 1614720, 486718, 508682, 524674, 532694, 486694, 532674, 1608698, 508722, 1588698, 508698, 532674, 1610698, 510696};
DEPRECATED: Please use IRrecvDumpV2.ino instead!
Unknown encoding: C6FF31DD (4 bits)
Raw (9): {532, 6741612, 694510, 694532, 672};
DEPRECATED: Please use IRrecvDumpV2.ino instead!
///////////////////////////
OFF Code:
250200D31 (35 bits)
Raw (74): {9016, 4442700, 1614694, 534672, 510694, 510694, 1612694, 1612696, 512692, 510694, 1610696, 510694, 1634674, 1612696, 510696, 532672, 512694, 510694, 510694, 532674, 532672, 532674, 532674, 1610696, 512694, 512692, 510696, 532674, 510694, 510696, 1612694, 532672, 1632676, 532672, 532674, 1612696, 530674};
DEPRECATED: Please use IRrecvDumpV2.ino instead!
Unknown encoding: 27937DD3 (3 bits)
Raw (7): {1612, 696532, 6741614, 694};
DEPRECATED: Please use IRrecvDumpV2.ino instead!
////////////////////////////
Valid Codes is :
9CB0040A
8CB0040A

i use Version : 2.7.7 - and i copy/past all of new github file / VScode/

[NiKiZe]

This still seems to be a magnitude of from being possible, as asked before, "use IRrecvDumpV2.ino instead" also make sure that is configured correct, as in having the correct pin on the board and in the code

[win32cpp]

Timestamp : 000617.937
Library : v2.7.7
Protocol : UNKNOWN
Code : 0x774B249A (52 Bits)
uint16_t rawData[103] = {8954, 4386, 614, 1604, 614, 516, 536, 568, 592, 512, 618, 514, 590, 514, 562, 544, 586, 518, 618, 512, 568, 1628, 612, 1604, 536, 1704, 616, 1604, 614, 1604, 614, 1604, 562, 1678, 590, 1628, 606, 1618, 588, 516, 612, 516, 536, 568, 594, 538, 566, 516, 590, 514, 558, 570, 588, 514, 596, 1626, 590, 1630, 560, 1682, 536, 1682, 616, 1606, 590, 1650, 568, 1650, 514, 1704, 594, 538, 574, 532, 590, 494, 560, 566, 588, 514, 594, 540, 566, 538, 588, 494, 558, 1682, 618, 1602, 592, 1650, 580, 1638, 512, 1684, 612, 1624, 620, 13290, 8926, 2178, 622}; // UNKNOWN 774B249A
//////////
Arduino result:
Enabling IRin
Enabled IRin
807FC03F

[NiKiZe]

That seems more reasonable, what is the remote / device that you are trying to use? (preferrable brand and model number of both remote and device that that remote is for)

And please do try to read the Troubleshooting Guide It does mention UNKNOWN what it means and that you should not expect much (really anything) from it

And there is also The FAQ

[win32cpp]

That seems more reasonable, what is the remote / device that you are trying to use? (preferrable brand and model number of both remote and device that that remote is for)
////////////
Thank you - yes it was one of the previous GREE brands that was solved using IRrecvDumpV2.ino - but unfortunately it's the Midea brand sender that is not a reputable brand - but my problem is not brand recognition - I'm going to save the code And send if necessary. Unfortunately, the code is incorrect.

[NiKiZe]

As you hopefully did read in the linked documentation, since this is not detected as a "supported protocol" that code can change a lot, is just an attempt at getting a value. If it does change when pressing the same button, than that means that the timing does change. If you want, you can read the code for the hash function that is used if no other protocol is matched: https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/IRrecv.cpp#L1020-L1053

The reason for asking for brand and model, is first to check for if something is already supported, but miss detected, and the other is to possibly write support for it. Do you have the brand and model? (this was also requested in the issue template)

Both Gree and Midea does have support in the lib, so this is for a A/C unit ?
Your raw data does seem to match what we have for the Midea protocol, only need to do some tweaks for the header and gap maybe.

[NiKiZe]

At least this is not to far of from working with existing Midea code

Some tweaking of header mark, and Gap and this should be usable.
One note tho is that current checksum function is not happy about it.
But more information is needed to know what the best approach is

TEST(TestDecodeMidea, DecodeRealExampleIssue1170) {
  IRsendTest irsend(kGpioUnused);
  IRrecv irrecv(kGpioUnused);
  irsend.begin();
  irsend.reset();

  const uint16_t rawData[103] = {
      8954 - 4000, 4386,
      614, 1604, 614, 516,  536, 568,  592, 512,  618, 514,  590, 514,
      562, 544,  586, 518,  618, 512,  568, 1628, 612, 1604, 536, 1704,
      616, 1604, 614, 1604, 614, 1604, 562, 1678, 590, 1628, 606, 1618,
      588, 516,  612, 516,  536, 568,  594, 538,  566, 516,  590, 514,
      558, 570,  588, 514,  596, 1626, 590, 1630, 560, 1682, 536, 1682,
      616, 1606, 590, 1650, 568, 1650, 514, 1704, 594, 538,  574, 532,
      590, 494,  560, 566,  588, 514,  594, 540,  566, 538,  588, 494,
      558, 1682, 618, 1602, 592, 1650, 580, 1638, 512, 1684, 612, 1624,
      620, 13290 - 7000,
      8926, 2178, 622}; // UNKNOWN 774B249A
  irsend.sendRaw(rawData, 103, 38);
  irsend.makeDecodeResult();

  EXPECT_TRUE(irrecv.decodeMidea(&irsend.capture, kStartOffset, kMideaBits,
                                 false));
  //ASSERT_TRUE(irrecv.decodeMidea(&irsend.capture));
  EXPECT_EQ(decode_type_t::MIDEA, irsend.capture.decode_type);
  EXPECT_EQ(kMideaBits, irsend.capture.bits);
  EXPECT_EQ(0x807FC03FC03F, irsend.capture.value);
  EXPECT_EQ(
      "Power: Off, Mode: 7 (UNKNOWN), Celsius: On, Temp: 17C/62F, "
      "Fan: 3 (High), Sleep: On, Swing(V) Toggle: Off",
      IRAcUtils::resultAcToString(&irsend.capture));
  stdAc::state_t r, p;
  ASSERT_TRUE(IRAcUtils::decodeToState(&irsend.capture, &r, &p));
}

[crankyoldgit]

I'm going to save the code And send if necessary. Unfortunately, the code is incorrect.

How do you know the "code" isn't correct? i.e. what code and sendProtocol() did you use to send the message with the other library.

You should be able to use the rawData[] line from IRrecvDumpV2 with sendRaw() to save/reproduce the message. See the code examples for how to do it.

[win32cpp]

I'm going to save the code And send if necessary. Unfortunately, the code is incorrect.

How do you know the "code" isn't correct? i.e. what code and sendProtocol() did you use to send the message with the other library.

You should be able to use the rawData[] line from IRrecvDumpV2 with sendRaw() to save/reproduce the message. See the code examples for how to do it.

Yes - I re-send the (remote code) using this library. If the (remote code) is incorrect, the device will not work. I will test it and send the result.

[win32cpp]

As you hopefully did read in the linked documentation, since this is not detected as a "supported protocol" that code can change a lot, is just an attempt at getting a value. If it does change when pressing the same button, than that means that the timing does change. If you want, you can read the code for the hash function that is used if no other protocol is matched: https://github.com/crankyoldgit/IRremoteESP8266/blob/master/src/IRrecv.cpp#L1020-L1053

The reason for asking for brand and model, is first to check for if something is already supported, but miss detected, and the other is to possibly write support for it. Do you have the brand and model? (this was also requested in the issue template)

Both Gree and Midea does have support in the lib, so this is for a A/C unit ?
Your raw data does seem to match what we have for the Midea protocol, only need to do some tweaks for the header and gap maybe.

brand and model:

[win32cpp]

I tested three modes that I attach to their file.
Case 1: Raw information received by the Arduino Library
raw_data_from_arduino_library_media_on_code.txt

Case 2: Raw information received by IRremoteESP8266 Library
raw_data_from_IRremoteESP8266_library_media_on_code.txt

Case 3: Raw information received from raw data sent.
raw_dara_from_loop_back_irsend_to_irrecv_ESP8266_library.txt

my test code:
main.cpp.txt

Result: Unfortunately, the device is not activated with the sent code.
but !!! when i send this (remote code from arduino lib) 807FC03F with IRremoteESP8266 the code work and device activated!!!!!!!!!

[crankyoldgit]

FYI, doing a loop-back setup like that is not going to work well with this library. I'm not going to go into the reasons here, but you can't reliably send & receive an IR message at exactly the same time on the same hardware. They will screw up each other.

I've compared by hand, the two captures (Arduino & original ESP8266), they are essentially the same.
I think your test code is what is to blame.

Please try just the code in IRsendDemo.ino with the appropriate changes for just using/sending your rawData from raw_data_from_IRremoteESP8266_library_media_on_code.txt

The device/protocol in the raw data (Arduino & original ESP8266) is not NEC. I checked it by hand to be absolutely sure. It's is however very much NEC-like in nature, but it is too big. That is why our library is not detecting it.

As it is a simple NEC variant I can code up something to support it fairly quickly.

[crankyoldgit]

@win32cpp Can you please download and test PR #1171 / Branch https://github.com/crankyoldgit/IRremoteESP8266/tree/Issue1170 and let me know if it works for you.

It (IRrecvDumpV2 etc) should detect your protocol correctly (The full 48 bits vs NEC's 32-bits) and you should be able to send via the new sendMideaNec(0x807FC03FC03F); procedure.

Looking at the numeric (hex) code, there may be some consistency checks & data efficiency improvements we can add if you can supply more data. e.g. It looks like each 8-bit byte is followed by and inverted copy, and there appears like duplication in the last 32-bits too.

If that proves to be the case, the protocol name/function/data may change. This is experimental at this point.

If they decode/match successfully, we don't need the rawData line from IRrecvDumpV2, just the data/code line(s).

[win32cpp]

I download the updated files and clear the project (IRrecvDumpV2) and re-compiled it. Unfortunately, the problem still persists.
Raw information received from the IRremoteESP8266 library:
Test_Changes.txt

Hash the files in the source folder
source_folder_hash.txt

[crankyoldgit]

I'm afraid your build environment is NOT using the version of the library you've just downloaded, or you've failed to upload the new binary.

You may need to remove the normal/release(d) version of the library via Library Manager etc.
You can confirm this by changing the following line:
https://github.com/crankyoldgit/IRremoteESP8266/blob/461fa164891f7f891ddfe9da578bb04c6af3d97a/src/IRremoteESP8266.h#L55
It will show up in your serial output.
e.g.

#define _IRREMOTEESP8266_VERSION_ "2.7.7-Issue1170"

I can confirm this as I just added the raw data from your Test_Changes.txt file, and it detects it perfectly.

Your hash file does indicate you've successful downloaded the correct branch, however.

[win32cpp]

I will try again to solve the problem and send the result. Currently the output is as shown below.
thank you

[crankyoldgit]

Hmm. That's confusing. Assuming you edited the files you downloaded, then you're building from the correct files and running the new code. It should be detecting it as MIDEA_NEC

[crankyoldgit]

Can you check the file you edited also contains multiple references to MIDEA_NEC?

[win32cpp]

Do you mean this part?

[crankyoldgit]

Yep. They will do. Just checking it wasn't turned off

[win32cpp]

[crankyoldgit]

Fyi, please cut and paste the text. I can't use screenshots to get the data to test with

[win32cpp]

It looks like I can't find the source of this function in the file.
decodeMideaNec

[win32cpp]

[crankyoldgit]

It's in ir_Midea.cpp

[win32cpp]

IRrecvDump is now running and waiting for IR input on Pin 14
Attempting Midea-Nec decode
Timestamp : 000003.875
Library : v2.7.7-Issue1170

Protocol : UNKNOWN
Code : 0xCBEC0079 (53 Bits)
uint16_t rawData[105] = {8924, 4410, 596, 1628, 590, 538, 538, 568, 588, 520, 592, 516, 588, 518, 588, 516, 558, 568, 594, 538, 566, 1652, 568, 1650, 540, 1680, 590, 1628, 592, 1628, 590, 1628, 590, 1650, 540, 1680, 592, 1630, 590, 518, 586, 538, 538, 568, 590, 514, 616, 494, 588, 516, 588, 516, 560, 566, 590, 1630, 586, 1634, 564, 1652, 538, 1704, 566, 948, 254, 450, 564, 1654, 566, 1652, 540, 1682, 610, 518, 588, 516, 590, 514, 590, 514, 582, 526, 614, 436, 670, 512, 592, 514, 538, 1578, 718, 1602, 614, 1542, 676, 1626, 538, 1678, 586, 1634, 616, 13308, 8920, 2158, 626}; // UNKNOWN CBEC0079

[crankyoldgit]

Plus it would not compile if it wasn't

[crankyoldgit]

As I said, in ir_Midea.cpp:
https://github.com/crankyoldgit/IRremoteESP8266/blob/e2f1de33fd36edf3e14240dc836201f0b94d6d7c/src/ir_Midea.cpp#L470-L496

[win32cpp]

Is it possible to find an error with these signs?
debug_test.txt

[crankyoldgit]

Some analysis:

Your rawData from: https://github.com/crankyoldgit/IRremoteESP8266/issues/1170#issuecomment-639349316
contains "..., 1704, 566, 948, 254, 450, 564, 1654, ..."

Those two numbers tell me something happened interrupting the IR signal or output from the IR decoder module. So bad signal, bad IR module, or bad circuit, or .. bad ESP. Anyway, that raw data doesn't match, and it shouldn't match.

Now, your data from: https://github.com/crankyoldgit/IRremoteESP8266/issues/1170#issuecomment-639358566 matches okay. See:
https://github.com/crankyoldgit/IRremoteESP8266/blob/3a27640cb3cfaa14b494110905487493194abe5b/test/ir_Midea_test.cpp#L907-L923

I suggest you clean/blow-away everything to do with IRremoteESP8266, and redownload the latest copy of that branch.

I don't know what other changes you've made to those files, but something isn't working. Hence lets clean up everything, including the examples etc. A clean copy of IRrecvDumpV2 built from a clean copy of that branch should be fine to decode it.

[win32cpp]

Okay - thank you very much - I will try.
This line appears to return a zero value:

if (! matchAtLeast (* (data_ptr + offset), footerspace, tolerance, excess))
           return 0;

Which causes this condition to return the false value.Some values that are passed to the function.
offset: 2
results-> rawlen - offset: 102
nbits: 48
kNecHdrSpace: 4480
kNecBitMark: 560
kNecZeroSpace: 560
kNecMinGap: 22400

  // Match Header (cont.) + Data + Footer
  if (!matchGeneric(results->rawbuf + offset, &data,
                    results->rawlen - offset, nbits,
                    0, kNecHdrSpace,
                    kNecBitMark, kNecOneSpace,
                    kNecBitMark, kNecZeroSpace,
                    kNecBitMark, kNecMinGap, true)) return false;

[crankyoldgit]

@win32cpp I've just push a "special" config with all the other protocols disabled and only the new protocol enabled, plus it has DEBUG mode on.

Can you please download and try that branch again? I'll need the FULL text output from IRrecvDumpV2

As far as I can test from here, it still appears to be working.

I'll also need info on your entire arduino build environment. e.g. What versions of software are you using? Arduino IDE? Atom + PlatformIO? Visual Studio Code + PlatformIO? What is the OS you're using? i.e. mac/windows/ubuntu v1.2.3 etc. What hardware you're using? D1 Mini/NodeMCU/etc. ESP8266 or ESP32 etc etc. What version of ESP "core" etc etc etc.

This is so I can try to reproduce what you are seeing.

[crankyoldgit]

P.S. No alterations to the code other than the GPIO/pin etc please. No extra debug prints etc.

[win32cpp]

OK - I re-download the entire library from the specified directory and then install - Excellent - The problem seems to be solved and successfully recognizes the remote code.
debug.txt

[crankyoldgit]

I think the issue is with the timeout parameter to IRrecv's class constructor.

In IRrecvDumpV2, it defaults to a large value when it's expecting some A/C protocols with large gaps in it. Lowering that value should make it behave better for your case. It will take some more work to fix this protocol so it works in all cases.

I'll upload a different version for you to try, with everything turned on again/ debug off etc, and we can capture some other commands/buttons to see if we can break down & improve this protocol a little more. (as I mentioned earlier)

[crankyoldgit]

Okay, I've updated the branch again. It should now work as described in my last message.

I should have fixed the issue with the larger than default timeout.

Thus, it should capture "normally". Now we can collect some uint64_t data = 0x807FC03FC03F; lines to see if we can shrink this down a bit. i.e. there is a pattern in the data.

[win32cpp]

Okay, I've updated the branch again. It should now work as described in my last message.

I should have fixed the issue with the larger than default timeout.

Thus, it should capture "normally". Now we can collect some uint64_t data = 0x807FC03FC03F; lines to see if we can shrink this down a bit. i.e. there is a pattern in the data.

Test Result:
new_update_with_other_keys.txt

[NiKiZe]

uint64_t data = 0x807F C03F C03F;
uint64_t data = 0x807F E01F E01F;
uint64_t data = 0x807F DA25 DA25;
uint64_t data = 0x807F D02F D02F;
uint64_t data = 0x807F D827 D827;
uint64_t data = 0x807F F00F F00F;
uint64_t data = 0x807F C837 C837;
uint64_t data = 0x807F D22D D22D;
uint64_t data = 0x807F F20D F20D;

In theory we could get this down to 8 bits, (at least)
Maybe there is better ways, but here is one:
right now there is 6 bytes
every other byte is inverted from the previous 0x80 == ~0x7F && 0xC0 == ~0x3F
that would get it down to 3 bytes
First byte is always 0x80 as prefix.
the 2 other bytes are always repeated, which gives us one byte of actual data left.
Maybe that is to strict if there comes anything other similar?

[crankyoldgit]

In theory we could get this down to 8 bits, (at least)
Maybe there is better ways, but here is one:
right now there is 6 bytes
every other byte is inverted from the previous 0x80 == ~0x7F && 0xC0 == ~0x3F
that would get it down to 3 bytes
First byte is always 0x80 as prefix.
the 2 other bytes are always repeated, which gives us one byte of actual data left.
Maybe that is to strict if there comes anything other similar?

@NiKiZe
I've found that occasionally there are rare circumstances where more flexibility is needed or reused.
So it's probably best to err on the cautious side.
I concur, we could probably get this down to 8 bits. As it is a simple fan, that's probably safe, but who knows if they alter the protocol for something else.
My feeling/thoughts are to play it safe and go with 24 bits (3 bytes). Adding a protocol check only for the XOR/inverting of the bits/bytes.

So, I'll probably rework this protocol to be 24 bits, and rename it "MIDEA24" consequently.

@win32cpp Per chance, have you been able to test using sendMideaNec() at all yet? i.e. Does it work?

[win32cpp]

Yes - sendMideaNec() works well and I tested it -(0X807FC03FC03F) 48 bits
It also works if I send this code (0x807FC03F) 32 bits

[crankyoldgit]

Yes - sendMideaNec() works well and I tested it -(0X807FC03FC03F) 48 bits

Excellent. Just in time for me to completely change it. ;-)

It also works if I send this code (0x807FC03F) 24 bits

That gives me sooooo much confidence in the quality of this device. :-P

[crankyoldgit]

Okay. Hopefully the last update to the branch. (Famous last words).

sendMideaNec() -> sendMidea24
48 bits -> 24 bits
MIDEA_NEC -> MIDEA24

Codes will either need to be recaptured or you can convert them by hand, by throwing away every second byte (pair of hexadecimal digits).
e.g.
0x807FC03FC03F -> 0x80C0C0

Please download and test decoding and sending, and let me know etc.
One minor thing, is there a model number or something on the remote at all?

[win32cpp]

Sorry there was a bit of an error in my send test function. I will send the test results of the functions again ...

[crankyoldgit]

irsend.sendMidea24(0x80C0C0,24,5); //worked successfully.
irsend.sendNEC(0x807FC03FC03F,48,5); //worked successfully.
irsend.sendNEC(0x807FC03F,32,5); //worked successfully.

Previously, I mistakenly used the sendNEC function to send code !
Does the sendMideaNec function work in this version?)

irsend.sendMidea(0x807FC03FC03F,48,5); //Failed
irsend.sendMidea(0x807FC03F,32,5);  //Failed
irsend.sendMidea(0x807FC0,24,5);  //Failed

If the code you got before was 0x807FC03FC03F, then you would use:

irsend.sendMidea24(0x80C0C0);  // or
irsend.sendMidea24(0x80C0C0, 24, 5);  // or
irsend.sendMidea24(0x80C0C0, kMidea24Bits, 5);  // or
irsend.sendNEC(0x807FC03FC03F,48,5);

There is no longer a sendMideaNec() function, it's now sendMidea24(). Note the 24.

[crankyoldgit]

How is decoding working for you?

[win32cpp]

irsend.sendNEC(0x807FC03FC03F,48,5); //worked successfully.
irsend.sendNEC(0x807FC03F,32,5); //worked successfully.
irsend.sendMidea24(0x80C0C0,24,5); //worked successfully.
irsend.sendMidea24(0x80C0C0); //worked successfully.
irsend.sendMidea24(0x80C0C0, kMidea24Bits, 5); //worked successfully.

irsend.sendNEC(0x807FC0,24,5); //Failed
irsend.sendMidea24(0x807FC0,24,5); //Failed
irsend.sendMidea(0x807FC03FC03F,48,5); //Failed
irsend.sendMidea(0x807FC03F,32,5); //Failed
irsend.sendMidea(0x807FC0,24,5); //Failed

[crankyoldgit]

Thanks. That is what I would expect.

I'm still surprised the 32 bit NEC code works, but hey. _shrug_

How did decoding (IRrecvDumpV2 etc) go?

[win32cpp]

How did decoding (IRrecvDumpV2 etc) go?

I don't understand what you mean. what should I do?
i test again: irsend.sendNEC(0x807FC03F,32,5); It works well

[crankyoldgit]

Can you confirm that the library can detect the code correctly? I.e. when you use IRrecvDumpV2 etc, does it detect it as MIDEA24?

[crankyoldgit]

I.e. can it detect your remote correctly

[win32cpp]

Thank you....
yes it's ok.
see result:

Test_9_keys.txt

[crankyoldgit]

Thank you!

[crankyoldgit]

FYI, the code & changes referenced above have been included in the v2.7.8 release of the library.