Irremoteesp8266: Return of the Big Hitachi AC (424 bit)

[jamsinclair]

Overview

As encountered in https://github.com/crankyoldgit/IRremoteESP8266/issues/417#issuecomment-384945500, I'm trying to decode my Hitachi AC which is sending a huge 424 bit remote state (Different to the previous two Hitachi protocols in this lib).

Hitachi Shirokumakun
AC Model: RAS-AJ25H
AC Remote Model: RAR-8P2
Manual (Japanese): https://kadenfan.hitachi.co.jp/support/raj/item/docs/ras_aj22h_a_tori.pdf

Output of raw data from IRrecvDumpV2.ino (if applicable)

I've dumped some initial variations of On/Off while toggling the temperature and started a WIP spreadsheet:
https://docs.google.com/spreadsheets/d/1TTRx7INyDlsJBn9UwebL2Q4Q0S0apq0DlKP6bfrVPQw/edit#gid=0

The analysis of raw data was pretty consistent with a little variation:

Found 853 timing entries.
Potential Mark Candidates:
[29784, 3416, 470]
Potential Space Candidates:
[49290, 1604, 1250, 416]
DANGER: Unexpected and unused mark timings!
Guessing encoding type:
Looks like it uses space encoding. Yay!

Guessing key value:
kHdrMark   = 29784
kHdrSpace  = 1604
kBitMark   = 463
kOneSpace  = 1208
kZeroSpace = 372
kSpaceGap = 49290

Decoding protocol based on analysis so far:

kHdrMark+UNEXPECTED->GAP(49290)UNKNOWN(3416)UNEXPECTED->kHdrSpace+1000000000001000000000000000001011111101111111110000000000110011110011000100100110110110110010000011011100111010110001010000000011111111000000001111111100000000111111110000000011111111000000001111111111001010001101011000111101110000000000001111111100000000111111110000000111111110110000000011111110000000011111110001000111101110000000001111111100000000111111111111111100000000111111110000000011111111000000001111111100000000
  Bits: 424
  Hex:  0x80080002FDFF0033CC49B6C8373AC500FF00FF00FF00FF00FFCA358F7000FF00FF01FEC03F807F11EE00FF00FFFF00FF00FF00FF00 (MSB first)
        0x00FF00FF00FF00FFFF00FF007788FE01FC037F80FF00FF000EF1AC53FF00FF00FF00FF00FF00A35CEC136D9233CC00FFBF40001001 (LSB first)
  Dec:  21666770463250971033249250747302630158357464218891161163035832525825434564377831675503794869126268735511944198247894513495375616 (MSB first)
        168571844243726586691794086226450419200576177610623344152195260950249734545225589859643087812860908833344117446370839379316737 (LSB first)
  Bin:  0b1000000000001000000000000000001011111101111111110000000000110011110011000100100110110110110010000011011100111010110001010000000011111111000000001111111100000000111111110000000011111111000000001111111111001010001101011000111101110000000000001111111100000000111111110000000111111110110000000011111110000000011111110001000111101110000000001111111100000000111111111111111100000000111111110000000011111111000000001111111100000000 (MSB first)
        0b0000000011111111000000001111111100000000111111110000000011111111111111110000000011111111000000000111011110001000111111100000000111111100000000110111111110000000111111110000000011111111000000000000111011110001101011000101001111111111000000001111111100000000111111110000000011111111000000001111111100000000101000110101110011101100000100110110110110010010001100111100110000000000111111111011111101000000000000000001000000000001 (LSB first)

Total Nr. of suspected bits: 424

Unlike #417 I'm getting a wild header mark value 😬

Sending the raw data with your library works ✅
However sending data using the guessed protocol from analysis tool are not being registered 🙅‍♂

Before I start breaking down the bytes, thought I'd get some sanity checking and advice if you have the time?

[crankyoldgit]

Yeah, poor ol' auto_analyse_raw_data.py will have a hard time with that protocol's layout. It's not really typical, so it's doing a poor job of generating code for it.

As it says:
Generating a VERY rough code outline .. In this case it is just that.

I'll make the obvious tweaks it needs and give you something (code) that should work soon.

I'll look at tweaking auto_analyse_raw_data.py later to produce slightly better code (it still won't be automatic/correct, just less horrible. :)

[crankyoldgit]

Hey @jamsinclair Can you please download and try out the code in this branch. It should probably work for you: https://github.com/crankyoldgit/IRremoteESP8266/tree/GunnaNeedABiggerBoat

