Irremoteesp8266: Hitachi AC Remote (13 Byte, HITACHI_AC1)

[soumaxetuirk]

I can receive HITACHI_AC1 codes as the primary support is added for a while now.The AC class is not yet updated to send synthetic commands based on attributes.
I went through previously done work by DiggiD (post #453 )and analysed all other bytes for HITACHI_AC1.
Found: Mode, fan speed, temp, Kaimin (night) mode, Horizontal swing, power,filter rest, timer
The checksum is mostly sum of preceding bytes.(Did not calculate, but seen it changing same value as the other bytes...so)
My IR data spreadsheet.

[crankyoldgit]

What is the make and model numbers of both the A/C unit and the IR remote please?

[soumaxetuirk]

AC Model: HITACHI KAZE-312KSDP
Remote : R-LT0541-HTA/Y.K.1.1-1 V2.3

[crankyoldgit]

@soumaxetuirk Thanks for that.
I think I've worked out code for most of it, but the checksum alg. isn't obvious. You're going to have to work that out in order for it all to work at all.

[soumaxetuirk]

@soumaxetuirk Thanks for that.
I think I've worked out code for most of it, but the checksum alg. isn't obvious. You're going to have to work that out in order for it all to work at all.

thank you sir.

[MarkEvens]

when i use example ir receive dump v2 for decode remote it show hitachi ac1 but i don't know how to use is there any example for it

[crankyoldgit]

when i use example ir receive dump v2 for decode remote it show hitachi ac1 but i don't know how to use is there any example for it

@MarkEvens Please don't hijack a similar issue for something else. Create your own issue.
There are plenty of examples of how to use things like sendHitachiAc1() in the examples.
e.g. https://github.com/crankyoldgit/IRremoteESP8266/blob/master/examples/IRsendDemo/IRsendDemo.ino

[DiggiD]

Hiya @crankyoldgit! feels good to reconnect here! havent been able to get into this in a long long long while. Haaa!
have all the time now with the virus lockdowns all over :)

@soumaxetuirk Great stuff!! looks like you got most the functions..
your AC and mine, are off by just 1 bit. should be a physical switch on the backside of your remote in the battery compartment that flips byte 4

yours-->23/Cool/Auto ---- B2AE4D 9 1F061840000000020A8
mine -->23/Cool/Auto ---- B2AE4D 5 1F061840000000020A8

im as flummoxed as yall trying to work out the checksum at the end, but quite looking forward to wrap this up in a neat bow!
found a couple links that i thought might help

1.
https://medium.com/@camilloaddis/smart-air-conditioner-with-raspberry-pi-an-odissey-2a5b438fe984
Camillo has not only decoded his IRP with checksum but also programmed a the encoder-- really illuminating!

1. 
   https://github.com/hristo-atanasov/Tasmota-IRHVAC
   Now this one is my goal, exactly where id like to see this go because im using homeassistant too!
   its based on tasmota and David's IRremoteESP8266 library and IRP definitions.

onwards!!!

[crankyoldgit]

yours-->23/Cool/Auto ---- B2AE4D 9 1F061840000000020A8
mine -->23/Cool/Auto ---- B2AE4D 5 1F061840000000020A8

What's really interesting is that value change doesn't appear to be affecting the checksum. Bizarre, if correct, that indicates that it's not using every bit/nibble/etc in the checksum alg.

[soumaxetuirk]

yours-->23/Cool/Auto ---- B2AE4D 9 1F061840000000020A8
mine -->23/Cool/Auto ---- B2AE4D 5 1F061840000000020A8

On the duster filter command, byte 6 - 12 are zero and the checksum too. I am guessing first 5 bytes are not used for checksum.

@DiggiD I also need the IRHvac with my tasmota. So for now I created a little large csv files with every combination of remote scan code. Then I use a python script to relay required signal by pahomqtt. Its slow but working for the time being .

[crankyoldgit]

Okay, that's something to try. Maybe not all of the command is checksum'ed. I'll take a look later.

[DiggiD]

What's really interesting is that value change doesn't appear to be affecting the checksum. Bizarre, if correct, that indicates that it's not using every bit/nibble/etc in the checksum alg.

On the duster filter command, byte 6 - 12 are zero and the checksum too. I am guessing first 5 bytes are not used for checksum.

I found this paper setting out to build a universal IRP decoder/encoder, that outlines quite a few methods/algos to work out the checksum- but i haven't worked through all of the algos yet,
@crankyoldgit @soumaxetuirk
do have a look, when you get a chance :)

