이번 포스트는 지난 그렉스 열교환기 포스팅 이후 이어지는 글이다.

지난 번에 Fibaro Smart Module로 2개를 24VDC 전원으로 연결하도록 하였다. 1개에 2개의 스위치가 지원하기에 3 Level 조절을 위하여 2개의 모듈을 사용했었다.

스위치박스가 넓은 특수 규격이었기에 Fibaro 모듈 2개를 넣고도 충분한 공간이 되었다. 이번에 창고행이 될 5구 스위치가 가능한 모듈이 생겨서 교체해보았다.

5구 스위치는 Heltun사의 HE-RS01 quinto 스위치이다. 구할 수 있는 쇼핑몰이 한정적이고, 가격이 상당하기 때문에 불용자재로 있기엔 아까워서 Fibaro 모듈 2개를 대체하기로 했다. (Fibaro 모듈 2개 값이 더 비싸긴하다.)

모듈 규격이 유럽형에 맞춰져 있어서 KS스위치박스에는 맞지 않을 수 있다.

기존에 설치해두었던 Jung 스위치도 위/아래 모두 스위치가 가능한 4버튼으로 바꾸어 교체하였다.

기존 설치에서 크게 달라질 구성은 없어서, quinto 스위치 모듈의 1구는 비워두고, 2,3,4구에 열교환기의 L/M/H 선을 연결했다.

ER로 작성해둔 동작관련 Rule이다. M, H 단이 동작하기 위해선 이전 단도 모두 On이 되어야 한다.
H가 켜지면 L, M이 켜지도록 하였고 M이 켜지면 L이 켜지도록 하였다.
1구버튼이 눌리면 끄는 것으로 해서 모든 스위치를 끄도록 하였다.

  rule("living.vent.master:central.keyId == 1 => living.vent.L:off")
  rule("living.vent.H:isOn => || living.vent.M:isOff >> living.vent.M:on")
  rule("living.vent.M:isOn => || living.vent.L:isOff >> living.vent.L:on")
  rule("living.vent.L:isOff => || living.vent.M:isOn >> living.vent.M:off; \
                               || living.vent.H:isOn >> living.vent.H:off; \
                               || bathroom.fan:isOn >> bathroom.fan:off; \
                               || shower.fan:isOn >> shower.fan:off")

HC3에 이것저것 많이해두어서… 처리량이 많아서 그런 것으로 생각하고 있었다. 하지만 QuickApp들을 하나씩 중단을 해도 CPU 사용률은 동일해서 이상하다고 생각했다.

아마도 기기 온도 상승으로 인한 쓰로틀이 걸리면서 CPU 사용률이 올라가는 것으로 확인되는 것 같다.

지금 HC3은 신발장에 설치가 되어있다. 여기에는 Unifi사의 UDM, 스위치와 NAS도 설치되어있다. 신발장을 닫아두면 신발장 내부 온도가 36도까지 올라간다. 문을 열때면 후끈한 열기가 느껴진다. (신발 건조기...)

시간을 늘려 그래프를 보니 샘플링으로 인해 CPU가 100%까지 치솟는 것은 보이지는 않지만 실제로는 100%로 치솟는다. 두 번째 그래프는 6/16일 자정 이후부터는 온도와 상관없이 idle한 상태인데, 이때에는 모든 QuickApp을 중단해두었다.

초기에 신발장에 설치할 때 여름을 대비해서 아래쪽에 쿨러를 달아야하나 싶었는데, 지금이라도 달아야할지… 당분간은 문을 열어두어야할 것 같다.

적용에 따른 책임은 각자에게 있습니다.
패킷을 잘못 보내게 되면 실내기 주소 충돌로 인해 에어컨이 동작하지 않을 수 있다.

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바이트씩) 설명하겠다.

우리집에 설치된 실내기는 총 4대이고 번호는 200000부터 200003까지로 확인 되었다.
WIFI KIT의 주소는 620000인 것으로 추정되고, 다른 주소도 확인되나 실외기나 다른 임의의 주소인 듯 싶다.

수신되는 단위로 판단한다면 시작 바이트 32 앞에 임의의 바이트(FFFDF1 등..)가 포함된다. 그렇기에 32부터 시작하는 부분을 찾아야 한다.
또한 마지막 바이트가 34이지만 패킷의 payload에 34가 포함될 수 있으므로 3~6번째 byte의 패킷 사이즈로 데이터를 잘라 확인하여야 한다.

10~11번째 패킷의 종류는 3종류까지 확인이 되었다.

C016 패킷은 C013 패킷이 발생한 뒤 payload가 00으로 acknowledgement 만 하는 패킷으로 판단된다.

32 000E 200000 620000 C016 01 00 9BA2 34

온도 표기는 섭씨온도의 소수점 1자리까지 표현하고, 온도의 10배의 값을 16진수로 표기한다.

나타낼 수 있는 온도의 한계가 있는지는 모르겠다. 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번째 바이트에 따른 값 바이트 사이즈는 아래로 추정된다.

앞에 자른 코드 데이터는 아래에 따라 구분되는 것 같다

찾아내야할 상태값은 전원, 모드, 풍향, 풍량, 실내온도, 설정온도, 무풍, 청정, 롱바람, 필터, 자동건조, 전력소모량 일 것 같다.

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로 모든 실내기를 상태조회하면 네트워크 상태가 만만찮을테니 상태조회같은 기능은 없을 것 같다.)

아직 초여름(?)이기에 에어컨을 가동하지 않아 본격적으로 가동하는 시기가 오면 좀더 다양하게 분석해 볼 수 있을 것 같다.

새로 마련한 보금자리에 그렉스 바닥열교환기가 설치되어있다. 다른 공동주택에 설치되어있는 전열교환기와 유사한 기능을 하지만 열소자가 없고 겨울철 바닥의 잔열을 이용해 외부 공기를 데워 실내의 공기와 교환하는 기기이다.

대림의 다른 아파트는 월패드에서 열교환기를 제어할 수 있다고 하지만, 우리집은 그렇지 않았다.

대림의 벽스위치와 동일한 룩앤필의 컨트롤러 제품이다. 디자인 상을 받았다고는 하지만 이 컨트롤러는 비프음도 크고 동작 후 끄려면 전원을 길게 누르거나 전원을 두세번 눌러야 한다.

천장에 달린 열교환기를 열어볼 방법이 없어서 (열어보려면 커버를 열어야 하는데 열 방법이 천장에서 탈착할 방법밖에 보이지 않았다.) 포기하려던 차에 st카페에서 기판의 통신단자를 확인할 수 있는 글이 올라와서 작업하였다.

5개의 핀과 2개의 핀이 있는데 2개의 핀은 dry out으로 화장실에 설치된 환풍기를 동작하는 dry contact 접점이다. 5핀이 컨트롤러 전원과 본체와 통신하는 단자들인데, 전원(+, -)과 풍속(L, M, H)이다. 위 사진 기준으로는 (H, M, L, -, +) 순서이다.
전원은 12VDC이고 풍속은 5V wet contact 접점으로 1단 일 때 L 접속, 2단 일 때 L,M 접속 이런식이다.

일단 12VDC 전원으로 동작하는 iot릴레이를 찾기 어려워, 만능급인 fibaro smart module을 설치하였다.
fibaro smart module은 220VAC에서도 동작하지만 24V~30VDC에서도 동작한다. 화장실 환풍기 dry contact로 포설된 남은 utp가닥으로 24VDC를 공급하기로하고 더블 모듈을 2개 설치하여 1,2,3단으로 릴레이하도록 하였다. smart module은 220VAC, dry, wet 접점 모두 릴레이 가능하기에 정말 만능이다.

화장실 환풍기는 이미 iot 스위치가 연결되어있기 때문에 여기의 환풍기 dry contact는 사용하지 않았다. 여기서도 제어하려면 모듈 3개가 필요하다. 환풍기는 자동화를 통해서 별도로 제어하려고 한다.
샤워를 할 때이면 전열교환기는 동작중이지만 환풍기 동작을 멈추고 싶기 때문에 자동화로 제어하는게 나았다.

결선도 출처: domotique store

릴레이 설치로 인해서 본래의 컨트롤러는 이미 기능을 상실하였기에 컨트롤러를 빼고 jung 스위치를 설치하였다.

