Matter и Zigbee в умном доме

Почему возникает путаница

На коробке одного устройства написано Zigbee, на другом Matter, у третьего Matter over Thread, а хаб одновременно поддерживает несколько протоколов.

Из этого легко сделать неверный вывод, что все названия описывают одно и то же.

Удобнее разделить систему на уровни:

1. как устройство физически связано с сетью;
2. как передаются данные;
3. каким языком описаны функции устройства;
4. где выполняется автоматизация;
5. какие экосистемы получают доступ к функциям.

После такого разделения роль каждого стандарта становится понятнее.

Zigbee — сеть устройств

Zigbee давно используется для датчиков, кнопок, реле, ламп, термостатов и другой автоматики.

Его сильная сторона — mesh-сеть.

Стационарные устройства, способные маршрутизировать трафик, формируют сетевую инфраструктуру. Батарейные конечные устройства могут большую часть времени спать и экономить энергию.

Для дома это удобно там, где нужны десятки маломощных устройств без отдельного Wi-Fi-подключения каждого датчика.

Matter — общий прикладной язык

Matter решает другую проблему.

Рынок умного дома долго состоял из отдельных экосистем. Даже если две лампы выполняли одинаковую функцию, разные платформы могли описывать и подключать их по-разному.

Matter создаёт стандартизированную модель устройств, команд и состояний.

Совместимая лампа должна быть представлена как лампа, розетка как розетка, замок как замок, независимо от того, какая поддерживаемая экосистема взаимодействует с устройством.

Это уменьшает количество специальных интеграций между каждой парой производителей.

Matter работает поверх IP

Matter использует IP-сети.

В домашней инфраструктуре это прежде всего:

• Ethernet;
• Wi-Fi;
• Thread.

Это важное отличие от Zigbee.

Zigbee формирует собственную сеть, а Matter использует IP-транспорт.

Поэтому фраза «Matter или Wi-Fi» тоже не совсем корректна. Matter-устройство может использовать Wi-Fi как транспорт.

А маломощное Matter-устройство может использовать Thread.

Thread тоже не является Matter

Thread — IPv6 mesh-сеть для маломощных устройств.

Matter может работать поверх Thread, но Thread сам по себе не является Matter.

Можно представить уровни так:

Zigbee в такой схеме находится рядом как отдельный стек со своей mesh-сетью и прикладной моделью.

Зачем тогда оставлять Zigbee

Потому что в мире уже существует огромная установленная база Zigbee-оборудования, а сама технология продолжает развиваться.

Connectivity Standards Alliance прямо рассматривает совместное существование Zigbee и Matter и предусматривает мосты между ними.

Zigbee 4.0 дополнительно развивает безопасность, commissioning, работу маломощных устройств и Sub-GHz направление Suzi.

Поэтому появление Matter не делает исправные Zigbee-устройства бесполезными.

Matter Bridge соединяет два мира

Ключевой механизм — Matter Bridge.

Мост подключён к Zigbee-сети и одновременно представляет поддерживаемые Zigbee-устройства в Matter-экосистеме.

Упрощённая схема выглядит так:

Пользователь при этом может вообще не видеть границу между протоколами.

В интерфейсе остаётся обычная лампа, датчик или розетка.

Мост — не простой переводчик пакетов

Хорошая реализация должна сопоставить возможности Zigbee-устройства с моделью Matter.

Например, реальное устройство может иметь:

• включение;
• яркость;
• цветовую температуру;
• измерение энергии;
• дополнительные фирменные параметры.

Мост определяет, какие возможности можно корректно представить наружу.

Поэтому наличие Matter Bridge не означает, что абсолютно каждая нестандартная функция любого Zigbee-устройства автоматически появится во всех Matter-экосистемах.

Пример: датчик движения

Представим Zigbee-датчик движения.

Внутри HouseClever он подключён к локальной Zigbee-сети.

