[정보💡] Matter over Thread의 문제점 1편:큰 패킷과 복잡한 세션

[스싱마스터(stmaster)]

매터 표준은 인터넷 프로토콜인 ip, 그 중에서도 ipv6 기반으로 스마트홈 기기들의 통신을 소프트웨어 애플리케이션 계층에서 표준화하려는 프로젝트임

매터에는 기능적으로 미완성된 부분과 수 많은 단점이 계속 보고되고 있지만 더 자세히 살펴보면 매터의 통신 구조 안에 깊숙이 자리 잡은

태생적으로 비효율적으로 자원을 쓸 수 밖에 없는 철학과 설계를 바탕으로 시작했기 때문에

IoT의 가장 중요한 본질인 저전력을 달성하기 위한 에너지 효율을 희생해버린다는 구조적인 한계가 존재하고 있음

그래서 매터가 잘못된 방향으로 간다고 늘 생각했고, 작년에 여기에 대한 글을 써서 매터가 구조적으로 무거울 수밖에 없는 한계를 가지고 있다는 사실에 대해 짚어봤었음.

https://m.dcinside.com/board/smartthings/9308

매터가 스마트홈에서 비효율적이 돼가는 이유

그래서 매터의 이러한 비효율을 야기하는 구조적 한계를 더 구체적으로 알아보고 실제로 얼마만큼의 측정된 사이드 이펙트를 야기하는지 확인해보려고함.

주로 찾아보려고 했던건 스레드 프로토콜을 데이터링크 계층으로 쓰는 matter over thread임.

왜냐하면 thread는 현재 스마트싱스와 IoT 세계에서 널리 쓰이고 있는 zigbee와 똑같은

802.15.4 표준을 기반으로 만들어진 저전력 데이터 전송규격이며, zigbee와 같은 안테나를 쓰고 dual rcp로 분배하기 때문에 직접적인 비교대상이 되면서

매터의 아키텍처의 비효율적인 에너지 사용 측면에서 zigbee와 같은 초경량 IoT 프로토콜에 비해 구조적인 약점을 가지는 점을 구체적인 데이터로 분석하기 좋기 때문임.

따라서 앞으로 언급하는 매터는 거의 대부분이 matter over thread를 뜻하며, 애플리케이션 레이어의 매터sdk 그 자체를 가리킬때도 스레드 스택 위에 올라간 매터의 구현을 뜻함 

[시작하기 앞서 주의사항 1]

이 글에서 다루는 스레드는 matter over thread인만큼 당연히 애플리케이션 레이어의 matter sdk를 포함하고 있음. 그 이유는 스레드가 오로지 네트워크 계층에만 집중하는 프로토콜이기 때문임.

기존의 스마트홈 통신 규격들은 기기 간의 연결 방식뿐만 아니라 어떤 명령어를 어떻게 표준화해서 주고받을지에 대한 데이터의 규격인 클러스터까지 정의되어 있는 풀스택 프로토콜이었지만, 스레드는 그런거 없이 복잡한 상위 계층의 클러스터의 로직에 구글, 오픈스레드 등 온갖 단체와 회사가 참여하도록 냅두고있었음.

그래서 thread 제품은 같은 네트워크 스택이지만 다른 클러스터를 쓰는 바람에 서로 연동되지 못했고, 파편화의 길을 걸었음. 그래서 matter가 등장하기 전까지 thread 기기는 전 세계적으로 100개정도밖에 없었고 시장에서 외면받았던 역사가 있음.

하지만 매터가 나오면서 지난 3년간 다른 클러스터는 안그래도 외면받았지만 시장에서 더 도태되었고, 현실적으로 오늘날 말하는 스레드는 대부분 매터 오버 스레드를 가리키게 되었음. 따라서 그 둘을 분리해서 보기 힘들고, 지그비와 같은 표준과 비교할때는 더 그렇고, 애초에 독립적으로 스레드만을 쓸수도 없으니 이 정도면 충분한 설명이 되었다고 봄.

