Hitachi split AC Decode HELP!

[DiggiD]

Hi, I need help decoding the IR codes for the Hitachi V1 series split AC's. i have been unable to find any hitachi decoder that can help. the remote used is made by another Chinese company - Lytran- their website offers no help either.

so, i have been working to decipher them myself. ive done a bit of the grunt work i.e cataloguing all the binary codes with button presses on the remote. so far ive managed to find codes for some of the modes - on&off/cool/recycle/dry fan high/mid/low/auto - but i need all the help i can get with the actual protocol.

the ON/OFF raw codes are as follows: ON 23C Cool Auto

Timing[211]: +3400, -3350, + 450, -1250, + 450, - 400, + 400, -1300,

• 350, -1300, + 450, - 400, + 400, - 450, + 400, -1300,
• 400, - 400, + 400, -1300, + 400, - 400, + 450, -1250,
• 400, - 450, + 400, -1250, + 450, -1250, + 450, -1250,
• 400, - 450, + 350, - 450, + 400, -1300, + 400, - 400,
• 450, - 400, + 400, -1300, + 400, -1300, + 400, - 400,
• 450, -1250, + 400, - 450, + 350, -1350, + 400, - 400,
• 400, -1300, + 400, - 400, + 450, - 400, + 400, - 400,
• 400, -1300, + 400, -1300, + 400, -1300, + 450, -1250,
• 400, -1300, + 400, - 400, + 400, - 400, + 450, - 400,
• 400, - 400, + 450, - 400, + 400, -1300, + 450, -1250,
• 400, - 400, + 450, - 400, + 400, - 400, + 450, - 400,
• 400, -1300, + 400, -1250, + 450, - 400, + 400, - 400,
• 450, - 400, + 400, - 400, + 450, -1250, + 450, - 400,
• 400, - 400, + 400, - 450, + 400, - 400, + 450, - 350,
• 450, - 400, + 400, - 400, + 450, - 400, + 400, - 400,
• 450, - 400, + 400, - 400, + 450, - 400, + 400, - 400,
• 450, - 400, + 400, - 400, + 450, - 400, + 400, - 400,
• 450, - 400, + 400, - 400, + 450, - 400, + 400, - 400,
• 400, - 450, + 400, - 400, + 450, - 350, + 450, - 400,
• 400, - 400, + 450, - 400, + 400, - 450, + 400, - 400,
• 400, - 400, + 450, - 400, + 400, - 450, + 400, - 400,
• 400, - 400, + 450, - 400, + 400, - 400, + 450, -1250,
• 400, -1300, + 450, - 350, + 450, - 400, + 400, - 400,
• 450, - 400, + 400, -1300, + 400, - 400, + 450, -1250,
• 450, -1250, + 400, -1300, + 400, - 400, + 450, - 400,
• 400, - 400, + 450

rawData[211] = {3400,3350,450,1250,450,400,400,1300,350,1300,450,400,400,450,400,1300,400,400,400,1300,400,400,450,1250,400,450,400,1250,450,1250,450,1250,400,450,350,450,400,1300,400,400,450,400,400,1300,400,1300,400,400,450,1250,400,450,350,1350,400,400,400,1300,400,400,450,400,400,400,400,1300,400,1300,400,1300,450,1250,400,1300,400,400,400,400,450,400,400,400,450,400,400,1300,450,1250,400,400,450,400,400,400,450,400,400,1300,400,1250,450,400,400,400,450,400,400,400,450,1250,450,400,400,400,400,450,400,400,450,350,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,400,450,400,400,450,350,450,400,400,400,450,400,400,450,400,400,400,400,450,400,400,450,400,400,400,400,450,400,400,400,450,1250,400,1300,450,350,450,400,400,400,450,400,400,1300,400,400,450,1250,450,1250,400,1300,400,400,450,400,400,400,450}; //UNKNOWN C996B0A

Binary:110110010101011100100110101010001111100000110000110000100000000000000000000000000000000000011000010111000

OFF 23C Cool Auto

Timing[211]: +3400, -3350, + 450, -1250, + 450, - 400, + 400, -1300,