KS규격의 복스이기에 지난번 포스팅 처럼 세로로 설치하는 꼼수가 필요하다. 두 개의 스위치이기에 1단, 2단만 직접 컨트롤이 가능하고 윗칸에 붙이려는 버튼제품에 자동화로 3단을 적용할 예정이다.

옆쪽에는 jung 조명스위치가 가로로 두 줄로 설치되어있어서 이렇게 세로로 설치하는 것과 언밸런스하여 흰색 무광으로 튀지 않도록 할 예정이다. 맞지 않은 가로 간격과 미세하게(?) 다른 하단 정렬이 거슬리긴한다. 초기에 온도컨트롤러는 변경을 포기하였는데, Nest로 교체를 할 걸 그랬다.

19/20년에 ST카페에서 zigbee/zwave 도어락이 유행하였다.
우선 먼저 떠오른 것은 통신사 연동패키지에서 나온 zwave 연동 도어락이었다. 게이트맨과 samsung sds 제품이 있었으나 게이트맨은 연동팩을 구하기 어려웠고, samsung sds 연동 모듈은 대리점을 통해서 구할 수 있었다.
다만 zwave는 주파수 문제가 있기 때문에, 한국 st 허브가 출시되기 전에는 사용할 수 있는 방법은 open zwave로 연동해서 사용해야했다. (지금은 한국 st허브가 출시되었으니 직접 연결이 가능하겠다.)
사용했던 HA의 zwave stick의 특성을 타는 것인지 연결이 안정적이지 못해서, 새로 이사한 집에는 zigbee 도어락으로 교체하였다.

사용해보니 zwave버전은 zwave의 lock with code(?) 표준을 구현하여서 열림, 키코드 등록이 가능하고 zigbee버전은 wifi 모듈일 때 키코드 등록이 가능하지만 zigbee 모듈로 연동하면 키코드 등록이 불가능하다. (도어락에서 기본적으로 복수의 키코드를 지원하지 않기 때문일지도, zwave 도어락도 zwave 명령을 통해 등록이 가능했었음)

사용하는 모델명 SHP-DP960, 지문인식과 비상키(열쇠) 개방이 되는 고급라인 제품이다. 이 제품은 wifi연결이 기본이나 zigbee 모듈을 통해 연결이 가능하다.

현재 zigbee2mqtt에는 정식 연동이 안되는 제품이다. 도어락이 보통 국가의 안전/보안에 대한 가이드라인을 맞춰야하고 설치규격에 맞춰 나라별로 출시하기에, 해외에서는 또 이러한 도어락을 잘 안쓰는 듯하기에 아직 지원은 없는 듯하다.
최근 st와는 연동이 되는 듯 해보이지만, 나는 HC와 z2m만 사용 중이기에 연동을 진행하였다.

zigbee-herdsman, zigbee-herdsman-converters 코드에 수정해야할 부분은 아래와 같다. 수정한 부분만 발췌했다.

// in cluster.js
// closuresDoorLock > commands
samsungSdsUnlock: {
    ID: 31,
    response: 1,
    parameters: [
        {name: 'code', type: BuffaloZclDataType.LIST_UINT8},
    ],
},

// in devices.js
{
    fingerprint: [
        {type: 'EndDevice', manufacturerID: 3, endpoints: [
            {ID: 1, inputClusters: [0,1,3,4,5,9,257], outputClusters: [25]},
        ]},
    ],
    zigbeeModel: ['SHP-DP960'],
    model: 'SHP-DP960',
    vendor: 'Samsung SDS',
    description: 'Samsung SDS fingerprint lock',
    supports: 'lock/unlock, battery',
    fromZigbee: [fz.samsung_lock, fz.battery],
    toZigbee: [tz.samsung_lock],
},