[시작하기 앞서 주의사항 2]

저전력 IoT 디바이스에 쓰이는 mcu에서 직접 지그비와 매터 오버 스레드의 데이터를 찾기 위해 매터를 개발하고있는 csa와, 매터의 프로젝트칩 레포지토리의 매터 sdk가 대응하는 IoT 제품의 프로세서인 mcu를 만드는 nxp, 실리콘랩스, 텍사스 인스투르먼트 등 IoT 제품용 레거시 팹을 운용하는 반도체 메이커들의 문서를 참조했음.

여기서 쓰이는 mcu는 일반적인 IoT 제품을 만들때 쓰이는 mcu보다 높은 스펙을 가지고 있음. 왜냐하면 매터는 pki라는 클라우드 서버와 IoT 제품 사이의 통신을 거쳐야하는데, 이때 디바이스에 dac라는 인증서를 메모리에 저장해야하고, 큰 페이로드와 ipv6에 기반한 스펙 자체의 무거움으로 인해 높은 자원을 요구하기 때문임.

매터 오버 스레드의 문제점1:

패킷이 너무 크고 세션이 복잡하다

IoT 제품은 전원 온오프, 발기 변경, 색x 변경 등 몇바이트 안에서 정의될 수 있는 단순한 일을 하고 있음.

그런데 이런 단순한 일을 처리하기위해서

배터리로 작동하는 저전력 IoT 기기와 허브 사이에 오고 가는 데이터의 크기가 커질 수록 에너지가 낭비되어 배터리 수명을 직접적으로 줄여버림.

따라서 하나의 명령을 실행하기위해 필요한 정보의 뭉텅이인 패킷의 크기를 최소화하고 통신 구조를 단순화하는 것은 최적화된 저전력 프로토콜 설계의 핵심이며, zigbee와 z-wave 베이스의 IoT 제품들은 이러한 원칙에 맞게 가볍게 만들어짐.

매터가 비효율적으로 전력을 많이 소모하는 근본적인 이유는 인터넷 프로토콜 기반의 ip통신 그 자체에 있음. zigbee, z-wave와 같은 저전력 프로토콜은 커널에서부터 애플리케이션 레이어까지 저전력에 최적화된 독자적인 스택을 사용하지만, 매터는 모든 패킷이 거대한 ipv6 스택을 통과해야 함.

ipv6 헤더는 그 자체로 상당한 크기를 가지며, 스레드가 6lowpan으로 이를 압축하려 노력하지만, 태생적으로 짧은 주소를 사용하는 초저전력 프로토콜보다 큰 오버헤드를 가질 수밖에 없음. ip 주소 정보 처리에만 더 많은 에너지를 써야 하고 필연적으로 더 많은 자원을 쓰게되고, 이것은 배터리의 사용을 늘림.

뿐만아니라 ip통신은 모든 패킷을 6lowpan으로 한번에 담아서 보낼 수 없다는 한계를 가지고 있음. 따라서 서버에 여러번에 걸쳐서 패킷을 나누어 보내게됨. 따라서 주기적으로 mcu가 깨워지게됨.

이건 매터 기반의 문열림 센서의 실제 데이터 전송량에서 드러남.

nxp의 AN14841 문서인 '802.15.4 Matter and Zigbee Power Consumption Analysis for MCX W72'를 살펴보면

long idle time이 지원돼서 short idle time을 가진 기기에 비해 전력효율이 높은 matter 1.4의 문열림센서 애플리케이션을 적용한

mcx w72 기반의 매터 디바이스가 문 열림의 감지됨 상태를 리포트하는 총 데이터양은 88 바이트임. 이 데이터를 리포팅하는 것은 단일 패킷의 전송으로 끝나지 않음. 이 리포팅은 여러 패킷으로 나누어져 전송됨.