• 400, -1300, + 400, - 400, + 450, - 400, + 400, -1300,
• 400, - 400, + 400, -1300, + 400, - 400, + 450, -1250,
• 400, - 450, + 400, -1300, + 400, -1250, + 450, -1250,
• 450, - 400, + 400, - 450, + 400, -1250, + 450, - 400,
• 400, - 400, + 400, -1300, + 400, -1300, + 400, - 400,
• 450, -1250, + 450, - 400, + 400, -1300, + 400, - 400,
• 450, -1250, + 400, - 400, + 450, - 400, + 400, - 400,
• 450, -1250, + 400, -1300, + 450, -1250, + 450, -1250,
• 400, -1300, + 400, - 400, + 450, - 400, + 400, - 450,
• 350, - 450, + 400, - 400, + 400, -1300, + 400, -1300,
• 400, - 400, + 450, - 400, + 400, - 400, + 450, - 400,
• 400, -1300, + 400, -1250, + 450, - 400, + 400, - 400,
• 450, - 400, + 400, - 400, + 450, -1250, + 450, - 400,
• 400, - 400, + 450, - 400, + 400, - 400, + 450, - 400,
• 400, - 400, + 450, - 400, + 400, - 400, + 450, - 400,
• 400, - 400, + 400, - 450, + 400, - 400, + 400, - 400,
• 450, - 400, + 400, - 400, + 450, - 400, + 400, - 450,
• 400, - 400, + 400, - 400, + 450, - 400, + 400, - 400,
• 450, - 400, + 400, - 450, + 400, - 400, + 400, - 400,
• 400, - 450, + 400, - 400, + 400, - 400, + 450, - 400,
• 400, - 400, + 450, - 400, + 400, - 400, + 450, - 400,
• 400, - 400, + 450, - 400, + 400, - 400, + 450, - 400,
• 400, -1300, + 400, - 400, + 450, - 400, + 400, - 400,
• 400, - 400, + 450, -1250, + 450, - 400, + 400, - 400,
• 450, -1250, + 450, -1250, + 450, - 400, + 400, - 400,
• 450, - 400, + 400

rawData[211] = {3400,3350,450,1250,450,400,400,1300,400,1300,400,400,450,400,400,1300,400,400,400,1300,400,400,450,1250,400,450,400,1300,400,1250,450,1250,450,400,400,450,400,1250,450,400,400,400,400,1300,400,1300,400,400,450,1250,450,400,400,1300,400,400,450,1250,400,400,450,400,400,400,450,1250,400,1300,450,1250,450,1250,400,1300,400,400,450,400,400,450,350,450,400,400,400,1300,400,1300,400,400,450,400,400,400,450,400,400,1300,400,1250,450,400,400,400,450,400,400,400,450,1250,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,400,450,400,400,400,400,450,400,400,400,450,400,400,450,400,400,400,400,450,400,400,400,450,400,400,450,400,400,400,400,400,450,400,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,1300,400,400,450,400,400,400,400,400,450,1250,450,400,400,400,450,1250,450,1250,450,400,400,400,450,400,400}; //UNKNOWN 828A89E1

Binary:110110010101011100100110101010001111100000110000110000100000000000000000000000000000000000001000010011000

and table:

the full table is a numbers file which i cant upload here.. but ill share them if anyone needs the rest

thanks for your help

[crankyoldgit]

Some suggestions off the top of my head. 1) Don't assume you've got the correct/best bit order. Some times the data is transmitted Least Significant Bit First, or it could be Most Significant Bit First order. I find would from the lowest temp setting to the highest and finding which bits flip helps guess the correct order. e.g. the lowest is typically 0/0b000 (often 16C on the remote) in the data, and the highest around 14/0b1110(30C).

2) Use something like Google Sheets to store the data so others can see it/comment etc. It's a handy way of sharing the data etc.

3) If you're using an ESP8266 to capture the data, I suggest you update the code the latest version of IRrecvDumpV2 etc. You're using an old version.

4) On the plus side, I recently added some experimental Hitachi code to the library. While it is not the same protocol to this, it is extremely similar. i.e. This one looks like it's just a shorter variant. That is, a command length of 13 bytes instead of the expected 28 bytes in HITACHI_AC_STATE_LENGTH. Try changing that value might help you get a working basic decoder of sorts.

[crankyoldgit]

