search

crankyoldgit / IRremoteESP8266

Infrared remote library for ESP8266/ESP32: send and receive infrared signals with multiple protocols. Based on: https://github.com/shirriff/Arduino-IRremote/
GNU Lesser General Public License v2.1
2.98k stars 832 forks source link

question : bluesky air conditioner - code #463

Closed gnkarn closed 6 years ago

gnkarn commented 6 years ago

Doing some quick google search , it appears that this brand is white branded manly for big supermarket chains , it is manufactured by a turkey company named ARGELIK , or ARCELIK ( the C is cedilla letter) . i was not successful at finding the code , so here we are making the effort to crack it .

i found that the AC branded as FIRSTLINE are the same ( at least in the models i tested)

this is just to ask if this code may seams correctly captured , and if it looks similar to some other .

ecoded Unknown(0): Value:0 Adrs:0 (0 bits)        
Raw samples(100): Gap:60822        
Head: m3726  s1514        
0:m546 s1130 1:m546 s1134   2:m574 s434 3:m566 s442
4:m494 s510 5:m574 s1106   6:m570 s442 7:m478 s530
8:m570 s1102 9:m578 s1102   10:m574 s442 11:m530 s1146
12:m530 s470 13:m578 s442   14:m554 s1126 15:m554 s1122
         
16:m554 s446 17:m574 s1102   18:m578 s1102 19:m574 s446
20:m554 s442 21:m550 s1126   22:m578 s430 23:m570 s446
24:m466 s1206 25:m550 s458   26:m570 s442 27:m474 s526
28:m574 s442 29:m558 s442   30:m578 s442 31:m554 s446
         
32:m546 s454 33:m574 s442   34:m554 s450 35:m574 s442
36:m554 s442 37:m574 s434   38:m566 s442 39:m474 s550
40:m554 s442 41:m474 s530   42:m574 s1102 43:m574 s442
44:m554 s446 45:m574 s1102   46:m578 s442 47:m554 s446
         
48:m546        
Extent=63542        
Mark  min:466 max:578      
Space min:430 max:1206      
crankyoldgit commented 6 years ago

I think it looks okay at a quick glance. But honestly, it's easier for us (and you) to tell via the IRrecvDumpV2 sketch. As it produces output that we can run other tools on. e.g. the auto analyse script in the tools dir.

gnkarn commented 6 years ago

david this is the data from dumpv2 temp down

imestamp : 000267.836 Encoding : UNKNOWN Code : B97DA207 (114 bits) Library : v2.4.0

Raw Timing[227]:

uint16_t rawData[227] = {3012, 1498, 578, 1080, 568, 1078, 624, 388, 582, 418, 628, 390, 606, 1070, 606, 390, 628, 392, 606, 1070, 606, 1070, 606, 390, 602, 1074, 602, 418, 606, 390, 600, 1076, 602, 1082, 594, 420, 606, 1070, 606, 1070, 606, 390, 602, 404, 620, 1058, 618, 390, 602, 418, 606, 1056, 620, 390, 526, 478, 622, 388, 578, 422, 600, 416, 606, 392, 602, 416, 580, 414, 574, 428, 624, 390, 606, 396, 626, 388, 606, 390, 602, 418, 606, 392, 598, 404, 596, 414, 528, 1148, 528, 476, 598, 414, 606, 1070, 606, 396, 626, 388, 606, 1070, 580, 416, 628, 392, 580, 414, 604, 402, 596, 414, 526, 478, 598, 414, 528, 1148, 528, 470, 604, 1076, 600, 414, 580, 416, 604, 414, 582, 414, 630, 390, 580, 414, 574, 428, 600, 414, 526, 1150, 526, 474, 602, 1078, 598, 414, 580, 422, 598, 416, 580, 414, 628, 380, 594, 414, 600, 402, 600, 414, 580, 420, 600, 414, 580, 416, 628, 376, 596, 414, 628, 376, 596, 416, 554, 444, 602, 414, 580, 422, 598, 416, 580, 414, 626, 376, 574, 440, 548, 454, 600, 416, 554, 440, 628, 392, 554, 440, 628, 376, 596, 416, 528, 474, 598, 414, 554, 444, 602, 416, 554, 446, 626, 1076, 574, 1102, 574, 1106, 570, 440, 528, 472, 602, 1074, 602, 1078, 600, 414, 606}; // UNKNOWN B97DA207