그리고 보고서에는 이 리포팅의 구체적인 비동기 통신의 이벤트 실행순서와 세션을 소개하고있음

주황색 화살표가 IoT제품이 허브에 보내는 데이터

파란색 화살표가 허브가 IoT제품에 보내는 데이터임.

IoT제품이 허브인 스레드 보더라우터에 22바이트짜리 데이터 요청을 보냄.

허브가 승인을 보냄

허브로부터 승인을 받으면 첫번째 패킷을 보냄

다시 22바이트 데이터 요청을 보냄

허브가 승인을 보냄

이 다음은 500ms의 데이터 폴링 간격를 기다리고 똑같은 사이클을 반복해야함

그 이유는 전체 패킷을 한번에 보내지 못하기 때문임. 따라서 사이클이 계속 도는 과정에서 모두 88바이트의 패킷을 순차적으로 보내게됨

이 과정에서 기기가 잠들고 깨어남을 반복하고 mcu와 802.15.4 라디오를 켜고 끄는것을 수차례 반복하게됨. 리포팅이 너무 잦음.

패킷의 크기가 커지고 사이클이 잦아지니까 제품이 켜지는 시간이 직접적으로 늘어나고, 곧바로 배터리를 더 쓰게됨.

한편 지그비는 기본적으로 zigbee cluster library이라는 표준클러스터를 가지고 있음. 오버헤드를 극한으로 줄인 zcl 표준 덕분에 데이터 밀도가 매우 높음.

csa에서 발행한 Zigbee Cluster Library Specification 문서를 보면 프레임 컨트롤 8비트, 제조사 코드 0~16비트, 트랜젝션 시퀀스 넘버 8비트, 커맨드 ID 8비트가 끝으로 24~40비트, 즉 3~5바이트 안에서 처리하고 있는 극단적으로 작은 케이스임.

제조사가 표준 zcl 외에 자기들만의 커스텀 기능을 넣고 싶을 때는 zcl payload를 쓰는데, 이때는 자기들 마음대로 데이터를 구성함. 하지만 이 역시 지그비 프레임워크 안에서 돌아가기 때문에 매우 작음.

그래서 같은 mcu인 mcx w72 기반의 지그비 디바이스에서는 같은 명령 이벤트가 한번에 처리되어 끝나는걸 알 수 있음. zigbee의 패킷 크기가 작기 때문에 한눈에 봐도 효율적으로 구동되고 있음.

문열림센서는 감지됨과 감지되지 않음으로 센서에 정의된 밸류가 2가지뿐인 매우 단순한 디바이스임. 스마트싱스의 capability로는 contactSensor의 attribute인 contact의 타입은 enum이고 open,closed 단 두가지의 스테이트만이 정의되어 있음. 그리고 스마트싱스 허브의 os인 스마트싱스 허브코어의 언어인 lua에서 이것의 크기는 1바이트임.

그러나 매터가 ipv6을 채택함으로써 문열림센서와 같은 단순한 디바이스에 거대한 패킷이 만들어지는 이벤트가 너무 잦아지게 만들어 더 많은 배터리를 비효율적으로 쓰게되었음.

그리고 여기에는 매터로 인해 IoT기기에게는 넘치는 필요 이상의 스펙을 올린 결과, mcu를 비롯한 보드 자체에서 물리적으로 늘어나게 된 연산에 쓰이는 에너지와 대기전력과 같은 요소도 개입할 수 있음.

이렇게 매터의 문제점인 무거운 패킷과 복잡한 세션을 알아봤음.

다음 매터의 문제점은 스레드 스택과 매터의 long idle time 사이에서 벌어지는 폴링 타임아웃 제한의 부조화와 물리적인 충돌임

그것은 다음 글에서 자세히 설명하겠음

[스싱붕이 1(221.163)]

와 퀄리티 지리노...

[스싱붕이 2(211.107)]

IOT제품 제조사들은 매터 탑재 마케팅할때 이런 효율성 문제는 쏙뺴놓고 말하지 ㅋㅋ

