Arduino nano with Airconditioner.

Other Hardware Home Automation
1

So I recently got my self an Arduino Nano as I wanted to set up some home automation, specifically I would like to be able to turn my air conditioner on when I am out and about though my phone. My first step is of cause to find out what signals my air conditioner remote sends but when I used the IRrecieve dump function found in the arduino-IRremote-Master library it constantly gives back differing information for the power button. I am wondering if there is a way to only send a power on/off signal, preferably set the temp and mode. The model is SRK56HEA-S and the remote is RMA502A001.

Is there a way to achieve this goal? Thanks in advance for any help.

This is the power buttons outputs as you can see it sends new infomration each time it cycles the state of the machine.

F1E60D97
Unknown encoding: F1E60D97 (32 bits)
Raw (101): 3150 -1550 450 -350 450 -1100 450 -250 500 -400 450 -1100 450 -250 500 -1150 450 -300 500 -350 400 -1150 450 -1150 400 -1150 450 -250 500 -1150 400 -400 400 -1150 450 -1150 400 -1150 450 -250 500 -200 600 -350 400 -400 450 -1100 400 -1200 400 -200 600 -1150 400 -1150 450 -250 500 -300 500 -1150 450 -250 500 -300 500 -1150 450 -250 500 -350 450 -1150 400 -1150 450 -350 400 -1150 450 -1100 450 -1150 450 -1100 450 -1150 400 -1150 400 -1200 400 -1150 400 -1150 450 -1150 400 -350 
8797C969
Unknown encoding: 8797C969 (32 bits)
Raw (101): 3150 -1550 450 -250 550 -1150 400 -300 450 -400 400 -1150 450 -350 400 -1150 450 -250 500 -350 500 -1100 400 -1200 400 -1150 400 -350 450 -1150 400 -350 450 -1150 400 -1200 400 -1150 400 -350 450 -350 450 -350 400 -350 500 -1100 400 -1200 400 -300 500 -1150 400 -1150 400 -350 500 -350 400 -1150 450 -250 500 -350 450 -1150 400 -300 500 -350 450 -1150 400 -1150 400 -400 400 -1150 400 -1200 400 -1150 400 -1150 450 -1150 400 -1150 450 -1150 400 -1150 400 -1150 450 -1150 400 -350 
B91DF4A3
Unknown encoding: B91DF4A3 (32 bits)
Raw (101): 3150 -1550 450 -350 400 -1150 450 -250 550 -350 400 -1150 450 -350 400 -1150 450 -250 550 -250 500 -1150 400 -1200 400 -1150 400 -350 450 -1150 400 -350 450 -1150 450 -1150 400 -1150 450 -350 400 -250 550 -350 400 -350 450 -1150 400 -1200 400 -250 550 -1150 400 -1150 450 -250 550 -300 450 -1150 400 -400 400 -350 450 -1150 400 -300 500 -350 450 -1150 400 -1150 450 -250 500 -1150 400 -1150 450 -1150 450 -1100 450 -1150 400 -1150 450 -1100 450 -1150 450 -1100 450 -1150 400 -350 
CB09CC41
Unknown encoding: CB09CC41 (32 bits)
Raw (101): 3200 -1550 450 -250 550 -1100 400 -400 450 -250 500 -1150 450 -250 500 -1150 450 -250 550 -350 400 -1150 400 -1150 450 -1150 400 -200 600 -1150 450 -250 500 -1150 400 -1150 450 -1150 400 -300 500 -350 400 -400 400 -300 500 -1150 400 -1150 450 -300 450 -1200 400 -1150 450 -350 400 -350 450 -1150 400 -300 500 -350 400 -1200 400 -250 550 -250 500 -1150 450 -1150 400 -300 500 -1150 400 -1150 450 -1150 400 -1150 450 -1100 450 -1150 450 -1100 450 -1150 400 -1150 450 -1150 400 -350
2

You may get more help if you update your post with the make & model of your airconditioner..

3

rw950431:
You may get more help if you update your post with the make & model of your airconditioner..

Good idea thanks, I have updated it.

4

So your device is a Mitsubishi?
I'm not familiar with them but your raw pulses looks identical in timing to the pulses of a Hitachi unit I did some reverse enginering on a few years ago. I have no idea if the codes have any similarity but the first step is to retrieve complete series of pulses and convert them to bits and bytes that you can analyze.

Judging from the raw data that you have managed to capture it looks quite consistent although the sketch is interpreting it differently each time because it doesn't know how to read them. I had to use a different sketch to capture the pulses from my remote because the codes were much longer, 296 bits. Compare that to the 32 bits your sketch is capturing.
Use this sketch:

You can read about the method I used to get a grip of the Hitachi protocol and hopefully find some hints that can take you forward in analyzing the codes for your unit. Link to a blog post about my adventures:

5

perhof:
So your device is a Mitsubishi?
I'm not familiar with them but your raw pulses looks identical in timing to the pulses of a Hitachi unit I did some reverse enginering on a few years ago. I have no idea if the codes have any similarity but the first step is to retrieve complete series of pulses and convert them to bits and bytes that you can analyze.

Judging from the raw data that you have managed to capture it looks quite consistent although the sketch is interpreting it differently each time because it doesn't know how to read them. I had to use a different sketch to capture the pulses from my remote because the codes were much longer, 296 bits. Compare that to the 32 bits your sketch is capturing.
Use this sketch:
Air Conditioner Record long Infrared Remote control signals - Arduino

