Data payload cutted

[mp3-10]

Hello!

I'm trying to decode Hisense/Kelon "iFeel" function. I dump codes and (probably) found what bit is telling AC to run or not, but I can't test that, because i don't have idea how to send codes :(

When I use:
irsend.sendKelon(code, 48);

Sending code is limited to half of the code. I mean when I'm sending 0x2096000070000683 or 0x2816000070000683
receiver see only: Code: 0xFFFFFFFF (48 Bits) (using example IRServer) or Code: 0x70000683(48 Bits) (using example IRMQTTServer)

My first idea was bad uint value, so I changed (in IRServer but still the same) to:

void handleIr() {
  for (uint8_t i = 0; i < server.args(); i++) {
    if (server.argName(i) == "code") {
      uint64_t code = strtoul(server.arg(i).c_str(), NULL, 50);
#if SEND_NEC
      irsend.sendKelon(code, 48);

[crankyoldgit]

strtoul(server.arg(i).c_str(), NULL, 50);

strtoul() returns an unsigned long (ul) aka a uint32_t. i.e only 32bits, you need at least 48.

You want/need an unsigned long long (ull) aka uint64_t. I don't think Arduino offers a strtoull(), check the IRMQTTServer code for how I do it to be sure.

[crankyoldgit]

Also, you're setting the base to 50. That's wrong. Hexadecimal is 16.

Read https://www.cplusplus.com/reference/cstdlib/strtoul/ for how it works.

[crankyoldgit]

0x2096000070000683

Also, that value is larger than 48 bits.
Are you confusing a decimal (base 10) value with a hexadecimal (0x) (base 16) value?

[mp3-10]

@crankyoldgit,
Thanks for your all replies. Codes I get from IRrecvDumpV2:

13:23:57.265 -> Timestamp : 000153.655
13:23:57.265 -> Library   : v2.8.0
13:23:57.265 -> 
13:23:57.265 -> Protocol  : KELON
13:23:57.265 -> Code      : 0x178D000070030683 (48 Bits)
13:23:57.265 -> Mesg Desc.: Temp: 25C, Mode: 0 (Heat), Fan: 3 (High), Sleep: Off, Dry: 0, Timer: Off, Turbo: Off
13:23:57.265 -> uint16_t rawData[343] = {8922, 4494,  548, 1714,  524, 1718,  524, 572,  524, 550,  550, 556,  550, 560,  548, 586,  524, 1724,  526, 564,  524, 1692,  550, 1696,  550, 552,  550, 554,  550, 560,  548, 586,  524, 550,  548, 1688,  550, 1694,  548, 548,  550, 552,  548, 556,  548, 582,  524, 586,  524, 576,  524, 540,  548, 568,  526, 572,  526, 548,  550, 1702,  550, 1706,  550, 1734,  526, 574,  526, 564,  526, 544,  550, 548,  548, 550,  550, 554,  550, 582,  526, 586,  524, 550,  548, 540,  550, 544,  550, 570,  526, 550,  550, 558,  546, 582,  524, 586,  524, 562,  524, 7978,  548, 1690,  548, 568,  524, 1696,  548, 1700,  548, 554,  550, 560,  548, 560,  550, 1722,  526, 1686,  550, 1692,  548, 1696,  550, 576,  524, 1704,  548, 558,  550, 562,  548, 550,  550, 564,  524, 570,  524, 548,  548, 576,  524, 578,  526, 558,  550, 586,  524, 574,  524, 566,  524, 568,  526, 548,  548, 576,  526, 556,  548, 558,  550, 560,  550, 550,  550, 564,  526, 544,  548, 548,  548, 552,  548, 556,  548, 582,  526, 564,  548, 550,  550, 540,  548, 568,  526, 546,  550, 550,  550, 580,  524, 558,  550, 560,  550, 1698,  550, 542,  548, 542,  550, 546,  550, 1722,  524, 1706,  548, 582,  526, 586,  524, 574,  526, 1690,  548, 544,  550, 546,  550, 552,  548, 1726,  526, 1730,  524, 1734,  526, 562,  524, 7976,  550, 566,  524, 544,  550, 570,  526, 550,  548, 554,  550, 1706,  550, 562,  548, 574,  526, 542,  548, 544,  550, 572,  526, 548,  552, 554,  550, 582,  526, 584,  526, 574,  524, 542,  548, 544,  548, 572,  524, 552,  548, 578,  524, 560,  548, 562,  548, 550,  550, 540,  550, 546,  548, 572,  524, 576,  526, 556,  548, 560,  546, 564,  548, 574,  526, 540,  550, 546,  546, 546,  550, 1698,  550, 1728,  524, 1706,  548, 564,  548, 574,  524, 544,  548, 568,  526, 548,  548, 574,  524, 554,  550, 558,  550, 562,  548, 550,  550, 566,  524, 544,  548, 546,  552, 1698,  548, 1702,  550, 560,  546, 586,  524, 538,  546};  // KELON 178D000070030683
13:23:57.466 -> uint32_t address = 0x80000000;

13:23:57.466 -> uint32_t command = 0x207118;

13:23:57.466 -> uint64_t data = 0x178D000070030683;

13:23:57.466 -> 

13:23:57.466 ->

Tomorrow maybe I try with "rawData" that should be easier

[crankyoldgit]

Okay, providing the rawdata is as we always say, very helpful.

Another one of your (many) issues is the message you captured is NOT a 48 bit KELON message. That issue was ours, though. It should not have detected it as such. That's our bad. That will be fixed with PR #1746.

See the following link for explicit details.

IRremoteESP8266/test/ir_Kelon_test.cpp

Lines 436 to 499 in c378245

	TEST(TestDecodeKelon, Discussion1744) {
	IRsendTest irsend(kGpioUnused);
	IRrecv irrecv(kGpioUnused);
	// Ref: https://github.com/crankyoldgit/IRremoteESP8266/discussions/1744#discussioncomment-2061968
	// Note: This message is NOT at 48-bit Kelon protocol message.
	// It is actually 48 + 64 + 56 = 168 bit (21 byte) message.
	// i.e. A different protocol all together.
	const uint16_t rawData[343] = {
	8922, 4494, // Header
	548, 1714, 524, 1718, 524, 572, 524, 550, // Byte 0
	550, 556, 550, 560, 548, 586, 524, 1724,
	526, 564, 524, 1692, 550, 1696, 550, 552, // Byte 1
	550, 554, 550, 560, 548, 586, 524, 550,
	548, 1688, 550, 1694, 548, 548, 550, 552, // Byte 2
	548, 556, 548, 582, 524, 586, 524, 576,
	524, 540, 548, 568, 526, 572, 526, 548, // Byte 3
	550, 1702, 550, 1706, 550, 1734, 526, 574,
	526, 564, 526, 544, 550, 548, 548, 550, // Byte 4
	550, 554, 550, 582, 526, 586, 524, 550,
	548, 540, 550, 544, 550, 570, 526, 550, // Byte 5
	550, 558, 546, 582, 524, 586, 524, 562,
	524, 7978, // Section Footer
	548, 1690, 548, 568, 524, 1696, 548, 1700, // Byte 6
	548, 554, 550, 560, 548, 560, 550, 1722,
	526, 1686, 550, 1692, 548, 1696, 550, 576, // Byte 7
	524, 1704, 548, 558, 550, 562, 548, 550,
	550, 564, 524, 570, 524, 548, 548, 576, // Byte 8
	524, 578, 526, 558, 550, 586, 524, 574,
	524, 566, 524, 568, 526, 548, 548, 576, // Byte 9
	526, 556, 548, 558, 550, 560, 550, 550,
	550, 564, 526, 544, 548, 548, 548, 552, // Byte 10
	548, 556, 548, 582, 526, 564, 548, 550,
	550, 540, 548, 568, 526, 546, 550, 550, // Byte 11
	550, 580, 524, 558, 550, 560, 550, 1698,
	550, 542, 548, 542, 550, 546, 550, 1722, // Byte 12
	524, 1706, 548, 582, 526, 586, 524, 574,
	526, 1690, 548, 544, 550, 546, 550, 552, // Byte 13
	548, 1726, 526, 1730, 524, 1734, 526, 562,
	524, 7976, // Section footer
	550, 566, 524, 544, 550, 570, 526, 550, // Byte 14
	548, 554, 550, 1706, 550, 562, 548, 574,
	526, 542, 548, 544, 550, 572, 526, 548, // Byte 15
	552, 554, 550, 582, 526, 584, 526, 574,
	524, 542, 548, 544, 548, 572, 524, 552, // Byte 16
	548, 578, 524, 560, 548, 562, 548, 550,
	550, 540, 550, 546, 548, 572, 524, 576, // Byte 17
	526, 556, 548, 560, 546, 564, 548, 574,
	526, 540, 550, 546, 546, 546, 550, 1698, // Byte 18
	550, 1728, 524, 1706, 548, 564, 548, 574,
	524, 544, 548, 568, 526, 548, 548, 574, // Byte 19
	524, 554, 550, 558, 550, 562, 548, 550,
	550, 566, 524, 544, 548, 546, 552, 1698, // Byte 20
	548, 1702, 550, 560, 546, 586, 524, 538,
	546 // Footer
	}; // KELON 178D000070030683
	irsend.begin();
	irsend.reset();
	irsend.sendRaw(rawData, 343, 38000);
	irsend.makeDecodeResult();
	EXPECT_TRUE(irrecv.decode(&irsend.capture));
	EXPECT_NE(KELON, irsend.capture.decode_type); // Not a KELON message
	EXPECT_NE(kKelonBits, irsend.capture.bits); // Not a 48 bit message.
	}

It is in fact a 168 bit (21 byte) message.

In short, we need to add a new protocol for this message-type you have.
i.e. Follow https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-IR-protocol
I've created Issue #1745 to track adding the new protocol. Please add results/answers in #1745
e.g. Brand & model numbers of the AC and the remote.

Until #1745 is done, you'll need to use sendRaw().

FYI @depau as it was their code.