[스싱붕이 3(112.172)]

니가 말하는건 매터오버와이파이 MoW 이고, 이 글에서 말하는건 매터오버쓰레드, MoT 야

[익명(page7888)]

[스싱붕이 4(211.235)]

이글보니까 문열림센서, 온습도같은 기기를 IP체계의 스마트홈에 통합하는게 과연 맞는건지 의문이 듬.... 이미 하나의 플랫폼안에 연결하는 일은 스마트싱스같은 오픈 플랫폼이 더 논리적으로 잘하고있는 일인데 매터로 해보겠다고 복잡해지고 배터리 많이쓰게생겼네

[스싱붕이 8(118.38)]

스싱 엣지나 HA가 예외적인 상황인거지 지그비 자체는 여전히 특정플랫폼 종속이고 투야는 노골적으로 지그비 표준을 씹어드시는 걸 생각하면 IOT 접근성을 높이려면 matter 같은 표준은 필수긴함. 다만 결과적으로 지금처럼 된게 아쉬울 뿐

[스싱붕이 10(1.216)]

그냥 저전력인척하는 ocf임

[스싱붕이 11(1.216)]

럭키 ocf ㅋㅋ

[익명(117.111)]

전력을 희생하고 호환성이나 보안을 챙긴 거 아닐까 특히 보안을 해결 못하면 기업에서는 쓰기 어려우니까

[스싱붕이 9(27.165)]

매터는 신뢰성이 떨어져서 호환성 보안이 무색해지는듯. 매터네트워크 품질이 지그비에 비해 불안정하고 그에비해 지그비 지웨이브들은 기업들 기관들에서 잘쓰일 정도로 신뢰성을 입증 받은상태니까. 패킷분할하는 구조가 패킷드롭 킹능성을 몇 배로 높이는게 원인인거같은데

[익명(117.111)]

@스싱붕이9(27.165) 매터가 1.0 때 안정성이 좀 망하기는 했는데, 제조사들이 매터 1.5 정도 다루는데 익숙해질 때 되면 안정성 문제는 해결될 것 같음 지그비는 4.0에서 보안에 신경 많이 쓴 거 보면, 지그비 3.0은 보안이 좀 불안했던 것 같음 서로 단점 보완하고 나면 일단은 호환성의 매터 / 저전력의 지그비 이렇게 나뉘지 않을까

[햄식이(hamsig)]

@ㅇㅇ(117.111) 지그비의 호환성은 오픈플랫폼의 힘으로 돌파할수있음 그러나 매터의 안정성은 제조사 커스텀 여지가 적고 설계문제임 시장이 나뉠거같은데 이대로가면 제대로 스마트홈 하려는 사람들이 지그비로 가고, 멋모르는 경우는 일반 와이파이로 가서 개인적으로 매터 입지는 어중간해질거로 보임. 매터제품은 선택받겠지만 그건 기기 자체의 매력에서 오는거지 매터로부터 오는건 X

[햄식이(hamsig)]

@ㅇㅇ(211.36) 엣지드라이버 딸깍이면 연결되는걸 표준 지그비 클러스터제품들은 그런거 없이 바로 연결되고 현재 스마트홈 제대로 하려는 사람들은 오픈 플랫폼을 선택하고 있고, 허브와 프로토콜의 개념에 대해서 이해하고 있음. 그 밖에 사람들은 그냥 단일 기기 몇개 원격제어 용도지 그러면 후자는 와이파이나 블루투스같은거 살 수 있음. 매터가 노리는건 전자 아님? 전자가 과연 지그비와 같은 효율적인거 말고 매터를 고를 이유가 딱히 안보이는데. 그저 선택가능한 범위에 있을 뿐이지. 예를들면 내가 지그비센서 매터센서 있으면 지그비 센서 고를거임. 근데 매터제품중에 좋은게 있으면 그걸 살텐데 그건 매터라서 사는게 아니라 제품이 좋아서 살거임.

