andrewmv / ac-control-stuff Goto Github PK

IR signal duty is 38khz modulated, 50% duty cycle

Sampling from a Sensibo IR gateway - it produeced similar, but not identical, output to the factory remote

• packets start with a 4400us pulse, followed by 4400us wait
• Subsequent pulses are always 400us long
• A High bit is encoded as a 600us wait between pulses
• A low bit is encoded as a 1600us wait between pulses
• Packets end with another 4400us pulse, and always have at least a 5000us wait betwen them
• Sensibo gateway sends a 4400us START/STOP pulse at the beginning and end of both packets
• Factory remote omits the 4400us pulse at the end of the second packet

Signals are 2 packets wide, but the 2nd packet seems to just be a 1's complement of the first. Both the Senisbo gateway and the factory remote behave this way.

I've been choosing to ignore the first packet, as the second encodes things more intuitively (e.g. '1' is 'on', and higher temperatures are encoded as larger hex values). I've yet to confirm if both codes are necessary to operate the device (update - they are).

Packets are always exactly six octets long.

Packets can be one of three different formats, and only one will be sent at a time.

• State packets begin with 0xa1, and encode power state, fan mode, HVAC mode, and target temperature. These are fully idempotent and declarative, representing the intended state of the device, rather than the changes to make to it.
• Command packets begin with 0xa2, and encode specific changes that are not included in the state.
• Follow-Me packets begin with 0xa4, and encode remote temperature sensor update data.

Octet 1: Packet Type
	0xa1 = state (normal packet, sends modes and target temperature)
Octet 2: Power State + Fan mode + HVAC Mode
MSB	7: Power
	6: Always 0
	5: Fan Mode
	4: Fan Mode
	3: Fan Mode
	2: HVAC Mode
	1: HVAC Mode
LSB	0: HVAC Mode 
Octet 3: Target temperature (Degress F + 34)
	62 Farenheit -> 0x60
	86 Farenheit -> 0x78
	Should be 0x7E for Dry and Fan modes
Octet 4, 5: Always 0xff
Octet 6: Checksum 

Display control is sent as a toggle command packet

Oscillation control is sent as an idempotent on/off command packet

Octet 1: Packet Type
	0xa2 = command (sends a command that does NOT include modes and target)
Octet 2: Power State + Fan mode + HVAC Mode
MSB	7: Always 0
	6: Always 0
	5: Always 0
	4: Always 0
	3: Toggle Display if set
	2: Always 0
	1: Enable Oscillation if set
LSB	0: Disable Oscillation if set
Octet 3-5: Always 0xff
Octet 6: Checksum 

The AC has a "Follow Me" mode, in which the factory remote acts as a thermostat, and the AC unit uses updates from the remote in leiu of its own sensor.

These packets should not cause the AC unit to beep or wake the display.

This packets have header of 0xA4, and use the fifth octet to transmit temperature information.

The forth packet seems to contain information about toggling Follow Me mode on an off.

Octets 2 and 3 are identical to a state packet

The AC will disable Follow Me mode if it does not receive an update packet for 7 minutes.

Octet 1: Packet Type
	0xa4 = follow me
Octet 2: Power State + Fan mode + HVAC Mode
MSB	7: Power
	6: Always 0
	5: Fan Mode
	4: Fan Mode
	3: Fan Mode
	2: HVAC Mode
	1: HVAC Mode
LSB	0: HVAC Mode 
Octet 3: Target temperature (Degress F + 34)
Octet 4: Follow Me Options
MSB 7: Follow Me Mode
	6: Follow Me Mode
	5: Always 1
	4: Always 1
	3: Always 1
	2: Always 1
	1: Always 1
LSB 0: Always 1
Octet 5: Follow Me reported temperature (Degrees F - 31)
Octet 6: Checksum 

Note - a full FM packet, including the current reported remote temperature, is included in the packet that sends the Disable command.

Last octet transmitted in each packet is the checksum. Samples:

Checksum function seems to be:

• Reverse the order of the bits every octet (0x01 -> 0x80, etc.)
• Add a 0xff padding byte
• Sum all five bytes, including the unused ones (three 0xff's in total)
• AND 0xff (modulo 0x0100)
• Reverse the order of the bits again
• Negate (one's compliment)

Some messy and ineffecient Python:

def rev(data):
  return int(format(data, '0%db' % 8)[::-1], 2)
def check1(p1, p2, p3):
    return hex( (rev((0xff + rev(p1) + rev(p2) + rev(p3) + 0xff + 0xff) & 0xff) ^ 0xff ))
check1(0xa1, 0x88, 0x75)

May be a rebranded Haier device (update - it is not).

Timings and byte encodings appear to be the same, but packet structure is different

Packets begin with a 8800us start pulse followed by a 4600us wait, and are 4 bytes long, but do not have a stop block.

Bytes are encoded LSB first which is the oppostite of the Insignia device

Supported fucntions

HVAC Modes:

• Cool
• Dry
• Fan

3 Fan Speeds

Timer function (enabling and adusting sends codes)

F/C adjust

Octet 1: Device code - always 0xed
Octet 2: HVAC Mode, Fan Speed
LSB	0: Always 1
	1: Fan Speed
	2: Fan Speed
	3: Fan Speed
	4: HVAC Mode
	5: HVAC Mode
	6: HVAC Mode
MSB	7: HVAC Mode
Octet 3: Timer, F/C, Power
LSB	0: Timer
	1: Timer
	2: Timer
	3: Timer
	4: Power (0 = on, 1 = off)
	5: F/C
	6: ?
MSB	7: ?
Octet 4: Target temperature

Farenheit temperature directly recorded in ones compliment, LSB first, so 74 degrees farenheit = 0xAD. Celcius temperature is the same, but with 16 degress (0x10) subtracted, so 29 degress celcius = 0xF2

It's not entirely clear how the timer and celcius modes work, but I don't have any use case for reverse engineering them right now.