Різниця між ZigBee та Z-Wave?

Я встановив вимикачі та розетки Z-Wave у кількох місцях свого будинку. Однак я помітив, купуючи пристрої, що у бренду, на який я дивився, є кілька різних бездротових варіантів.

Мені буде цікаво дізнатися деякі плюси та мінуси між Z-Wave та ZigBee пристроями. Таке порівняння, як цей пост про те, коли використовувати WiFi через Bluetooth, було б дивним.

Наприклад, мені цікаво інформація, наприклад, якщо один стиль потенційно сприятливіший в будинках з багатьма стінами або якщо один ярмарок краще в "галасливих" бездротових будинках (наприклад, безліч бездротових пристроїв / типів сигналу).

Я думаю, що в основному вам слід подбати: чи рішення ZigBee 2,4 ГГц або 868/908 МГц? 2,4 ГГц проникає менше, ніж ~ 900 МГц через стіни, а 2,4 ГГц ділиться спектром з Wifi, Bluetooth, мікрохвильовою піччю. Z-Wave використовує лише діапазон 900 МГц.

Обидва рішення мають повні мережеві стеки, але вони не є сумісними, принаймні, не для таких програм, як управління світлом. Жодна з цих технологій не є поширеною в мобільних телефонах, і тому, якщо ви хочете контролювати додаток, вам потрібно пройти через шлюз для обраної технології.

Є кілька речей, які дійсно відрізняють Z-Wave і ZigBee один від одного.

Частота

Перший (як зазначав Ейрік М) - це частота, з якою вони діють. Z-Wave працює в діапазоні ISM 915 МГц. Це забезпечує розумне проникнення будівельних матеріалів (краще, ніж Wi-Fi) та хорошу загальну відстань. Той факт, що мало хто з інших побутових пристроїв використовує цю смугу (тепер, коли бездротові телефони 900 МГц менш поширені) означає, що також є менше перешкод.

ZigBee може працювати на частотах 2,4 ГГц або 915 МГц. ¹ 2,4 ГГц - це зайнятий діапазон; саме там працюють Wi-Fi та мікрохвильові печі (серед іншого). Це означає, що пристрої ZigBee 2,4 ГГц піддаються більшої інтерференції, ніж пристрої Z-Wave та ZigBee 915 МГц. Вони також не проходять крізь стіни так легко. (Діапазон 2,4 ГГц дає більш високі швидкості передачі бітів, тому WiFi живе там (а також використовує діапазон 5 ГГц), але більшості пристроїв IoT не потрібно швидко передавати багато даних, тому нижня пропускна здатність 915 МГц гурт не є недоліком.)

¹ 915 МГц використовується лише в Північній Америці. Хоча 2,4 ГГц доступний у всьому світі, нижча частота діапазону ZigBee варіюється від одного регулятивного регіону до іншого. Різні діапазони в основному знаходяться в діапазоні від 700 МГц до 900 МГц, тому твердження про діапазон 915 МГц в Північній Америці, як правило, застосовні і для інших регіонів.

Відкритість

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 підтримує ряд різних профілів, які мають спільний протокол, але використовують різні деталі зв'язку. (Це дещо аналогічно двом різним API HTTP; обидва використовують HTTP як транспорт, але API Карт Google не буде дуже корисним, якщо ви спілкуєтесь із серверами GitHub.) БільшістьПристрої IoT ZigBee використовують профіль домашньої автоматизації, але це, як правило, не зафіксовано на пристрої, тому ви можете зіткнутися з несподіваними проблемами. Наприклад, світильники Philips Hue використовують ZigBee, але робіть це навмисно непрацюючим способом, тому вам доведеться використовувати міст Philips Hue Bridge для управління ними. (На відміну від Z-Wave: процес сертифікації Z-Wave вимагає, щоб будь-які лампочки Z-Wave використовували стандартні класи управління, і, таким чином, ними можна керувати будь-який сумісний контролер Z-Wave.)

На даний момент Альянс ZigBee розробляє нову ітерацію протоколу ZigBee під назвою ZigBee 3.0. Схоже, що метою нової специфікації буде збільшити сумісність пристроїв 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); хоча вони можуть мати шлюзи, які дозволяють іншим системам керувати ними, лише ті пристрої компанії можуть приєднуватися до мережі.

Як хлопець із програмного забезпечення - і хлопець у цьому стеці - я схильний дивитися на це інакше, ніж ви могли.

Для мене ці протоколи - це матеріали "низького рівня" ( шари 1 і 2 моделі шару OSI 7 ).

Мене особливо не хвилює споживання електроенергії, якщо пристрій не працює від акумулятора або сонячної енергії. У своєму професійному житті я можу залишити рішення щодо апаратного забезпечення, яке, якщо воно не працює, має тенденцію диктувати вибір протоколу 2 рівня, апаратним хлопцям. У своєму приватному житті я вибираю за ціною, підтримкою (розмір спільноти та доступність форумів дуже важливий) та найкраще розуміння специфікації

Я прагну шукати функціональність загальної системи. Наприклад, для сітчастих мереж є чудові рішення ZigBee.

Наприклад, чи спрацьовують деякі сигнали краще далекого, а інші - в "галасливих" умовах?

Для далекої дальності я не можу рекомендувати достатньо високий Flutter з дальністю в 1 км / півмилі, на відміну від 100 м.

Він коштує лише 20 доларів США, і ось малюнок, щоб дати вам деяке уявлення про асортимент

Шумні середовища не є моєю спеціальністю - я залишаю це апаратним хлопцям, вибачте, - але ви, можливо, захочете заглянути до таких речей, як ліміт Шеннона , який є програмним забезпеченням, на відміну від апаратного, підходу до шуму (також, Forward Error Correction , тощо)

Як я вже говорив, ці протоколи - це "низький рівень" для мене, як розробника додатків (власне, рівень 3), який трохи нижче.

Так, важливо врахувати таку річ, але багато хто просто скаже «Я знаю, я поїду з Raspberry PI (або що завгодно)» і прийму все, що вона пропонує.

Після цього, розробляючи свою програму, потрібно вирішити, який протокол вищого рівня використовувати. Як правило, якщо ваш сервер не диктує певний протокол, у вас є три основні варіанти:

• Використовуйте TCP та розробляйте фірмовий протокол.
• Використовуйте HTTP (S) і розробіть інтерфейс RESTful (перейдіть на AJAX, якщо ви хочете асинхронний, не блокуючий, наприклад, якщо ви маєте багатопотокові). Якщо у вас є безліч транзакцій, критичні за часом або ваші операції з сервером займуть багато часу, ви можете піти з блокувальним інтерфейсом.
• Виберіть один із безлічі "стандартів" IoT. Я б радив це лише у тому випадку, якщо ваш пристрій підтримує один конкретний протокол або якщо цього вимагає ваш сервер.

Я сподіваюся, що я правильно зрозумів ваше питання. Можливо, ви можете сказати нам, чи більше ви орієнтовані на апаратне чи програмне забезпечення, і чи будете ви розробляти лише для пристрою IoT, або також для сервера, чи, можливо, це лише загальне питання (яке не рекомендується)?