[익명(211.36)]

@햄식이 엣지 드라이버 딸깍이면 되는데 그거 라이트 유저들한테 설명해보셈. 게다가 제조사 공식 드라이버도 아니고 유저들이 만든 걸 설치하게 만드는 게 쉬운지. 윈도우에서도 드라이버도 설치 딸깍이면 되지만 시장성 큰 라이트 유저들은 그거 못함. 그리고 매터가 호환성에 왜 그렇게 집착했겠음? 라이트 유저 잡으려고 그런 거임. 매터가 노리는 건 달인 기기 몇 개 원격제어하고, 관심 조금 더 있으면 자동화나 보이스 어시스턴트 조금 추가하는 유저들임. 어차피 하드 유저들은 지그비 기기 알아서 쓰는데 더 잡을 필요도 없음.

[익명(211.36)]

@햄식이 라이트 유저들이 처음에는 허브 없이 클라우드로 쓰다가, 관심 생기면 아무 허브나 골라서 쓸 수 있게 만드는 게 매터임. 지그비 반쯤 버린 아마존, 지그비 버린 애플 구글, 와이파이 가전 위주로 만드는 삼성이 점유율 높은 게 다 라이트 유저 잡아서 그런 거임. 그리고 매터가 프로토콜로 와이파이 고른 게 그렇게 보급 쉽다는 이유 때문이고. 지금 스마트홈 시장 커지고 있는 건 매터 오버 와이파이로 호환성 잡은 덕분이지 그냥 와이파이 기기라서 그런 게 아님. 어떤 제조사 제품이든 매터 마크 박힌 거 구입하면 아마존 구글 애플 삼성 허브에 등록해서 쓸 수 있다, 제조사 망해도 상관 없다, 이게 얼마나 큰 장점인데.

[햄식이(hamsig)]

@ㅇㅇ(211.36) 매터오버 와이파이는 좋은게 맞고 솔직히 매터가 와이파이로만 갔으면 더 좋은 평가를 받을 수 있다고보고, 특히 매터오버와이파이는 상시전력쪽으로 지그비와 비교할 대상은 아닌거같음. 내가 애매하다고 말하는건 매터오브쓰레드쪽임

[햄식이(hamsig)]

@ㅇㅇ(211.36) 센서를 사는 사람들은 거의 100% 자동화를 하려고 삼. 자동화를 짜는 사람은 0부터 시작하지않고 보통 인터넷에서 프로유저들이 해놓은거 보고 따라함. 그리고 그것은 한결같이 오픈플랫폼, 허브, 디바이스와 세팅방법들 등의 정보를 포함하고 있음. 이 시점에서 폐쇄형 플랫폼인 애플 구글 아마존은 탈락된다고 봄. 이야기하다보니 라이트유저를 좀 더 세분화할 필요도 있어보이네. 센서를 쓰는 사람과 상시전원 액추에이터 계열의 제품을 사는 사람으로. 전자는 자동화하려는사람, 후자는 그냥 원격제어 느낌이 강함. 매터오버쓰레드가 노려야하는건 자동화하려는 라이트유저 쪽인데, 이 사람들은 매터에 관심 가질수는 있지만 이미 오픈 플랫폼 고른 상황에서 매터를 고른다? 글쎄다 싶네. 프로유저 따라가는 특징+매터제품이 비쌈까지

[익명(211.36)]

