TL;DR
Разбираю реальный кейс нестабильной Zigbee-сети из 50 устройств. Перепробовали всё: антенны, координаторы, каналы, конфиги, wb-rules. Рассказываю, что действительно влияет на стабильность, а что оказалось мифом.
Предыстория
В рамках пуско-наладочных работ необходимо было запустить систему умного дома в жилой двухкомнатной квартире в многоквартирном доме. В основу умного дома выбрано оборудование на протоколе Zigbee:
Освещение(Споты) - mesh-роутеры
Датчики температуры - батарейные датчики
Датчики движения - mesh-роутеры
Реле - mesh-роутеры
Шторы - mesh-роутеры
Из 50 устройств подавляющее большинство являются роутерами, то есть участвуют в построении mesh-топологии и ретрансляции пакетов.
Координатор Zigbee был установлен в углу квартиры.
Wi-Fi-роутер находился примерно в 3 метрах от координатора.
Дополнительно в эфире стабильно присутствуют соседские сети 2.4 ГГц (что характерно для плотной жилой застройки).
Иными словами, среда работы радиоканала изначально была далека от лабораторной:
плотный Wi-Fi-эфир
железобетонные стены
угловое размещение координатора WBE2R-R-ZIGBEE v.2
50 активных Zigbee-устройств
При такой конфигурации ожидалось, что благодаря большому количеству mesh-роутеров сеть будет самобалансироваться и работать стабильно. Однако на практике всё оказалось сложнее.
Симптомы проблемы
После завершения монтажа и проведения пуско-наладочных работ сеть была собрана полностью — все 50 устройств успешно добавлены, сценарии настроены, базовая проверка показала работоспособность.
Однако спустя непродолжительное время начали проявляться проблемы, причём в достаточно резкой форме.
-
Низкий linkquality
У большОго количества устройств(20-30) показатель linkquality оказался нестабильным и периодически снижался до значений, при которых связь становилась ненадёжной(0 - 20 в столбце качества связи).
При этом физически устройства находились в пределах одной квартиры и, с учётом большого количества mesh-роутеров, не должны были испытывать дефицита маршрутов. -
Неодновременная отработка групп устройств
При переключении группы(логической, не z2m-группы) освещения из 5-10 устройств частично начали реагировать с заметной задержкой относительно друг друга.
Часть светильников включалась мгновенно, часть — спустя 0.5–3 секунды.Для пользователя это выглядело как «рваная» работа системы.
-
Отработка не всех устройств
Иногда часть устройств в группе(логической, не z2m-группы) вообще не выполняли команду.
Повторная отправка команды решала проблему, но предсказать, какие именно устройства не отработают в следующий раз, было невозможно. -
Резкое ухудшение работы в вечернее время
Особенно показательной оказалась зависимость от времени суток.
В вечерние часы отклик устройств заметно снижался(увеличились задержки, возрастало количество пропущенных команд) -
Потеря событий от датчиков
Наиболее критичная проблема — датчики движения периодически не отправляли события.
В результате сценарии автоматического включения света в зонах с управлением по движению не отрабатывали, что уже напрямую влияло на пользовательский опыт.
Ход работ
Шаг первый — пересборка топологии сети.
Вместо того чтобы подключать все устройства напрямую к координатору с включённым режимом «разрешить всё», мы перешли к древовидной структуре сети. Ближайшие к координатору устройства подключались напрямую, а остальные — через них. По сути, на каждую комнату выделялось один–два роутера, связанные с координатором, а остальные устройства в помещении уже цеплялись к ним. Это позволило разгрузить координатор и сделать сеть более устойчивой, поскольку координатор имеет ограниченное количество прямых подключений и таблиц маршрутизации.
Шаг второй — проверка влияния физического препятствия.
Мы предположили, что металлическая дверь шкафа автоматизации может ухудшать прохождение сигнала. Однако анализ карты сети и параметра linkquality на главной панели не показал заметной разницы - разница в самых низких позициях составила 1-4 linkquality. При этом нестабильность работы сохранялась, что намекало на наличие других факторов.
Шаг третий — поиск проблем вне Zigbee2MQTT.
Во время наблюдения за сетью стало ясно, что не все сбои связаны непосредственно с z2m. Анализ логики работы сценариев показал периодические аномалии. Это выглядело странно, поэтому мы обратили внимание на нагрузку процессора.
Оказалось, что сервис wb-rules практически полностью загружает CPU до 380-400%(всего ядер 4, а на wb-rules приходилось более 300%). При высокой загрузке контроллер не успевал обрабатывать сообщения MQTT и отправлять команды устройствам, настроенным в node-red.
Дальнейшее расследование показало наличие так называемых «системных скриптов», отвечающих за отображение статусов Zigbee-устройств на главной панели Wiren Board — включая управление шлюзом и кнопку permit join.
После удаления этих скриптов нагрузка на процессор перестала быть проблемой. Более того, стало очевидно, что большое количество Zigbee-устройств в стандартной конфигурации Wiren Board может нарушать обработку данных, поступающих из Zigbee2MQTT.
Скрипты располагались в директории:
/usr/share/wb-rules-system/rules
Шаг четвёртый — настройка радиопараметров.
После устранения проблем с нагрузкой мы перешли к конфигурации радиопараметров Zigbee-сети. В первую очередь проанализировали загруженность каналов Wi-Fi, чтобы минимизировать взаимные помехи.
Zigbee работает в диапазоне 2.4 ГГц и использует каналы 11–26, которые частично перекрываются с Wi-Fi (особенно с каналами 1, 6 и 11). В условиях многоквартирного дома эфир был сильно зашумлён: в зоне видимости стабильно находилось несколько соседских сетей.
Для оценки загрузки использовали сканирование Wi-Fi-эфира (через интерфейс роутера), что позволило определить наиболее занятые участки диапазона.
Выяснилось, что наименьшая активность наблюдается в верхней части диапазона, поэтому был выбран 26-й канал Zigbee. Этот канал находится на краю спектра и реже пересекается с Wi-Fi, что теоретически снижает уровень помех.
Дополнительно увеличили мощность передатчика координатора (параметр усиления) до максимального значения — 20(для CC2652P/CC1352P-2 20 dBm).
Однако на практике смена канала дала лишь незначительное улучшение, что указывало на то, что радиопомехи не являются основной причиной проблемы.
Шаг пятый — Прошивка координатора
Согласно официальной инструкции Wiren Board, я обновил прошивку координатора WBE2R-R-ZIGBEE v.2. На практике это дало незначительное улучшение работы сети, однако на форумах отмечают, что для большинства типичных проблем именно этот шаг оказывается решающим. Перед прошивкой рекомендую сделать резервную копию текущих настроек, чтобы при необходимости можно было быстро восстановить рабочую конфигурацию(в рамках данного кейса резервную копию создать не удалось).
Шаг шестой — Смена координатора
Чтобы окончательно решить проблему со стабильностью сети Zigbee, мы пошли на самый трудозатратный вариант: заменили координатор на Zigbee Sonoff Dongle Plus E монтированный в на Raspberry Pi 5 и прошили его по инструкции Neuracube.
Далее настроили Zigbee2MQTT v2.9.2 согласно официальной документации и заново перестроили сеть, соблюдая древовидную структуру и размещение координатора в геометрическом центре дома.
На практике, согласно прочитанным форумам, чип EFR32MG21 показывает более стабильную работу по сравнению с CC2652P, что смена координатора, вероятно, также повлияло на улучшение работы сети. Для логики автоматизации установили Node-RED прямо на Raspberry Pi 5 — его мощности хватает для обработки всей логики, а данные между контроллером и устройствами передаются по MQTT. При этом на Raspberry Pi использовалась последняя версия Zigbee2MQTT v2.9.2, тогда как на Wiren Board ранее применялась версия v2.5.1, ограниченная официальной поддержкой платформы. В итоге это также могло повлиять на стабильность работы сети и совместимость устройств, особенно в условиях большого количества узлов.
Пример конфигурационного файла ниже:
version: 4 mqtt: base_topic: zigbee2mqtt server: mqtt://localhost:1883 serial: port: /dev/ttyUSB0 adapter: ember baudrate: 115200 rtscts: false advanced: log_level: info channel: 11 network_key: GENERATE pan_id: GENERATE ext_pan_id: GENERATE transmit_power: 127 frontend: enabled: true port: 8080 dashboard: false homeassistant: enabled: false
Обратите внимание на параметр transmit_power: 127 , в инструкции к настройке адаптера указано что максимальное значение будет ограничено оборудованием, поэтому поставили просто большое число.
Параметр channel: 11 оставили по умолчанию при установке.
Вывод
В ходе диагностики стало очевидно, что нестабильность Zigbee-сети в данном кейсе была вызвана не одной причиной, а совокупностью факторов. При этом ключевую роль сыграли не радиопомехи, как можно было предположить изначально, а ограничения платформы и архитектуры системы.
Критичным фактором оказалась перегрузка CPU контроллера. При загрузке на уровне 300–400% система переставала успевать обрабатывать MQTT-сообщения, отправлять команды устройствам и корректно реагировать на события от датчиков. В результате возникали задержки, пропуски команд и потеря событий, несмотря на нормальные показатели linkquality. Это показало, что стабильность Zigbee определяется не только радиоканалом, но и способностью системы обрабатывать данные в реальном времени.
Существенное влияние оказало и размещение координатора. Установка в углу квартиры приводила к неравномерному покрытию сети, увеличению количества промежуточных узлов и росту нагрузки на отдельные роутеры. Перенос координатора ближе к центру позволил выровнять топологию и снизить количество «длинных» маршрутов.
Дополнительным ограничением оказался сам координатор и платформа, на которой он работал. При большом количестве устройств они хуже справлялись с обработкой маршрутов и высокой плотностью mesh-сети. Переход на более производительное устройство и другой координатор в сочетании с актуальной версией Zigbee2MQTT позволил устранить эти ограничения и стабилизировать работу сети.
Отдельно стоит отметить, что изначальная архитектура с подключением большого количества устройств напрямую к координатору также вносила вклад в нестабильность. Перестроение сети в древовидную структуру с распределением нагрузки по роутерам позволило снизить нагрузку на координатор и улучшить устойчивость маршрутизации.
При этом факторы, которые изначально казались основными, на практике оказались вторичными. Радиопомехи от Wi-Fi действительно присутствовали, однако смена канала и увеличение мощности дали лишь незначительное улучшение. Аналогично, физические препятствия в рассматриваемом случае не оказали существенного влияния. Это важно, поскольку на практике именно эти аспекты чаще всего считаются первопричиной проблем.
Полученный опыт позволяет сформулировать несколько практических выводов. В первую очередь необходимо контролировать нагрузку на систему и избегать ситуаций, когда обработка данных становится узким местом. Также критически важно правильно размещать координатор и изначально проектировать топологию сети, а не полагаться на её самобалансировку. При работе с большим количеством устройств стоит учитывать ограничения используемого оборудования и при необходимости выносить Zigbee на более производительную платформу.
Комментарии (55)
akod67
13.04.2026 09:34Спасибо за статью. Пригодится в аргументации в спорах, почему на черновой стадии ремонда лучше всё таки тянуть провода =)
Palmyra-debug Автор
13.04.2026 09:34После такого опыта у меня наоборот пропала неприязнь к zigbee, тут важно сразу учесть много факторов, как и в любом проекте. Обычно все отказывает работать, если клиент хочет подешевле, тогда по комментарию выше вероятность наладки системы резко снижается.
vbifkol
13.04.2026 09:34Перестроение сети в древовидную структуру с распределением нагрузки по роутерам позволило снизить нагрузку на координатор и улучшить устойчивость маршрутизации.
Не очень понятно как вы это делали. Спариванием от роутера? У меня устройства мигрируют по сети по своей воле и им глубоко пофиг, от чего их спаривали, у кого lq выше, туда и приползут.
В первую очередь необходимо контролировать нагрузку на систему и избегать ситуаций, когда обработка данных становится узким местом.
Т.е. захлебнулся контроллер WB?
Поддержу предыдущего оратора по поводу невнятных устройств, особенно роутеров и выключателей в сети.
Palmyra-debug Автор
13.04.2026 09:34Да, можно в z2m указать конкретное устройство-роутер через которое планируем подключать. Но по наблюдениям версия старая v2.5.1 пыталась всячески игнорировать пожелания, тогда как в новой все строилось именно так как планировали. Отмечу что "автоматическая" перепривязка устройств происходит после полной потери устройства из сети, но более точно ответить не смогу, поскольку плотно не занимался этим. Кстати из этого вытекает интересный факт, после полного отключения того же контроллера-адаптера сеть перестроится как ей хочется(надо уточнить) и положение адаптера в географическом центре остается единственным важным фактором при перестройке.
Да, процесс перекладки топиков из формата wb в z2m сожрал все ресурсы что были.
Ответил выше)
vbifkol
13.04.2026 09:34Да, можно в z2m указать конкретное устройство-роутер через которое планируем подключать.
Это именно стартовая точка. Ну по крайней мере у меня так работает. Если я подключаю термодатчик от координатора, но при этом рядом есть роутер с лучшим LQI, то устройство простроит обе связи почти одновременно. Если после этого условия изменятся, то оно переползет чисто на роутер.
Отмечу что "автоматическая" перепривязка устройств происходит после полной потери устройства из сети, но более точно ответить не смогу, поскольку плотно не занимался этим. Кстати из этого вытекает интересный факт, после полного отключения того же контроллера-адаптера сеть перестроится как ей хочется(надо уточнить) и положение адаптера в географическом центре остается единственным важным фактором при перестройке.
У меня нет, батарейные устройства плавают без "полной потери из сети" (это когда переспаривать приходится?).
Вот текущая карта одной подсети. Все устройства подключались к координатору. Физически дийрузовское реле висит рядом с координатором, у координатора есть внешняя антенна а у реле нет, но какого-то хрена теромдатчики с координатора сползли.Уличный датчик висит на стене, на расстоянии 4 метра от дийруза и координатора через деревянную стену, на расстоянии 12 метров через полметра кирпича и 40 см бетона от реле в новом доме.
И это еще фигня. У меня есть объект на 360 датчиков и 30 роутеров в 4 подсетях, там блуждания датчиков похожи на пятнашки.
sekuzmin
13.04.2026 09:34Интересно, что никто не упомянул binding, который можно настроить в z2m дополнительно с координатором. Он будет работать даже если координатор недоступен, а в случае с выключателем на батарейке и Икеевскими рулонными шторам на аккумуляторе, работает и при отсутствии электричества. Удивили китайские реле, которые работают с bind, но не Aqara SSM-U01, который не смог. При этом не будет задержек, т.к. трафик не идет через координатор и автоматизации.
Palmyra-debug Автор
13.04.2026 09:34Я изучал этот вопрос, но не всегда устройство-триггер и устройство-исполнитель заведены в z2m, соответственно решил выбрать единую "сценарную машину". Например, кнопка на сухом контакте подключенном по GPIO в WB а свет или штора zigbee.
dimkin-eu
13.04.2026 09:34А можно дропнуть z2m и пользовать ZHA :) ( Относительно ) недавно вышел ZBT-2 + у меня одно устройство не работало нормально в z2m - перешёл поменяв в том числе и Dongle Plus E. 50+ устройств, но эфир довольно пустой - вроде пока норм.
Palmyra-debug Автор
13.04.2026 09:34Уверен на тысячу процентов что работа софта очень роляет. Адаптер использовал такой же.
stigory
13.04.2026 09:34А ещё рекомендую обратить внимание на проект HOMEd. После Z2M это было как глоток свежего воздуха.
Juf8887
13.04.2026 09:343 сети zegbee, 2mqtt, zha, hue. В каждой по 200+ устройств. 3 этажа 5 камер дошкольных с обработкой картинки через НА
У соседей zha 100 устройв.
Zha и 2mqtt потом сама раскидало конечные устройства по маршрутизаторам, я просто по привычке, все подключал полок основного свистка. Т.е. не загонялся.
В зверинце есть супер ноунейм китайцы.
Всё отлично. ;)
Создал не один умный дом, все на распберри и сонофф свистках. Таких проблем как вы не испытывал.
Palmyra-debug Автор
13.04.2026 09:34Тут очень важным отличием является используемый софт (zha vs z2m), а также взаимное расположение устройств. Также использовал сонофф адаптер + распбери. Ксати, вспомнил что некоторые китайцы, в частности мои датчики движения, очень часто шлют сообщения, интересно есть ли возможность указать что только по изменению статуса движения необходимо отправлять сообщение? Это вполне может влиять на пропускную способность.
silvercaptain
13.04.2026 09:34Zigbee — это самоорганизующаяся mesh‑сеть:
координатор не управляет маршрутизацией
устройства сами выбирают родителя
-
решения принимаются по:
уровню сигнала (LQI / RSSI)
задержке
стабильности
таблицам маршрутизации
➡️ Поэтому в Роутере нет и не может быть переключателей типа
“подключать это устройство напрямую к координатору”
Palmyra-debug Автор
13.04.2026 09:34Координатор не управляет маршрутизацией, согласен, но он включает режим сопряжения и указывает какое устройство именно будет входить в этот режим. Может вы знаете как именно принимается решение о перестройке, у меня информация что только при полном отсутствии сети и ее возобновлении. Соответственно перезапуск адаптера/софта/устройства пересоберет сеть, связанную с этим устройством.
silvercaptain
13.04.2026 09:34На самом деле, я бы этого не делал вообще. Самый правильный вариант:
настроить оптимальное разделение WI-FI и Zigbee
Wi-FI Canal Zigbee canal1 - 15,20,25
6 - 20,25
11 - 15,25
Если Wi-Fi использует 40 MГч (широкий канал):
Лучше перевести Wi-Fi на 5 ГГц (если возможно), a Zigbee оставить на канале 25.
И я бы не увеличивал мощность передатчика координатора. Вы пытаетесь перекричать всех, когда в комнате и так шумно. В результате вас слышно где-то далеко, где слышать не надо, и не слышно близко.
50 устройств не так много. у меня примерно суммарно так же, но большая часть работает через отдельные экосистемы Philips Hue/Aqara/GoogleHome. Но у меня еще вдобавок thread есть, что так же добавляет сложности.
ОТ конкретной реализации так же сильно много зависит. От IKEA мне прилось отказаться совсем. Зато Philips - прямо эталон. Но да, стоит как крыло от боинга.
Palmyra-debug Автор
13.04.2026 09:34Каналы менял не помогло(
Спасибо большое что поделились опытом! Увеличение мощности адаптера при зашумлении плохой паттерн.
Соглашусь что проивзодитель оборудования может стать камнем преткновения и никакие настройки не помогут, но вроде получилось избежать этого.
ZhenyaRUS39
13.04.2026 09:34Zigbee это какой-то хаос, а не сеть. В квартире в бетонными 0.5м стенами вообще нереально чтобы сеть выстроилась и не разваливалась. Как и автор думал, что достаточное количество устройств -роутеров решит проблему, но нет, стабильности никакой, то устройство отрабатывает мгновенно находясь в метре от координатора, то три секунды отклик. Нажимаешь кнопку и постоянно ловить себя на мысли "отработает или нет". Ужасный способ автоматизации. Жаль, что ничего более стабильного при таком энергопотреблении так и не появилось. На мой взгляд эта их история с "самоопределением" прям заваливает всю стабильность.
parakhod_1
13.04.2026 09:34"Вы просто не умеете их готовить" (ц)
У меня и дом с толстыми кирпичными стенами, и многие устройства живут в саду, и до самых дальних метров 30 от дома. И прекрасно всё себе работает и не отваливается.
Берите нормальный хаб и нормальные девайсы.Palmyra-debug Автор
13.04.2026 09:34В проделанной мною работе очень часто не хватало метрик, это было основной загвоздкой что отталкивает большинство интеграторов. Все сравнивал наблюдением, только после работ написал программу которая подписывается на все топики от z2m и выводит linkquality по устройствам в таблице, может пригодится:
ZhenyaRUS39
13.04.2026 09:34Я часто слышу, что в частном доме всё отлично работает у людей, а в МЖД проблемы из-за кучи помех wifi 2.4. Мне кажется исключительно в этом дело.
parakhod_1
13.04.2026 09:34Отчасти может быть (и да, на 2,4 ж не только вайфай, хотя понятно что от него шума больше всего). Но у нас тоже точек по дому было разбросано (естественно все по разным каналам сидят), и у соседей есть, и даже публичный вайфай во дворе добивает.
Z-wave можно попробовать, датчиков-кнопков на нём море, но он на 800мГц живёт, заодно и стены лучше будет пробивать. У меня, если что, тоже работает (Ring на нём живёт), и тоже никаких проблем.
sekuzmin
13.04.2026 09:34Жаль, что ничего более стабильного при таком энергопотреблении так и не появилось.
Много лет существует Eaton xComfort, который работает на 868.3 Mhz (лучше чем 2.4 GHz проникает через стены и диапазон не так загружен как 433 MHz). Энергопотребление - батарейки в выключателе рассчитаны на 10 лет работы. Используя MRF (софт для конфигурации) можно вручную указать роутинг сообщений. Есть подтверждение доставки сообщений и т.д. Сказка…. Только протокол проприетарный и возможно имеет проблемы с безопасностью.
Cpsskipper
13.04.2026 09:34О, спасибо ребята! Благодаря таким интеграторам у нас постоянные заказы на проекты.
Это же надо додуматься использовать wirenboard (проводная система автоматизации) и повесить на него аж 50 беспроводных устройств в квартире! Я даже не говорю про то, что родные координаторы и ПО для zigbee у вайрена хорошо так отстает по версиям. Уверен сверху еще sprut hub поставили для счастья.
Palmyra-debug Автор
13.04.2026 09:34Рад что благодаря мне вы успешный интегратор)
Давайте взглянем на следующее:
Слышал что адаптер wb не самое надежное решение, исходя из этого выбрал сонофф, НО еще нигде не видел точного сравнения двух адаптеров. Слышал позитивные отзывы об адаптере jethome, да и сам в целом был доволен им, только на неюольших инсталляциях
Сам выбор контроллера wb или raspberry pi не имеет никакого значения, нужна была железка с портом usb. Более важным в ходе работ оказался тип монтажа, rpi можно поставить на стол)
С версиями ПО z2m согласен, одной из ошибок было установка не с гита. По поводу адаптера, слышал что обновление на вб помогает, но не в моем случае, к сожалению.
спрутхаб тоже не имеет значение во всем этом тесте, поскольку использовался только в рамках mqtt
Надеюсь вы поделитесь опытом и подскажите какие решения более релевантны.
Cpsskipper
13.04.2026 09:34Конечно поделюсь.
1. Дело не в производителях координаторов, а в используемых чипах. Адаптер в WB сделан на уже сильно устаревшем чипе Ti CC2652. На этом же чипе Sonoff делали координаторы Dongle P. Новые прошивки я на него уже давно не видел. Почему это важно? Пример: у Aqara есть хорошие датчики температуры и влажности (которые без экранчика). Так вот столкнулись с ситуацией когда координатор Sonoff Dongle E ( на более новом чипе EFR32) на старой прошивке мог такой датчик подключить, но не видел показания температуры. Проблема решались более свежей прошивкой контроллера.
2. Контроллер Zigbee очень чувствителен к месту установки. Как показала практика, металлическая дверь распред. шкафа, где обычно установлен WB снижает качество приема. Так же на качество приема влияет сам ПК в который подключен координатор. Его необходимо выносить на USB удлинителе подальше от прочего оборудования, а еще лучше использовать координаторы с PoE питанием и выбирать его расположение в рамках проекта без привязки к распред шкафу или серверной стойке. Так же во время проекта можно заложить не один, а несколько координаторов в разных частях объекта.
Не забывайте, что Zigbee сеть должна быть настроена на максимально свободные от WiFi частоты. Тут, кстати, тоже есть нюанс. Не все Zigbee устройства умеют работать на разных диапазонах. Есть залоченые на какой то один канал, к примеру, 11 или 15.
Важен так же правильный выбор zigbee устройств. Сталкивался с несколькими термостатами, которые просто засоряли сеть постоянными сообщениями и, как следствие, появлялись задержки в работе всей сети. В этом случае помогает либо прошивка устройства на альтернативную доработанную прошивку или замена устройства. Тут важно понимать, что настройка в z2m только помогает не спамить в mqtt и никак не влияет на саму сеть zigbee.
3. ПО z2m в репозиториях WB отстает от релизной ветки оригинального z2m. В целом это не проблема, но об этом нужно знать.
4. Использование Raspberri Pi в проекте плохая идея. Дело в том, что у нее часто выходят из строя карты памяти. В сети есть много вариантов подключения к ней SSD диска, решающее эту проблему, но тогда стоимость такого решения легко может превысить NUC подобные ПК на полноценных платформах той же intel.
В итоге, если уж приходится использовать Zigbee, то ставим один или несколько координаторов с питанием PoE, к примеру, Sonoff Dongle M. Каждый в режиме координатора, а не усилителя и работающего каждый со своим z2m. Эта схема позволяет обеспечить правильное покрытие сигналом всех устройств и в то же время увеличить отказоустойчивость системы, позволяя зарезервировать контроллер на котором крутятся контейнеры z2m. Так же, в отличие от wb модуля, в дальнейшем такие координаторы можно относительно легко заменить на новые модели.И да, мы стараемся не использовать беспроводные устройства там, где можно сделать проводное управление. Это сильно снижает количество бессонных ночей :)
NutsUnderline
13.04.2026 09:34Дело в том, что у нее часто выходят из строя карты памяти.
это вопрос отдельных статей которые уже давным давно написаны.
Palmyra-debug Автор
13.04.2026 09:34Спасибо за детальный ответ, прослеживается большой опыт в интеграции беспроводных решений!
Поддержка современных адаптеров действительно важный критерий, с этой стороны вполне объясняется как поддержка устройств(хотя считал что софт работающий с адаптером решает эту задачу, юудто проткоол один и гораздо реже обновляется, ну лан), так и производительность в том числе.
Тут с вами согласен, но по наблюдениям шкафчик открыт или закрыт, выносная антенна или без нее, не было практически никакой разницы, возможно в других инсталляциях это было бы юолее весомым фактором, например если контроллер в щитовой, то зигби там и останется). У вас есть на примете координаторы с poe питанием? С выбором устройств тоже подностью согласен
Да
Очень интересная архитектуру вы выбираете при наладке, у вас разные сети зигби на разных каналах, разбросанные по разным частям объекта, объединены одной железкой с N usb портов и внутри крутятся несколько z2m, видимо вы на этом собаку съели. По рпи, то он на ссд.
Тут все зависит от клиента так или иначе.
Cpsskipper
13.04.2026 09:34По п.4 Мы используем не usb, а lan координаторы с питанием по PoE. Схема следующая: контроллер с n контейнерами z2m -> PoE роутер-> n lan координаторов. Канал для всей zigbee можно использовать один и тот же, важнее чтобы wifi на него влиял минимально.
Пример lan координатора Sonoff Dongle M
vbifkol
13.04.2026 09:342.нормальная антенна добавляет, но немного.
4.USB не нужен, ethernet координаторы же, в общей ethernet сети. Как вариант - в wifi сети, если проводов нет. XZG умеет одновременно и зигби и вайфай.
Slacky1965
13.04.2026 09:34Вместо того чтобы подключать все устройства напрямую к координатору с включённым режимом «разрешить всё», мы перешли к древовидной структуре сети. Ближайшие к координатору устройства подключались напрямую, а остальные — через них. По сути, на каждую комнату выделялось один–два роутера, связанные с координатором, а остальные устройства в помещении уже цеплялись к ним. Это позволило разгрузить координатор и сделать сеть более устойчивой, поскольку координатор имеет ограниченное количество прямых подключений и таблиц маршрутизации.
Это так не работает. Нет, при первоначальном вводе в сеть устройства в z2m можно выбрать конкретный роутер. Но через некоторое время сеть перестроится так, что он вашей привязки не останется и следа. Нельзя привязать устройство к конкретному роутеру, оно само в процессе работы сети решит, где ему лучше ...
Palmyra-debug Автор
13.04.2026 09:34Да, спасибо. Подскажите у вас есть понимание как этот механизм работает? Я считал что только полное отсоединение от текущего родителя сети запускает этот процесс.
vbifkol
13.04.2026 09:34Да, спасибо. Подскажите у вас есть понимание как этот механизм работает? Я считал что только полное отсоединение от текущего родителя сети запускает этот процесс.
Когда батарейному устройству А надо отправить пакет, он отправляет rreq - запрос всем ближайшим устройствам с адресом куда надо отправить пакет - (до координатора или в биндинг), назовем это устройство Б. Если у принявшего В есть свежий маршрут до конечной точки, он отправляет широковещательный ответ, все соседи записывают "хочешь попасть в Б, попроси передать В". Каждому пакету в памяти присваивается lqi - попугай, показывающий надежность маршрута. Каждый новый пакет может вызвать перестроение маршрута. Разница по времени между пакетами может быть часы или даже дни.
Несколько снижают очарование происходящего пи...ца роутеры, которые обмениваются пакетами сильно чаще, соответственно их таблицы немножко стабильней, зато ветвистей.Крч, "непредсказуемая траектория" - это как раз про зигби. Чисто теоретически это должно обеспечить построение маршрута на слабых или зашумленных линиях с динамичными изменениями. Практически - лучше пользоваться проводами, от лукавого все эти забавы.
Palmyra-debug Автор
13.04.2026 09:34Теперь чуть больше стал понимать работу устройств. А по поводу проводов, то мы знаем какие основные причины выбора беспровода, да и хочется уметь и иметь понимание работы, а не просто кнопки тыкать.
Slacky1965
13.04.2026 09:34Я не большой специалист, но по тому, что я наблюдаю иногда в снифере, маршрут меняется в процессе работы сети ...
Palmyra-debug Автор
13.04.2026 09:34Ниже jaha33 посоветовал инструкцию для сниффинга, может у вас есть своя, чем вы пользуетесь?
Slacky1965
13.04.2026 09:34Zboss sniffer, который запускает Wireshark.
А, ну и вот такой модуль - https://ali.click/z0b361g
Slacky1965
13.04.2026 09:34А, вот еще. Это что за зверь такой :))
группы(логической, не z2m-группы)
Palmyra-debug Автор
13.04.2026 09:34В z2m есть функционал группы устройств, не разбирался с его работой. А под логической имел ввиду объединение устройств в сценарной машине по триггеру например.
Slacky1965
13.04.2026 09:34А вы попробуйте группы в z2m (хотя это не группы z2m, это группы в стандарте). Не нужно в сценариях все объединять. Можно просто команду в группу отправить и все. А если "командное" устройство правильно работает с группами, то достаточно его просто в группу добавить. И все будет работать.
Palmyra-debug Автор
13.04.2026 09:34В следующей инсталляции, если таковая будет, попробую чернз группы сделать.
jaha33
13.04.2026 09:34А сниффером почему не посмотрели что там у вас происходит?
Palmyra-debug Автор
13.04.2026 09:34Утилита tshark сможет смотреть что приходит с адаптера? или вы что-то другое имеете ввиду? Я написал программу которая фиксирует в эксельке linkquality всех приходящих сообщений по мктт, но это уже после работ, т.е. весь анализ построен на наблюдении.
https://github.com/Palmyra-debug/ZigLQ
jaha33
13.04.2026 09:34Можно взять платку на ESP32 с поддержкой ZB (C6 или H2), прошить и настроить согласно гайду:
2. Developing with ESP Zigbee SDK - ESP32 - — ESP Zigbee SDK latest documentation
Тогда в Wireshark можно видеть все, что происходит в сети ZB на вашем канале, там будет видно и LQI и RSSI, и откуда куда идут пакеты, кто спамит в сеть, кто отваливается и перезаходит и т.д.
Palmyra-debug Автор
13.04.2026 09:34Большое спасибо! Обязательно проверю, а плата тут становится координатором или роутером, какая роль в сети?
jaha33
13.04.2026 09:34Никакой роли не будет, плата будет слушать эфир и перекидывать zb пакеты в wireshark. Он уже это дело парсит и показывает.
Но чтобы начать хоть как то понимать что там отображается, надо как минимум почитать статью про устройство zb на хакере.
Полет пчелы. Как работают сети ZigBee и как искать уязвимости в них — Хакер
NutsUnderline
13.04.2026 09:34Просто восхитительно. zigbee работает по сути как черный ящик с at-командами который должен делать все самостоятельно (взялся за гуж). Но он умудряется заdossить этими командами целый не слабый комп на линуксе (WB) что пришлось ставить еще более мощный комп. Скрипты на sh и py - что могло пойти не так :D
Palmyra-debug Автор
13.04.2026 09:34Да, было удивлением такое наблюдать, что есть скрипты, которые запускаются и находятся в директории которая не описана в документации. А так на wb-rules js используется))
AlexKMK
13.04.2026 09:34По опыту на сетях более серьезного размера (200+) результаты следующие :
1. Используем только стек EFR. Он гораздо гибче (и дальше будет понятно почему это важно).
2. Расположение координатора - в какой-то мере важно, но не совсем так. Координатору важно, чтоб рядом с ним было 2-3 хороших роутера, чтоб всё не шло на координатор. Но с другой стороны, если рядом с координатором стоит только один роутер (у меня так было - координатор в щитке, там же стоит счетчик) - роутер может стать единственным next-hop координатора и весь трафик тогда пойдет через него, если роутер так себе, то это приведет к проблемам.
3. binding и спаривание. С кем вы спарили устройство не влияет на то с кем устройство будет работать. через 15-30 минут сеть перестраивается и устройство может выбрать любой parent router. Но, если вы настроите биндинг с желаемым роутером - совсем не обязательно "по делу", можно какой-нибудь genBasic биндить, то тем самым повысите вероятность, что parent будет тот который хотите.
4. Память и прошивки. Современные железки - очень мощные и могут держать большие таблицы. Но прошивки для этих железок такие, буд-то авторы прошивок сетей больше чем на 15-20 устройств не видели. Берите прошивку для EFR и подгоняйте под ваши размеры сети. Например так : https://github.com/AlexMKX/silabs-firmware-builder/blob/sonoff-zigbee-dongle-e-mega-router/manifests/sonoff/sonoff_zbdonglee_mega_router.yaml
5. Репитеры. Мантры вроде : Лампочки IKEA - хорошие репитеры, поставьте больше мощных репитеров - не больше чем мантры. Репитеры - нужны хорошие и это факт. Хорошие репитеры это не какие-то лампочки/розетки правильных брендов. Хороший репитер - это тот же ZB DongleE или SMLight с прошивкой под вашу сеть (в большинстве случаев просто с мощной прошивкой).Диагностика сети. Даже в хорошо спроектированной сети кто-то будет дурить и ломать всю сеть. Может быть из-за брака. Возьмите хорошего агента (GPT/Opus) включите дебаг логи в z2m. Пусть сеть поработает, выделите проблемы которые вам мешают жить и отправьте его в логи разобраться - какой перент портит всю картину.
Slacky1965
13.04.2026 09:34Но, если вы настроите биндинг с желаемым роутером - совсем не обязательно "по делу", можно какой-нибудь genBasic биндить, то тем самым повысите вероятность, что parent будет тот который хотите.
При работающей сети прямой биндинг все равно идет по маршруту.
parakhod_1
У меня четыре zigbee-сети в доме – две на хабах Philips Hue, одна на хабе SmartThings (не используется сейчас, просто живёт), одна на брелке на HA. Разумеется все по разным каналам разнесены. Дом трёхэтажный, часть лпч с зигбёй живёт в саду, Hue. На филипсовских хабах под 50 лпч на каждом, на HA около 25 разнообразного (датчики, кнопки и икеевские бп tradfri для лпч).
В общем долго я этот зоопарк и строил и приводил в порядок.
По опыту – что сильно ломает, так это невнятные китайские девайсы с непонятными контроллерами и непонятной прошивкой. Валят всю сеть только так. Даже когда через них маршрутизация не строится (уж не знаю как у них это получается). Самое отвратительное что было – лампочки Innr. Некий полубренд претендующий под что-то приличное, но по сути китай китаем. Заменил их все на филипсы и икею, и всё заработало идеально.
Та же фигня с китайскими кнопками и платами с релюшками. Сразу в помойку, если нервы дороги.
Palmyra-debug Автор
Тут я вам отвечу, что состав производителей в моей сети очень широк и часть устройств отрабатывали реально очень плохо(штуки 2 которые очень выделялись). Через них старались не подключать соседние устройства. Так что да - производитель и способность маршрутизировать точно ключевой фактор.
parakhod_1
Ну вот я за этими глюкловами заметил особенность что они умудрялись перекашивать сеть даже когда вроде через них ничего не шло. Так что имхо единственным правильным решением для таких устройств является заменить их на что-нибудь нормальное, а их самих - в помойку.