Локальный сценарий может выглядеть так:

Для выполнения этой функции облако не требуется.

Если датчик дополнительно представлен через Matter Bridge, его состояние может быть доступно совместимой внешней системе.

Но локальная автоматизация HouseClever при этом не обязана переноситься во внешнюю экосистему.

Это важное разделение

Устройство можно показать внешней платформе и при этом сохранить основную автоматику локально.

Для инженерного умного дома это сильная архитектура.

Внешняя экосистема получает удобный пользовательский доступ.

Контроллер объекта сохраняет локальные сценарии, аварийную логику и связи между инженерными системами.

Зачем хабу несколько протоколов

Современный контроллер может одновременно работать с несколькими сетями.

Это не недостаток архитектуры.

Разные устройства имеют разные требования.

Matter может объединить часть этих устройств на уровне общей модели, но физическая связь всё равно остаётся разной.

Один протокол на весь дом не является целью

На первый взгляд кажется удобным выбрать одну технологию для всего.

Но требования камеры и датчика протечки принципиально различаются.

Камере нужна высокая пропускная способность и постоянное питание.

Датчику протечки важнее малое энергопотребление и длительная работа от батареи.

Контроллеру нужна предсказуемая стационарная связь.

Воротам на удалённой части участка может понадобиться большая дальность.

Поэтому хорошая архитектура унифицирует управление, а не обязательно физический транспорт.

Как это выглядит в HouseClever

HouseClever может отделить возможности устройства от способа связи.

Верхнему уровню нужна функция:

включить свет

или:

получить температуру

или:

закрыть клапан.

Ниже runtime знает, каким устройством реализована функция и через какой транспорт с ним взаимодействовать.

Это позволяет развивать нижний уровень без переписывания всех сценариев.

Matter как внешний слой совместимости

Есть ещё один полезный вариант.

HouseClever управляет устройствами локально, а наружу публикует часть возможностей через Matter Bridge.

Тогда одна физическая система может оставаться основным владельцем автоматизации, но совместимые функции становятся доступны другим платформам.

Например:

Это лучше, чем строить отдельную физическую сеть для каждого голосового ассистента или приложения.

Что должно оставаться локальным

Не вся логика дома должна зависеть от внешней платформы.

Особенно это касается функций, связанных с безопасностью и работоспособностью здания:

• защита от протечек;
• критические климатические ограничения;
• управление резервным питанием;
• отключение некритических нагрузок;
• аварийные реакции;
• базовые сценарии освещения;
• восстановление после потери связи.

Matter может дать удобный доступ к состояниям и командам, но локальный контроллер остаётся естественным местом для такой логики.

Что происходит без интернета

Matter не означает автоматически «облако».

IP-сеть может существовать локально без доступа во внешний интернет.

Zigbee также работает как локальная сеть.

Поэтому архитектуру можно построить так, чтобы основные функции внутри объекта продолжали работать при потере внешнего канала.

Это один из принципов HouseClever: внешние сервисы расширяют возможности, но базовые функции здания не должны исчезать только из-за недоступности интернета.

Zigbee Direct добавляет ещё один вариант

Zigbee Direct позволяет Bluetooth LE-устройствам, например смартфону, участвовать в onboarding и управлении Zigbee-сетью через стандартизированный механизм.

Это ещё раз показывает, что современные стандарты развиваются не в сторону «один протокол победит остальные», а в сторону удобного взаимодействия между уровнями.

Zigbee Direct может упростить ввод устройств и отдельные сценарии управления, не превращая Zigbee в Matter.

Где здесь Suzi

Suzi расширяет Zigbee в Sub-GHz диапазон для более дальних маломощных сетей.

Поэтому будущая архитектура большого объекта может выглядеть ещё интереснее:

Это уже не набор конкурирующих логотипов, а слои одной системы.

Что важно при выборе оборудования

Не стоит покупать устройство только из-за надписи Matter или Zigbee.