@햄식이 배터리 때문에 매터 오버 스레드 써야 하는 슬리피 엔드 디바이스 문제는 매터가 빨리 해결해야하는 문제인 건 맞음. 그런데 매터 1.1에서 그 문제 많이 개선 됐고, 매터 판 올라갈 때마다 연결 문제 관련 업데이트 계속 추가되고 있음. 나도 매터 오버 스레드 1.3 제품 몇 개 쓰는데 연결 문제는 없음. 연결만 안정화되면 배터리가 지그비보다 구리기는 해도 2년은 갈 거니까. 지금 시장의 매터 오버 스레드 제품이 구린 건 1.규격 만들고 몇 년 안 되어서 개발자와 제조사가 덜 익숙한 점, 2.불안정했던 제품의 재고가 아직 소진되지 못한 점이 크다고 본다. 이건 진짜 시간 지나면 해결될 문제임. 문제 개선 되고 나면, 매터 오버 스레드의 단점은 지그비보다 배터리 수명 조금 짧은 거 말고는 없어질 거라고 봄.

[햄식이(hamsig)]

@ㅇㅇ(211.36) 나는 쓰레드 제품은 없고 매터는 와이파이로만(위즈, 타포) 쓰고있지만 매터랑 쓰레드 설계에서 터지는 문제들을 읽어보면 회생가능성이 없어보임. 호환성을 위해 스펙 자체가 희생하도록 만들어져서 메시구조, 쓰레드 Timeout이랑 LIT충돌, 페이로드 등등 글쓴게이가 언급한 문제들이 터졌는데 이걸 뜯어고치려면 매터 자체를 갈아엎어야지 제조사가 커스텀으로 극복하기는 어려워보임

[햄식이(hamsig)]

@ㅇㅇ(211.36) 쉽게말해 지그비는 플랫폼으로 호환성을 돌파할 수 있지만 매터는 단일기기의 커스텀으로 비효율을 돌파하기 어려움.

[익명(211.36)]

@햄식이 제조사가 커스텀할 수 있게 만들면 호환성 또 망하는 거니까 그렇게는 안 할 거고, 매터 버전 올리면서 고치겠지. 규격 자체에서는 이미 꽤 많이 해결하기도 했고. 지금 매터 오버 스레드의 제일 큰 문제는 제조사가 매터 규격에 익숙해지려면 시간이 필요하다는 점이라고 본다. 이제 규격 자체 문제는 아니라고 봄. 이케아도 새로 출시한 센서 연결 문제가 있는 것 같은데, 매터 제품 출시가 처음이라 그런 거라고 본다. 그나마 이케아는 시간이 걸리더라도 패치는 해 주는 회사니까 희망은 있다고 봄.

[햄식이(hamsig)]

@ㅇㅇ(211.36) 매터오버쓰레드에서 터지는 문제들의 원인이 인터넷 프로토콜을 기반으로한 네트워크를 강요하는 쓰레드의 특징이라서 버전업으로 불가능해보이는데...? 인터넷을 버릴순 없잖아. 근데 이케아 나오면 어떤거 살거임? 알프스투가 말고 끌리는거 없던데. 집에 스싱 공식모션이랑 아카라 모션 있어서 모션은 안살거같음

[익명(211.36)]

@햄식이 매터가 1.1, 1.2에서는 일단 연결이 안 끊어지게 만드는데 집중했음. 그리고 매터 1.3에서 sit 안정화, 매터 1.4에서 lit 도입 같은 배터리 최적화 기술이 들어갔음. 규격 자체는 어느 정도 정리됐으니 제조사 적응 기간이 필요하다고 본다. 이케아 제품은 알프스투가 사서 놓고, 모션 센서 사서 자동화 안 된 곳에 추가하고, kajplats 전구 몇 개 살 예정임. 화이트 스펙트럼 전구가 1521루멘으로 엄청 밝고 2200k-6500k로 나온 것 같아서 밝은 조명 필요한 곳에 좀 설치할 예정.

[햄식이(hamsig)]

@ㅇㅇ(211.36)
LIT은 그냥 매터에서 정의 가능한 수치이고 실제 적용이 안됨
https://m.dcinside.com/board/smartthings/12302

[익명(211.36)]