// in toZigbee.js
const options = {
    'Samsung SDS': {
        manufacturerCode: 0x0003,
    },
...

samsung_lock: {
    key: ['state'],
    convertSet: async (entity, key, value, meta) => {
        await entity.command('closuresDoorLock', 'samsungSdsUnlock', {'code': [16, 4, 49, 50, 51, 53]}, { manufacturerCode: 0x0003 });

        return {readAfterWriteTime: 200};
    },
    convertGet: async (entity, key, meta) => {
        await entity.read('closuresDoorLock', ['lockState']);
    },
},

// in fromZigbee.js
samsung_lock: {
    cluster: 'closuresDoorLock',
    type: 'raw',
    convert: (model, msg, publish, options, meta) => {
        const controlBy = msg.data[3];
        const stateCode = msg.data[4];
        let state = '';
        let lock_state = '';
        let operated_by = '';
        let id = ''
    
        switch (stateCode) {
            case 1:
                state = 'MODIFY LOCK CODE';
                lock_state = 'lock code modified';
                break;
            case 2:
                state = 'UNLOCK';
                lock_state = 'unlocked';
                if (controlBy == 0) {
                    operated_by = 'By Lock Code'
                } else if (controlBy == 4) {
                    operated_by = 'By Fingerprint'
                    id = 'finger-' + (msg.data[5] - 30);
                } else if (controlBy == 3) {
                    operated_by = 'By RFID Tag'
                    id = 'rfid-' + (msg.data[5] - 2);
                } else if (controlBy == 5) {
                    operated_by = 'By Bluetooth'
                } else if (controlBy == 2) {
                    operated_by = 'By Manual'
                } else if (controlBy == 1) {
                    operated_by = 'By Key'
                }
                break;
            case 3:
            case 4:
            case 5:
                state = 'ADD RFID Tag';
                lock_state = 'rfid tag added';
                operated_by = '';
                id = 'rfid-' + (msg.data[5] - 2);
                break;
            case 6:
                state = 'DELETE RFID Tag';
                lock_state = 'rfid tag deleted';
                operated_by = '';
                id = 'rfid-' + (msg.data[5] - 2);
                break;
            case 7:
                state = 'LOCK';
                lock_state = 'locked';
                method = 'Ansimi';
                break;
            case 8:
                state = 'LOCK';
                lock_state = 'locked';
                operated_by = 'Unknown';
                break;
            case 9:
                state = 'UNLOCK';
                lock_state = 'unlocked';
                operated_by = 'By Key';
                break;
            case 13:
                state = 'LOCK';
                lock_state = 'locked';
                operated_by = 'By Key';
                break;
            case 14:
                state = 'UNLOCK';
                lock_state = 'unlocked';
                operated_by = 'From Inside';
                break;
            case 10:
                state = 'LOCK';
                lock_state = 'locked';
                operated_by = 'Auto';
                break;
            case 16:
                state = 'UNLOCK';
                lock_state = 'unlocked';
                operated_by = 'Zigbee';
                break;
            case 33:
                const type = msg.data[5];
                if (type == 4) {
                    if (msg.data[6] == 16) {
                        state = 'DELETE ALL Fingerprint';
                        lock_state = 'all fingerprint deleted';
                    } else if (msg.data[6] == 15) {
                        state = 'DELETE Fingerprint';
                        lock_state = 'fingerprint deleted';
                        id = 'finger-' + (msg.data[7] - 30);
                    } else if (msg.data[6] == 14) {
                        state = 'ADD Fingerprint';
                        lock_state = 'fingerprint added';
                        id = 'finger-' + (msg.data[7] - 30);
                    }
                } else if (type == 3) {
                    state = 'DELETE ALL RFID Tag';
                    lock_state = 'all rfid tag deleted';
                }
                break;
        }
            
        return {
            state,
            id,
            operated_by,
            lock_state
        };
    },
},

UNLOCK만 가능하고, 디바이스로부터 리포트 되는 상태에서는 unlock/lock 상태는 오류가 없지만 키 등록, 열쇠로 열림 등에 대한 정보는 아직 정확하지 않은 것으로 알고 있다.

내가 수정한 코드는 꽤 예전 버전(12.0.224)에 수정했기에 최신버전에서는 맞지 않을 수 있다.
디바이스를 등록하고 나서 디바이스의 모델명을 불러와야하지만 아직 불러오지 않는 문제가 있다. (unknown) 모델명을 불러오는 방법은 확인되었으나, z2m에서 다른 패킷에서 모델 정보가 리포트되면 어떻게 해야할지 모르겠어서 아직 적용되지 않았다.

코로나로 인해 실제 출시는 좀 밀려서 하반기에 출시가 되었다. 구매가 가능한 시점에 바로 구매해서 설치해서 사용 중이었다.

기본 베이스 모듈은 Hue의 Tap 스위치와 동일하다. 이 계열로 그간 나온 4버튼 Friend of Hue 제품이 다 같은 enocean 사의 GreenPower 스위치 제품을 사옹한다. Niko 사에서 나온 4버튼 무광 화이트 버튼을 눈여겨 보고 있다가 LS990과 같은 라인으로 출시되어 바로 구매했었다.
배터리 없이 클릭으로 에너지를 발생하여 10여년정도 사용가능하다고 한다. 다만 버튼 타격감은 호불호가 있는듯하다. (개인적으로는 불호이다.)

하지만 Jung 스위치가 유럽형 규격에 맞춤인데, 이 제품은 스위치박스 없이 사용할 수 있는 제품이다. 기본적으로는 Hue Bridge와 연동하여 Hue 조명을 제어할 수 있고, zigbee2mqtt 등에 연결하여 확장성 있게 사용할 수 있다.

우리집은 부분 인테리어를 하였기에 일명 까대기를 하지 않아 벽면의 스위치박스는 한국(KS) 규격이다. KS규격 1갱에도 유럽형 스위치 1갱은 삽입이 가능하다. 하단부나 상단부를 잘 맞춰 볼트를 잠그면(유럽형은 M3이기 때문에 기본적으론 볼트 규격이 맞지않지만...) 스위치를 사용할 수 있다. 하지만 KS 규격은 세로가 긴 직사각형 규격이기에 빈 공간이 남는다. 이 부분은 도배할 당시에 잘 가리면 커버가 가능하다.

그렇게 처리한 KS 규격 스위치 박스에 심은 Jung 스위치.
아래 빈공간에 나무 조각을 넣어 고정시키고 퍼티로 평탄화 후, 도배를 하였다.

이런 방법이 아니라면, 2갱 프레임에 Jung Friend of Switch(JFOH)를 사용하여 마감하려고 구매를 했던 것이다.

이렇게 빈 공간이 보이게 될 텐데 여기를 가리기 위해 JFOH를 사용한다. (수급이 지연되어 몇 개월째 저렇게 있다.)

이렇게 설치하면 감쪽같이 2갱 스위치가 설치된 장소인 것처럼 보인다. 아랫부분이 일반 스위치이고, 윗부분이 JFOH 제품이다.
외관 상으론 같은 스위치 제품이 설치된 것으로 보이지만, 눌러보면 다르다는 것을 확인할 수 있다. Jung 에서도 기존 스위치와 동일한 방식임을 생각할 수 있도록 디자인했다고 본 것 같다.
모르는 사람이 보면 일반 스위치처럼 아래 부분을 눌러 조명을 켠다고 생각할 수 있을 것이다. 아래쪽 버튼으로만 켬/끔을 사용하고 윗쪽 버튼은 활용하지 않으면 일반 스위치처럼 UX를 동일하게 사용하는 셈이다.

여기는 타일벽이라 타일을 새로 하지 않는 이상 이렇게 밖에 사용할 수 없고, 도배로 처리못한 방에도 설치를 하였는데 아래처럼 색을 주었다.

다만, JHOF는 흰색 Duroplastic 제품 뿐이기 때문에 추가 비용을 지불해야했다. 규격은 enocean 제품과 동일하기에 enocean용으로 몇 년전에 출시한 컬러 제품을 구매하여 커버만 교체하였다. 커버만 따로 구매 가능하면 좋을텐데 그렇지 않다.
이 제품은 Stainless가 lacquered 처리된 제품이기에 일반 스위치와는 색상/질감차이가 난다.

여기는 방에 설치된 에어컨을 켜고 끌 수 있도록 할 예정이다.

지금은 zigbee2mqtt에 연동하여 사용하고 있다. 버튼을 몇 번 누르면 coordinate가 뻗는 문제가 있었지만 coordinate를 업그레이드하고 난 뒤로 문제가 발생되지 않았다. 그런 문제가 발생한 정확한 원인은 알 수 없었다.

음성알림용으로 많이 사용하는 구글홈미니도 있지만 구글 홈은 다른 쓸 용도가 없어서 켜지도 않고, 갤럭시 홈 역시 별로 쓸모는 없지만 IR기능을 아주 가끔 사용할 일이 있어서 켜두고 있다.
다른 ST허브가 있다면 WebCore 등을 이용해서 음성알림을 설정할 수 있겠지만, ST도 없고 이제 왠만한 자동화는 Home Center3에서 처리되고 있기 때문에 처분했던 ST허브를 다시 들이기는 싫었다.

ST는 ST허브가 없어도 클라우드에서 충분히 동작한다는 것이고, 갤럭시 홈미니는 허브기능없이 클라우드 장비이기도 하다.

삼성이 기존의 클래식에서 존재하던 로컬 기능들을 대부분 정리하고, C2C API를 공개하고 개발을 장려(?)하는 분위기 때문에 찾아보았다.

참고)
https://smartthings.developer.samsung.com/docs/api-ref/st-api.html
https://smartthings.developer.samsung.com/docs/api-ref/capabilities.html

아직 Preview 버전인 것 같고 앞으로 또 어떻게 될 지 모르겠다.

https://account.smartthings.com/tokens 여기서 ST 이용 계정으로 로그인을 하고, Token을 생성한다.
Generate New Token을 선택하고 device에 명령만 내리면되기 때문에

이미지에서 보이는 "Devices" 부분을 전체 선택하고 생성하면된다. 버튼을 누르고 나면 나오는 토큰은 복사해두고 노출되지 않게 저장해둔다.

이제 갤럭시 홈 미니 device id만 알면 말을 시킬 수 있다. ide 접속을 통해서 id를 알아 낼 수 있겠지만, 없다면 API로 알아내어야 할 것이다.

curl https://api.smartthings.com/v1/devices -H 'Authorization: Bearer {발급한 access token}'

요청에 token을 header로 보내야하기 때문에 curl을 사용한다. 혹은 GUI 툴을 이용해서 하면 될 것이다.
이렇게 요청해서 응답한 내용에서 나의 갤럭시 홈 미니 device id를 찾아내면 된다.

curl -H 'Authorization: Bearer {발급한 access token}' -H 'Content-Type: application/json' 'https://api.smartthings.com/v1/devices/{갤럭시홈미니id}/commands' -d '{
  "commands": [
    {
      "component": "main",
      "capability": "speechSynthesis",
      "command": "speak",
      "arguments": [
        "안녕하세요? 저는 갤럭시 홈 미니입니다."
      ]
    }
  ]
}'

이런식으로 요청을 보내면 갤럭시 홈 미니가 말을 하기 시작한다.

Home Center의 lua에서 http request를 보낼 수 있기 때문에 이를 이용해서 QuickApp을 만들 수도, 간단히 ER에서 자동화 로직에도 추가가 가능할 것이다.

여름이 다가왔는데, 아직도 HC에서 미완성인 삼성가전 연동으로 인해 삼성에어컨을 직접 연동하기 위한 작업을 하다가 곁들어 작업한 내용이었다.

예전에 사용하던 샤오미 도어센서들이 몇 개 쌓어있는데 이걸 다시 활용해보려고 zigbee2mqtt를 해보기로 했다.
샤오미 게이트웨이가 가끔 wifi 문제도 있고, 연동하고 있는 Hubitat과 Mi connector 간의 지연현상도 간헐적으로 보여서(보통 Hubitat의 문제다) 게이트웨이는 빼버리고 zigbee 허브류 중에 가장 호환성이 좋은 zigbee2mqtt를 선택했다.

덕분에 연동할 길이 없어서 그냥 서랍 속에 잠들고 있던 Trust ZYCT-202 제품도 사용할 수 있게 되었다. Aqara Opple버튼도 모든 버튼 트리플 클릭까지 사용가능하다.

zigbee2mqtt 설정은 인터넷의 다른 글들을 참고하고, HA와는 연동하지 않았다. 그래서 GUI로 사용가능한 Zigbee2MqttAssitant를 설치하여 GUI로 간단히 보고 있다.

HC3 최신 펌웨어에서 mqtt client가 추가되어서 QuickApp으로 연동을 작업해보았다.
QuickApp 제작에 참고했던 것은 jgab의 Children Of Hue 2 버전이다.