Сначала определяют функцию.

1. Что устройство должно делать?
2. Где оно установлено?
3. Есть ли постоянное питание?
4. Нужен ли кабель?
5. Какова требуемая дальность?
6. Должно ли оно работать при отсутствии интернета?
7. Участвует ли оно в критическом сценарии?
8. Нужно ли показать его другим экосистемам?
9. Какие состояния и команды должны быть доступны?
10. Как система поведёт себя при потере связи?

После этого выбирают подходящую технологию.

Ошибка: строить архитектуру по логотипам

Наличие одинакового логотипа на двух коробках ещё не означает одинаковое качество устройства, радиосвязи или программной реализации.

И наоборот, устройства с разными протоколами могут отлично работать в одной системе, если контроллер правильно разделяет транспорт, capabilities и автоматизацию.

Для владельца важнее конечный результат:

• команда выполняется;
• состояние подтверждается;
• сценарий работает локально;
• отказ одного внешнего сервиса не ломает дом;
• устройство можно заменить без перестройки всей архитектуры.

Что меняется для проектировщика

Раньше вопрос часто звучал так:

Какой протокол выбрать для умного дома?

Полезнее задавать другой:

Какой транспорт нужен каждой функции и как объединить их в одну управляемую систему?

Это меняет сам подход к проектированию.

Протокол становится инструментом, а не архитектурой целиком.

Практическая схема HouseClever

Для нового объекта разумна многоуровневая модель:

• кабельная сеть для стационарной инфраструктуры;
• маломощная mesh-сеть для датчиков;
• IP mesh там, где нужен Matter over Thread;
• дальний радиоконтур для распределённых точек, если он нужен;
• единый локальный контроллер;
• Capability Runtime над транспортами;
• Matter Bridge для совместимых внешних экосистем;
• критические сценарии внутри объекта.

Такой дом не зависит от судьбы одного протокола.

Главное

Matter и Zigbee не нужно сталкивать друг с другом.

Zigbee остаётся эффективным способом построить локальную сеть множества устройств.

Matter стандартизирует взаимодействие между совместимыми устройствами и экосистемами поверх IP и позволяет подключать существующие технологии через мосты.

Для HouseClever это естественно укладывается в модульную архитектуру: транспорт находится внизу, capabilities — выше, сценарии работают с функциями, а внешние экосистемы получают только тот уровень доступа, который им действительно нужен.

FAQ

Matter заменяет Zigbee?

Нет. Matter и Zigbee решают разные задачи и могут сосуществовать в одном объекте. Matter предусматривает мосты для представления устройств других технологий, включая Zigbee.

Matter работает по Zigbee?

Нативный Matter использует IP-транспорт, включая Ethernet, Wi-Fi и Thread. Zigbee-устройства могут быть представлены в Matter через мост.

Что такое Matter Bridge?

Это устройство или программно-аппаратный узел, который представляет совместимые функции устройств другой сети, например Zigbee, в Matter-экосистеме.

Thread и Zigbee — одно и то же?

Нет. Обе технологии могут строить маломощные mesh-сети, но Thread является IP-сетью, а Zigbee использует собственный сетевой и прикладной стек.

Нужен ли Zigbee-хаб, если есть Matter?

Для Zigbee-сети всё равно нужен подходящий способ управления ею. В конкретной архитектуре эту функцию может выполнять контроллер или мост, который одновременно представляет устройства в Matter.

Будут ли Zigbee-сценарии работать без Matter?

Да. Zigbee-сеть и локальная автоматизация могут существовать независимо от Matter. Matter нужен тогда, когда требуется стандартизированное взаимодействие с совместимыми Matter-системами.

Что лучше для HouseClever?

Не выбирать один протокол для всех задач. Стационарную инфраструктуру, батарейные датчики, внешние интеграции и дальние устройства рациональнее рассматривать отдельно, а затем объединять их единым уровнем управления.