Oh and for 4) you might want to tweak HITACHI_AC_HDR_SPACE to 3300 too. (It's not as similar as I first thought)

[DiggiD]

awesome!! thanks for all the suggestions @crankyoldgit

watch this space..

[DiggiD]

on point number 3) i actually used the irremote library for arduino with a few tweaks for binary decode to get these codes, i havent built an ESP-01 IR receiver yet. but i do intend to use the ESP-01 as IR transmitter

[crankyoldgit]

I really recommend capturing A/C remotes on an ESP8266 device using our IRrecvDumpV2 version. Some A/C remotes have two back-to-back distinct messages with a 10-20 millisecond gap between them. That can cause the Arduino IRremote library version to miss them as it sees the first half as a stand-alone message and misses the second half as it is decoding/displaying the first half. That, and the ESP8266 has far more ram and we capture codes with 500+ pulses (i.e. 1000+ elements in rawData).

Oh, seriously, invest in a couple of Wemos D1 mini's (or similar) to do development work on. Far far easier. ;-)

FYI, we have some tools to help decode these sorts of messages and generate example code etc:

~/git/IRremoteESP8266/tools$ cat /tmp/j
uint16_t rawData[211] = {3400,3350,450,1250,450,400,400,1300,400,1300,400,400,450,400,400,1300,400,400,400,1300,400,400,450,1250,400,450,400,1300,400,1250,450,1250,450,400,400,450,400,1250,450,400,400,400,400,1300,400,1300,400,400,450,1250,450,400,400,1300,400,400,450,1250,400,400,450,400,400,400,450,1250,400,1300,450,1250,450,1250,400,1300,400,400,450,400,400,450,350,450,400,400,400,1300,400,1300,400,400,450,400,400,400,450,400,400,1300,400,1250,450,400,400,400,450,400,400,400,450,1250,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,400,450,400,400,400,400,450,400,400,400,450,400,400,450,400,400,400,400,450,400,400,400,450,400,400,450,400,400,400,400,400,450,400,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,400,450,400,400,1300,400,400,450,400,400,400,400,400,450,1250,450,400,400,400,450,1250,450,1250,450,400,400,400,450,400,400}; //UNKNOWN 828A89E1
~/git/IRremoteESP8266/tools$ ./AutoAnalyseRawData.sh -g < /tmp/j
Potential Mark Candidates (using a range of 200):
3400
450

Potential Space Candidates (using a range of 200):
3350
1300
450

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

Guessing key value:
HDR_MARK = 3400
BIT_MARK = 450
HDR_SPACE = 3350
ONE_SPACE = 1300
ZERO_SPACE = 450

Decoding protocol based on analysis so far:

HDR_MARK+HDR_SPACE+10110010101011100100110101010001111100000110000110000100000000000000000000000000000000000001000010011000
  Bits: 104
  Hex:  0xB2AE4D51F06184000000001098 (MSB first)
        0x19080000000021860F8AB2754D (LSB first)
  Dec:  14156556793482006891505546956952 (MSB first)
        1983179942935188636463938041165 (LSB first)
  Bin:  10110010101011100100110101010001111100000110000110000100000000000000000000000000000000000001000010011000 (MSB first)
        00011001000010000000000000000000000000000000000000100001100001100000111110001010101100100111010101001101 (LSB first)

Generating a VERY rough code outline:

// WARNING: This probably isn't directly usable. It's a guide only.
// DANGER: More than 64 bits detected. A uint64_t for data won't work!
// DANGER: Try using alternative AirCon version below!