5.030.45 에서 추가된 DeviceController 타입으로 연동을 주관하는 Parent 디바이스를 만들고, Child 디바이스를 추가하는 형태로 작업하였다. 작업이 완료될 때쯤 Children Of Hue 3버전은 DeviceController를 사용하지 않았다... (헉😱)

연결한 device별로 action이 다르기 때문에 device 별로 다르게 작업을 해주어야 하는데, QuickApp의 Child 디바이스 구현이 디바이스 타입별로 하나만 가능하다.

    self:initChildDevices({
        ["com.fibaro.binarySwitch"] = MyBinarySwitch,
    })

QuickApp 초기화 때, 아래와 같이 피바로 타입에 구현한 구현체를 Table로 등록하는데, table이기 때문에 하나의 피바로 타입에 하나의 구현체만 가능하다.

처음 Trust 디머버튼과 Opple 버튼을 각각 구현했다가 제대로 동작하지 않아서, 저 부분에서 결국 하나의 타입만 가능하다는 것을 알았다. (jgab의 QD는 별도의 정의 테이블에서 자동으로 등록하기 때문에 문제가 될 지 몰랐다.)
아마도 이러한 이유에 있어서 jgab도 DeviceController를 사용하지 않는 것 같다.
관련 포스트가 여기있다.

DeviceController를 사용하면 parent를 제거할 때 자동으로 삭제가 된다.

그리고 여젼히 문제가 되는 부분이 있는 Home Center 3의 웹 화면에서는 긴 문자열을 입력할 수 없다. 디바이스의 이름이나 variables의 긴 문자열은 입력이 불가능하다. api나 lua를 통해서만 가능하다.
개발 과정에서 child 정보를 수동으로 수정할 필요가 생겨 해보려고 했더니 되지 않았다.

jgab의 QD 매커니즘을 그대로 유지한 채로 수정하지 않았지만, 버튼과 도어 센서을 연동했다.
RemoteController 타입에 속하는 Trust 디머스위치와 Opple 버튼 2가지인데, 이에 대한 연동을 하나의 클래스에서 모델명에 따라 분기하여 로직을 적용했어야 했다.

나중에 HC3에서 직접 zigbee가 지원되어도, 표준 profile을 적용한 제품만 지원한다거나 커스텀한 디바이스들을 지원하지 않는다면 zigbee2mqtt를 사용하여 연동하는 방법을 최종안으로 고려중이다.

이렇게 연동한 도어센서는 자동창문 열림위치 판단에 사용할 예정이다.

HC2를 사용해보지 않았기 때문에, 기존의 lua scene이 어떻게 작성되었는지 몰랐다. 우선 HC3에서 scene을 적용시켜보려고 구글링으로 걸리는 몇 가지를 적용시켜보려고 했다.
하지만 정상적으로 동작하지 않았고, 이유를 찾아보았다. (문서를 세심히 살폈다면 바로 해결됐을텐데..)

scene에는 condition/trigger가 있고, 그에 따라 동작시킬 action이 있다.

HC2용 lua scene에는 trigger이 따로 없었으며, trigger되는 항목을 선언하면 action에서 원하는 컨디션인지 체크하고 action이 동작될 수 있도록 했던 것 같다.
Trigger를 선언하는 것은 scene의 헤더부에 작성하도록 되어있다. scene 코드를 보면 아래처럼 되어있는데

--[[
%% properties
10 value
%% events
%% globals
--]]

-- the action is descripted below.

lua의 주석구문을 활용하여 scene 코드 상단에 기술하도록 변칙적으로 작성하였다.
위의 properties, event, globals는 속성, 이벤트, 글로벌 변수 변경에 대해 트리거링 되는 것이다. 그리고 10번 디바이스의 value property가 변경될 때 트리거링 된다.

HC3에는 저런 변칙적인 것을 빼버렸다.
scene 에디터에서 condition/trigger 와 action을 작성하는 에디터가 나뉘어져있다.
전체 properties, event, globals에 대한 트리거링은 없어진 것 같다. 트리거링 조건도 같이 지정할 수 있고, trigger인지, condition인지도 지정이 가능하다.
Trigger이면 변경이 되고, 조건이 만족해야만 action이 실행되고, condition이면 다른 trigger에 의해 동작을 할 때 조건이 만족해야 action이 실행된다.

WebCore에서의 switch "changed to" on/off (trigger) 와 switch "is" on/off (condition)의 차이겠다.

value 변경에 대해서 기존엔 모든 변경에 반응했지만 지금은 비교조건이 반드시 필요한 것으로 확인된다.

{
    type = "device",
    id = 24,
    property = "value",
    operator = ">=",
    value = 1,
    isTrigger = true
}

property, operator, value 가 존재하고 조건이 만족해야지만 action이 실행되는 것으로 확인된다. 값에 따라 0보다 크거나 같다고 하면, 모든 변경에 대해 반응될 수 있기 때문에 이런식으로 사용할 수 있을 것 같다.

조건이 정의에 포함되면서 서술하는 양이 많아졌고 action은 간단하게 서술할 수 있게 되었다. 다만 경우에따라 예전처럼 모든 변경에 대헤 정의할 필요가 있다면 condition을 정의하기 애매해질 수도 있다.

action에 대해서도, 2에서는 lua가 동작할 수 있는 곳이 scene이기 때문에 모든 작업이 여기서 가능했었다. 하지만 3에서 QuickApp이 추가되면서 scene에서는 할 수 없는 것이 생긴 것 같다.
HC3의 scene에서는 net.HTTPClient가 사라졌다. QuickApp에서는 사용할 수 있으니 scene에서도 QuickApp을 통해서 작업해야할 부분이 생긴 것 같다. (모든 것이 QuickApp에서 가능할 수도 있으나, 아직 타 device의 변경에 대한 트리거 되는지 모르겠다.)

Fibaro HomeCenter 3를 받고 사용하고 있던 Hubitat을 안전히 Migration 하기 위해서, 각을 세우고 있다. Zigbee와 Z-wave로 연결되는 디바이스들은 별 문제가 되지 않지만 IP로 연결되는 디바이스들이 문제이다.

ST/HE에서는 이러한 디바이스들을 지원하기 위해 Virtual Device가 있으며, 이러한 디바이스를 생성하기 위해 SmartApp도 있다. 보통 SmartApp은 디바이스 서비스 사업자의 클라우드 서비스에 연동할 수 있도록 계정 연결을 하고 Virtual Device를 생성하도록 작업되어 있다.

ST/HE의 SmartApp과 Device를 간단히 모식도를 그리면 이렇다. SmartApp은 Child SmartApp을 만들 수 있으며, SmartApp은 Device를 가질 수 있다. SmartApp에서 디바이스를 생성할 수도 있고, 삭제할 수도 있으며 attribute뿐만 아니라 이름 등의 정보도 업데이트가 가능하다.
심지어 SmartApp에서 디바이스 목록을 보고 디바이스를 선택하게 된다면 zigbee/z-wave 디바이스들의 attribute에 접근가능하고, 업데이트도 가능하다. (Homebridge 등의 SmartApp이 이러하다.)

ST/HE에서의 Device와 SmartApp은 샌드박스 안에 있는 개념이고, 허브의 글로벌한 값을 가져올 순 없는 것으로 알고 있다. 쉽게 볼 수 있는 예로 WebCore에 전역 변수가 있지만, WebCore에서만의 전역변수이고 WebCore가 아닌 다른 자동화 로직에서 절대 참조할 수 없다. HC3은 이러한 개념이 없다고 봐야하며, 어디서나 Global에 저장한 값을 가져올 수 있다. 또한 어디서나 디바이스의 ID만 안다면 다른 디바이스 가져와 사용할 수 있는 것으로 확인된다.

HC3에는 SmartApp은 없다. HC에는 Device의 영역이 한계가 없기 때문에 그런 것 같다. 제공되는 Plugin도 Device로 추가되지만, 실제적으론 SmartApp과 유사한 동작을 하는 것들이 있다. 마찬가지로 QuickApp에서 디바이스간의 통신도 가능한 것 같고, Scene의 Action으로 구성될 필요가 없어 보인다.

QuickApp 이라는 이름에서도 이것이 App인지 Device인지 헷갈리는 부분이다.