power off Timestamp : 002079.347 Encoding : UNKNOWN Code : A83A36A1 (114 bits) Library : v2.4.0

Raw Timing[227]:

uint16_t rawData[227] = {3804, 386, 768, 262, 600, 1094, 608, 1070, 582, 416, 628, 390, 582, 414, 2042, 430, 598, 350, 586, 1154, 546, 1130, 546, 458, 598, 1078, 600, 412, 502, 414, 494, 1084, 542, 1076, 524, 418, 628, 1048, 628, 1048, 604, 414, 580, 416, 544, 1104, 528, 414, 528, 424, 464, 1150, 530, 412, 496, 396, 502, 414, 580, 418, 604, 414, 580, 414, 602, 420, 580, 414, 580, 422, 598, 414, 582, 416, 628, 378, 594, 414, 628, 376, 596, 414, 548, 454, 600, 414, 606, 392, 602, 416, 582, 414, 628, 1048, 628, 392, 582, 416, 626, 1050, 628, 376, 624, 388, 580, 422, 600, 414, 606, 390, 604, 402, 596, 418, 570, 1102, 628, 378, 596, 1080, 596, 414, 602, 404, 624, 388, 580, 418, 604, 414, 580, 418, 602, 402, 594, 414, 600, 1076, 600, 406, 596, 1080, 596, 414, 524, 498, 606, 414, 602, 402, 598, 414, 580, 418, 602, 416, 582, 416, 602, 402, 594, 416, 600, 402, 600, 414, 580, 420, 602, 414, 580, 414, 604, 418, 580, 414, 602, 420, 582, 414, 580, 418, 602, 414, 580, 418, 602, 418, 580, 414, 600, 402, 598, 416, 580, 420, 626, 390, 554, 442, 628, 376, 596, 414, 602, 402, 598, 416, 580, 422, 598, 1078, 598, 1078, 598, 416, 580, 418, 602, 416, 580, 1096, 580, 1096, 580, 422, 624}; // UNKNOWN A83A36A1

power on

imestamp : 002145.665 Encoding : UNKNOWN Code : F066D25A (115 bits) Library : v2.4.0

Raw Timing[229]:

uint16_t rawData[229] = {3672, 1542, 602, 1076, 630, 1046, 628, 390, 580, 414, 602, 402, 598, 1082, 620, 388, 600, 404, 596, 1076, 600, 1080, 596, 414, 598, 1078, 574, 432, 598, 414, 530, 1148, 526, 1150, 524, 480, 600, 1078, 624, 1052, 598, 414, 580, 422, 626, 1050, 602, 412, 582, 420, 626, 1050, 602, 414, 582, 414, 630, 376, 598, 414, 546, 456, 600, 414, 606, 396, 624, 390, 1624, 380, 682, 228, 700, 398, 628, 388, 580, 420, 602, 414, 634, 362, 630, 376, 620, 256, 510, 302, 582, 414, 602, 402, 598, 1078, 598, 414, 600, 406, 596, 1078, 598, 414, 580, 420, 598, 414, 668, 330, 604, 402, 596, 414, 598, 422, 580, 1080, 596, 416, 572, 1104, 548, 458, 624, 388, 580, 418, 656, 362, 582, 422, 626, 414, 580, 416, 602, 402, 620, 322, 292, 440, 596, 414, 602, 1074, 602, 404, 596, 416, 546, 456, 598, 414, 580, 420, 600, 416, 580, 416, 600, 422, 578, 414, 688, 320, 594, 414, 582, 414, 604, 416, 580, 416, 602, 402, 596, 416, 546, 458, 596, 416, 550, 448, 652, 342, 602, 416, 602, 420, 580, 414, 600, 402, 598, 414, 580, 424, 648, 390, 580, 386, 718, 334, 576, 414, 658, 364, 580, 414, 604, 402, 598, 416, 580, 1096, 580, 1096, 600, 1076, 626, 376, 598, 414, 580, 1096, 572, 1104, 546, 456, 624}; // UNKNOWN F066D25A