http://uu.diva-portal.org/smash/get/diva2:910960/FULLTEXT01.pdf
PAGE 13 section 3.2.2

I also need the IRHvac with my tasmota. So for now I created a little large csv files with every combination of remote scan code. Then I use a python script to relay required signal by pahomqtt. Its slow but working for the time being .

this looks like a good workaround! @soumaxetuirk
im using MQTT too, could i look through your implementation perhaps? would be great if i could mcguyver it for my hass instance while we work out the actual IRP :)

[crankyoldgit]

I found this paper setting out to build a universal IRP decoder/encoder, that outlines quite a few methods/algos to work out the checksum- but i haven't worked through all of the algos yet,
@crankyoldgit @soumaxetuirk
do have a look, when you get a chance :)

http://uu.diva-portal.org/smash/get/diva2:910960/FULLTEXT01.pdf
PAGE 13 section 3.2.2

I know pretty much everything that paper is talking about (and a heck of a lot more ;-)

Have a read of: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#integrity-checks

I've documented most of the algs I've come across there. I've tried most of them on this one.
It's NOT (just) the common ones, I can assure you. e.g. xor or summing _all_ the data. I didn't try summing only some of the bytes though. (See motivation comments below)

I have read of a checksum alg that sums the lower half of _some of_ the bytes, and xor's the upper half of _some of_ the bytes. I haven't tried that yet, but as I indicate on the site, I've done so many of these now, that I'm weary of doing more. e.g. The Kelvinator one took me weeks to work out, and I did that only because I own one. TL;DR: You've got the motivation to crack it, I don't. ;-)

[DiggiD]

I know pretty much everything that paper is talking about (and a heck of a lot more ;-)

:p no doubt no doubt! explains ALL of the nudging im doing 8-]

im no coder, not by a longshot, more like feeling around in the dark learning along the way..
was actually hoping it may spark an idea or two in this discussion. without the help here it would have taken me waay longer than the year ive been banging away at this ONE irp :D heh

Have a read of: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#integrity-checks

on it mate,
cheers!

[crankyoldgit]

Most of the checksum algs can be done by hand, or in a spreadsheet. You don't need to be able to program to work it out, but it does help if you can _read_ a program.
Most of them I've done by hand or with a calculator, only using a spreadsheet to organise the data.

[DiggiD]

yep, my coding kungfu is limited at best - will come knocking when its time to code it for sure.

Found my IR codes spreadsheet in the wiki.. thanks for that! : )
working to consolidate @soumaxetuirk and my codes into that one sheet- will help later to build an extensive IRP at some point, im hoping.
should be easier to see which bytes are actually affecting the checksum?

[camilloaddis]

Hi everybody,
I think I found the algorithm for the checksum calculation, even if I don't know if this is the best way to calculate it.
Let's take this signal string as an example: B2AE4D91F061C8000000001058

• The first five bytes (B2AE4D91F0) are ignored as they always remains the same;
• each of the next seven bytes is splitted in two groups of four bits (e.g. 0x61, binary 01100001 is splitted into 0110 and 0001);
• every group is read as a binary number in reverse – LSB order (e.g. our previous couple becomes 0110 and 1000) ;
• all these numbers are summed up to obtain the checksum, also in LSB order (e.g. 61C80000000010 splitted in groups gives 26 as sum, binary 00011010, reversed 01011000 which in hex is 0x58).

Here is the spreadsheet I used to calculate the checksum, based on the data from @soumaxetuirk and @DiggiD spreadsheets, and here's a gist with a simple js function to calculate the checksum with the rest of the string.

Cheers!

[crankyoldgit]

@camilloaddis I've tried that, I think. I can't get it to work with all cases.

every group is read as a binary number in reverse – LSB order (e.g. our previous couple becomes 0110 and 1001) ;

Shouldn't that be 0110 and 1000?

[crankyoldgit]

Huzzah! .. Yes, it's adding the LSB nibbles(4bits) together after the 5th byte. I'd been trying adding the LSB bytes(8 bits) together.

[camilloaddis]

Shouldn't that be 0110 and 1000?

Sure, my bad, only a typo I've just corrected, sorry.

[crankyoldgit]

@camilloaddis @soumaxetuirk @DiggiD @MarkEvens
I've added the working checksum alg and fully enabled the protocol in this branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/hitachi_ac1_detailed / PR #1072

Please download & try it out and let me know how it goes for you all.

[DiggiD]