#define HDR_MARK 3400U
#define BIT_MARK 450U
#define HDR_SPACE 3350U
#define ONE_SPACE 1300U
#define ZERO_SPACE 450U
// Function
void IRsend::sendXYZ(const uint64_t data, const uint16_t nbits, const uint16_t repeat) {
  for (uint16_t r = 0; r <= repeat; r++) {
    // Header #1
    mark(HDR_MARK);
    space(HDR_SPACE);
    // Data #1
    // e.g. data = 0xB2AE4D51F06184000000001098, nbits = 104
    // DANGER: More than 64 bits detected. A uint64_t for data won't work!
    // DANGER: Try using alternative AirCon version below!
    sendData(BIT_MARK, ONE_SPACE, BIT_MARK, ZERO_SPACE, data, nbits, true);
    // Footer #1
    mark(BIT_MARK);
    delay(100);  // A 100% made up guess of the gap between messages.
  }
}
Alternative (aircon code):
// Alternative Function AirCon mode
void IRsend::sendXYZ(uint8_t data[], uint16_t nbytes, uint16_t repeat) {
  // nbytes should typically be 13
  // data should typically be of a type: uint8_t data[13] = {};
  // data[] will is assumed to be in MSB order.
  for (uint16_t r = 0; r <= repeat; r++) {
    sendGeneric(HDR_MARK, HDR_SPACE, BIT_MARK, ONE_SPACE, BIT_MARK, ZERO_SPACE, BIT_MARK
                100, data, nbytes, 38, true, 0, 50);
}

[DiggiD]

understood. i set it up on an ESP8266 and got the following

ON 23C COOL AUTO

Timestamp : 000053.151 Encoding : UNKNOWN Code : 2E00843A (106 bits) Library : v2.4.0

Raw Timing[211]:

• 3418, - 3426, + 448, - 1264, + 418, - 406, + 432, - 1284,
• 426, - 1278, + 424, - 408, + 430, - 398, + 430, - 1306,
• 410, - 398, + 428, - 1292, + 414, - 386, + 452, - 1288,
• 418, - 412, + 422, - 1284, + 426, - 1278, + 428, - 1294,
• 418, - 390, + 444, - 396, + 428, - 1286, + 426, - 402,
• 426, - 404, + 434, - 1284, + 420, - 1288, + 420, - 408,
• 456, - 1258, + 444, - 374, + 462, - 1254, + 436, - 396,
• 432, - 1278, + 424, - 410, + 424, - 392, + 438, - 404,
• 428, - 1272, + 436, - 1294, + 442, - 1256, + 444, - 1266,
• 454, - 1246, + 442, - 414, + 402, - 406, + 434, - 402,
• 424, - 408, + 422, - 410, + 416, - 1290, + 426, - 1280,
• 444, - 380, + 438, - 404, + 432, - 404, + 420, - 402,
• 424, - 1284, + 428, - 1278, + 438, - 452, + 382, - 398,
• 424, - 424, + 412, - 392, + 434, - 1304, + 442, - 360,
• 434, - 398, + 432, - 418, + 414, - 406, + 430, - 394,
• 432, - 402, + 436, - 406, + 420, - 410, + 458, - 386,
• 408, - 412, + 448, - 372, + 426, - 406, + 434, - 386,
• 438, - 402, + 428, - 422, + 408, - 404, + 428, - 406,
• 422, - 406, + 426, - 404, + 424, - 404, + 430, - 424,
• 412, - 404, + 426, - 404, + 424, - 400, + 430, - 410,
• 416, - 408, + 428, - 424, + 410, - 400, + 426, - 410,
• 422, - 410, + 418, - 432, + 404, - 422, + 412, - 418,
• 408, - 402, + 426, - 392, + 462, - 282, + 522, - 1292,
• 420, - 1304, + 438, - 374, + 440, - 394, + 450, - 382,
• 422, - 402, + 426, - 1282, + 432, - 402, + 444, - 1256,
• 434, - 1306, + 414, - 1276, + 430, - 416, + 452, - 356,
• 436, - 414, + 414

uint16_t rawData[211] = {3418, 3426, 448, 1264, 418, 406, 432, 1284, 426, 1278, 424, 408, 430, 398, 430, 1306, 410, 398, 428, 1292, 414, 386, 452, 1288, 418, 412, 422, 1284, 426, 1278, 428, 1294, 418, 390, 444, 396, 428, 1286, 426, 402, 426, 404, 434, 1284, 420, 1288, 420, 408, 456, 1258, 444, 374, 462, 1254, 436, 396, 432, 1278, 424, 410, 424, 392, 438, 404, 428, 1272, 436, 1294, 442, 1256, 444, 1266, 454, 1246, 442, 414, 402, 406, 434, 402, 424, 408, 422, 410, 416, 1290, 426, 1280, 444, 380, 438, 404, 432, 404, 420, 402, 424, 1284, 428, 1278, 438, 452, 382, 398, 424, 424, 412, 392, 434, 1304, 442, 360, 434, 398, 432, 418, 414, 406, 430, 394, 432, 402, 436, 406, 420, 410, 458, 386, 408, 412, 448, 372, 426, 406, 434, 386, 438, 402, 428, 422, 408, 404, 428, 406, 422, 406, 426, 404, 424, 404, 430, 424, 412, 404, 426, 404, 424, 400, 430, 410, 416, 408, 428, 424, 410, 400, 426, 410, 422, 410, 418, 432, 404, 422, 412, 418, 408, 402, 426, 392, 462, 282, 522, 1292, 420, 1304, 438, 374, 440, 394, 450, 382, 422, 402, 426, 1282, 432, 402, 444, 1256, 434, 1306, 414, 1276, 430, 416, 452, 356, 436, 414, 414}; // UNKNOWN 2E00843A

OFF 23C COOL AUTO

Timestamp : 000958.585 Encoding : UNKNOWN Code : 828A89E1 (106 bits) Library : v2.4.0

Raw Timing[211]:

• 3428, - 3396, + 422, - 1290, + 456, - 336, + 464, - 1282,
• 424, - 1290, + 426, - 396, + 432, - 402, + 422, - 1290,
• 424, - 424, + 406, - 1284, + 422, - 416, + 418, - 1284,
• 428, - 402, + 418, - 1296, + 430, - 1274, + 458, - 1230,
• 456, - 404, + 456, - 352, + 450, - 1300, + 412, - 398,
• 434, - 400, + 428, - 1278, + 452, - 1250, + 430, - 422,
• 420, - 1296, + 410, - 402, + 434, - 1282, + 450, - 376,
• 422, - 1286, + 444, - 422, + 396, - 404, + 424, - 402,
• 430, - 1292, + 414, - 1288, + 424, - 1284, + 426, - 1286,
• 428, - 1276, + 438, - 402, + 446, - 400, + 404, - 410,
• 428, - 394, + 434, - 400, + 428, - 1284, + 424, - 1292,
• 422, - 394, + 444, - 394, + 430, - 402, + 428, - 408,
• 450, - 1190, + 520, - 1258, + 424, - 404, + 426, - 434,
• 394, - 404, + 430, - 424, + 406, - 1274, + 442, - 392,
• 436, - 392, + 434, - 412, + 424, - 398, + 426, - 406,
• 428, - 402, + 470, - 356, + 430, - 444, + 386, - 414,
• 426, - 396, + 424, - 406, + 430, - 398, + 424, - 404,
• 434, - 372, + 454, - 404, + 424, - 418, + 414, - 404,
• 432, - 400, + 426, - 400, + 434, - 404, + 424, - 410,
• 424, - 426, + 410, - 394, + 436, - 398, + 438, - 402,
• 424, - 400, + 430, - 400, + 420, - 442, + 424, - 378,
• 430, - 420, + 440, - 376, + 452, - 378, + 424, - 420,
• 410, - 422, + 408, - 402, + 428, - 404, + 424, - 406,
• 434, - 1320, + 384, - 402, + 426, - 402, + 430, - 408,
• 424, - 420, + 410, - 1282, + 430, - 416, + 408, - 410,
• 418, - 1288, + 428, - 1276, + 464, - 376, + 420, - 428,
• 404, - 406, + 432

uint16_t rawData[211] = {3428, 3396, 422, 1290, 456, 336, 464, 1282, 424, 1290, 426, 396, 432, 402, 422, 1290, 424, 424, 406, 1284, 422, 416, 418, 1284, 428, 402, 418, 1296, 430, 1274, 458, 1230, 456, 404, 456, 352, 450, 1300, 412, 398, 434, 400, 428, 1278, 452, 1250, 430, 422, 420, 1296, 410, 402, 434, 1282, 450, 376, 422, 1286, 444, 422, 396, 404, 424, 402, 430, 1292, 414, 1288, 424, 1284, 426, 1286, 428, 1276, 438, 402, 446, 400, 404, 410, 428, 394, 434, 400, 428, 1284, 424, 1292, 422, 394, 444, 394, 430, 402, 428, 408, 450, 1190, 520, 1258, 424, 404, 426, 434, 394, 404, 430, 424, 406, 1274, 442, 392, 436, 392, 434, 412, 424, 398, 426, 406, 428, 402, 470, 356, 430, 444, 386, 414, 426, 396, 424, 406, 430, 398, 424, 404, 434, 372, 454, 404, 424, 418, 414, 404, 432, 400, 426, 400, 434, 404, 424, 410, 424, 426, 410, 394, 436, 398, 438, 402, 424, 400, 430, 400, 420, 442, 424, 378, 430, 420, 440, 376, 452, 378, 424, 420, 410, 422, 408, 402, 428, 404, 424, 406, 434, 1320, 384, 402, 426, 402, 430, 408, 424, 420, 410, 1282, 430, 416, 408, 410, 418, 1288, 428, 1276, 464, 376, 420, 428, 404, 406, 432}; // UNKNOWN 828A89E1

at first glance looks pretty similar t :)) going to try the analyse tool next