mode heat

Timestamp : 002185.255 Encoding : UNKNOWN Code : B97DA207 (114 bits) Library : v2.4.0

Raw Timing[227]:

uint16_t rawData[227] = {3780, 1438, 630, 1070, 606, 1070, 582, 416, 628, 392, 606, 388, 600, 1076, 600, 406, 596, 412, 574, 1102, 574, 1102, 574, 432, 596, 1080, 596, 414, 524, 476, 602, 1078, 598, 1096, 582, 414, 530, 1148, 528, 1146, 626, 376, 600, 414, 582, 1096, 572, 428, 600, 414, 580, 1096, 580, 416, 628, 392, 580, 414, 628, 376, 598, 414, 528, 476, 598, 414, 580, 418, 628, 390, 582, 414, 602, 406, 594, 414, 600, 402, 600, 414, 580, 424, 624, 414, 580, 418, 602, 1074, 626, 390, 582, 416, 624, 1052, 628, 390, 582, 416, 600, 1076, 600, 406, 594, 414, 574, 428, 600, 414, 582, 418, 602, 414, 580, 418, 600, 1072, 604, 418, 580, 1096, 582, 414, 626, 376, 598, 414, 582, 420, 600, 414, 580, 416, 604, 404, 592, 416, 598, 1078, 628, 378, 594, 1080, 596, 414, 602, 418, 580, 414, 528, 472, 602, 414, 580, 418, 602, 416, 580, 414, 602, 402, 598, 414, 626, 406, 596, 414, 546, 454, 602, 414, 580, 418, 626, 392, 580, 414, 602, 420, 580, 414, 530, 474, 598, 416, 580, 418, 628, 378, 592, 416, 600, 406, 596, 416, 572, 428, 600, 414, 580, 416, 604, 416, 580, 414, 628, 376, 598, 414, 552, 456, 622, 1096, 580, 1096, 578, 1098, 578, 416, 604, 402, 596, 1080, 596, 1080, 596, 416, 626}; // UNKNOWN B97DA207

crankyoldgit commented 6 years ago

You can analyse this yourself using auto_analyse_raw_data.py: e.g. Here is the last of your entries.

IRremoteESP8266/tools$ ./auto_analyse_raw_data.py --code "uint16_t rawData[227] = {3780, 1438,
 630, 1070, 606, 1070, 582, 416, 628, 392, 606, 388, 600, 1076, 600, 406, 596, 412, 574, 1102, 574, 1102, 574, 432, 596, 1080, 596, 414, 524, 476, 602, 1078, 598, 1096, 582, 414, 530, 1148, 528, 1146, 626, 376, 600, 414, 582, 1096, 572, 428, 600, 414, 580, 1096, 580, 416, 628, 392, 580, 414, 628, 376, 598, 414, 528, 476, 598, 414, 580, 418, 628, 390, 582, 414, 602, 406, 594, 414, 600, 402, 600, 414, 580, 424, 624, 414, 580, 418, 602, 1074, 626, 390, 582, 416, 624, 1052, 628, 390, 582, 416, 600, 1076, 600, 406, 594, 414, 574, 428, 600, 414, 582, 418, 602, 414, 580, 418, 600, 1072, 604, 418, 580, 1096, 582, 414, 626, 376, 598, 414, 582, 420, 600, 414, 580, 416, 604, 404, 592, 416, 598, 1078, 628, 378, 594, 1080, 596, 414, 602, 418, 580, 414, 528, 472, 602, 414, 580, 418, 602, 416, 580, 414, 602, 402, 598, 414, 626, 406, 596, 414, 546, 454, 602, 414, 580, 418, 626, 392, 580, 414, 602, 420, 580, 414, 530, 474, 598, 416, 580, 418, 628, 378, 592, 416, 600, 406, 596, 416, 572, 428, 600, 414, 580, 416, 604, 416, 580, 414, 628, 376, 598, 414, 552, 456, 622, 1096, 580, 1096, 578, 1098, 578, 416, 604, 402, 596, 1080, 596, 1080, 596, 416, 626}; // UNKNOWN B97DA207"
