Почему Zigbee “сыпется”: опыт диагностики и оптимизации сети

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 устройств успешно добавлены, сценарии настроены, базовая проверка показала работоспособность.

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

1. Низкий linkquality

   У большОго количества устройств(20-30) показатель linkquality оказался нестабильным и периодически снижался до значений, при которых связь становилась ненадёжной(0 — 20 в столбце качества связи).
   При этом физически устройства находились в пределах одной квартиры и, с учётом большого количества mesh-роутеров, не должны были испытывать дефицита маршрутов.

2. Неодновременная отработка групп устройств

   При переключении группы(логической, не z2m-группы) освещения из 5-10 устройств частично начали реагировать с заметной задержкой относительно друг друга.
   Часть светильников включалась мгновенно, часть — спустя 0.5–3 секунды.

   Для пользователя это выглядело как «рваная» работа системы.

3. Отработка не всех устройств

   Иногда часть устройств в группе(логической, не z2m-группы) вообще не выполняли команду.
   Повторная отправка команды решала проблему, но предсказать, какие именно устройства не отработают в следующий раз, было невозможно.

4. Резкое ухудшение работы в вечернее время

   Особенно показательной оказалась зависимость от времени суток.
   В вечерние часы отклик устройств заметно снижался(увеличились задержки, возрастало количество пропущенных команд)

5. Потеря событий от датчиков

   Наиболее критичная проблема — датчики движения периодически не отправляли события.

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

Ход работ

Шаг первый — пересборка топологии сети.

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

Шаг второй — проверка влияния физического препятствия.

Мы предположили, что металлическая дверь шкафа автоматизации может ухудшать прохождение сигнала. Однако анализ карты сети и параметра 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: 4mqtt:  base_topic: zigbee2mqtt  server: mqtt://localhost:1883serial:  port: /dev/ttyUSB0  adapter: ember  baudrate: 115200  rtscts: falseadvanced:  log_level: info  channel: 11  network_key: GENERATE  pan_id: GENERATE  ext_pan_id: GENERATE  transmit_power: 127frontend:  enabled: true  port: 8080  dashboard: falsehomeassistant:  enabled: false

Обратите внимание на параметр transmit_power: 127 , в инструкции к настройке адаптера указано что максимальное значение будет ограничено оборудованием, поэтому поставили просто большое число.
Параметр channel: 11 оставили по умолчанию при установке.

Вывод

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

Критичным фактором оказалась перегрузка CPU контроллера. При загрузке на уровне 300–400% система переставала успевать обрабатывать MQTT-сообщения, отправлять команды устройствам и корректно реагировать на события от датчиков. В результате возникали задержки, пропуски команд и потеря событий, несмотря на нормальные показатели linkquality. Это показало, что стабильность Zigbee определяется не только радиоканалом, но и способностью системы обрабатывать данные в реальном времени.

Существенное влияние оказало и размещение координатора. Установка в углу квартиры приводила к неравномерному покрытию сети, увеличению количества промежуточных узлов и росту нагрузки на отдельные роутеры. Перенос координатора ближе к центру позволил выровнять топологию и снизить количество «длинных» маршрутов.

Дополнительным ограничением оказался сам координатор и платформа, на которой он работал. При большом количестве устройств они хуже справлялись с обработкой маршрутов и высокой плотностью mesh-сети. Переход на более производительное устройство и другой координатор в сочетании с актуальной версией Zigbee2MQTT позволил устранить эти ограничения и стабилизировать работу сети.

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

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

Полученный опыт позволяет сформулировать несколько практических выводов. В первую очередь необходимо контролировать нагрузку на систему и избегать ситуаций, когда обработка данных становится узким местом. Также критически важно правильно размещать координатор и изначально проектировать топологию сети, а не полагаться на её самобалансировку. При работе с большим количеством устройств стоит учитывать ограничения используемого оборудования и при необходимости выносить Zigbee на более производительную платформу.