[crankyoldgit]

The last batch of data has a "bad" entry. Either noise, or a freq. modulation mismatch, or interference etc. e.g. one of the entries is "10" .. that's too short. Don't trust the signals of [212] length, [211] is most likely correct.

[DiggiD]

having some issues with analysis

D$ cat t uint16_t rawData[211] = {3440,3410,428,1280,428,402,426,1286,428,1278,450,382,426,404,432,1274,428,440,398,1288,408,414,428,1270,430,408,426,1288,424,1282,426,1286,430,418,408,400,440,1316,396,394,446,402,434,1258,452,1280,404,406,422,1286,424,412,424,1288,414,410,428,1296,440,372,428,418,414,386,452,1282,452,1246,456,1294,388,1280,458,1258,434,396,434,388,440,408,448,400,412,424,408,1294,412,1310,400,404,426,396,442,398,440,392,448,1266,420,1294,438,388,428,398,424,406,426,404,424,1284,428,406,428,404,470,354,434,408,420,412,424,398,426,402,434,396,438,394,436,450,378,400,430,410,422,404,456,374,424,394,444,396,430,402,442,408,404,402,440,418,424,396,418,408,418,422,416,420,408,404,434,394,426,402,430,394,446,392,432,424,410,394,456,400,412,402,426,402,426,408,428,420,428,1256,436,1284,456,376,428,398,428,398,434,400,450,1264,424,408,428,1300,404,1288,434,1276,452,378,428,406,426,400,426}; // UNKNOWN 355E0171 D$ sh ./AutoAnalyseRawData.sh -g < t sed: 1: "s/^.uint.{//i": bad flag in substitute command: 'i' sed: 1: "s/^.uint.{//i": bad flag in substitute command: 'i'

