Skip to content

Protocol description of the serial communication channel of Samsung airconditioners.

License

Notifications You must be signed in to change notification settings

NamedP1ayer/Samsung-HVAC-buscontrol

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

17 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Samsung-HVAC-buscontrol

Purpose

Samsung airconditioners can be controlled by a wired remote controller (MWR-WE10). I was wondering if I could replace the wired remote controller with my own home automation system. Thats why I started to investigate how the communication works between the controller and the airconditioner. So far I reverse engineered the communication protocol and with the information I found I can already do some basic control of the airconditioning. The purpose of this repository is to complete the protocol details as much as possible to allow anybody else connect Samsung airconditioners to their own home automation systems.

Note that this does not describe the communication protocol of a wireless IR controller !!

Why did I fork this?

I'd like to use this repo as a start for a package which I could use for my home automation. To do this I will need to seperate the current scripts into a reusable section and the 4 applications.

Physical layer

The physical layer is a 2 wire RS-485 communications bus. Each unit has 2 such busses. The wires are labelled F1, F2, F3 and F4. F1 and F2 are used for communications with the outdoor unit, the F3 and F4 wires are used for the wired remote control.

Protocol

Serial communication settings used on the bus are 2400 baud, 8E1. The wired remote control is the master, the indoor units are the slaves. The wired remote control send commands as a message of 14 bytes. The units respond with a similar message with the same length. The protocol can be described as follows:

<start> <src> <dst> <cmd> <data: 8 bytes> <chksum> <end>

With:
Byte   Identifier   Comments
----------------------------
1      Start  : start of message (0x32)
2      Src    : Source address
3      Dst    : Destination address
4      Cmd    : Command byte
5-12   Data   : Data is always 8 bytes in length, unused bytes will be zero
13     Chksum : Checksum of message which is the XOR of bytes 2-12
14     End    : end of message (0x34)

In my case the address of the wired remote control is 0x84, the address of my 2 indoor units are 0x20 and 0x21. The master sends a command to a slave, the slave responds to the master. An example communication can look like this (all values are hex and xx represent any value):

Command:
32 84 20 53 xx xx xx xx xx xx xx xx xx 34
Reply:
32 20 84 53 xx xx xx xx xx xx xx xx xx 34

That was the easy part of the communication sniffing. The difficult part is to find out the meaning of all commands and the meaning of al bytes for each command/response.

Command tables

All values of the commands and bit group values in the following tables are in hexadecimal notation. The bits that are not described in the following tables are zero and the function of those bits are unknown.

Command A0

Change settings command, by exception the unit replies with command 50, all other commands are replied with the same command identifier. This is the command to be used when the settings of the HVAC unit needs to be changed.

Data byte Settings
1

bit 4-0 : 0x1a = blade swing up/down
0x1f = blade swing off

bit 5 : sleep
2 0
3 bit 4-0 : temperature setting

bit 7-5 : fan speed
0 = auto
2 = low
4 = medium
5 = high

4

bit 2-0 : mode
0 = auto
1 = cool
2 = dry
3 = fan
4 = heat

bit 5 : reset "clean filter" message
5

bit 7-0 : on/off
c4 = switch off
f4 = switch on

6 0
7

bit 3-0 : set blade position
0 = closed
1 = open smallest
2 = mid positions
7 = open max

bit 4 : set blade position
bit 5 : quiet mode
8 0

Command 52

This command is an information request. The bytes in the command are all zeroes, the reply to this command is described below:

Data byte Settings
1 bit 4-0 : set temperature - 9
2 bit 4-0 : room temperature - 9
3 temperature ?
4

bit 2-0 : fan speed
0 = auto
2 = low
4 = medium
5 = high

bit 7-3 : blade swing
1A = swing up/down
1F = blade swing off

5

bit 3-0 : 1 = wired control
2 = remote control

bit 4 : 1 = defrost on

bit 7 : 0 = power is off
1 = power in on

6 bit 4 : 1 = filter needs cleaning
7 0
8 temperature ?

Command 53

This command is an information request. The bytes in the command are all zeroes, the reply to this command is described below:

Data byte Settings
1 0
2 0
3 0
4 0
5

bit 7-0 : 0 = blade swing off
1A = blade swing up/down

6 0
7 0
8

bit 2-0 : mode
0 = auto
1 = cool
2 = dry
3 = fan
4 = heat

Command 54

This command is an information request. The bytes in the command are all zeroes, the reply to this command is described below:

Data byte Settings
1 contains value 21, meaning unknown
2

bit 3-0 : blade position when swing is off
0 = closed
1 = open smallest
2 = mid positions
7 = open max

bit 4 : 0 = blade swing off
1 = blade swing up/down

3 1E : meaning unknown
4 0
5 0
6 unknown
7 0
8 0

Command 64

This command is the temperature information command to the unit, the reply to this command is described below:

Data byte Settings
1 contains value 20 for command and reply, meaning unknown
2

command and reply: bit 0: used temperature for regulation
0 = use internal temperature
1= use wired remote temperature

3 command: wired remote temperature value high byte
reply: used temperature value high byte
4 command: wired remote temperature value low byte
reply: used temperature value low byte
5 reply: unit temperature value high byte
6 reply: unit temperature value low byte
7 0
8 0

The temperature in degrees is calculated as follows:

(<high byte> * 256 + <low byte> - 553) / 10

Other commands

Other commands seen on the link are: 63, 70, 71, 83, D1. The meaning of these commands and replies are unknown. Be careful with trying other commands because it is possible that there exist commands that have impact on the flash memory contents of the unit and may brick the memory contents of the unit.

Tools

To snif the communication protocol I used a Raspberry Pi and a RS485 -> TTL convertor which you can easily find on e-bay (search for: TTL RS485 Adapter 485 UART Seriell 3.3V 5 Volt Level Konverter Modul Arduino). Although I had the impression that the RS-485 driver was not working well on 3.3V, I replaced it with following driver : SN65HVD11D from Texas Instruments. I connected the 2 RS-485 wires from the indoor unit to the convertor, the convertor is connected to the Pi's rx and tx pins of the IO header. Be aware the the TTL levels must be 3.3V compatible, if they are 5V, the Pi's IO's will be damaged.

I made some Python scripts to display all the information coming from the serial comms in a meaningful manner. Pyserial is a required package.

Call the scripts with the -h option to obtain info on how to use it. serial_dump.py dumps all serial communication on screen, there is no transmission of commands. lib_serial.py is used by ac_control.py

In my setup, I use the wired remote control in combination with the Raspberry Pi which acts also as a master. This makes the communication a bit tricky. The wired remote control sends commands to all units in sequence and ends the communication with a command to destination address 0xAD, no reply is coming from any of the units on this one. I suspect the 0xAD address to be a broadcast address. Then there is a 300 ms gap in the communication and then it all starts over with other commands. During this gap the tools make use of the bus to send their own commands. The wired remote will not notice the presence of the other master but it will take over the changed settings of the untis when it polls their status.

About

Protocol description of the serial communication channel of Samsung airconditioners.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Python 100.0%