replaced current IRremote library with https://github.com/crankyoldgit/IRremoteESP8266/tree/hitachi_ac1_detailed
and IRMQTTServer sketch to test.

on the server home page, sending _Complex(air conditioner) IR msg_ works as expected using
HITACHI_AC1 as Type and B2AE4D51F061840000000030B8 as State code

Though constructing a msg on the _Air Conditioner Control_ page of the server does not seem to work
settings used:
Protocol = HITACHI_AC1
Model tried all options in the dropdown i.e. default,unknown,1,2,3,4,5,6
Power = On
Mode = Auto
Temp = 25 C
Fan Speed = Auto
all other options kept off

Q: are the first 5 bits used as constants (since they dont add to the checksum)?
theres a 1 bit difference between my and @soumaxetuirk 's codes and hence possibly not working for me

@soumaxetuirk have you tested it?

[soumaxetuirk]

The starting 5 bytes are coming zero for all commands.
The first bit of 7th Byte (temp) is always 0 instead of 1.So temp byte is wrong.
Sleep is not implemented
FOR
IRhvac {"Vendor":"HITACHI_AC1", "Power":"On","Mode":"cool","FanSpeed":"auto","Temp":22}
RESULT
"IrReceived":{"Protocol":"HITACHI_AC1","Bits":104,"Data":"0x0x00000000006178000000003094","Repeat":0}

@DiggiD
single protocol will not work on both as AC is only detecting the original remote when button is set to specific one side.
As written the remote, mine is set to A and yours is B.
@crankyoldgit So probably have to create two protocols for both mode to work??

[crankyoldgit]

Oops, I think I know what I did wrong. I'll fix it in a few hours, I hope.

Re: A & B. I will see what I can do. I'll probably use the "model" setting for it. No promises yet.

[crankyoldgit]

Okay, the state being mostly zero should be now fixed.
You can set the A & B mode via setModel()
i.e. 1 is Mode A, 2 is Mode B on the remote. i.e. @soumaxetuirk you're 1, @DiggiD you're 2.

@soumaxetuirk Thanks for providing data in your response. It helped me narrow down the problem almost instantly.

Download the branch again and let me know how it goes.

[crankyoldgit]

@soumaxetuirk Can you please explain to me what this means?

bit (5-7) = Kaimin(night) mod
K1-100
K2-010
K3-1110
K4-001

I'm guessing they are sleep (night) modes, or something?
What do they do? i.e. how are they different?

In the common A/C API, "sleep" is either on or off or a time of some sort.
If we could only choose one mode for on, which K should we use? and .. is there an off value? I assume it's 000. Correct?

[crankyoldgit]

Also K3 is 4 bits? Rather than the 3 you specify & the others. What's the correct value?

[crankyoldgit]

I've updated the branch again. Please re-download & test again etc.

[soumaxetuirk]

It's my typing mistake. Kaimin is always 3 bits. 8th bit is swing toggle.
K1 - 100
K2 - 010
K3 - 110
K4 - 001
OFF - 000
Kaimin or Night mode can be activated only on Auto or Cool mode. In this mode AC will increase the temp by 1 degree (if K-1) hourly basis until it reaches to comfort Level (25c).Also lower the fan speed.
2 degree increment (K2) will be preferable for all I guess.

[DiggiD]

modes updated and new added
https://docs.google.com/spreadsheets/d/1oY_bNaFLmCt-Fu7lKBoQNOIQ1IfCY3-3j6nOzg2e8rQ/edit?usp=sharing

MODE check [byte 6]

{"IrReceived":{"Protocol":"HITACHI_AC1","Bits":104,"Data":"0x0xB2AE4D51F0F1A4000000003054","Repeat":0}}
auto mode expected value xE1
received value xF1

{"IrReceived":{"Protocol":"HITACHI_AC1","Bits":104,"Data":"0x0xB2AE4D51F061A4000000003084","Repeat":0}}
cool mode values match !

{"IrReceived":{"Protocol":"HITACHI_AC1","Bits":104,"Data":"0x0xB2AE4D51F021A40000000030F8","Repeat":0}}
dry mode expected value x28 (fan is fixed at low for dry mode x8)
received value x21

{"IrReceived":{"Protocol":"HITACHI_AC1","Bits":104,"Data":"0x0xB2AE4D51F041A40000000030B8","Repeat":0}}
Fan mode expected value x42 (fan is fixed at high for fan mode x2)
received value x41