[DiggiD]

The last batch of data has a "bad" entry. Either noise, or a freq. modulation mismatch, or interference etc. e.g. one of the entries is "10" .. that's too short. Don't trust the signals of [212] length, [211] is most likely correct.

caught that as soon as i posted.... edited now :)

[crankyoldgit]

Yeah, I need to fix the sed issue. The sed command that ships with OSX doesn't seem to support that option for some reason. Try removing the trailing "i" on the sed regex. Or install gnu sed.

[DiggiD]

woot Success! installed gnu-sed- did not work. removed the trailing i and that did the job

result:

Potential Mark Candidates (using a range of 200):
3440
470
Potential Space Candidates (using a range of 200):
3410
1316
450
Guessing encoding type:
Looks like it uses space encoding. Yay!
Guessing key value:
HDR_MARK = 3440
BIT_MARK = 470
HDR_SPACE = 3410
ONE_SPACE = 1316
ZERO_SPACE = 450
Bits: 104
Hex:  0xB2AE4D51F061840000000030B8 (MSB first)
          0x1D0C0000000021860F8AB2754D (LSB first)
Dec:  14156556793482006891505546965176 (MSB first)
          2301330533031531367113012966733 (LSB first)
Bin:  10110010101011100100110101010001111100000110000110000100000000000000000000000000000000000011000010111000 (MSB first)     00011101000011000000000000000000000000000000000000100001100001100000111110001010101100100111010101001101 (LSB first)