아직 HC3의 공식적으로는 QuickApp을 GUI 설정화면 이외에서 생성하는 방법은 없는 것으로 보이며, Fibaro 포럼의 jgab이라는 유저가 올린 fibaroapiHC3.lua 코드를 참고하면 api로 생성하는 방법이 있다. 포럼의 본 글은 HomeCenter 브라우저 콘솔에서 코딩하지 않도록 하기 위한 SDK 코드와 QuickApp을 잘 만들기 위한 팁들을 공유하고 있는 것이다.
일부분만 봤지만 HC3의 웹 대시보드 역시 HC3 Rest API를 이용해서 구성되어있는 것 같기 때문에 QuickApp API가 문서화만 되지 않았을 수 있다.

아래 설명부터 QD라고 축약해서 사용할 것인데, 이는 QuickApp Device의 축약어이다. QA는 Question and Answer 로 쓰이기 때문이다. (jgab도 그런 이유에 QD라고 쓴다고 한다.)

현재 글을 작성하는 시점으로 fibaroapiHC3.lua 최신 버전 v0.63에서 보면

  local function createQuickApp(args)
    local d = {} -- Our device
    d.name = args.name or "QuickApp"
    d.type = args.type or "com.fibaro.binarySensor"
    local body = args.code or ""
    local UI = args.UI or {}
    local variables = args.quickvars or {}
    local dryRun = args.dryRun or false
    d.apiVersion = "1.0"
    d.initialProperties = makeInitialProperties(body,UI,variables,args.height)
    if dryRun then return d end
    Log(LOG.SYS,"Creating device...")--..json.encode(d)) 
    if not d.initialProperties.uiCallbacks[1] then
      d.initialProperties.uiCallbacks = nil
    end
    local d1,res = api.post("/quickApp/",d)
    if res ~= 201 then 
      Log(LOG.ERROR,"D:%s,RES:%s",json.encode(d1),json.encode(res))
      return nil
    else 
      Log(LOG.SYS,"Device %s created",d1.id or "")
      return d1.id
    end
  end

POST {HC3-HOST}/api/quickApp 를 통해 QD를 생성하고 있음을 알 수 있다. 요청의 body는 위 부분에서 사용하는 코드를 전체적으로 보면 알 수 있는데, 결과적으로 웹 대쉬보드 Device 설정에서 QuickApp 을 다운로드하면 생기는 fqa 파일 내용이다.
fqa파일을 열어보면 JSON 포맷의 데이터가 있다.

{
  "name": "퀵앱 생성 테스트",
  "type": "com.fibaro.binarySwitch",
  "apiVersion": "1.0",
  "initialProperties": {
    "viewLayout": {
      "$jason": {
        "body": {
          "header": {
            "style": {
              "height": "0"
            },
            "title": "quickApp_device_57"
          },
          "sections": {
            "items": []
          }
        },
        "head": {
          "title": "quickApp_device_57"
        }
      }
    },
    "uiCallbacks": [],
    "mainFunction": "function QuickApp:onInit()\n    self:debug(\"onInit. Binary Switch QuickApp Test\")\nend ",
    "quickAppVariables": [
      {
        "name": "name",
        "value": "value"
      }
    ],
    "typeTemplateInitialized": true
  }
}

파일에는 개행 문자없이 한 줄로 표현되어있기 때문에 보기 좋게 개행을 추가하면 이렇다.
이름, 타입, 디바이스에 표현될 뷰, 뷰를 클릭할때 action (버튼, 슬라이드), lua 코드, variables 를 지정해서 생성한다.

타입은 몇 가지 웹에서 생성해보면 값을 알 수 있다. viewLayout 에 포함되는 quickApp_device_57 이런 값은 숫자에 의미가 있는지 모르겠지만 값이 어떻게 되든 문제는 없어보인다. QuickApp의 핵심인 lua 코드는 mainFunction에 있다. 디바이스에 필요한 코드를 넣어서 생성하면 된다.

POST /api/quickApp을 요청의 응답으로는 생성된 결과 디바이스 정보이며, 여기서 디바이스의 ID를 취득하여 서버에서 통신하면 될 것이다.

생성된 디바이스의 액션을 취하거나, 상태를 업데이트하기 위한 것이 필요할텐데 이것은 callAction api를 사용하면 된다.
POST /api/devices/{id}/action/{actionName} 이다. id는 디바이스 ID이고 actionName은 lua 코드에 있는 함수명을 지정하면 된다.

function QuickApp:setValues(power, energy)
    self:debug("setValues", power, energy)
    self:updateProperty("value", energy) 
    self:updateView("label1", "text", "Power: " .. power .. "W")
    self:updateView("label2", "text", "Energy: " .. energy .. "kWh")
end

위와 같은 코드가 있다면, 10번 QD에 대해서

curl 'http://userId:password@192.168.1.1/api/devices/10/action/setValues' \
  -d '{"args":["162","10"]}'

이렇게 한다면 162W와 10kWh (단위는 코드에서 임의로 표현하면 된다) 데이터를 QD에 업데이트 하도록 한 것이다. args가 함수의 파라메터이며 배열로 순서대로이다. 함수 내부에서 updateProperty은 fibaro manual을 참고하면 된다.

분명히 이렇게 구성하다보면, QD를 수정해야할 일이 생길 것이다. 이 것은 /api/devices API를 사용하면 된다. 이 부분은 fibaro의 공식 문서에 있기 때문에 그것을 참고하면 된다.
Lua 코드만을 수정할 수 있는 방법은 없으며 device에 대한 전체 속성을 수정 해야한다.
그래서 수정이 필요하다면, GET /api/devices/{id}를 통해 device에 대한 현재 값을 조회한 후 그 값에서 수정할 lua 코드만 변경하여 PUT /api/devices/{id}로 업데이트하면 될 것이다.

ST/HE의 커넥터에서 직접 DTH를 설치해야하고, 경우에 따라 SmartApp도 업데이트가 필요했던 부분이 HC3는 커넥터 서버에서 모두 일괄 관리가 가능한 장점이 생겼다.

ps. QuickApp 생성할 때, 한글에 대해서 인코딩이 깨지는 것 같지만 추가 테스트가 필요해보인다.
ps. 아직 오픈되지 않은 zigbee에 대해서도 어떻게 수많은 zigbee 디바이스를 지원할지도 기대가 된다.

Fibaro Home Center 3 (HC3) 가 출시되고, HC3로 넘어가길 기다리는 차에 현재 사용중인 Zigbee 네크워크를 살펴보았다. HC3으로 전환되어도 리피터 역할을 하는 outlet, 커튼, 블라인드들은 계속 사용할 예정이니 HC3에서도 네트워크가 잘 구성될지 봤다.

현재는 이사 후 몇 개월째 기존에 사용하던 센서류를 최대한 배제하고 수동 제어하고 있으며, 있는 센서류도 대부분 샤오미 센서라서 Hubitat의 네트워크에는 End Device가 많지 않다.
그리고 허브는 집 가장 안쪽 구석에 설치되어 있고, 가운데 화장실이 위치해 있어 반대편까지 콘크리트 벽이 두 개가 있다. 화장실 맞은 편으로 주방이 위치해있기 때문에, 전자레인지도 있다. 그리고 그 주위에 WiFi 라우터도 있다.
Zigbee는 2.4GHz를 사용하고 있기 때문에 전자레인지에 의해 방해될 수 있으며, wifi 역시 같은 주파수이기 때문에 방해될 수 있다. 그래서 리피터를 넉넉히 설치해서 사용 중이다.

Zigbee는 허브와 End device가 다이렉트로 연결될 수 있는 개수는 32개가 한계이며, 네트워크를 구성할 수 있는 디바이스 개수는 제한이 없지만 end device가 바로 연결할 수 있는 개수 제한이 있기에 사용자들은 리피터를 추가한다. Zigbee의 스펙으로는 상시 전원이 부가되는 디바이스는 신호를 리피팅한다.

R로 표기된 디바이스는 Router이고, 그 중 좌상단의 초록색 R로 되어있는 기기가 모니터링을 위해 확인하고 있는 디바이스이다. 그 옆의 C 디바이스가 Coordinator로 Hubitat이다. E로 표기된 디바이스가 배터리를 이용하는 End device, 센서류이다.

사용중인 라우터는 Smartthings 플러그, Develco 플러그, 다원 벽 매립콘센트, Aqara 전동 블라인드, 샤오미 전동 커튼 1세대, Aqara Opple 전등, eZex 전등 스위치, 알리 구매 Zigbee dimmer 컨트롤러이다.