{"IrReceived":{"Protocol":"HITACHI_AC1","Bits":104,"Data":"0x0xB2AE4D51F091A4000000003024","Repeat":0}}
powerful mode(aka. heat / sun icon) expected value x92 (fan mode auto x1 not available this mode)
received value x91

SWING check.. [byte 12]
{"IrReceived":{"Protocol":"HITACHI_AC1","Bits":104,"Data":"0x0xB2AE4D51F041A40000000061F8","Repeat":0}}
V.swing ON values match!
V.swing OFF expected x21 received x20 (this resets the swing position on next command if swing toggle bit is not received on OFF command)

{"IrReceived":{"Protocol":"HITACHI_AC1","Bits":104,"Data":"0x0xB2AE4D51F041A40000000020A8","Repeat":0}}
H.swing ON expected value xA1
received value x20
H.swing OFF value expected x21 received x20 (this resets the swing position on next command if swing toggle bit is not received on OFF command)

im guessing the Swing toggle bit[bit 8 of byte 12] encodes the swing position somehow so it stays fixed through other commands, until you pass either swing ON command again

[DiggiD]

@soumaxetuirk just to double check..
are our remotes exactly the same?!

ive put an image of my remote in the sheet, can you confirm?

the x3C value in Byte 5 points to RESET DUST FILTER for you,
but same value for me gives me a WIDE swing mode (i.e. horizontal vanes move opposite to each other as opposed to together as in H.Swing)

[soumaxetuirk]

@crankyoldgit I have tested the latest commit.
Only Auto mode is not working.
1-4 bit of 6th byte should be 1110 instead of 1111.

Also thanks @DiggiD, I just marked the restrictions.

