Hitachi split AC Decode HELP! #453

DiggiD · 2018-05-07T14:33:04Z

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 · 2018-05-07T15:35:20Z

Some suggestions off the top of my head.

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).
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.
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.
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 · 2018-05-07T15:41:26Z

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 · 2018-05-07T15:57:41Z

awesome!! thanks for all the suggestions @crankyoldgit

watch this space..

DiggiD · 2018-05-07T16:02:46Z

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 · 2018-05-08T01:12:46Z

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 · 2018-05-08T07:58:43Z

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 · 2018-05-08T08:28:57Z

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 · 2018-05-08T08:30:39Z

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 · 2018-05-08T08:31:40Z

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 · 2018-05-08T08:41:02Z

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 · 2018-05-08T14:34:45Z

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 · 2018-05-08T14:39:32Z

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 · 2018-05-08T14:58:16Z

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 · 2018-05-08T15:05:32Z

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 · 2018-05-08T15:29:06Z

"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 · 2018-05-08T17:47:21Z

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 · 2018-05-09T00:34:39Z

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 · 2018-05-10T11:01:01Z

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

@crankyoldgit were you able to have a look?

crankyoldgit · 2018-05-10T14:24:23Z

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 · 2018-05-10T16:58:45Z

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 · 2018-05-11T00:43:29Z

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 · 2018-05-13T11:34:47Z

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 · 2018-05-13T23:35:42Z

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

Probably. ;-)

DiggiD · 2018-05-14T09:59:12Z

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 · 2018-05-14T10:06:55Z

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

crankyoldgit · 2018-05-14T10:32:18Z

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 · 2018-05-14T10:34:01Z

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

crankyoldgit · 2018-05-14T10:38:04Z

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 · 2018-05-14T11:01:44Z

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!

HITACHI_AC1 is basically the same as HITACHI_AC except only 13 bytes long and a Header Space that is the same length as the Header Mark. Ref: #453

crankyoldgit · 2018-05-14T16:14:11Z

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 · 2018-05-14T16:19:40Z

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

DiggiD · 2018-05-14T17:18:05Z

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 · 2018-05-14T22:56:12Z

Thanks. Noted in the code.

HITACHI_AC1 is basically the same as HITACHI_AC except only 13 bytes long and a Header Space that is the same length as the Header Mark. Ref: #453

* Add basic support for 13 & 53 byte Hitachi A/C protocol. HITACHI_AC1 is basically the same as HITACHI_AC except only 13 bytes long and a Header Space that is the same length as the Header Mark. Ref: #453

crankyoldgit · 2018-05-20T12:26:20Z

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

crankyoldgit · 2018-09-14T00:39:38Z

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

Add deep support for the Hitachi 28-Byte A/C Protocol. Ref: #417 #453

* Experimental IRHitachiAc class. Add deep support for the Hitachi 28-Byte A/C Protocol. Limited to basic functions. Unit tests Update IRrecvDumpV2 to reflect improvements. Note: We incorrectly (historically) have Hitachi as MSB First bit ordering, it's really in LSBF order. Due to legacy usage, we'll keep the sending routines and array data in MSBF and reverse bits as needed. Fixes #417 Fixes #453

crankyoldgit · 2018-11-23T11:33:52Z

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

soumaxetuirk · 2020-03-04T22:59:48Z

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 · 2020-03-04T23:18:26Z

@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

crankyoldgit added the help wanted label May 12, 2018

crankyoldgit mentioned this issue May 12, 2018

Help Decoding HITACHI AC Remote #417

Closed

crankyoldgit added a commit that referenced this issue May 14, 2018

Initial code to handle Hitachi A/C 13 byte codes.

785fdee

HITACHI_AC1 is basically the same as HITACHI_AC except only 13 bytes long and a Header Space that is the same length as the Header Mark. Ref: #453

crankyoldgit mentioned this issue May 14, 2018

Initial code to handle Hitachi A/C 13 & 53 byte codes. #461

Merged

crankyoldgit added a commit that referenced this issue May 14, 2018

Initial code to handle Hitachi A/C 13 byte codes.

71f5601

HITACHI_AC1 is basically the same as HITACHI_AC except only 13 bytes long and a Header Space that is the same length as the Header Mark. Ref: #453

crankyoldgit added a commit that referenced this issue May 19, 2018

Initial code to handle Hitachi A/C 13 byte codes.

391e6fb

HITACHI_AC1 is basically the same as HITACHI_AC except only 13 bytes long and a Header Space that is the same length as the Header Mark. Ref: #453

crankyoldgit added a commit that referenced this issue Oct 28, 2018

Experimental IRHitachiAc class.

eaa2814

Add deep support for the Hitachi 28-Byte A/C Protocol. Ref: #417 #453

crankyoldgit mentioned this issue Oct 28, 2018

Add deep support for the Hitachi 28-Byte A/C Protocol #563

Merged

crankyoldgit closed this as completed in #563 Nov 4, 2018

Repository owner locked as resolved and limited conversation to collaborators Mar 4, 2020

Hitachi split AC Decode HELP! #453

Hitachi split AC Decode HELP! #453

Comments

DiggiD commented May 7, 2018 • edited Loading

crankyoldgit commented May 7, 2018 • edited Loading

crankyoldgit commented May 7, 2018

DiggiD commented May 7, 2018

DiggiD commented May 7, 2018

crankyoldgit commented May 8, 2018

DiggiD commented May 8, 2018 • edited Loading

crankyoldgit commented May 8, 2018

DiggiD commented May 8, 2018

DiggiD commented May 8, 2018

crankyoldgit commented May 8, 2018

DiggiD commented May 8, 2018 • edited by crankyoldgit Loading

DiggiD commented May 8, 2018

crankyoldgit commented May 8, 2018

DiggiD commented May 8, 2018

crankyoldgit commented May 8, 2018

DiggiD commented May 8, 2018

DiggiD commented May 9, 2018 • edited Loading

DiggiD commented May 10, 2018

crankyoldgit commented May 10, 2018

DiggiD commented May 10, 2018 • edited Loading

crankyoldgit commented May 11, 2018

DiggiD commented May 13, 2018

crankyoldgit commented May 13, 2018

DiggiD commented May 14, 2018 • edited Loading

DiggiD commented May 14, 2018

crankyoldgit commented May 14, 2018

crankyoldgit commented May 14, 2018

crankyoldgit commented May 14, 2018

DiggiD commented May 14, 2018

crankyoldgit commented May 14, 2018

crankyoldgit commented May 14, 2018

DiggiD commented May 14, 2018 • edited Loading

crankyoldgit commented May 14, 2018

crankyoldgit commented May 20, 2018

crankyoldgit commented Sep 14, 2018

crankyoldgit commented Nov 23, 2018

soumaxetuirk commented Mar 4, 2020

crankyoldgit commented Mar 4, 2020

DiggiD commented May 7, 2018 •

edited

Loading

crankyoldgit commented May 7, 2018 •

edited

Loading

DiggiD commented May 8, 2018 •

edited

Loading

DiggiD commented May 8, 2018 •

edited by crankyoldgit

Loading

DiggiD commented May 9, 2018 •

edited

Loading

DiggiD commented May 10, 2018 •

edited

Loading

DiggiD commented May 14, 2018 •

edited

Loading

DiggiD commented May 14, 2018 •

edited

Loading