네트워크에 있는 모든 라우터 디바이스 모두 라우터 서로 간이나 end device를 리피팅하고 있다. 외톨이처럼 혼자 덩그러니 있는 라우터는 없다.
위 지도의 화살표가 초록색인 경우 연결이 강한 경우인데, 초록색으로 나타난 두 디바이스는 한 멀티탭에 연결되어 있는 플러그로 간격은 10cm 정도이다.

천장에 존재하는 Aqara Opple 전등과 Zigbee dimmer 컨트롤러가 비교적 리피팅을 많이 한다. 이것과 관련이 있을진 모르겠지만, 공교롭게 모두 Zigbee 3.0 디바이스이다. 천장이라는 위치로 인해 리피팅이 잘 되는 것일 수도 있다. 신호 방해의 큰 원인일 WiFi 라우터는 허리높이와 바닥에 위치해있다.

사용 중인 End device는 Smartthings 모센센서, Smartthings 버튼, Hue dimmer, 샤오미 전동 커튼 2세대(배터리버전), Heiman 누수센서, 샤오미 온습도 센서(원형 - Hubitat과 연결해서 잘 사용중이다.)이다.

샤오미 센서는 미 게이트웨이에 연결되어있고, (다양하게 설정이 가능한) 센서는 z-wave 디바이스이다 보니 zigbee 디바이스는 주로 Actuator로 상시전원이 들어가는 제품들로 사용 중이다.
네트워크, 브랜드, 센서 타입에 따라 주로 사용되는 종류가 있다보니 이런 상황이 된 것 같다. 그래서 호환성을 맞추는 것도 늘 고민이고, 초기 설정시 불편함을 겪어야 한다는 부분도 고통이다.

이 글은 내가 작업한 내용을 토대로 작성하였고, 그대로 진행할 때에 오류가 발생할 수 있으며 굳이 똑같이 진행하지 않아도 다른 방법들이 있을 수 있다.

참고한 문서는 zigbee2mqtt의 how_to_sniff_zigbee_traffic 이다.

준비물 : CC2531, CC Debugger(CC2531 플래시용 - 라즈베리 등으로 대체 가능), GUI 리눅스 머신, Wireshark 소프트웨어

맥을 사용하고 있지만 맥에서는 제대로 안되는 것 같아서 리눅스를 가상머신에서 띄우고 거기서 작업하였다. (Synolgy NAS에서 스니퍼를 인식한다면 가능할 것도 같지만 시놀로지는 여러 리눅스 패키지들이 삭제되어 있어 씨름하기 싫어서 그냥 가상머신 사용했다.)

플래시는 맥에서 진행하였다.
TI사이트에서 PACKET-SNIFFER를 다운받는다. 2가 아닌 1버전이어야 한다. exe 파일이 다운로드 되지만, exe안에 포함된 펌웨어 파일이 필요하기 때문에 다운받은 파일을 7zip 같은 exe 파일 분리 프로그램으로 펌웨어를 뽑아낸다. 경로는 bin/general/firmware/sniffer_fw_cc2531.hex 이다.
이것을 CC Debugger를 통해 CC2531에 플래싱한다.(플래싱도 역시 여기 참조) 이렇게 되면 스틱은 준비 완료.

스틱을 통한 패킷을 캡쳐하기 위해 리눅스머신을 준비하고, whsniff라는 프로그램을 설치해야한다. (gui가 아닌 cli에서 캡쳐를 진행해보지 않았다.)
리눅스의 터미널을 열어 아래와 같이 한줄한줄 실행한다.

cd /opt
sudo apt-get install -y libusb-1.0-0-dev wireshark
curl -L https://github.com/homewsn/whsniff/archive/v1.1.tar.gz | tar zx
cd whsniff-1.1
make
sudo make install

위 명령어의 두 번째 라인에서 wireshark도 같이 설치되었다.

이제 캡쳐하려는 zigbee 네트워크를 준비(?)한다. 캡쳐에 필요한 정보는 zigbee 채널 번호와 두 개의 네트워크의 암호화 키이다.

일단 zigbee 연결에 기본적으로 사용되는 암호화 키인 Trust Center link key를 등록해준다.

Wireshark를 열고, Edit -> Preferences -> Protocols -> ZigBee를 선택하고 Pre-configured Keys의 Edit를 해준다.

^{<이미지를 클릭하면 크게 볼 수 있습니다>}

5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39, Byte Order: Normal 로 새로운 값을 추가한다. (Hue Bridge는 Trust Center Link Key가 다르다고 한다. 위 how_to_sniff_zigbee_traffic 문서에 링크가 있다.)

그리고 추가로 암호화 키를 하나 더 입력하여야 하는데, 이것은 각 허브마다 지정되어 있는 값이 있기 때문에 직접 찾아내야 한다.
zigbee2mqtt의 경우 암호화 키를 설정 가능하기 때문에 설정파일에 있는 키를 찾아 입력하면 되지만, 기성 허브의 경우엔 다른 방법으로 찾아내야 한다. 그 값을 찾아내기 위해 zigbee 디바이스 하나를 준비하고 패킷 캡쳐를 시작한다.

일단 사용하고 있는 허브의 Zigbee 채널을 확인하고, 패킷 캡쳐를 시작한다. 아래 명령어의 25 대신에 자신이 사용하는 Zigbee 채널을 입력한다.

sudo whsniff -c 25 | wireshark -k -i -

wireshark 창이 뜨면서 패킷 캡쳐가 시작된다. 시작되면 허브의 페어링모드를 시작하고 디바이스 (리)페어링을 한다. 페어링이 완료되면 일단 캡쳐는 중단한다. 어차피 확인하기 어려운 패킷이기 때문에 의미없다.

프로토콜이 ZDP 인 것을 필터링한다. 패킷 내용의 Zigbee Security Header의 값이 필요하다.

이미지의 파랗게 선택된 라인의 [Key: a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6] 이런 값을 복사하여 아까의 암호화 키 형태로 두 문자 사이에 :를 추가하여 A1:B2:C3:D4:E5:F6:G7:H8:I9:J0:K1:L2:M3:N4:O5:P6 처럼 수정하여 Pre-configured Keys에 추가한다.

이렇게 하면 허브의 Zigbee 패킷은 모두 확인할 수 있게 된다.
키 두 개 모두 추가하지 않은 상황에서는 통신하는 내용이 암호화되어 확인할 수 없으니 두 키를 입력 후에 다시 패킷 캡쳐를 시작하고 디바이스를 컨트롤하면 된다.

패킷 캡쳐 설명에 사용된 기기는 샤오미 전동 커튼 B1 모터이다. 패킷 캡쳐로 실제 DTH도 만들었고, 샤오미 기기만의 다른 부분이 있어서 이걸로 설명하겠다. 샤오미 게이트웨이에 연결 후 위치를 변경하고, 각종 커튼의 설정값을 변경해보며 캡쳐하였다.

Zigbee 커맨드는 Hubitat에 맞춰 작성한 것이며, Smartthings도 유사하나 정확한 것은 Smartthings의 문서에서 추가 확인이 필요하다. 여기서 DTH의 상세 테크닉은 여기서 다루지 않을 예정이다. 패킷 캡쳐를 통해 획득한 정보를 DTH 커맨드로 어떻게 변환하는지 정도만 설명한다.

Zigbee HA 패킷을 필터링을 하기 위해 필터에 zbee_nwk 로 필터링한다.

필터를 적용하면 Zigbee와 Zigbee HA프로토콜의 패킷만 보인다.
그 중에 Info 컬럼을 보면 ZCL:Write Attributes, ZCL:Report Attributes, ZCL:Read Attributes, ZCL:Read Attributes Response 가 보인다.

이 4종류의 패킷을 이용해서 DTH를 만들 수 있다.

먼저 Read Attributes를 살펴보면

필요한 부분은 Zigbee Application Support Layer Data의 Cluster와 Zigbee Cluster Library Frame의 Attribute Field 정보이다.

Zigbee Cluster Library (ZCL)을 알아두면 좋다. 0x0000 옆에 Basic으로 표기가 되어있는데, ZCL에 미리 정의된 값들이 있다. 전원, 센서 메트릭, 전력 측정 등 정해진 값이 있다. 보통의 표준을 지킨 디바이스들은 라이브러리에서 지정한 클러스터 번호와 Attribute를 사용하여 통신하기 때문에 굳이 패킷을 캡쳐하지 않아도 DTH를 만들 수 있다.