>#define HDR_MARK 3440U
#define BIT_MARK 470U
#define HDR_SPACE 3410U
#define ONE_SPACE 1316U
#define ZERO_SPACE 450U
Alternative (aircon code):
// Alternative Function AirCon mode
void IRsend::sendXYZ(uint8_t data[], uint16_t nbytes, uint16_t repeat) {
  // nbytes should typically be 13
  // data should typically be of a type: uint8_t data[13] = {};
  // data[] will is assumed to be in MSB order.
  for (uint16_t r = 0; r <= repeat; r++) {
    sendGeneric(HDR_MARK, HDR_SPACE, BIT_MARK, ONE_SPACE, BIT_MARK, ZERO_SPACE, BIT_MARK
                100, data, nbytes, 38, true, 0, 50);
}

[DiggiD]

if i assume this line to be correct // data[] will is assumed to be in MSB order. then my table of decoded Binary and Hex values along with my inferences are correct:)

building on that some more: will post a google docs link

[crankyoldgit]

Cool. I started the re-write into Python for the script. It's mostly working. That should alleviate the sed issues in future and make it run on more than just unix.

Yes, it's just an assumption of MSB order. Only a guess. Like all assumptions, it can make an ass out of you and me to quote the ol' gag. Don't trust it at all for determining if the data is LSB or MSB order. ;-)

[DiggiD]

Only a guess. Like all assumptions, it can make an ass out of you and me to quote the ol' gag. Don't trust it at all for determining if the data is LSB or MSB order. ;-) lol

well, sending RAW timings via irsend works like a charm and the Aircon behaves as expected...so, how does irsend do it? MSB or LSB first? again i think im making an assumption somewhere

[crankyoldgit]

"It depends" for the real irsend stuff on a per protocol basis.

The example code the script pumps out is assuming you are feeding it data in MSB order (like it says) and it will send it in MSB order. That has nothing to do with the content of the data being in MSB or LSB order. As long as they are the same, it should be fine. It's just that the values in the data may make (more) sense in the other order.

It is more than just what the script dumps out (as a guide) for adding it to the library, but its a good first approximation.

[DiggiD]

i see...

currently im working on transcribing all the raw/binary to hex, and updating my code table, so i can get a handle on identifying the changing bits n bobs.

will post soon

[DiggiD]

here we go: https://docs.google.com/spreadsheets/d/1oY_bNaFLmCt-Fu7lKBoQNOIQ1IfCY3-3j6nOzg2e8rQ/edit?usp=sharing

your warning looms large over this-- cant shake the suspicion that this protocol uses LSB the only way i seem to be getting temp info is using LSB in the last byte but still dont understand all of it

uuuggghhhh id rather not redo it all....

what do you think?

[DiggiD]

hmm... even with LSB. i cant seem to decipher the temperature protocol.

@crankyoldgit were you able to have a look?

[crankyoldgit]

The temp looks like it is LSB to me. Examining "byte 7", it's clearly (mostly) the temp byte. FYI, I think you are confusing "byte 13" with the temp. The last byte is often the checksum of the previous bytes (working out the checksum alg. is often time consuming and painful btw). As the temp changes, so will it.

Back to byte 7 (Bits 0-7): Bit 0 (first transmitted), seems to always be '1'. Then bits 1-5 appear to contain the temp in LSB order. e.g. 16C = 0b10010 (MSB) or 0b01001 (LSB) or 9 (LSB) (16-7) 17C = 0b01010 (MSB) or 0b01010 (LSB) or 10 (LSB) (17-7) 18C = 0b11010 (MSB) or 0b01011 (LSB) or 11 (LSB) (18-7) ... 30C = 0b11101 (MSB) or 0b10111 (LSB) or 23 (LSB) (30-7)

i.e. temp_on_remote - 7 = value of byte 7, bits 1-5 (in LSB first order)

[DiggiD]

whoa!!! mindblown mate. Nice one!! as a novice programmer that would have taken me forever to figure that out!

is the checksum calculation needed before writing out the protocol for IRsend?

[crankyoldgit]

is the checksum calculation needed before writing out the protocol for IRsend?

No, and yes. If you already have the long HEX code (e.g. 0xB2AE4D51F061840000000030B8), then no you don't need to calculate it to send a valid message. It already contains the correct checksum.

However, if you are trying to synthetically construct a new message (i.e. not from a capture), you need to calculate the checksum in order to send a valid message. e.g. "Set the mode to cool, the temp to 27C, and fan to max, and turn on the device. Make it so!"

