ZigBee와 Z-Wave의 차이점은 무엇입니까?

집 주변의 몇 곳에 Z-Wave 스위치와 콘센트를 설치했습니다. 그러나 장치를 구입할 때 내가보고 있던 브랜드에 몇 가지 다른 무선 옵션이 있음을 알았습니다.

Z-Wave와 ZigBee 장치의 장단점을 알고 싶습니다. 블루투스를 통한 WiFi 사용시기에 대한 이 게시물 과 같은 비교 는 놀랍습니다.

예를 들어, 벽이 많은 주택에서 한 스타일이 더 유리한지 또는 "시끄러운"무선 주택 (예 : 많은 무선 장치 / 신호 유형)에서 박람회가 더 나은지 등의 정보가 궁금합니다.

ZigBee 솔루션이 2.4GHz 또는 868 / 908MHz입니까? 2.4GHz는 벽을 통해 ~ 900MHz 미만으로 침투하며 2.4GHz는 Wifi, Bluetooth, 전자 레인지와 스펙트럼을 공유합니다. Z-Wave는 900MHz 대역 만 사용합니다.

두 솔루션 모두 완전한 네트워크 스택을 가지고 있지만 적어도 조명 제어와 같은 응용 프로그램에는 적합하지 않습니다. 어떤 기술도 휴대 전화에서 일반적으로 사용되는 것은 아니므로 앱 제어를 원할 경우 선택한 기술의 게이트웨이를 통과해야합니다.

Z-Wave와 ZigBee를 실제로 구별하는 몇 가지가 있습니다.

회수

첫 번째는 Eirik M이 지적한대로 작동 빈도입니다. Z-Wave는 915MHz ISM 대역 내에서 작동합니다. 이를 통해 건축 자재 (Wi-Fi보다 나은)가 합리적으로 보급되고 전체 거리가 양호합니다. 그 대역을 사용하는 다른 가정용 장치가 거의 없다는 사실 (현재 900 MHz 무선 전화기가 널리 보급되지 않음)은 간섭이 적다는 것을 의미합니다.

ZigBee는 2.4GHz 또는 915MHz에서 작동 할 수 있습니다. ¹ 2.4GHz는 통화 중 대역입니다. Wi-Fi 및 전자 레인지가 작동하는 곳입니다. 즉, 2.4GHz ZigBee 장치는 915MHz Z-Wave 및 ZigBee 장치보다 더 많은 간섭을받습니다. 그들은 또한 쉽게 벽을 통과하지 않습니다. (2.4GHz 대역은 더 높은 비트 전송률을 제공하므로 WiFi가 5GHz 대역을 사용하는 이유도 있지만 대부분의 IoT 장치는 많은 데이터를 빠르게 전송할 필요가 없으므로 915MHz의 낮은 대역폭 밴드는 단점이 아닙니다.)

¹ 915 MHz는 북미에서만 사용됩니다. 전 세계적으로 2.4GHz를 사용할 수 있지만 ZigBee의 저주파수 대역은 규제 지역마다 다릅니다. 다양한 대역은 주로 700MHz ~ 900MHz 범위에 있으므로 915MHz 북미 대역에 대한 설명은 일반적으로 다른 지역에도 적용됩니다.

개방 상태

ZigBee는 개방형 표준이지만 ZigBee 장치를 판매하려면 ZigBee 제휴 (유료)에 가입해야합니다. Z-Wave는 라이센스가있는 독점 표준이지만 고급 프로토콜은 공개적으로 문서화되어 있습니다. Z-Wave 하드웨어를 만들려면 Z-Wave Alliance의 사양에 라이센스를 부여한 다음 장치가 표준을 준수하는지 테스트해야합니다. 적절하게 프로그래밍 가능한 인터페이스가있는 Z-Wave 장치를 구입하는 경우 이미 라이센스가 부여 된 하드웨어를 공개 프로토콜 사양과 함께 사용하여 고유 한 소프트웨어를 작성할 수 있습니다.

가격

진입 장벽이 낮기 때문에 ZigBee 장치는 동일한 기능을 가진 Z-Wave 장치보다 저렴할 수 있습니다. 물론 소비자 IoT 하드웨어는 여러 가지 이유로 가격이 다양 할 수 있습니다.

상호 운용성

Z-Wave 장치는 전체적으로 더 나은 상호 운용성을 갖는 경향이 있습니다. Z-Wave 표준의 새 버전이 출시 될 때 이전 버전과의 호환성을 유지했습니다. Z-Wave 장치는 각각의 연령이나 제조업체에 관계없이 다른 Z-Wave 장치와 현명하게 통신 할 수 있어야합니다. (새로운 프로토콜 기능은 존재하지 않지만 이전 기능은 유지됩니다.) 상호 운용성 테스트는 Z-Wave 준수 프로세스의 일부입니다. ZigBee는 엄격한 테스트 방식을 가지고 있지 않기 때문에 서로 대화 할 수 있어야하는 두 개의 ZigBee 장치가 하나 또는 두 장치의 구현 결함으로 인해 불가능한 경우가 있습니다.

또한 ZigBee는 모두 동일한 기본 프로토콜을 공유하지만 다른 통신 세부 사항을 사용하는 여러 다른 프로파일 을 지원합니다 . (이 두 개의 서로 다른 HTTP API에 다소 유사하다;. 전송 등을 모두 사용 HTTP하지만, Google지도 API는 GitHub의 서버로 대화하는 경우 매우 유용 될 수 없습니다) 대부분의IoT ZigBee 장치는 홈 자동화 프로파일을 사용하지만 일반적으로 장치에 문서화되어 있지 않으므로 예기치 않은 문제가 발생할 수 있습니다. 예를 들어 Philips Hue 조명은 ZigBee를 사용하지만 의도적으로 작동하지 않는 방식으로 작동하므로 Philips Hue Bridge를 사용하여 조명을 제어해야합니다. (Z-Wave와 대조 : Z-Wave 인증 프로세스를 위해서는 모든 Z-Wave 전구가 표준 제어 클래스를 사용해야하므로 모든 호환 Z-Wave 컨트롤러로 관리 할 수 ​​있습니다.)