이미지에서 Cluster 0x0000, Attribute 0x0001 이다. DTH의 Zigbee 신호 커맨드에서는 이렇게 된다.

zigbee.readAttribute(0x0000, 0x0001)

Attribute의 0x0001이 Application Version에 대한 속성이기 때문에, 이 속성에 대해 읽기를 요청하면 모터에 설치된 버전 정보를 알 수 있다.

이번엔 Write Attributes에 패킷을 보면,

역시 동일하게 Cluster와 Attribute Field 정보를 확인한다.

Cluster : 0x000d
Attribute : 0x0055
Data Type : 0x39
Data값은 Float 24이다.
Write의 경우 코드로 변경하면 아래처럼 된다.

zigbee.writeAttribute(0x000d, 0x0055, 0x39, 24)

0x000d 클러스터의 0x0055 속성은 아날로그 값을 변경하기 위한 커맨드이고, 커튼에서 명령어의 밸류를 커튼의 위치로 사용하고 있다. 커튼 위치의 아날로그의 범위는 0-100까지 가능하다. 위 커맨드는 커튼의 위치를 24%까지 움직이라는 명령어가 된다.

Smartthings의 Device Type Handler에서는 4번째 파라메터의 밸류를 16진수(Hex string)으로 변경해서 사용하고 있기도하니 각 허브에서 어떤식으로 사용하는지 확인하여야 한다.

Read Attributes를 통해서 기기에서 응답하는 데이터인 Read Attributes Response를 본다.

앞서 본 Read Attributes 패킷의 Read 0x0000, 0x0001의 결과이다.

Cluster가 0x0000이고 Attribute가 0x0001이다. 데이터의 타입이 8-Bit Unsigned Int(0x02)이고, 데이터는 12(0c) 이다.

마지막으로, 남은 Report Attributes를 보자. 이 패킷은 디바이스에 따라 발생하지 않을 수 있다. 디바이스가 센싱 정보가 리포팅 되지 않는 스펙이라면 패킷이 발생되지 않는다.

Cluster가 0x000d이고, 첫 번째 Attribute Field의 Attribute가 0x0055이다. 데이터의 타입이 Single Precision Float(0x39)이고, 데이터는 24 이다.
앞서 Write Attributes의 24%까지 위치를 지정한 데이터 쓰기 이후 커튼이 동작이 완료된 뒤 자신의 상태를 report 한 것이다.

위 Report Attributes 패킷의 경우에 Attribute Field가 두 개이다. 첫 번째 Attribute가 메인 값이고, 두 번째가 additional attribute로 확인이 가능하다.

Read Attributes Response나 Report Attributes는 디바이스로부터 허브로 데이터가 전송되는 것이기 때문에, DTH의 parse 메소드로 데이터가 전송되어 확인이 가능하다.

위의 패킷에 대응하는 코드를 보자.

def parse(String description) {
	log.trace "Description is $description"

	def event = zigbee.getEvent(description)
	def msg = zigbee.parseDescriptionAsMap(description)

    // 허비탯은 event가 지원이 되는지 확인 불가능. 사용했던 디바이스들은 모두 event가 없었다.
	log.trace "Parsed event: ${event}, msg: ${msg}"

	if (msg?.cluster == "0000") {
		if (msg?.attrId == "0001") {
            // msg.value는 0c로 되어있을 것이다. 필요에 따라 10진수로 변경하여 사용하면 된다.
			log.debug "Device application version : ${msg.value}"
		}
    } else if (msg?.cluster == "000D") {
        if (msg?.attrId == "0055") {
            long longValue = Long.parseLong(msg.value, 16)
            float position = Float.intBitsToFloat(longValue.intValue())
			log.debug "Device position : ${position}"
		}
	}
} 

허브로 데이터가 들어오는 때 모두 parse 메소드가 호출되기 때문에 각 메시지에 따라, 데이터를 분석하여 허브의 디바이스 상태를 변경할 수 있도록 하여야 한다.

Write Attributes Response 패킷도 있으나 보통 Success로 응답이 올 것이고, 허브에서는 무시되는 것 같다.

추가로 다른 Write Attributes를 확인해보자.

첫 번째 패킷의 내용은 모터의 이동 방향을 변경하는 패킷이다. 두 번째 패킷은 앞서 봤던 위치 변경 패킷이다.
첫 번째 패킷을 커맨드로 작성하면 아래와 같다.

zigbee.writeAttribute(0x0000, 0xff28, 0x01, 0)
zigbee.writeAttribute(0x0000, 0xff28, 0x01, 1)

이렇게 하여 DTH에서 동작시키면 모터의 방향이 변경되지 않는다. 자세히 보면 두 개의 패킷 사이에 데이터 말고 조금 다른 부분이 있다.
Frame Control Field에 Manufaturer Specific: True/False 가 다르다. Frame Control Field 역시 Zigbee 패킷에 대해 알아두면 좋다.

Manufacturer Specific 값을 전송하기 위해 아래처럼 하여야 한다.

zigbee.writeAttribute(0x0000, 0xff28, 0x01, 0, [mfgCode: "0x115f"])
zigbee.writeAttribute(0x0000, 0xff28, 0x01, 1, [mfgCode: "0x115f"])

5번째 파라메터에 mfgCode값을 별도로 전달해주어야 허브에서도 Manufacturer Specific 하도록 패킷을 보낼 수 있는 것이다. mfgCode값은 패킷의 Manufacturer Code: Unknown (0x115f)를 참고하여 입력하면 된다.

그리고 3 번째 파라메터의 인코딩 값은 스마트싱스 문서에 잘 정리가 되어있어 링크를 걸겠다. Smartthings Document

그리고 아직 B1 모터의 미해결점이 있는데, ST나 Hubitat에 연결하면 커튼 동작 후 위치 리포팅이 제대로 안되고 있다.
샤오미 게이트웨이에서는 앞서 본 캡쳐 내용처럼 정확히 24%로 리포팅이 되고 있으나 다른 허브에 연결된 경우에는 2%로 리포팅이 된다. 이 부분을 해결할 수 있는 고수가 나타나길 기대하고 있다.

내년엔 제대로 Zigbee 3.0 센서들이 많이 출시될 것 같은데 위 방법대로는 3.0이 캡쳐되는지 잘 모르겠다.

가끔 패킷 캡쳐를 하다보면 Permission Denied 에러나 다른 에러메시지가 발생하곤 하는데, 이런 경우

chmod 755 /usr/bin/dumpcap

를 실행해주거나, wireshark도 sudo로 실행하거나, 리눅스 머신을 재시작해보거나 한다. 정확한 해결법은 찾아보지 않았다.

^{나중에라도 오류가 확인된다면, 수정될 수 있다.}

타이틀에는 일반 Zigbee 플러그라고 적어두었지만, Smartthings Zigbee 플러그의 전력사용량 리포팅을 확인해보고자 한다.
Smartthings Hub와는 궁합이 잘 맞아(당연한 얘기) 기본 DTH로도 전력사용량이 세밀하게 리포트 된다고 한다. 하지만 Hubitat에서는 다르게 동작한다.

지난 글의 그래프를 다시 가져와본다.
Hubitat에 Smartthings Zigbee Plug를 연결하여 리포팅받은 그래프이다. 연결된 기기는 iPad Pro USB-PD 충전기이다. 세밀하게 리포팅된다고 느껴진다.

하지만...

Hubitat의 내장된 Driver의 첫 번째 설정이 Enable automatic power reporting값인데, 자동으로 리포팅하려는 전력사용량 변화값이다. 어떠한 이유인지는 모르겠지만 전력이 1W 이상 변경될 경우부터 이벤트가 발생하도록 되어있다. (Local로 동작하는 만큼 Hub의 로드가 높아질 걸 대비하여 제한을 둔 것일지도)

iPad 충전기보다 훨씬 더 적은 전력을 쓰는 LED 전자벽시계를 연결해보았다. 네XX에서 검색하면 바로 찾을 수 있는 플라이토 벽시계이다. [Link]
전력 소모량이 1W 내외인 저전력 제품이다. (최대 밝기로 해두면 1W 소모한다)