@햄식이 호환성과 검색 관련해서 내가 말하고 싶은 건, 나름 헤비 유저라는 사람들도 그렇게 검색해야 하고, 검색을 해도 드라이버 문제로 못 쓰는 제품이 있을 정도로 지그비 호환성은 이미 어렵다는 거임. 매터 제품은 본체 버튼 길게 누르고, 스마트폰 들고 qr코드 찍으라고 하면 되는데.

[햄식이(hamsig)]

@ㅇㅇ(211.36) 지그비는 지그비변종이 아니면 스마트싱스의 경우는 드라이버 없이도 연결해서 쓸 수 있음. 이 경우 정의되어있는 데이터를 전부 조회할 수는 없고 그걸 뚫어주는게 엣지드라이버인데, 그건 매터도 같은 조건임. 매터 역시 스펙에서 매터가 접근할수있는 데이터의 리미트를 정의해놓고있고, 이미 자사앱에 기능이 더 많은 그런 제품들이 있음. 그리고 그걸 뚫어주는게 또 엣지드라이버임. 물론 이건 스마트싱스에서 해당되는 거지 폐쇄형 플랫폼은 어림도 없는거지만 이미 이정도까지 이야기할정도면 폐쇄형 플랫폼 유저가 아니니까 뭐 상관없겠지

[익명(211.36)]

@햄식이 내가 느끼기에 매터 오버 스레드 배터리는 어차피 지그비 못 따라감. 지그비로 5년 쓸 거 매터 오버 스레드로 3년 쓰세요 수준임. 아니면 배터리 조금 더 큰 거 쓰거나, 교체가 쉬운 배터리 쓰거나. 쓸 만한 정도로 만들어서 라이트 유저 잡는 게 매터의 목적이지, 배터리 효율까지 지그비 따라잡아서 시장 다 먹겠다는 게 목표가 아닌 것 같음. 어차피 라이트 유저 입장에서는 기기 숫자가 적어서, 배터리가 5년 가나 3년 가나 대단한 차이가 아님. 기업이나 헤비 유저처럼 센서 100개 달고 쓰는 사람들은 지그비 4.0이나 매터 브릿지 쓰라는 거겠지.

[햄식이(hamsig)]

@ㅇㅇ(211.36) 비효율적 구조때문에 속도도 느려서 뭐.. 당장 리포팅을 지그비보다 5배는 무겁게 던지는 판인데 지그비 잡는건 불가능하지않을까. 자동화를 하려고 센서 사는 입문 유저들 입장에서 매터오버스레드도 고려할 리스트 안에는 있겠지만 지그비두고 고를 메리트가 없어보임. 뭐 나는 이케아 갈때 사보고 게이가 말한 제품들도 구경도 해봐야겠네.

[익명(211.36)]

@햄식이 게임기를 보면 해당 세대 초창기 게임이랑 말기 게임이랑 최적화 차이가 엄청나게 난다. 마찬가지로 지그비는 엄청 오래 쓴 기술이니까 하드웨어 개발자들이 최적화를 개빡세게 해놓아서 지금의 미친 효율이 나오는 거고. 매터도 매터 오버 와이파이로 입문 통로 넓혀 놨으니, 초창기 유저들로 유료 베타테스트 해서 매터 오버 스레드도 개선할 걸로 본다.

[스싱붕이 5(223.118)]

발기를 변경할수있구나

[스싱붕이 7(125.130)]

지그비 = 고트

[스싱붕이 12(118.41)]

배터리를 많이 갉아먹는것도 치명적이지만 그거 말고도 IoT 기기 자체가 배터리 구동+초저사양+메쉬 토폴로지라는 특징이 있기 때문에 통신 오버헤드가 조금만 커져도 체감 성능이 크게 떨어짐

[스싱붕이 12(118.41)]

매터 오버 스레드의 주요 단점이 자동화가 가끔씩 늦게 반응하거나 빼먹고 기기 추가나 재설정이 자주 실패하거나 오래 걸리는 현상 등인데 거기에 영향을 미치는것중 하나가 통신 오버헤드임