Auto mode: TEMP fixed at 25c, FAN fixed at AUTO
Cool mode: NO RESTRICTION
Fan mode: Fan can be High,mid or low. (fan can't be set to AUTO)
Dry mode: FAN fixed at low
Heat/Power mode : Fan can be High mid or low. (FAN can't be set to AUTO)

About the swing toggle key:
there are 2 bits for swing.in 12th byte the 2nd bit is swing value. and the 8th bit is only swing toggle info. when you change swing value between 0 & 1, only that time 8th bit changes to 1 or else it stays 0.leaving toggle value always 1 is not gonna create any trouble.while the byte is different it provides the same functionality.

[soumaxetuirk]

@soumaxetuirk just to double check..
are our remotes exactly the same?!

ive put an image of my remote in the sheet, can you confirm?

the x3C value in Byte 5 points to RESET DUST FILTER for you,
but same value for me gives me a WIDE swing mode (i.e. horizontal vanes move opposite to each other as opposed to together as in H.Swing)

My remote is same as yours except 2 buttons are blank.the lock key & vertical swing. Mine has only vertical swing.I just went through your data sheet.

The 1st bit of 12th byte is SwingH _(not yet implemented)_ & 2nd bit is SwingV. 8th bit is the Swing Toggle.
you are getting issue as in every command SwingH is fixed at 0 for now not for the toggle value.
@crankyoldgit requesting for SwingH implementation (12th byte - 1st bit).

[DiggiD]

ive allowed edits temporarily,
ive added your codes table to the sheet as well, could you add your remote's image to the sheet?
https://docs.google.com/spreadsheets/d/1oY_bNaFLmCt-Fu7lKBoQNOIQ1IfCY3-3j6nOzg2e8rQ/edit?usp=sharing

I just went through your data sheet.

do you have a link to share?

you are getting issue as in every command SwingH is fixed at 0 for now not for the toggle value.

yes thats correct

[crankyoldgit]

Only Auto mode is not working.
1-4 bit of 6th byte should be 1110 instead of 1111.

Should be fixed now.

requesting for SwingH implementation (12th byte - 1st bit).

Done.

Auto mode: TEMP fixed at 25c, FAN fixed at AUTO
Cool mode: NO RESTRICTION
Fan mode: Fan can be High,mid or low. (fan can't be set to AUTO)
Dry mode: FAN fixed at low
Heat/Power mode : Fan can be High mid or low. (FAN can't be set to AUTO)

&

Kaimin or Night mode can be activated only on Auto or Cool mode.

I'll try to get to those (restrictions) tomorrow. I'm done for the night!

I've fixed the Sleep/Night values too.

As usual, please download and test, and give feedback etc.

[crankyoldgit]

Alright. Restrictions added to the branch. Please test etc.

I think that's the last of it.

[soumaxetuirk]

Alright. Restrictions added to the branch. Please test etc.

I think that's the last of it.

thank you @crankyoldgit & @camilloaddis .Everything working ok, I have checked scan codes manually to be sure.
Only one last minor error I found.

In Dry mode FAN is restricted to "auto" instead of low. And heat mode FAN is restricted high only.

silly question,
I have seen implementation of On TIMER & OFF timer.if that's true then in which command? what is argument for that?

[crankyoldgit]

Dry mode: FAN fixed at low
Heat/Power mode : Fan can be High mid or low. (FAN can't be set to AUTO)

In Dry mode FAN is restricted to "auto" instead of low. And heat mode FAN is restricted high only.

Geesh! Make up your minds! :-P I'll adapt it soon.

silly question,
I have seen implementation of On TIMER & OFF timer.if that's true then in which command? what is argument for that?

See:
https://github.com/crankyoldgit/IRremoteESP8266/pull/1072/commits/ae11fc401d6e8e8e58826754f2ba423bdb0f35ed#diff-cd4d85e9786ca64a0f3a8926ecc5293bR223-R226
& https://github.com/crankyoldgit/IRremoteESP8266/pull/1072/commits/ae11fc401d6e8e8e58826754f2ba423bdb0f35ed#diff-d5d6db27d28df393499227716fa26edbR1612-R1618

i.e.

  ac.setOnTimer(2 * 60 + 39);  // 2h39m, 0 is off
  ac.setOffTimer(10 * 60 + 17);  // 10h17m, 0 is off

[soumaxetuirk]

Dry mode: FAN fixed at low
Heat/Power mode : Fan can be High mid or low. (FAN can't be set to AUTO)

In Dry mode FAN is restricted to "auto" instead of low. And heat mode FAN is restricted high only.

Geesh! Make up your minds! :-P I'll adapt it soon.

silly question,
I have seen implementation of On TIMER & OFF timer.if that's true then in which command? what is argument for that?

See:
ae11fc4#diff-cd4d85e9786ca64a0f3a8926ecc5293bR223-R226
& ae11fc4#diff-d5d6db27d28df393499227716fa26edbR1612-R1618

i.e.

  ac.setOnTimer(2 * 60 + 39);  // 2h39m, 0 is off
  ac.setOffTimer(10 * 60 + 17);  // 10h17m, 0 is off

I mean current commit restricting to wrong fan mode.
As I said before DRY mode should have FAN fixed at low. That is correct information.

But in the latest commit,IRRemoteESP8266 is restricting it to AUTO.

[crankyoldgit]

In Dry mode FAN is restricted to "auto" instead of low. And heat mode FAN is restricted high only.

@soumaxetuirk done

[crankyoldgit]

I mean current commit restricting to wrong fan mode.
As I said before DRY mode should have FAN fixed at low. That is correct information.

@soumaxetuirk Wait?! What now? I'm utterly confused.

Are these statement(s) correct?

Auto mode: TEMP fixed at 25c, FAN fixed at AUTO
Cool mode: NO RESTRICTION
Fan mode: Fan can be High,mid or low. (fan can't be set to AUTO)
Dry mode: FAN fixed at low
Heat/Power mode : Fan can be High mid or low. (FAN can't be set to AUTO)
&
Kaimin or Night mode can be activated only on Auto or Cool mode.

If so, then the change I've just made will screw that up.
Also "If so", then what was it doing wrong, and how did you get it to go "wrong" i.e. what sequence etc?

[soumaxetuirk]

The statement I provided at beginning is correct. But your previous commit was restricting FAN to AUTO. (In dry mode)
So I asked to fix it as per I mentioned at first.
Sorry for my English.

[crankyoldgit]

So it's back to the way it was (after my "fix").
How did you get it to the wrong speeds? What method are you using to control it? what sequence?

[soumaxetuirk]

IRSend:
IRhvac {"Vendor":"HITACHI_AC1", "Power":"On","Mode":"dry","FanSpeed":"low","Temp":22.5}
IRReceived:
B2AE4D91F021F800000000310C

Which means 6th Byte is 0010001.It should be 00101000.

Also all these restrictions are build to remote.If I send wrong combination then AC accepts it and also shows on display too.But FAN rotates slow only.

[crankyoldgit]

@soumaxetuirk Dry mode fan is now fixed to low. Please check etc. Anything else?

[soumaxetuirk]

All done! Thank you 😊

[DiggiD]

double checked!! everything is working beautifully as expected !!

thank you @crankyoldgit @soumaxetuirk @camilloaddis

[crankyoldgit]

FYI, This has been included in the new v2.7.5 release of the library.