It looks like its very similar to HitachiAC2. i.e. same length, very similar timings. The difference is there is an additional message leader compared to the captures for the HitachiAC2 protocol.

I suspect there will be an overlap.

[jamsinclair]

Thanks a lot @crankyoldgit! Was about to say, please don't spend too much time.... too late.

As always great branch name, will give it a try tonight!

[crankyoldgit]

As always great branch name

I think someone may have given me inspiration .. don't know who. :)

[jamsinclair]

Woo!

Thanks, the commands are decoding A-OK 👌 with the dump example and your branch.

Also confirming the remote states are sending fine with ::sendHitachiAc424 and recognised by the aircon.

I'll have a play another day with configuring the state with the IRHitachiAc class.

[crankyoldgit]

Excellent. Thanks for the confirmation. FYI, the IRHitachiAc class is not for that protocol, or for IRHitachiAc2. So don't expect it to work. However, it may help you with decoding the protocol further.

I'll update the status of the new protocol to "stable" based on your report.

[jamsinclair]

Ah gotcha... not all smooth sailing 😅. Thanks for the help, I'll see where I get decoding further.

Do you want to keep this open? Or shall I create a new one once I have further data?

[btbouwens]

Not trying to hijack your ticket, really, but I'm getting a bit confused, starting to look into this subject.
In https://perhof.wordpress.com/2015/03/29/reverse-engineering-hitachi-air-conditioner-infrared-remote-commands/ I find an analysis of 37 byte messages, while my Hitachi gets 33 byte messages..
How many variations are there, really?

[crankyoldgit]

Do you want to keep this open? Or shall I create a new one once I have further data?

Honestly, I'd prefer the latter. It keeps things cleaner. I'll mark the PR to automatically close this issue when it's merged.

When you create the new issue, just add a ref to this issue so people can see the history etc.

[crankyoldgit]

Not trying to hijack your ticket, really, but I'm getting a bit confused, starting to look into this subject.
In https://perhof.wordpress.com/2015/03/29/reverse-engineering-hitachi-air-conditioner-infrared-remote-commands/ I find an analysis of 37 byte messages, while my Hitachi gets 33 byte messages..
How many variations are there, really?

@btbouwens _How long is a piece of string?_ ;-)
Honestly, you'll have to ask Hitachi.

This library offers varying levels of support for 4 different variations thus far:

const uint16_t kHitachiAcStateLength = 28;  // HITACHI_AC
const uint16_t kHitachiAc1StateLength = 13;  // HITACHI_AC1
const uint16_t kHitachiAc2StateLength = 53;  // HITACHI_AC2
// and soon to be merged.
const uint16_t kHitachiAc424StateLength = 53;  // HITACHI_AC424

However, I suspect HITACHI_AC424 & HITACHI_AC2 are probably the same, just the latter we have slightly more/better capture data for.

You've just alluded to 33 & 37 byte versions. So, maybe as many as 6?

That number isn't too unusual. The library has documented & supports 6 variations of _Panasonic_ A/C protocols (same signal, but different internal data breakdowns), while for _Daikin_ we have 7 completely different signal lengths/structures/protocols thus far.

[jamsinclair]

As discussed in the spreadsheet, I'll record a few more commands and see if any other clues about the bit ordering.

@crankyoldgit With your branch code in #975, is at as simple as toggling the MSBfirst param in sendGeneric and matchGeneric to force LSB ordering?

[crankyoldgit]

@crankyoldgit With your branch code in #975, is at as simple as toggling the MSBfirst param in sendGeneric and matchGeneric to force LSB ordering?

Pretty much. The unit tests will break as the test data needs to be reversed too, but if you don't care about that, then it should be fine change those parameters to get LSB results.

[crankyoldgit]

@jamsinclair FYI, https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#determining-the-bit-order-of-the-protocol may be of help. The clock or fan speed setting may also be a good value to see if it "increases" as expected too, when trying to work out bit ordering.

[jamsinclair]

I'm leaning towards this being LSB first. The On Timer and Fan speed _seem to_ also correlate with expected increases... 🤔

[crankyoldgit]

So mote it be!

Branch updated to LSBF ordering for HITACHI_AC424.
Good luck with the rest of the decode.

[crankyoldgit]

FYI, the changes mention above have been included in the v2.7.0 release of the library.