Found 227 timing entries.
Potential Mark Candidates:
[3780, 630]
Potential Space Candidates:
[1438, 1148, 476]

Guessing encoding type:
Looks like it uses space encoding. Yay!

Guessing key value:
HDR_MARK   = 3780
HDR_SPACE  = 1438
BIT_MARK   = 630
ONE_SPACE  = 1148
ZERO_SPACE = 476

Decoding protocol based on analysis so far:

HDR_MARK+HDR_SPACE+1100010011010011011001001000000000000000001001001000000010100000000101000000000000000000000000000000000011100110
  Bits: 112
  Hex:  0xC4D36480002480A01400000000E6 (MSB first)
        0x670000000028050124000126CB23 (LSB first)
  Dec:  3992100527850397574721982770970854 (MSB first)
        2089088189176860284038542868794147 (LSB first)
  Bin:  0b1100010011010011011001001000000000000000001001001000000010100000000101000000000000000000000000000000000011100110 (MSB first)
        0b0110011100000000000000000000000000000000001010000000010100000001001001000000000000000001001001101100101100100011 (LSB first)
Total Nr. of suspected bits: 112

Generating a VERY rough code outline:

// WARNING: This probably isn't directly usable. It's a guide only.
#define HDR_MARK 3780U
#define BIT_MARK 630U
#define HDR_SPACE 1438U
#define ONE_SPACE 1148U
#define ZERO_SPACE 476U
#define XYZ_BITS 112U
#define XYZ_STATE_LENGTH 14U
// DANGER: More than 64 bits detected. A uint64_t for 'data' won't work!
// Function should be safe up to 64 bits.
void IRsend::sendXYZ(const uint64_t data, const uint16_t nbits, const uint16_t repeat) {
  enableIROut(38);  // A guess. Most common frequency.
  for (uint16_t r = 0; r <= repeat; r++) {
    // Header
    mark(HDR_MARK);
    space(HDR_SPACE);
    // Data
    // e.g. data = 0xC4D36480002480A01400000000E6, nbits = 112
    sendData(BIT_MARK, ONE_SPACE, BIT_MARK, ZERO_SPACE, data, nbits, true);
    // Footer
    mark(BIT_MARK);
    space(100000);  // A 100% made up guess of the gap between messages.
  }
}

