적용에 따른 책임은 각자에게 있습니다.
패킷을 잘못 보내게 되면 실내기 주소 충돌로 인해 에어컨이 동작하지 않을 수 있다.
HomeAssistant 카페에서 삼성 시스템 에어컨에 EW11을 연결하는 방법이 공유되어 시작하였다. 집에 설치된 에어컨 통신은 신통신이라 불리우는 통신 프로토콜을 사용 중인 것 같다.
무튼 F1, F2, V1, V2에 EW11을 연결하고, 9600, 8bit, 1, even으로 세팅하면된다.
집에는 유선 리모컨(상업빌딩에서 흔히 볼 수 있는 벽 컨트롤러)는 없고, IR리모컨과 WIFI KIT이 연결되어있다.
다른 설정이 안맞는지 하나의 패킷이 딱 끊겨서 수신되지 않는 경우가 있다. 수신 데이터가 끊어진다면 다음 수신 데이터와 붙여 사용하면 된다.
예시 패킷
32 0015 620000 200000 C013 A8 0240000142010118 CD4D 34
2자리씩 나누어 (2바이트씩) 설명하겠다.
| bytes | 데이터 바이트 | 설명 |
|---|---|---|
| 1~2 | 32 | 시작 바이트 |
| 3~6 | 0015 | 패킷의 사이즈, 2번부터 n-1까지의 바이트수/2. 아직 510자 넘는 패킷을 확인한 바는 없다. |
| 7~12 | 620000 | source |
| 13~18 | 200000 | destination. 실내기 번호 |
| 19~22 | C013 | 패킷의 종류 |
| 23~24 | A8 | 패킷의 번호 |
| 25~26 | 02 | 패킷 Payload에 포함된 상태 개수 |
| 27~n-4 | 40000142010118 | 패킷 Payload |
| n-3~n-2 | CD4D | checksum 패킷의 유효성 판단 |
| n-1~n | 34 | 마지막 바이트 |
우리집에 설치된 실내기는 총 4대이고 번호는 200000부터 200003까지로 확인 되었다.
WIFI KIT의 주소는 620000인 것으로 추정되고, 다른 주소도 확인되나 실외기나 다른 임의의 주소인 듯 싶다.
수신되는 단위로 판단한다면 시작 바이트 32 앞에 임의의 바이트(FFFDF1 등..)가 포함된다. 그렇기에 32부터 시작하는 부분을 찾아야 한다.
또한 마지막 바이트가 34이지만 패킷의 payload에 34가 포함될 수 있으므로 3~6번째 byte의 패킷 사이즈로 데이터를 잘라 확인하여야 한다.
10~11번째 패킷의 종류는 3종류까지 확인이 되었다.
| 데이터 바이트 | 종류 | 설명 |
|---|---|---|
| C013 | 제어 패킷 | WIFI KIT에서 제어하면 이 패킷이 수신됨 |
| C014 | 디바이스 리포팅 패킷 | 디바이스로부터 올라오는 패킷으로 판단 |
| C016 | 제어 패킷에 대한 응답 | C013 패킷에 대한 응답으로 단순 ack 보임 |
C016 패킷은 C013 패킷이 발생한 뒤 payload가 00으로 acknowledgement 만 하는 패킷으로 판단된다.
32 000E 200000 620000 C016 01 00 9BA2 34
온도 표기는 섭씨온도의 소수점 1자리까지 표현하고, 온도의 10배의 값을 16진수로 표기한다.
| 온도 | 데이터 바이트 |
|---|---|
| 18 | 00B4 |
| 19 | 00BE |
| 30 | 012C |
나타낼 수 있는 온도의 한계가 있는지는 모르겠다. 4 bytes이니까 그 안에서 모두 표현할 수 있을 것으로 보인다.
패킷의 25번째 byte부터,
4 bytes, 4 bytes 중 2번째 byte 값에 따라 남은 byte를 자르고, 이를 반복해서 보면 된다.
32 0039 200000 B300FF C014 41 0D 4000 00 4001 01 4002 01 4007 FE 4028 00 4035 00 4051 00 4059 00 4060 00 4211 0000 42D1 FFFF 42D2 FFFF 42D3 FFFF C813 34
이렇게 25, 26번째 byte 0D로 이후 상태값을 세어보면 13개이다.
위 예시는 첫번째 바이트가 4로 시작하는데, 하나의 패킷 안에서는 대개 첫자리가 동일하기 때문에 눈으로 판단하기엔 첫자리 기준으로 나눠서 판단해도 얼추 맞다.
2번째 바이트에 따른 값 바이트 사이즈는 아래로 추정된다.
| 2번째 바이트 값 | 값의 바이트 사이즈 |
|---|---|
| 0 | 2 |
| 1 | 2 |
| 2 | 4 |
| 4 | 8 |
| 6 | 20 |
앞에 자른 코드 데이터는 아래에 따라 구분되는 것 같다
| 코드 | 설명 |
|---|---|
| 4000 | 전원 |
| 4001 | 모드? 자동, 냉방, 제습, 송풍 |
| 4002 | 모드? |
| 4006 | 풍량. 자동, 미풍, 약풍, 강풍 |
| 4007 | 롱바람 관련. |
| 4011 | 풍향. 상하바람 |
| 4043 | 청정 |
| 4060 | 무풍 관련. |
| 407E | 풍향. 좌우바람 |
| 4111 | 자동건조 설정 |
| 4201 | 설정온도? |
| 4202 | 설정온도? |
| 4203 | 실내온도 |
찾아내야할 상태값은 전원, 모드, 풍향, 풍량, 실내온도, 설정온도, 무풍, 청정, 롱바람, 필터, 자동건조, 전력소모량 일 것 같다.
32 0015 620000 200000 C013 02 02 4000 01 4201 0118 3A9B 34
이 패킷은 실내기 1번에 제어하는 패킷이며 전원을 01, 설정온도를 0118로 설정하는 패킷이다.
모드/온도을 조절할 때에는 전원값을 같이 포함하는 것 같다.
마지막 checksum은 CRC16-XMODEM 알고리즘에 의해 생성된다.
시작 바이트와 패킷의 길이(1~6byte)를 빼고 payload까지를 4 bytes 문자열을 생성한다.
620000 200000 C013 02 02 4000 01 4201 0118 => 3A9B
이로써 패킷의 패턴은 모두 분석이 되었다.
패킷을 생성해서 전송해보니, 패킷번호가 동일하거나 이전에 수신받은 패킷번호 보다 작으면 무시된다. (차이가 많이나면 성공하는 듯?)
그래서 EW11로만 명령을 내린다면 패킷번호를 단순히 하나씩 올리면 되겠지만, ST앱과 같이 사용한다면 수신된 마지막 C013 패킷의 패킷번호과 잘 맞춰 사용하여야 할 것이다. (EW11만을 위해 다른 주소를 부여해도 되는지 모르겠다. 620001)
혹은 다른 무언가로 패킷번호가 다시 0부터 시작 될 수도? 시간 단위나...
패킷의 송신이 성공한지는 C013 패킷을 송신한 다음 C016 패킷을 수신받는 것을 확인하여야 할 것 같은데, 아직은 패킷번호 오류말고는 전송이 실패하는 경우는 매우 드물기 때문에 현재는 C013 패킷을 생성하여 전송하는 것까지만 구현을 하였다.
켜짐 상태와 같이 명령을 내려야 할 상태값들이 더 있을 수 있으니 필요하다면 추가 분석해야한다.
그리고 상태를 읽어오는 패킷은 아직 확인이 되지 않았다. ST앱에서도 새롭게 상태를 조회하는 건 없는 것 같고, WIFI KIT에서 보낸 데이터를 클라우드 서버에 저장하고 서버에서 계속 조회하는 것 같다. (아마 실외기 당 연결가능한 실내기가 최대 64대인가 그럴것이고 실외기도 여러 대 연결이 가능하니, RS485로 모든 실내기를 상태조회하면 네트워크 상태가 만만찮을테니 상태조회같은 기능은 없을 것 같다.)
아직 초여름(?)이기에 에어컨을 가동하지 않아 본격적으로 가동하는 시기가 오면 좀더 다양하게 분석해 볼 수 있을 것 같다.