기본 Driver로 연결한 경우이다. 제품을 끄고 켤 때 잠깐 1W가 되는 것말고는 계속 1W보다 아래여서 전력량이 업데이트되지 않는다. 심지어 0W로 리포팅하고 있다.
디버깅 로그를 보면 전력량은 리포트 되고 있다.

이미지의 첫 번째 로그가 Cluster가 0B04, attribute id가 050B의 value가 0007이다. 0.7W 사용 중인 것이다. 하지만 Driver에서 0W로 리포팅을 하고 있어 연결된 기기가 사용 중인 것으로 판단할 수 없다.

이처럼 최대전력소모량이 1W밖에 안되는 저전력기기인 경우엔 기본 Driver는 0과 1W만 기록이 될 것이고, 고정적인 소비전력이 있는 상황에서 변화량이 1W이하인 경우 20W와 21W사이에서 지속적으로 변동이 있어도 전력량은 20W와 21W만 기록이 될 것이다.

Smartthings Hub에 연결해보면 1W 미만인 경우에도 정상적으로 이벤트를 발생시키고 있다.

기기에서 리포팅이 안되어서 문제가 발생하는 건 아니고, Driver에서 1W미만인 경우에 이벤트를 발생시키지 않는 문제이기 때문에 Driver만 수정해주면 문제해결이다. 그러던 중 Hubitat 포럼에 Enhanced Smart Plug Driver라고 올라온 글을 보았다.
Iris 플러그 Driver인데 Smartthings plug에도 테스트가 되었다. (ZHA 표준에 따랐다면 다 될 것 같다.) 이 Driver를 사용하면 좀더 세밀한 리포트와 Voltage와 AC주파수를 정보도 받을 수 있다. 최소/최대 리포팅 주기도 지정할 수 있다.

그래프의 양상이 Smartthings Hub에 연결했을 때와 동일하게 나타난다.

이렇게까지 저전력 리포팅을 찾아봤던 것은 LED 시계를 밤에는 끄고 싶은데, 플러그를 끄는 것 말고 IR리모트로 LED를 Off할 수도 있어 KuKu Harmony에서 쓰기 위해서이다. 저전력 기기를 연결해서 쓰는 것이 아니라면 내장된 Driver를 사용해도 문제없다.

[컴팩트 스마트 플러그 비교]글과 연관된다.

1. 컴팩트형 스마트 플러그 비교
2. 컴팩트형 스마트 플러그 비교 2

전 글에서 소개한 다원 z-wave 플러그와 Smartthings에 맞춤인 ST zigbee 플러그의 전력량 리포트 비교해보려고 한다. Smartthings zigbee 플러그는 전력량 리포트가 잘 된다고 소문난 제품이다.

허브에서 발생되는 이벤트를 InfluxDB로 전송하고, Grafana로 확인한 그래프이다. USB-PD로 충전한 아이패드 Pro의 전력사용량이다. 잔여 배터리가 20% 정도인 상태에서 완충까지 충전하였다.
두 개의 그래프가 겹쳐 있는데, 빨간색은 Smartthings zigbee 플러그이고, 초록색은 다원 z-wave 플러그의 전력사용량이다.

전력사용량의 측정 오차는 무시하도록 하고,
Smartthings zigbee 플러그는 이것보다 더 세밀하게 리포팅을 할 것으로 아는데, 연결되어있는 허브가 Hubitat이라서 1W 변동이 있을 때 리포팅이 하도록 되어있다. (ST에 연결하면 더 자주 리포팅될 것 같긴하다.)
선 위에 점이 있는 시점이 리포팅이 된 시각이다.

각각 따로 보면,

^{<이미지를 클릭하면 크게 볼 수 있습니다>}

왼쪽(상단)은 Smartthings zigbee 플러그 전력사용량이다. 그래프에 보이는 격자의 가로 한 칸이 10분이다. 사용 전력량이 변동이 있을 때마다 리포팅이 되어 10분 내에서도 선 위에 점이 여러개 확인된다.

오른쪽(하단)의 다원 z-wave 플러그 그래프를 보면 정확히 10분에 한번씩 리포팅 되고 있다. 역시 격자 한 칸이 10분이고, 매 10분보다 조금 일찍 X6분에 리포팅이 되고, 10분 동안은 사용 전력이 변동되어도 리포팅이 되지 않는다.
그리고 사용하지 않다가 사용하게 되어도 리포팅이 바로 시작되지 않는다. 처음 기록된 전력이 아래에서부터 시작되지 않고 36W로부터 시작된다. 전력 사용이 언제 시작되던 상관없이 본래의 10분 주기를 벗어나서 리포팅하고 있지 않다.
이렇게 될 경우 전자렌지, 토스터 등 짧게 사용하게 되는 전자제품에 대해서는 사용전력량이 잡히지 않는다.

안타깝지만, 다원 z-wave 플러그는 10분보다 짧게 하기 위해서는 허브에서 전력량을 가져오도록 신호를 보내야한다.

지난번 컴팩트형 스마트 플러그 비교를 작성하는 중에 추가로 구매한 제품이 있어서 추가하려고 한다. 이전 글을 작성하면서 구매했지만, 두 번째 본글은 이제서야 남기게 되었다.

그외 제품 소개로 유플러스에서 판매했던 wifi용이 아닌 플러그—z-wave용이며 다원DNS에서 제조한 10A, 16A 플러그와 이지세이버에서 제조한 16A 플러그—가 있다고 언급했었다. 유플러스에서 약정으로 가입했던 고객들도 이제 만기가 되고 있고 만기가 될 때 사용했던 제품은 회수하지 않고 있는 것 같다.
그러한 이유로 종종 중고 마켓에 판매가 되고 있고, 기회만 잘 잡으면 제품을 구매할 수 있다. 나도 몇 제품을 구매했다.

낱개로 구매하다보니 총 4개가 되었는데, 10A 2개, 16A 2개이다.

사진 왼쪽부터 다원 판매 z-wave 플러그 / uplus 유통 다원 z-wave 플러그 / 이지세이버 z-wave 플러그이다. 이지세이버 플러그는 노란색 스티커로 3.5KW 까지 사용할 수 있다고 표시되어있다. 16A용이다.
다원에서도 16A용을 출시는 한 것 같으나 아직 중고시장에서 확인이 되지 않는다.

첫 번째 사진에도 살짝 보이지만, uplus iot 서비스 마크가 찍혀있다.

이 제품의 통신 스펙은 현재 다원에서 유통되고 있는 zwave 플러그와 동일하다.
다원에서 직접 판매하는 플러그와 형태는 동일하지만 버튼부 디자인이 약간 다르고, SKT용 16A WIFI 플러그와 버튼 모양만 다른 동일한 디자인의 플러그이다.

한국에서 유통되었던 제품이니 국내 z-wave 주파수와 호환되는 플러그이다. 같이 구매한 유플러스 zwave 스틱을 Hubitat에 연결하여 한국 주파수로 사용하고 있다.

현재 판매하고 있는 Hubitat C5 버전은 호환되는 stick이 몇 개 되지 않아 사용할 수 없을 것 같고, 구형인 C4 버전에는 호환이 되어 사용 중이다.

어찌되었든 전력미터를 멀티탭에 연결해서 사용하는 방식은 불호하여 단일 제품을 연결하여 사용하는데, 사용전력이 2KW이상 넘는 제품이 거의 없지만, 넉넉하게 사용하는 것이 안전상, 플러그의 수명에 좋기 때문에 허용 용량이 높은게 좋다.

다원 zwave 플러그에도 동일하게 나타나는 증상이지만, zigbee 플러그만큼 전력량 리포트가 세밀하게 되지 않는다. 설정이 이상한 것인지 설계가 그렇게 된 것인지 정식으로 같이 출시된 허브와 소프트웨어에 연결해서 사용해본 적이 없어서 본래의 사용방식대로 사용하는 것인지 모르겠다. 전력리포팅에 대해서는 다음번에 포스팅을 남기도록 하겠다.

지금은 Driver를 수정하여 스위치가 켜져있으면 허브에서 10초마다 전력량 refresh를 전달하게 된다. 아직 zwave 기기들이 많지 않아 더 짧게 refresh를 하여도 문제가 없을 것 같지만 10초면 짧게 사용하는 기기의 전력도 충분하게 리포트 하고 있어서 문제가 없을 것 같다.
다만, 추가로 이 zwave 플러그를 구매하게 된다면 다시 고민하게 될 것 같다.