// Alternative >64 bit Function
void IRsend::sendXYZ(uint8_t data[], uint16_t nbytes, uint16_t repeat) {
  // nbytes should typically be XYZ_STATE_LENGTH
  // data should typically be:
  //   uint8_t data[XYZ_STATE_LENGTH] = {0xC4, 0xD3, 0x64, 0x80, 0x00, 0x24, 0x80, 0xA0, 0x14, 0x00, 0x00, 0x00, 0x00, 0xE6};
  // data[] is assumed to be in MSB order for this code.
  for (uint16_t r = 0; r <= repeat; r++) {
    sendGeneric(HDR_MARK, HDR_SPACE,
                BIT_MARK, ONE_SPACE,
                BIT_MARK, ZERO_SPACE,
                BIT_MARK
                100000, // 100% made-up guess at the message gap.
                data, nbytes,
                38000, // Complete guess of the modulation frequency.
                true, 0, 50);
}

Naturally, only the >64 bit version of the code will do as the payload is 112 bits(14 bytes) long.

You can process the rest yourself.

gnkarn commented 6 years ago

thank you , will make a try .

gnkarn commented 6 years ago

i have the first version that compiles ok, here:

but i know i have to do some modifications to enable tasmota to send the 14 data bytes as part of the json payload : something like :
cmnd/Multi-IR/irsend {"Protocol": "BLUESKY","Bits":120,"data": "[0xC4, 0xD3, 0x64, 0x80, 0x00, 0x24, 0x80, 0xA0, 0x14, 0x00, 0x00, 0x00, 0x00, 0xE6]" }

but , have not yet discovered the modification i may need to do on the tasmota , sonoff.ino mqtt callback function to be able to receive this data array instead of a plain decimal number .

gnkarn commented 6 years ago

@crankyoldgit ,While reading your IRMQTTServer example in order to get ideas on how to modify tasmota for long payloads , I got the idea that I may not need it , and I should just replace the long codes with just bytes on the mqtt message and then prepare the long output code on the function itself ..

Will think in this line , if you have better idea let me know , tks

gnkarn commented 6 years ago

PRELIMINARY Analisis information :

codigo modo vent swing temp 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31
0x640000000028000324000126CB23 cold auto 4 31 64 00 00 00 00 28 00 03 24 00 01 26 CB 23 101000
0x440000000008000324000126CB23 cold auto 0 31 44 00 00 00 00 08 00 03 24 00 01 26 CB 23 001000
0x4C0000000010000324000126CB23 cold auto 1 31 4C 00 00 00 00 10 00 03 24 00 01 26 CB 23 010000
0x540000000018000324000126CB23 cold auto 2 31 54 00 00 00 00 18 00 03 24 00 01 26 CB 23 011000
0x640000000028000324000126CB23 cold auto 4 31 64 00 00 00 00 28 00 03 24 00 01 26 CB 23 101000
0x5E0000000028000120000126CB23 heat auto 4 31 5E 00 00 00 00 28 00 01 20 00 01 26 CB 23 101000
0x600000000028000320000126CB23 cold auto 4 31 60 00 00 00 00 28 00 03 20 00 01 26 CB 23 101000
0x620000000028000124000126CB23 heat auto 4 31 62 00 00 00 00 28 00 01 24 00 01 26 CB 23 101000
0x6F0000000028070724000126CB23 vent auto 4   6F 00 00 00 00 28 07 07 24 00 01 26 CB 23 101000
0x71000000002A070724000126CB23 vent 1 4   71 00 00 00 00 2A 07 07 24 00 01 26 CB 23 101010
0x72000000002B070724000126CB23 vent 2 4   72 00 00 00 00 2B 07 07 24 00 01 26 CB 23 101011
0x74000000002D070724000126CB23 vent 3 4   74 00 00 00 00 2D 07 07 24 00 01 26 CB 23 101101
0x4F0000000008070724000126CB23 vent auto 0   4F 00 00 00 00 08 07 07 24 00 01 26 CB 23 001000
0x570000000010070724000126CB23 vent auto 1   57 00 00 00 00 10 07 07 24 00 01 26 CB 23 010000
0x5F0000000018070724000126CB23 vent auto 2   5F 00 00 00 00 18 07 07 24 00 01 26 CB 23 011000
0x670000000020070724000126CB23 vent auto 3   67 00 00 00 00 20 07 07 24 00 01 26 CB 23 100000
0x6F0000000028070724000126CB23 vent auto 4   6F 00 00 00 00 28 07 07 24 00 01 26 CB 23 101000
0x620000000028000124000126CB23 heat auto 4 31 62 00 00 00 00 28 00 01 24 00 01 26 CB 23 101000
0x630000000028010124000126CB23 heat auto 4 30 63 00 00 00 00 28 01 01 24 00 01 26 CB 23 101000
0x640000000028020124000126CB23 heat auto 4 29 64 00 00 00 00 28 02 01 24 00 01 26 CB 23 101000
0x650000000028030124000126CB23 heat auto 4 28 65 00 00 00 00 28 03 01 24 00 01 26 CB 23 101000
0x660000000028040124000126CB23 heat auto 4 27 66 00 00 00 00 28 04 01 24 00 01 26 CB 23 101000
0x670000000028050124000126CB23 heat auto 4 26 67 00 00 00 00 28 05 01 24 00 01 26 CB 23 101000
0x680000000028060124000126CB23 heat auto 4 25 68 00 00 00 00 28 06 01 24 00 01 26 CB 23 101000
0x690000000028070124000126CB23 heat auto 4 24 69 00 00 00 00 28 07 01 24 00 01 26 CB 23 101000
0x6A0000000028080124000126CB23 heat auto 4 23 6A 00 00 00 00 28 08 01 24 00 01 26 CB 23 101000
0x6B0000000028090124000126CB23 heat auto 4 22 6B 00 00 00 00 28 09 01 24 00 01 26 CB 23 101000
0x6C00000000280A0124000126CB23 heat auto 4 21 6C 00 00 00 00 28 0A 01 24 00 01 26 CB 23 101000
0x6D00000000280B0124000126CB23 heat auto 4 20 6D 00 00 00 00 28 0B 01 24 00 01 26 CB 23 101000
0x6E00000000280C0124000126CB23 heat auto 4 19 6E 00 00 00 00 28 0C 01 24 00 01 26 CB 23 101000
0x6F00000000280D0124000126CB23 heat auto 4 18 6F 00 00 00 00 28 0D 01 24 00 01 26 CB 23 101000
0x7000000000280E0124000126CB23 heat auto 4 17 70 00 00 00 00 28 0E 01 24 00 01 26 CB 23 101000
0x7100000000280F0124000126CB23 heat auto 4 16 71 00 00 00 00 28 0F 01 24 00 01 26 CB 23 101000
0x7300000000280F0324000126CB23 cold auto 4 16 73 00 00 00 00 28 0F 03 24 00 01 26 CB 23 101000
0x7200000000280E0324000126CB23 cold auto 4 17 72 00 00 00 00 28 0E 03 24 00 01 26 CB 23 101000
0x7100000000280D0324000126CB23 cold auto 4 18 71 00 00 00 00 28 0D 03 24 00 01 26 CB 23 101000
0x7000000000280C0324000126CB23 cold auto 4 19 70 00 00 00 00 28 0C 03 24 00 01 26 CB 23 101000
0x6F00000000280B0324000126CB23 cold auto 4 20 6F 00 00 00 00 28 0B 03 24 00 01 26 CB 23 101000
0x6E00000000280A0324000126CB23 cold auto 4 21 6E 00 00 00 00 28 0A 03 24 00 01 26 CB 23 101000
0x6D0000000028090324000126CB23 cold auto 4 22 6D 00 00 00 00 28 09 03 24 00 01 26 CB 23 101000
0x6C0000000028080324000126CB23 cold auto 4 23 6C 00 00 00 00 28 08 03 24 00 01 26 CB 23 101000
0x6B0000000028070324000126CB23 cold auto 4 24 6B 00 00 00 00 28 07 03 24 00 01 26 CB 23 101000
0x6A0000000028060324000126CB23 cold auto 4 25 6A 00 00 00 00 28 06 03 24 00 01 26 CB 23 101000
0x690000000028050324000126CB23 cold auto 4 26 69 00 00 00 00 28 05 03 24 00 01 26 CB 23 101000
0x680000000028040324000126CB23 cold auto 4 27 68 00 00 00 00 28 04 03 24 00 01 26 CB 23 101000
0x670000000028030324000126CB23 cold auto 4 28 67 00 00 00 00 28 03 03 24 00 01 26 CB 23 101000
0x660000000028020324000126CB23 cold auto 4 29 66 00 00 00 00 28 02 03 24 00 01 26 CB 23 101000
0x650000000028010324000126CB23 cold auto 4 30 65 00 00 00 00 28 01 03 24 00 01 26 CB 23 101000
0x640000000028000324000126CB23 cold auto 4 31 64 00 00 00 00 28 00 03 24 00 01 26 CB 23 101000

After making an evaluation this are my conclusions so far : the meaningful code is interpreted as (LSB first)

dividing the code in bytes ,

in summary THE FIRST BYTE , WAS CONFIRMED TO BE A CHECKSUM 8 MODULO 256 .

i have not decoded the timer and sleep functions , as well as other modes dry , sleep, auto, timer on off, waves, and auto swing.

Still to verify the purpose of the last 5 bytes , most probably device address is included there .

byte meaning
1 checksum 8 modulo 256
2 zero
3 zero
4 zero
5 timer 1h 06 2h 0C , 3h12, es horas/6 en Hexa
6 SWING - VENT , bits 0TSSSVVV , bit t =1 con timer on.
7 Temperature ( 0=31c, 1= 30c for Heat cool )
8 mode: 01-heat, 03 cool, 07 vent, 08 auto
9 24 power on, 20 power off, 2C timer on
10 0x00
11 0x01
12 0x26
13 0xCB
14 0x23

SWING VENT bit detail

0tsssvvv      
swing   vent  
s001 1 v000 auto
s010 2 v010 1
s011 3 v011 2
s100 4 v101 3
s101 5    
s111 SWING    
crankyoldgit commented 6 years ago

Assuming when you converted to LSB order, you flipped the entire code, and that the first byte that you don't understand is actually the LAST byte transmitted, then this will most likely be the checksum of the rest of the message. You can have a look at some of the checksum calculations in other a/c code to see how it might be calculated. Without the ability to calculate the checksum (assuming it is that) you won't be able to construct a "new" message/state and be able to send it to the device successfully. You'll be limited to recording and replaying "old" messages.

e.g. your code: "0x640000000028000324000126CB23" will be transmitted Byte "0x23" then byte "0xCB", ..., byte "0x00", then finally the checksum byte of "0x64".

gnkarn commented 6 years ago

here the modified version , included in tasmota that decodes a message with the format : https://github.com/gnkarn/Multi-IrControl/tree/multi_bluesky

{ "Vendor": "<Toshiba|Mitsubishi|Bluesky>", "Power": <0|1>, "Mode": "<Hot|Cold|Dry|Auto|Vent>", "FanSpeed": "<1|2|3|4|5|Auto|Silence>", "Temp": <17..30> }

i still don't have a decode logic for the byte data[0] ,

will test tomorrow just , making a "fake" byte[0] . and also im not sure if im sending the bytes correctly as , this is LSB first message decoding .

gnkarn commented 6 years ago

GOOD , will include this checksum calc tomorrow and test . ! thank you( i had not seen your answer before i sent the previous message)

gnkarn commented 6 years ago

first , compile ok version with all the elements in place , ready for testing , checksum calculation works ok , https://github.com/gnkarn/Multi-IrControl/tree/multi_bluesky the mqtt command format is :

cmnd/Multi-IR/irhvac {"VENDOR": "BLUESKY","POWER":1,"MODE":"V","FANSPEED":1,"TEMP":25}

still to verify if im sending the bytes in the right order . NOT included : the protocol DECODE detection functions , and of course cleanup is needed .

gnkarn commented 6 years ago

code is doing what is expected , generating the correct coded 14 bytes , but is not activating the AC , so will do some measures tomorrow , and see if parameters for timing , modulation frec, are correct.

crankyoldgit commented 6 years ago

What are the 14 bytes?

On Mon., 28 May 2018, 11:27 am gus, notifications@github.com wrote:

code is doing what is expected , generating the correct coded 14 bytes , but is not activating the AC , so will do some measures tomorrow , and see if parameters for timing , modulation frec, are correct.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/markszabo/IRremoteESP8266/issues/463#issuecomment-392395987, or mute the thread https://github.com/notifications/unsubscribe-auth/AMInDMdV1yp9RW3PmOWbxR7rxvnwuvcgks5t21J7gaJpZM4UD8Ph .

gnkarn commented 6 years ago

You can see the meaning on the table above , With byte number and meaning .

gnkarn commented 6 years ago

signal timing directly from the remote screen shot 2018-05-28 at 09 55 56

screen shot 2018-05-28 at 09 57 11

gnkarn commented 6 years ago

this is the carrier signal generated by the library code

screen shot 2018-05-28 at 10 27 49

what i see here is that the carrier frequency is 35 kHz instead of 38khz , this may be the cause ...

gnkarn commented 6 years ago

the rest of the signal looks good screen shot 2018-05-28 at 10 31 18

gnkarn commented 6 years ago

i can confirm that the carrier frequency is 2 us longer than what it should be ( 28 vs 26 ), im still not sure if this is the only problem , but it is one . @crankyoldgit david, i was looking at the functions on the irsend.cpp , but couldn't find a cause so far .( im testing on a NODE_MCU )

gnkarn commented 6 years ago

i fooled the code by providing an input signal of 40923 khz(38x28/26) and now the carrier frequency es ok . (38095).

crankyoldgit commented 6 years ago

Re: Frequency. That's interesting to know. I don't have an oscilloscope to verify myself, so I'll take your word for it. I might write some test code to do some self-timings to calibrate the values better,

Re: The 14 bytes. Can you give me the values/contents of the "data" 14 byte array you are passing to your void IRsend::send_bluesky(uint8_t data[], uint16_t nbytes) function? I need to see it to see if you formatting correctly for using it with that function, or if the function needs to be modified (I suspect it does if you are now storing it in reversed order)

crankyoldgit commented 6 years ago

I forgot I had already written something to improve timing calibrations on a per-chip basis.

If you call irsend.calibrate(38000); in your void setup() {}; section. i.e. It needs to only be called ONCE. e.g. Just after the irsend.begin(); call. It will produce a short signal, but it will reset some internal offsets based on the self-observed timings.

gnkarn commented 6 years ago

i think i get what is going on, and you mention is related to "reverse bits order "

lets say that the first bytes of the code is 23 CB 26 01 00 24 ..... the remote sends the signal with this sequence header 1100 ( 3) 0100 (2) 1101 (B) 0011 (C) 0110 (6) 0100 (2) 1000 (1) .... and so

so it is not only that the checksum byte is the last one , but the bits inside each byte are sent LSB first , so that was my mistake on interpreting LSB first ...

so , my function is wrong , as it is not reversing the bits order , just the bytes order ..

gnkarn commented 6 years ago

so i , set the sendGeneric function to MSB false, and now the data sequence is ok, i sill see some difference on freq , im getting 38278 on the lib , vs 38095 on the control.

will see your calibration function .. tks

gnkarn commented 6 years ago

@crankyoldgit git it to work ! calibration function works perfect , now to test all modes ...

crankyoldgit commented 6 years ago

Yay! Glad it's working.

As you can measure the output, how close is the resulting frequency to 38000 Hz when you use calibrate(38000); and use sendGeneric() with 38000 as the freq?

crankyoldgit commented 6 years ago

FYI, I've added a FAQ item for calibrate() here: https://github.com/markszabo/IRremoteESP8266/wiki/Frequently-Asked-Questions#im-noticing-a-slight-transmission-frequency-modulation-mismatch-what-can-i-do-to-fix-it

gnkarn commented 6 years ago

It is exact on the first three significant digits .

gnkarn commented 6 years ago

Later will send the exact number

crankyoldgit commented 6 years ago

@gnkarn That's awesome (and good enough for our purposes) I've added a commit to the master branch which has a new offset value which should fix it up for everyone. Seems we have had some drift since it was last calculated.

gnkarn commented 6 years ago

control is 26.125 (38278 hz) us and library is 26.250 us ( 38095hz)

gnkarn commented 6 years ago

@crankyoldgit , @markszabo on my fork , and branch multi_bluesky , you will find the final version working , including fan speed , and also swing position .

command format is

cmnd/Multi-IR/irhvac {"VENDOR": "BLUESKY","POWER":1,"MODE":"V","FANSPEED":2,"SWING":S,"TEMP":31}

where MODE can be HDCAV Fan speed can be : A1235 ( 1 is sleep ) Swing can be : 12345S , where S is sweep

i have not included a decoder . the main function is included on the sonoff/xdrv_02_irremote.ino of tasmota , so it ready to work on any device with tasmota on it , it may well be the separate file ir_bluesky.cpp on the library , need to understand better the dependences in order for the compiler to find them all .

it will be a good thing to have it be part of the library and of the tasmota ...