[DiggiD]

trying to crank out a command with #40- hitachi

(40, [long hex])

cant seem to find theHITACHI_AC_STATE_LENGTH variable to change to 13 as is needed according to my code length.

@crankyoldgit can i trouble you till success? :p

[crankyoldgit]

https://github.com/markszabo/IRremoteESP8266/blob/master/src/IRremoteESP8266.h#L252

Probably. ;-)

[DiggiD]

hey so, this is the result im getting in the serial monitor when i send payload_on: "40,0xB2AE4D51F061840000000030B8"

0002273.587: MQTT Payload (raw): 40,0xB2AE4D51F061840000000030B8 0002273.816: Sent the IR message. 0002273.816: Type: 40 0002273.817: Code: 0x61840000000030B8 0002273.817: Bits: 0 0002273.817: Repeats: 0

is it truncating the entire code? and bits = 0?

using MQTT Lens subscribed to my send/sent topics i see

/send 40,0xB2AE4D51F061840000000030B8 /sent 40,61840000000030B8,0,0

[DiggiD]

hold that thought!
--- just tested it with the IR circuit connected, WORKS LIKE A CHARM!! 👍 💯 ❤️ 🎆

[crankyoldgit]

I hear IR circuits can be useful. ;-)

I'll code up some official support for it in the next day or so.

Just to be sure, the only changes needed were HITACHI_AC_STATE_LENGTH and HITACHI_AC_HDR_SPACE, correct?

[crankyoldgit]

Oh, the bits 0 thing in the example code means "use the default" bit size for the protocol. It's a hack.

[crankyoldgit]

Hmm. Can you please log a separate issue for the fact that the serial output, and the "/sent" don't match the payload of the "/send'? ... That's a bug.

[DiggiD]

heheh.. yep, the only changes were

HITACHI_AC_STATE_LENGTH = 13U

and according to AutoAnalyseRawData.sh

define HITACHI_AC_HDR_MARK 3400U

define HITACHI_AC_HDR_SPACE 3400U

define HITACHI_AC_BIT_MARK 450U

define HITACHI_AC_ONE_SPACE 1300U

define HITACHI_AC_ZERO_SPACE 450U

define HITACHI_AC_MIN_GAP 100000U

ill open a new issue for the /sent & /send payload mismatch on serial/MQTT output for this...

thanks!

[crankyoldgit]

FYI, this branch: https://github.com/markszabo/IRremoteESP8266/tree/hitachi1 should work for basic sending/decoding. i.e. No decoding what the hex code(s) mean etc. Just detecting the protocol etc.

@DiggiD Note that it's now protocol number 41 for this variant/protocol for your MQTT setup.

[crankyoldgit]

Oh, can you also let me know what the model numbers are of the Hitachi remote and the A/C unit are?

[DiggiD]

its the "Hitachi Vi" series split AC - cant find any other model or serial numbers on the outside. will have to wait the maintenance guys to come open it up and have a look inside..

the remote used is made by another Chinese company - Lytran- www.lytran.net

the back of the remote PCB has the following : 61 401 2891 LT0541-HTA/YK.1-1 V1.5 2007-01-03

their website offers no help either.

[crankyoldgit]

Thanks. Noted in the code.

[crankyoldgit]

The basic support for 13 & 53 byte variants has been included in the latest official release of the library. (v2.4.1)

[crankyoldgit]

@DiggiD Did you have any luck decoding the various settings from the Hitachi code at all?

[crankyoldgit]

Hitachi 28 Byte A/C Protocol is has been included in the v2.5.3 release.

[soumaxetuirk]

Hitachi 13 Byte "HITACHI_AC1" protocol can only decode signals but unable to encode data. its been a while and I can only control by cloning remote produced codes. please at least add a basic functionality (mode,temp,fan speed)

[crankyoldgit]

@soumaxetuirk Please don't add to an existing CLOSED issue with a new request/problem etc. Open a new one.

No one has done any reverse engineering of the HITACHI_AC1 protocol yet. If you want it supported, you are going to have to collect the data and do the analysis yourself. See: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Frequently-Asked-Questions#Can_you_reverse_engineer_my_AirCon_protocol_for_me