구형 멀티에어컨을 별도의 child device card로 표시하는 것에 대한 건의글을 쓰다보니
기술적 내용에 대한 설명이 계속계속 필요하네요.. 휴우.......
(전 사실 2013년도 wifi모듈조차 없는 삼성에어컨을 쓰고 있어서.. 저랑은 무관한 문제이긴 합니다만.. Smartthings 카페 내에 워낙 다빈도로 올라오는 건의라 계속 글을 쓰고 있습니다)
...
오늘은 Smartthings에 기기 연결방식에 대해 알아봅시다.
(참고문헌은 https://smartthings.developer.samsung.com/docs/devices/device-basics.html )
Smartthings에 기기를 연결하는 방식은 3가지가 있습니다.
1. Cloud-connected device
2. Direct-connected device
3. Hub-connected device
이렇게 3 종류가 있습니다.
이제 하나씩 살펴보겠습니다.
1. Cloud-connected device
대부분 3rd party cloud제품을 연결하는데 사용됩니다.
대표적인 예로 다원DNS사의 WiFi 플러그를 예를 들어 봅시다.
[다원WiFi플러그] ---- [다원DNS서버] ---- [클라우드커넥터 서버] ---- [Smartthings서버]
의 구조입니다.
Smartthings에서 이러한 기기에 대해 기기추가를 하시다 보면, 해당 제조사 클라우드의 계정으로 로그인하라는 창이 뜹니다. 기기 등록 삭제 등은 모두 해당 회사 서버에서 진행이 되고, Smartthings에서 조작 및 상태반영은 'Smartthings서버'와 '해당회사 서버' 사이에 있는 '클라우드커넥터 서버'가 중개합니다.
이러한 경우, Smartthings서버는 클라우드커넥터 서버랑만 통신을 하며, Oauth인증 등으로 각 사용자를 구분하고, 각 사용자별로 여러개의 기기를 사용할 경우, 그 각각의 기기를 각각의 디바이스카드로 표시하여 조작 가능하게 합니다.
이 방식의 장점은 타사 기기와의 연동을 빠르게 늘릴 수 있다는 점이 장점이지만,
단점은, 매번 기기 조작 또는 상태변경시마다, 해당 회사 클라우드를 거쳤다가 와야 되어, 약간의 딜레이가 생길 수 있으며, 전력량모니터 등 상시 데이터 모니터시 서버부하가 커지고, 제휴사 클라우드가 다운되었을 때 기기조작 및 상태반영이 먹통이 된다는 단점이 있습니다.
따라서 IoT구축 맛보기에는 저비용에 좋은 방법일 수 있으나, 확장이 필요한 시기에는 한계가 발생합니다.
2. Direct-connected device
기기에 달린 WiFi를 통해 Smartthings서버와 직접 통신하는 방식입니다. 내부적으로는 Smartthings서버와 MQTT방식으로 통신을 한다고 합니다.
즉, 기기와 Smartthigs서버 사이에 그 어떠한 서버도 존재하지 않고, 직접 통신합니다.
주로 삼성 가전에서 이용하는 방식이지만, 꼭 삼성가전 한정으로만 쓸 수 있는 것은 아닙니다.
Smartthings Device SDK(STDK)/Developer Workspace(DevWS)를 공개하였기 때문입니다.
https://github.com/SmartThingsCommunity/st-device-sdk-c
저도 개인개발자로 등록한 뒤, 이 STDK/DevWS를 이용하여, Smartthings와 직결되는 스위치를 직접 만들어 본 적이 있고, 그 경험을 통해 그 구조를 이해하게 되었습니다.
https://cafe.naver.com/stsmarthome/18614
기기 자체가 서버와 통신하는 부분은 STDK를 이용하여 개발을 하게 되고,
서버에서 받아들인 정보를 처리하는 부분, 즉 기기의 capability 및 child component등에 대한 설정은 DevWS에서 설정을 합니다.
장점은 기기와 ST서버가 직접 통신하므로, 3rd party서버 문제로 작동이 안 되는 경우는 없다는 것이 장점이지만,
단점은 범용 기기를 만들 수 없고, ST서버하고만 통신하는 기기로밖에 제작이 안 되기 때문에, 타 제조사 입장에서는 이 방식으로 제품을 제작하기는 어렵습니다. 따라서 실질적으로는 삼성 생활가전 사업부 외에는 이 방식을 사용하여 제품을 출시한 회사는 현재까지는 전무합니다.
예를 들어, 2018년 이전 방식의 멀티에어컨의 경우, DevWS에서 메인 에어컨 카드를 생성한 뒤, 서브 에어컨은 child component로 생성한 방식으로 추정됩니다.
(아니면 통신 방식이 예전 삼성 smart home방식이라서 내부적으로 cloud-connected device로 되어있는지는 잘 모르겠습니다.)
(이에 대한 문제점 및 논의의 쟁점은 아래에서 추가로 설명드리겠습니다)
3. Hub-connected device
이 방식은 각 기가가 Smartthings Hub와 연결되어 통신하는 방식입니다. 기기가 Smartthings hub와 연결되는 통신방식은 3가지가 있습니다. Zigbee, Zwave, LAN connected 이렇게 3가지입니다.
Zigbee/Zwave는 저전력 통신방식으로 IoT구축에 필수이며, Smartthigs Hub가 이를 구현해 줍니다. 또한 LAN connected device는 기기 자체에 Local 네트워크를 통해서 통신할 수 있는 장치 (예를 들어 Phillips Hue Bridge, Logitech Harmony 등 Local API를 지원하는 장치)인 경우, Smartthigs Hub가 가정 내 인트라넷을 통해 이러한 기기와 직접 통신하는 구조로, Cloud-connected 방식보다 훨씬 빠르고 안정적인 구현이 가능합니다.
즉 Phillips Hue bridge와 통신할 때, [Phillips Hue bridge]--[ST Hub]--[ST서버]의 구조로, Phillips서버를 경유하지 않기 때문에, 속도와 안정성이 높아집니다.
장점은 Zigbee/Zwave방식으로 제작된 범용 제품의 연결이 가능, 클라우드를 거치지 않아 딜레이 없는 빠른 실행속도, 저전력 버튼/센서 연결 가능, 최적화된 방법으로 ST서버와 정적 연결 등등 모든 것이 다 장점입니다. (삼성관계자분께.. 제발 Smartthings Hub 국내 출시 부탁드립니다)
단점은 Smartthings Hub를 구매해야 한다는 초기 비용 지출이 있습니다.
이 방식의 경우 기기는 ST허브와 통신하는 모듈은 1개이나, 각각의 디바이스카드로 표시하는 것이 가능합니다. 앞 글에서 예를 들었던 ezex 3구 벽스위치의 경우, zigbee모듈은 1개이지만, 실제 논리적인 스위치는 3개로 표시되며, 다시말하면, 디바이스카드는 3개로 나타납니다. (이는 child device를 생성할 때 isComponent=false로 생성하면 됩니다. 아래 소스코드 124째줄 참고)
child device라고 모두 별도의 device로 표시되는 것은 아닙니다. child device를 생성할 때 isComponent=true로 생성하면, child device가 별개의 device controller로 표시되는 것이 아니라, 하나의 device controller 안에 내부 컴포넌트로 표시가 됩니다.
대표적인 예가 ikea 5 button입니다. 5개의 버튼이 각각 child device로 등록되어 있지만, isComponent=true 즉, component로 생성이 되기 때문에, 그 5개가 하나의 device card, 하나의 device controller로 표시가 됩니다.
(아래 소스코드 128째줄 참고)
----------------------
설명을 하다보니, child device의 component 내용이 나왔는데요
정리하자면, 물리적 통신모듈 1개에 대해 논리적 기기인 child device를 여러개 생성할 경우
- isComponent=true라고 하면, child가 별도의 논리적 기기가 아닌 1개의 기기 내의 구성요소로서의 컴포넌트 (예시: 이케아 5버튼)
- isComponent=false라고 하면, child가 별도의 논리적 기기로 별도의 device card및 device controller로 표시 (예시: ezex 3구 벽스위치)
이렇게 되겠습니다.
-------
자 이제 삼성 멀티에어컨 문제로 돌아가 사실관계를 정리해 보겠습니다.
- 삼성 에어컨은 Direct-connected Device입니다.
- 2018년 이전 모델은 통신모듈이 메인에어컨 1개이며, 서브 에어컨은 component (isComponent=true)로 등록이 되어 있고, 이에, 서브에어컨이 별도의 device가 아닌, 하나의 device card/controller에 표시가 되고, 서브에어컨의 자동화도 되지 않습니다.
- 2019년 이후 모델은 통신모듈이 각 실내기마다 존재하고, 따라서, 실내기 각각이 Direct-connected Device로 각각 ST서버와 통신하는 각각의 device로 표시가 됩니다.
---------
그럼 생활가전 사업부에서는 멀티에어컨을 왜 자꾸 child device 중 component가 아닌 별개의 논리적 디바이스로 하는 것이 불가능하고... 자꾸 하드웨어를 바꿔 달아야 한다고 하는 것일까요..
그건 Direct-connected device에 대해서는 DevWS에 그러한 기능이 없기 때문입니다.
Direct-connected device의 DevWS에서 Component를 만드는 기능은 있지만, isComponent=false로 해서 별도의 device 카드를 만들도록 하는 기능이 없습니다.
생활가전 사업부는, Smartthings플랫폼을 만드는 사업부는 아니고,
그들은 Smarttings팀에서 만들어 둔 Smartthings 플랫폼을 이용하여 제품을 만드는
어떻게 보면, 일개의 플랫폼 소비자인 셈입니다.
그런데 Smartthings 플랫폼을 만드는 쪽에서, Direct-connected Device에 대해서만 별개의 논리적 디바이스로 만드는 인터페이스(isComponent=false인 child device를 생성하는 인터페이스)를 내놓고 있지 않으니
생활가전 사업부에서는 이게 안 된다고 생각하는 것입니다.
----
정리하겠습니다.
Smartthings의 기본 설계 자체는 하나의 통신모듈에 대해 여러개의 child 논리적 device (isComponent=false인 child device)를 만들 수 있도록 설계되어 있습니다.
앞서 여러차례 말씀드렸다시피 Cloud-connected device 및 Hub-connected device에서 이게 다 가능하기 때문입니다.
그런데 Direct-connected device에 대해서는 STDK/DevWS에서 이걸 손쉽게 만드는 방법이 공개되어 있지 않습니다.
STDK/DevWS를 github를 통해 외부에 오픈하긴 했지만, 사실상 이를 이용하고 있는 곳은 삼성 생활가전 사업부가 거의 유일합니다. Direct-connected device 중 시장에 출시된 제품이 현재로서는 전무하기 때문입니다.
제가 삼성 가전이 타사제품 만도 못한 상태라고 이전 글에서 말씀드렸는데
그 구체적인 내용이 바로 위와 같은 내용입니다. 타사 제품은 Cloud-connected device또는 Hub-connected device이기 때문에, 위와 같은 문제가 발생하지 않지만, 오직 Direct-connected Device를 쓰는 삼성전자 가전에서만 이러한 문제가 발생하기 때문입니다.
따라서 Smartthings 플랫폼을 담당하시는 쪽에서는 Direct-connected device에 대해 여러개의 child 논리적 device (isComponent=false인 child device)를 만들 수 있도록 수정을 하시고,
생활가전 사업부에서도, 이러한 수정을 반영하여 수정을 가해주십사 부탁을 드립니다.
혹시 구 제품 통신방식 차이로 인하여, 내부적으로 "삼성 Smart Home" 클라우드 커넥터 (Cloud connected device)형태라면, 이건 더더욱 수정이 쉬울 겁니다.
삼성전자의 이익의 측면에서 살펴봐도 이는 좋은 선택입니다.
멀티에어컨의 통신모듈이 1개일 경우
- 제품 제작 원가가 절감됩니다.
- ST서버의 통신 접점이 줄어들어 서버 로딩이 줄어듭니다.
ㅡㅡㅡㅡㅡㅡ
그리고, direct-connected device에서 component 형태의 child device밖에 만들 수 없는 부분에 대한 수정(STDK/DevWS 수정)이 당장은 어렵다고 하더라도,
child component에 대해 자동화 규칙을 걸 수 없도록 구현한 것은 잘못이며, 이는 현 상태에서도 쉽게 수정 가능할 것입니다.
아래와 같이 developer workspace (devWS) 에서 main 및 child component 각각에 대해서 capability를 제대로 선언을 해 준다면 말입니다
이케아버튼에 대해 뉴앱 자동화를 걸어보면, child component 각각에 대해서도 자동화가 잘 걸어지므로, 이게 안 되지는 않을 것 같습니다.