ZigBee Alliance는 현재 ZigBee 3.0이라는 ZigBee 프로토콜의 새로운 반복을 개발하고 있습니다. 새로운 사양의 목표 중 하나는 ZigBee 장치 간의 상호 운용성을 높이는 것 같습니다. 그래도 어떻게 진행되는지 살펴 봐야합니다. 그러나 새로운 표준의 완성을위한 시간표는 아직 보이지 않습니다.

유사점

위의 내용을 작성하는 한 ZigBee와 Z-Wave가 IoT 장치에 사용되는 다른 프로토콜과 차별화되는 공통점을 언급했습니다.

ZigBee와 Z-Wave는 모두 메시 네트워크입니다. 모든 장치에서 컨트롤러를 볼 필요가있는 WiFi 및 Bluetooth와 달리 Z * 장치는 동일한 네트워크에있는 다른 Z * 장치와 컨트롤러간에 통신 경로가있는 한 괜찮습니다. (Z-Wave 장치는 Z-Wave 장치와 만 메시되고 특정 프로파일을 가진 ZigBee 장치는 물론 해당 프로파일을 가진 다른 ZigBee 장치와 만 메시됩니다.)

ZigBee 및 Z-Wave는 모두 다중 공급 업체 프로토콜입니다. 위의 "개방성"섹션에있는 내용에도 불구하고 ZigBee와 Z-Wave는 서로 경쟁하는 다양한 회사의 장치를 제공합니다. (예 : Z-Wave 전등 스위치를 만드는 회사에는 GE, Aeotec, Linear, DragonTech 등이 있습니다.) IoT와 관련된 다른 많은 프로토콜은 단일 회사 사일로 (예 : Lutron Caséta)입니다. 다른 시스템이 제어 할 수있는 게이트웨이가있을 수 있지만 해당 회사의 장치 만 네트워크에 참여할 수 있습니다.

소프트웨어 사용자와 그에 대한 프로토콜 스택 사용자로서 나는 이것과 다르게 생각하는 경향이 있습니다.

나에게이 프로토콜은 "낮은 수준"의 것들이다 ( OSI 7 레이어 모델의 레이어 1과 2 ).

장치가 배터리 또는 태양열 전원이 아닌 한 전력 소비는 특별히 신경 쓰지 않습니다. 전문적인 삶에서 하드웨어에 대한 결정을 내릴 수 있습니다. 하드웨어는 기성품 인 경우 하드웨어 사용자에게 Layer 2 프로토콜의 선택을 지시하는 경향이 있습니다. 개인 생활에서 나는 가격, 지원 (커뮤니티의 크기 및 포럼의 가용성이 매우 중요) 및 사양에 대한 최선의 추측 이해를 선택합니다.

전반적인 시스템의 기능을 찾는 경향이 있습니다. 예를 들어 메시 네트워크 의 경우 우수한 ZigBee 솔루션이 있습니다.

예를 들어, 일부 신호가 장거리 작동하고 "잡음이 많은"환경에서 더 잘 작동합니까?

장거리의 경우 100m와 달리 1km / 0.5 마일 범위의 Flutter 를 권장하지 않습니다 .

20 달러 밖에 들지 않으며 여기에 범위에 대한 아이디어를 제공하는 그림이 있습니다.

시끄러운 환경 내 아닌 전문-I는 하드웨어들에 미안 -하지만 당신은 같은 것을 보길 원하는 될 수있는 위치 섀넌 한계 소음 (또한, 하드웨어 반대로, 소프트웨어입니다, 접근 앞으로 오류 수정 , 기타)

내가 말했듯이, 이러한 프로토콜은 응용 프로그램 개발자 (계층 3 사람, 실제로는 조금 더 낮음)로서 저에게 "낮은 수준"입니다.

그렇습니다. 그런 종류의 것을 고려하는 것이 중요하지만, 많은 사람들은 "알고 있습니다. 나는 라즈베리 파이 (또는 무엇이든)와 함께 갈 것입니다."라고 말합니다.

그런 다음 응용 프로그램을 개발할 때 사용할 상위 레벨 프로토콜을 결정해야합니다. 일반적으로 서버가 특정 프로토콜을 지시하지 않는 한 세 가지 주요 선택 사항이 있습니다.

• TCP를 사용하고 독점 프로토콜을 개발하십시오.
• HTTP (S)를 사용하고 RESTful 인터페이스를 개발하십시오 ( 예 : 다중 스레드 인 경우 비동기 비 차단을 원하는 경우 AJAX 로 이동 ). 트랜잭션이 많거나 시간이 중요하지 않거나 서버 작업에 시간이 오래 걸리지 않으면 차단 인터페이스를 사용하여 벗어날 수 있습니다.
• 다양한 IoT "표준"중 하나를 선택하십시오. 장치가 하나의 특정 프로토콜을 강력하게 지원하거나 서버가 요구하는 경우에만 조언합니다.

귀하의 질문을 올바르게 이해하기를 바랍니다. 하드웨어 나 소프트웨어 지향적인지 여부와 IoT 장치 또는 서버용으로 만 개발할 것인지 아니면 일반적인 질문일까요 (권장하지 않음)?