You can read about the method I used to get a grip of the Hitachi protocol and hopefully find some hints that can take you forward in analyzing the codes for your unit. Link to a blog post about my adventures:
Reverse engineering Hitachi air conditioner infrared remote commands – perhof

Thanks, it looks very promising I shall spend today going over the information and trying to get it working and let you know how it goes.

6

perhof:
So your device is a Mitsubishi?
I'm not familiar with them but your raw pulses looks identical in timing to the pulses of a Hitachi unit I did some reverse enginering on a few years ago. I have no idea if the codes have any similarity but the first step is to retrieve complete series of pulses and convert them to bits and bytes that you can analyze.

Judging from the raw data that you have managed to capture it looks quite consistent although the sketch is interpreting it differently each time because it doesn't know how to read them. I had to use a different sketch to capture the pulses from my remote because the codes were much longer, 296 bits. Compare that to the 32 bits your sketch is capturing.
Use this sketch:
Air Conditioner Record long Infrared Remote control signals - Arduino

You can read about the method I used to get a grip of the Hitachi protocol and hopefully find some hints that can take you forward in analyzing the codes for your unit. Link to a blog post about my adventures:
Reverse engineering Hitachi air conditioner infrared remote commands – perhof

Using the new sketch I still have not been able to get consistent information from the remote, I have attached an excel spreadsheet with three tests worth of data, some lines up but I can't see a pattern Perhaps someone else can. Dropbox - Air con data.xlsx - Simplify your life

7

It looks totally consistent to me. You are looking at the wrong thing. Don't care about the numbers themselves. The numbers you get from that sketch is not the data you are looking for. It's pulse lengths. You might need to read my blog post again to understand them.

To get data from those pulse lengths remove the first two numbers (the big ones) because that's just a start pulse.
Now remove all the positive numbers. They are just pulses that separates the pauses (data)
The remaining negative numbers are your data bits. If you take a step back and look at them there are two differents sizes -400 and -1200 with a little variation. Small negative numbers are zero, big negative numbers are one.

The first four lines in you excel sheet translates into these bits

on  0100101001110101110000110110010010011011111111110000000011110000000011111010001101011100
off 0100101001110101110000110110010010011011111111110000000011110000000011111011001101001100
on  0100101001110101110000110110010010011011111111110000000011110000000011111010001101011100
off 0100101001110101110000110110010010011011111111110000000011110000000011111011001101001100

As expected there is just a few bits changing between off and on while the two lines from the on-command are identical as are the lines for the off command.

To avoid insanity you will need to write a script to translate the pulse lengths into bits or modify the sketch so that it does it for you.
I converted numbers < -800 (~-1200) to 1 and > -800 (~-400) to zero using this piece of powershell code:

$raw = gc "RawCodes.txt"

foreach ($rawrow in $raw){
    $rawrow = $rawrow.Trim()
    $rawrow = $rawrow.Substring(0,$rawrow.Length-1,1)
    [int]$b = 0
    [string]$code = ""
    $rawarray = $rawrow.split(",")
    foreach ($item in $rawarray){
        $int = [int]$item
        if (($int -lt 0) -and ($int -lt -800)){
            #write-host "$int=1"
            $code+="1"
            $b++
        }
        if (($int -lt 0) -and ($int -gt -800)){
            #write-host "$int=0"
            $code+="0"
            $b++
        }
    }      
    $b
    $code
    " "
}

It expects a text file called rawcodes.txt which contains all your pulses except the first control pulse. Like this:

384, -392, 400, -1204, 384, -388, 404, -388, 404, -1204, 384, -388, 400, -1208, 380, -392, 400, -392, 404, -1204, 380, -1204, 384, -1204, 380, -392, 400, -1204, 384, -392, 400, -1204, 384, -1204, 380, -1204, 384, -392, 400, -392, 400, -392, 400, -392, 400, -1208, 380, -1204, 380, -392, 404, -1204, 380, -1204, 384, -388, 404, -388, 404, -1204, 384, -388, 400, -396, 400, -1204, 384, -388, 404, -388, 404, -1204, 380, -1204, 384, -392, 400, -1204, 384, -1204, 380, -1204, 380, -1208, 380, -1204, 384, -1204, 384, -1200, 380, -1204, 384, -1204, 384, -1204, 380, -392, 400, -392, 400, -392, 400, -396, 400, -392, 400, -388, 404, -392, 400, -392, 404, -1204, 380, -1204, 384, -1204, 380, -1204, 384, -388, 404, -388, 404, -392, 400, -392, 400, -392, 404, -388, 404, -392, 400, -392, 400, -1208, 380, -1204, 384, -1204, 380, -1204, 380, -1208, 380, -388, 404, -1184, 400, -1208, 380, -392, 400, -392, 400, -1208, 380, -1204, 380, -392, 404, -1204, 380, -392, 400, -392, 404, -1204, 380, -1204, 384, -388, 404, -392, 400,

You can do the same using any language you like.

8

Ahh I see where I made the mistake, thanks. Now I can get to work writing some code to transmit it back. Before that though, I assume that I can even out the pulses say send a constant -400 for 0 and a -1200 for 1 and I assume it would be fine to leave a gap of 500 between each, but what about the starting two pulses? I know I would need to include them but do they have to be precise?

9

The length doesn't seem to be very critical. 500us sounds reasonable. Use lengths that seem to be an average of what you have received for the first two long ones too.

Note that the negative numbers are pauses and that all the 500us are pulsing.
All bits are sent using varying lengths of "silence" while the actual pulses are just separators between the bits.
Pulse for 500us and leave a gap of 1200us, pulse for 500us and leave a gap of 400us and so on. Always end by pulsing for 500us.