Zigbee 3.0 в АСКУЭ: архитектура, настройка, диагностика и протокол ПИРС

Основы работы Zigbee в АСКУЭ: стандарт, частотные диапазоны, ключевые отличия от Wi-Fi и Bluetooth

Представьте: на объекте установлено 200 приборов учёта электроэнергии, каждый из которых передаёт показания каждые 15 минут. Прокладывать кабель к каждому счётчику — дорого, долго и физически невозможно в ряде случаев (подвалы, этажные щитки, промышленные территории). Wi-Fi не выдержит такой нагрузки, Bluetooth не дотянется по дальности. Именно в таких сценариях инженеры АСКУЭ приходят к Zigbee — беспроводному протоколу, который изначально проектировался для сетей с сотнями и тысячами устройств, работающих от батарей годами.

Что такое Zigbee и почему именно он

Zigbee — это спецификация беспроводной связи, построенная на физическом и MAC-уровнях стандарта IEEE 802.15.4. Если IEEE 802.15.4 описывает, как именно биты летят по радиоканалу (модуляция, частота, мощность), то Zigbee добавляет на это сетевой уровень (маршрутизация, адресация) и прикладной уровень (стандартизированные команды и атрибуты устройств). Проще говоря, IEEE 802.15.4 — это «железная дорога», а Zigbee — «правила движения поездов» на этой дороге.

В АСКУЭ это означает, что ZB-модуль в счётчике не просто передаёт байты по радио — он участвует в самоорганизующейся сети, где каждый маршрутизатор (роутер) может ретранслировать данные соседних устройств. Счётчик на четвёртом этаже не обязан «видеть» координатора напрямую — его пакет пройдёт через промежуточные узлы, каждый из которых подтвердит приём.

Стандарт развивался и ужесточался: Zigbee 2004 → Zigbee PRO (2007) → Zigbee 3.0 (2016). Версия 3.0 унифицировала профили устройств (раньше устройства разных профилей — Home Automation, Smart Energy, Light Link — не всегда могли работать в одной сети), добавила улучшенную безопасность и совместимость оборудования разных вендоров. В контексте АСКУЭ это критически важно: счётчики, ретрансляторы и координаторы от разных производителей должны корректно взаимодействовать в рамках одной сети.

Частотные диапазоны

Zigbee работает в трёх диапазонах:

| Диапазон | Частота | Регион | Скорость | Количество каналов | |----------|---------|--------|----------|-------------------| | ISM 868 МГц | 868–868.6 МГц | Европа | 20 кбит/с | 1 | | ISM 915 МГц | 902–928 МГц | США, Австралия | 40 кбит/с | 10 | | ISM 2.4 ГГц | 2400–2483.5 МГц | Весь мир | 250 кбит/с | 16 (каналы 11–26) |

В АСКУЭ на территории России и СНГ используется исключительно диапазон 2.4 ГГц. Это даёт 16 каналов (от 11 до 26), каждый шириной 2 МГц, с центральными частотами, рассчитываемыми по формуле:

где — номер канала Zigbee (от 11 до 26), — центральная частота канала в МГц.

Например, канал 15 имеет центральную частоту 2425 МГц, а канал 26 — 2480 МГц.

Почему это важно для инженера АСКУЭ? Потому что в том же диапазоне 2.4 ГГц работают Wi-Fi, Bluetooth и микроволновые печи. Wi-Fi-каналы 1, 6 и 11 перекрываются с рядом каналов Zigbee. Если на объекте «эфир забит» соседними Wi-Fi-сетями, это напрямую влияет на качество связи ZB-модулей. Каналы Zigbee 25 и 26 (2475 и 2480 МГц) находятся на краю спектра и реже пересекаются с Wi-Fi — именно поэтому при диагностике нестабильной сети один из первых шагов — проверить загруженность эфира и при необходимости перенести сеть на «чистый» канал.

Ключевые отличия от Wi-Fi и Bluetooth

Чтобы понять, почему в АСКУЭ выбирают Zigbee, а не Wi-Fi или Bluetooth, нужно сравнить три технологии по параметрам, которые критичны для приборов учёта.

Wi-Fi ориентирован на высокую пропускную способность (десятки и сотни Мбит/с) и малое количество устройств. Стандартная точка доступа поддерживает до 32 клиентов, потребление энергии высокое (сотни мВт), а время подключения — до 3 секунд. Для счётчика, который передаёт несколько байт данных раз в 15 минут, Wi-Fi — это как грузовик для доставки письма: избыточно по ресурсам и дорого по энергии.

Bluetooth (включая BLE — Bluetooth Low Energy) заточен на короткие расстояния и парные соединения. Классический Bluetooth поддерживает до 7 устройств в сети «piconet», BLE работает точка-точка или через ограниченное число узлов. Масштабировать Bluetooth-сеть до 200 счётчиков — задача крайне сложная. Кроме того, подключение Bluetooth-устройства занимает до 10 секунд, что неприемлемо для периодического опроса.

Zigbee спроектирован именно для сетей с большим количеством устройств (теоретически до 65 000 узлов), низким энергопотреблением (единицы мВт в активном режиме, микроватты в спящем) и mesh-топологией с автоматической ретрансляцией. Время подключения к сети — около 30 миллисекунд. Скорость 250 кбит/с на частоте 2.4 ГГц более чем достаточна для передачи показаний счётчиков.

Вот как это выглядит в сравнении:

| Параметр | Zigbee | Wi-Fi | Bluetooth (BLE) | |----------|--------|-------|-----------------| | Скорость | 250 кбит/с | 54–600 Мбит/с | 1 Мбит/с (BLE) | | Дальность (в помещении) | 10–100 м | 30–50 м | 10–30 м | | Макс. устройств в сети | ~65 000 | 32 | 7 (класс.) / ~20 (BLE mesh) | | Потребление (актив.) | 1–50 мВт | 200–500 мВт | 10–50 мВт | | Топология | Mesh, звезда, дерево | Звезда | Звезда, mesh (BLE mesh) | | Время подключения | ~30 мс | 1–3 с | до 10 с | | Ретрансляция | Встроенная (роутеры) | Нет | Только в BLE mesh |

Почему mesh критичен для АСКУЭ

Главное архитектурное преимущество Zigbee для систем учёта — mesh-топология. В отличие от звезды (где каждый счётчик должен напрямую «видеть» базовую станцию), в mesh-сети каждый ZB-модуль, работающий в режиме маршрутизатора (роутера), может ретранслировать пакеты соседних устройств. Это означает:

Счётчик в подвале может передать данные через счётчик на первом этаже, тот — через счётчик на третьем, и так далее до координатора.

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

Не нужно тянуть кабель или ставить отдельный ретранслятор к каждому «глухому» месту — функцию ретранслятора выполняет сам прибор учёта.

Однако mesh не означает «включил и забыл». Как показывает практика, самобалансировка работает только при правильном начальном проектировании: выборе канала, размещении координатора, контроле количества прямых подключений к координатору и глубины маршрутов (хопов). Эти нюансы мы разберём подробно в следующих главах.

Стандарт IEEE 802.15.4: что инженеру нужно знать

Физический уровень IEEE 802.15.4 определяет, как именно данные кодируются в радиосигнал. Используется модуляция O-QPSK (Offset Quadrature Phase Shift Keying) с расширением спектра методом прямой последовательности (DSSS). Это обеспечивает устойчивость к помехам: даже если часть сигнала искажена, приёмник может восстановить данные благодаря избыточности кодирования.

MAC-уровень отвечает за доступ к эфиру. Используется метод CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) — перед передачей устройство «слушает» эфир и отправляет данные только если канал свободен. Если канал занят — ждёт случайное время и пробует снова. Это снижает вероятность коллизий (одновременных передач), но не исключает их полностью — именно поэтому каждый пакет подтверждается принимающим узлом (ACK-фрейм). Если ACK не получен — отправитель повторяет передачу.

Для инженера АСКУЭ это означает: если счётчик не получил подтверждение от координатора или роутера, он повторит отправку. Но количество повторов ограничено, и при высокой загрузке эфира или слабом сигнале данные могут быть потеряны. Мониторинг таких потерь — одна из ключевых задач диагностики.

Zigbee 3.0: что изменилось для АСКУЭ

До версии 3.0 устройства Zigbee были разделены по профилям — наборам стандартных кластеров и поведений для конкретных доменов. Счётчик электроэнергии работал в профиле Smart Energy, датчик температуры — в Home Automation, а лампа — в Light Link. Устройства разных профилей не могли общаться друг с другом без специального шлюза.

Zigbee 3.0 объединил все профили в единый набор, основанный на ZCL (Zigbee Cluster Library). Теперь счётчик, ретранслятор и координатор от разных производителей могут работать в одной сети без дополнительных преобразований. Для АСКУЭ это означает:

Свободу выбора оборудования: можно комбинировать ZB-модули от разных вендоров.

Упрощение развёртывания: не нужно проверять совместимость профилей.

Единый механизм безопасности: все устройства используют одинаковые протоколы аутентификации и шифрования.

Второе важное изменение — усиление безопасности. Zigbee 3.0 требует использования Install Code (кода установки) для первичного присоединения устройства к сети. Это 16-байтный код, уникальный для каждого устройства, который используется для генерации Link Key — ключа шифрования канала между устройством и координатором. Без Install Code злоумышленник не может «подключить» своё устройство к вашей сети АСКУЭ.

Если из этой главы запомнить три вещи — это:

Zigbee работает на частоте 2.4 ГГц, совпадающей с Wi-Fi — выбор канала и контроль эфира обязательны при настройке сети АСКУЭ.

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

Zigbee 3.0 унифицировал профили устройств и усилил безопасность через Install Code — это упрощает построение сетей из оборудования разных производителей.

Архитектура сети, роли устройств и хопы: координатор, маршрутизаторы, конечные устройства, топологии и ограничения

Когда инженер впервые открывает карту Zigbee-сети в конфигураторе и видит паутину связей между десятками узлов, возникает вопрос: кто здесь главный, кто просто помогает, а кто только спит и просыпается для передачи показаний? Ответ лежит в архитектуре ролей Zigbee — и именно непонимание этой архитектуры приводит к тому, что сеть из 50 счётчиков работает нестабильно, хотя «вроде бы всё настроено правильно».

Три роли в сети Zigbee

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

Координатор — единственный в сети узел, который создаёт сеть. Он выбирает рабочий канал, генерирует PAN ID (Personal Area Network Identifier — 16-битный идентификатор персональной сети), формирует Network Key (сетевой ключ шифрования) и начинает вещать beacon-фреймы, по которым другие устройства обнаруживают сеть и запрашивают подключение. Всегда включён, никогда не спит. В АСКУЭ координатор — это, как правило, модуль в устройстве передачи данных (УПД) или отдельный шлюз, подключённый к корпоративному серверу.

Маршрутизатор (роутер) — узел, который поддерживает сеть «в рабочем состоянии». Он ретранслирует пакеты других устройств, поддерживает таблицы маршрутизации, может принимать подключения новых устройств. Всегда включён, никогда не спит. В АСКУЭ каждый ZB-модуль счётчика, работающий в режиме роутера, — это потенциальный ретранслятор для соседних приборов учёта. Именно роутеры формируют mesh-каркас сети.

Конечное устройство (End Device) — узел, который может только отправлять и получать данные, но не ретранслирует чужие пакеты. Может уходить в спящий режим для экономии энергии. Подключается к одному «родительскому» узлу (роутеру или координатору), который буферизует входящие пакеты, пока конечное устройство спит. В АСКУЭ конечные устройства встречаются редко — большинство счётчиков работают от сети и не нуждаются в режиме сна, поэтому настроены как роутеры.

> Важно: роль устройства определяется прошивкой ZB-модуля, а не его физическим расположением. Счётчик может быть настроен как роутер или как конечное устройство — и от этого зависит, будет ли он помогать соседям или только сам передавать данные.

Топологии: звезда, дерево и mesh

Zigbee поддерживает три варианта организации топологии. В реальных сетях АСКУЭ они часто комбинируются.

Звезда (Star) — все устройства подключаются напрямую к координатору. Простая, но ограниченная: количество прямых подключений к координатору невелико (зависит от чипа, обычно 10–30), а дальность ограничена радиусом прямой связи. Подходит для небольших объектов (10–15 счётчиков в зоне прямой видимости координатора).

Древовидная (Cluster-Tree) — устройства образуют иерархию: координатор → роутеры первого уровня → роутеры второго уровня → конечные устройства. Маршрутизация жёстко следует по дереву. Устойчивость выше, чем у звезды, но нет альтернативных путей: если роутер верхнего уровня выходит из строя, вся его «ветка» теряет связь.

Сетчатая (Mesh) — роутеры связаны друг с другом произвольно, и каждый пакет может идти разными путями. Сеть автоматически перестраивает маршруты при выходе узла из строя. Это основной режим работы в промышленных сетях АСКУЭ. Именно mesh обеспечивает ту самую «самобалансировку», о которой говорят маркетологи — но с важными оговорками.

Хопы: сколько прыжков выдержит пакет

Хоп (hop) — это один «прыжок» пакета от одного узла к другому. Если счётчик на 5-м этаже передаёт данные через роутер на 3-м этаже, а тот — через роутер на 1-м этаже координатору, это два хопа.

Количество допустимых хопов — один из ключевых параметров, который нужно понимать при проектировании сети АСКУЭ. В спецификации Zigbee PRO максимальная глубина маршрута определяется параметром MaxDepth, который устанавливается координатором при создании сети. Типичные значения:

MaxDepth = 5 — стандартное значение для большинства координаторов. Это значит, что пакет может пройти не более 5 хопов от источника до координатора.

MaxDepth = 10–15 — расширенные значения, поддерживаемые некоторыми координаторами (например, на чипах Texas Instruments CC2652). Увеличение MaxDepth расширяет зону покрытия, но замедляет маршрутизацию и увеличивает потребление памяти роутерами.

Почему это важно? Представьте линейный объект (теплотрассу, трубопровод) длиной 500 метров, где счётчики стоят каждые 30 метров. Координатор — на одном конце. При MaxDepth = 5 последний счётчик на расстоянии 150 метров (5 × 30 м) сможет передать данные, а счётчик на 180 метрах — уже нет. Решение: увеличить MaxDepth или поставить дополнительный координатор/ретранслятор.

> На практике: каждый хоп добавляет задержку 10–50 мс и снижает вероятность доставки на несколько процентов. Сеть с 5 хопами и вероятностью доставки 98% на каждом хопе даст общую вероятность — то есть 10% пакетов будут потеряны. Именно поэтому инженеры стремятся минимизировать глубину маршрутов.

Таблица соседей и таблица маршрутизации

Каждый роутер и координатор ведут две ключевые таблицы:

Таблица соседей (Neighbor Table) — список устройств, которые «слышны» напрямую (в пределах одного хопа). Содержит их короткие адреса, роль, качество сигнала (LQI — Link Quality Indicator). Таблица ограничена по размеру (зависит от чипа, обычно 30–60 записей). Если рядом больше устройств, чем вмещает таблица, — часть из них не смогут подключиться к этому роутеру.

Таблица маршрутизации (Routing Table) — записи о том, через какой следующий узел отправить пакет конкретному адресату. Тоже ограничена (обычно 40–100 записей). Когда таблица заполнена, новые маршруты не создаются, и передача данных невозможна.

Для инженера АСКУЭ это означает конкретную практическую проблему: если к одному роутеру подключено слишком много счётчиков, его таблица соседей или маршрутизации переполняется. Счётчики начинают «скакать» между роутерами, терять связь, передавать данные с задержкой. Решение — не подключать все устройства к ближайшему роутеру, а распределять их осознанно.

PAN ID, Extended PAN ID и Network Key

PAN ID — 16-битный идентификатор сети (от 0x0000 до 0xFFFF). Все устройства одной сети должны иметь одинаковый PAN ID. Если на объекте работают две независимые сети Zigbee (например, АСКУЭ и система диспетчеризации), их PAN ID должны различаться.

Extended PAN ID (EPID) — 64-битный идентификатор, который однозначно идентифицирует сеть даже при совпадении 16-битного PAN ID. Генерируется координатором при создании сети.

Network Key — 128-битный ключ шифрования AES-128, который используется для защиты всех пакетов на сетевом уровне. Генерируется координатором и передаётся новым устройствам при присоединении к сети (зашифрованным Trust Center Link Key). В Zigbee 3.0 для передачи Network Key используется Install Code, что исключает перехват ключа при подключении нового устройства.

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

Конечные точки и кластеры: как счётчик «представляется» сети

На прикладном уровне каждое устройство описывается через конечные точки (Endpoints) и кластеры (Clusters).

Конечная точка — логический «порт» устройства. Например, двухканальный счётчик может иметь две конечные точки (по одной на канал), каждая из которых независимо передаёт показания. Конечная точка 0 зарезервирована для ZDO (Zigbee Device Object) — специальной точки, через которую устройство сообщает о себе: модель, производитель, версия прошивки, поддерживаемые кластеры.

Кластер — стандартизированный набор команд и атрибутов. Для АСКУЭ ключевые кластеры:

Metering (0x0702) — показания счётчика, единицы измерения, множитель, делитель.

Simple Metering — подкластер для простых счётчиков.

Price — информация о тарифах (если используется многотарифный учёт).

Diagnostics — параметры качества связи, счётчики ошибок.

Каждый кластер может быть серверным (содержит данные и отвечает на запросы) или клиентским (отправляет запросы). Счётчик — сервер кластера Metering, а координатор или ПО на сервере — клиент, который запрашивает показания.

Если из этой главы запомнить три вещи — это:

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

Количество хопов ограничено параметром MaxDepth (обычно 5), и каждый хоп снижает вероятность доставки пакета. Проектируйте сеть так, чтобы максимальная глубина маршрута не превышала 3–4 хопа.

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

Параметры модулей, координатора и настройки сети: что конфигурируется и как влияет на работу

Инженер, получив партию ZB-модулей для счётчиков, подключает их к координатору и обнаруживает, что треть устройств подключилась нестабильно, а качество связи на ближайших счётчиках хуже, чем на далёких. Причина не в браке — а в том, что параметры модулей, координатора и сети не были настроены под конкретный объект. Разберём, что именно конфигурируется и как каждый параметр влияет на работу.

Параметры ZB-модуля счётчика

Каждый ZB-модуль, установленный в прибор учёта, имеет набор настраиваемых параметров. Они делятся на три группы: радиопараметры, сетевые параметры и параметры поведения.

Радиопараметры

Канал (Channel) — номер радиоканала (11–26 для диапазона 2.4 ГГц), на котором работает модуль. Устанавливается координатором при создании сети, модуль подхватывает его автоматически. Но при первичной настройке или смене канала нужно убедиться, что все модули перешли на новый канал — иначе они «потеряются».

Мощность передачи (Transmit Power) — выходная мощность передатчика в дБм. Типичные значения: от −24 дБм (0.004 мВт) до +20 дБм (100 мВт). Чем выше мощность — тем дальше «добивает» сигнал, но тем сильнее помехи соседним устройствам и быстрее расходуется энергия (для батарейных устройств). В АСКУЭ, где большинство модулей питаются от сети, мощность обычно ставят максимальной или близкой к ней.

> На практике: увеличение мощности с +5 до +20 дБм на координаторе в реальном кейсе дало лишь незначительное улучшение linkquality — потому что основной проблемой были не радиопомехи, а перегрузка координатора. Мощность — не панацея, а один из параметров, который нужно настраивать комплексно.

Чувствительность приёмника — минимальный уровень сигнала, при котором модуль может декодировать пакет. Определяется чипом и не настраивается, но влияет на расчёт зоны покрытия. Типичное значение: −97…−100 дБм для современных чипов (CC2652, EFR32).

Сетевые параметры

PAN ID — идентификатор сети. Модуль с неправильным PAN ID не подключится к вашей сети, даже если физически находится в зоне покрытия. При массовом развёртывании PAN ID задаётся через конфигуратор или прописывается в конфигурационный файл координатора.

Extended PAN ID — 64-битный расширенный идентификатор сети. Используется для однозначной идентификации при совпадении 16-битного PAN ID.

Network Key — 128-битный ключ шифрования. Модуль получает его при подключении к сети. Если ключ не совпадает — модуль отвергается. При замене координатора без переноса ключа все модули нужно перевыпускать.

Install Code — уникальный код установки, используемый в Zigbee 3.0 для безопасного первичного подключения. Обычно зашит в модуль производителем и нанесён на этикетку (QR-код или строка символов). Координатор должен «знать» Install Code каждого модуля, чтобы разрешить ему подключение.

Параметры поведения

Роль (Device Type) — роутер или конечное устройство. В АСКУЭ счётчики почти всегда настраивают как роутеры, чтобы они участвовали в ретрансляции. Исключение — батарейные счётчики (счётчики воды, газа), которые работают в режиме конечного устройства для экономии заряда.

Интервал опроса родителя (Poll Rate) — как часто конечное устройство «будит» родительский роутер, чтобы проверить, не пришли ли данные. Измеряется в миллисекундах. Типичное значение: 1000–5000 мс. Чем чаще опрос — тем быстрее устройство получает входящие команды, но тем быстрее расходуется батарея.

Интервал входа в сон (Sleep Interval) — для конечных устройств: как долго устройство находится в спящем режиме между опросами. Может достигать минут и часов для счётчиков, передающих данные раз в 15 минут.

Параметры координатора

Координатор — центральный узел сети, и его параметры определяют поведение всей сети.

MaxChildren — максимальное количество «прямых потомков» (устройств, подключающихся напрямую к координатору). Зависит от чипа: для CC2530 — до 20, для CC2652 — до 60. Если устройств больше, чем MaxChildren, остальные должны подключаться через роутеры.

MaxDepth — максимальная глубина дерева (количество хопов). Устанавливается при создании сети и влияет на то, как далеко от координатора могут находиться устройства. Типичное значение: 5–10.

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

Permit Join Duration — время (в секундах), в течение которого координатор (или роутер) разрешает подключение новых устройств. По умолчанию 0 (подключение запрещено). Для добавления нового счётчика нужно открыть Permit Join на нужном роутере или координаторе на время (обычно 60–240 секунд), затем закрыть.

> Важно: если Permit Join открыт постоянно, к сети может подключиться постороннее устройство. В сетях АСКУЭ Permit Join должен быть закрыт по умолчанию и открываться только на время подключения нового оборудования.

Channel — рабочий канал сети (11–26). Выбирается при создании сети. Смена канала требует переподключения всех устройств — процедура нетривиальная и выполняется в окне обслуживания.

Transmit Power — мощность передатчика координатора. Увеличение мощности координатора расширяет зону прямого подключения, но не решает проблему, если устройства находятся за препятствиями (бетонные стены, металлические шкафы).

Параметры на уровне сети

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

Режим маршрутизации — в Zigbee PRO используется many-to-one routing (многие-к-одному), когда все устройства знают маршрут к координатору, а координатор запрашивает маршруты к конкретным устройствам по необходимости. Это экономит память роутеров по сравнению с попарной маршрутизацией, где каждому роутеру нужно знать путь к каждому устройству.

Source Routing — когда координатор хранит полный маршрут до конкретного устройства и вставляет его в заголовок пакета. Промежуточные роутеры просто передают пакет дальше по указанному пути, не тратя память на собственные таблицы маршрутизации. Это критично для сетей с большим количеством устройств: если каждый роутер хранит маршруты ко всем 200 счётчикам, его таблица переполнится. Source Routing снимает эту нагрузку.

Group Addressing — возможность объединить несколько устройств в группу и отправлять команды всем сразу (широковещательно в пределах группы). В АСКУЭ это может использоваться для одновременного опроса всех счётчиков на одном этаже или в одном здании.

Конфигурационный файл: что где лежит

В большинстве систем на базе Zigbee2MQTT (Z2M) параметры сети и устройств хранятся в конфигурационном файле configuration.yaml. Основные секции:

serial — порт и тип адаптера координатора.

mqtt — адрес MQTT-брокера и базовый топик.

advanced — канал, Network Key, PAN ID, EPID, мощность передачи, уровень логирования.

devices — индивидуальные настройки для каждого устройства (если нужны).

Пример настройки координатора на чипе EFR32 (Sonoff Dongle Plus E):

Параметр transmit_power: 20 устанавливает максимальную мощность (20 дБм), channel: 15 — рабочий канал. Значение GENERATE означает, что ключи и идентификаторы будут сгенерированы при первом запуске.

> Обратите внимание: в некоторых инструкциях (например, для адаптеров на базе CC2652) рекомендуется ставить transmit_power: 127 — это не 127 дБм, а «максимально доступное значение», которое прошивка ограничит аппаратным пределом чипа.

Что можно и нельзя настроить «на лету»

Не все параметры можно менять без последствий для сети:

| Параметр | Можно менять без переподключения | Требует переподключения устройств | Требует пересоздания сети | |----------|----------------------------------|-----------------------------------|--------------------------| | Мощность передачи | ✓ | | | | Permit Join | ✓ | | | | Уровень логирования | ✓ | | | | Канал | | ✓ | | | PAN ID | | | ✓ | | Network Key | | | ✓ | | MaxDepth | | | ✓ |

Если из этой главы запомнить три вещи — это:

Мощность передачи и канал — два радиопараметра, которые реально влияют на покрытие, но не решают проблему, если корень в архитектуре (переполненные таблицы, слишком глубокие маршруты).

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

Source Routing разгружает роутеры от хранения полных таблиц маршрутизации — в сетях АСКУЭ с десятками и сотнями счётчиков это критически важный механизм.

Протокол ПИРС, передача данных и ретрансляция: взаимодействие ZB-сети с корпоративным сервером

Zigbee-сеть собрала показания со всех счётчиков, данные лежат в буфере координатора — и что дальше? Между ZB-сетью и корпоративным сервером АСКУЭ стоит ещё один уровень: протокол ПИРС (протокол информационного обмена в системах коммерческого учёта энергоресурсов). Именно через ПИРС данные из локальной беспроводной сети попадают в систему сбора, хранения и обработки. Если Zigbee — это «последняя миля» от счётчика до шлюза, то ПИРС — это «магистраль» от шлюза до сервера.

Что такое ПИРС и зачем он нужен

ПИРС — это протокол прикладного уровня, разработанный для унифицированного обмена данными между приборами учёта (или концентраторами данных) и верхним уровнем АСКУЭ (сервером сбора данных, SCADA-системой, АИИС КУЭ). Протокол определяет формат запросов и ответов, структуру данных, механизмы аутентификации и контроля целостности.

Почему нельзя передавать данные напрямую через Zigbee на сервер? Три причины:

Zigbee работает в локальной сети — радиус действия ограничен десятками-сотнями метров. Сервер АСКУЭ может находиться в другом здании, городе или дата-центре.

Формат данных Zigbee (ZCL-кластеры) не совпадает с форматом, который ожидает сервер АСКУЭ. Нужен преобразователь (шлюз), который «переводит» данные из ZCL в ПИРС.

Адресация: Zigbee использует короткие 16-битные адреса внутри сети, а сервер АСКУЭ идентифицирует приборы учёта по серийным номерам, заводским номерам или внутренним кодам. Шлюз выполняет сопоставление.

Архитектура взаимодействия

Типичная цепочка передачи данных в АСКУЭ с Zigbee выглядит так:

Счётчик (ZB-модуль) → Zigbee-сеть (mesh, роутеры ретранслируют) → Координатор (шлюз/УПД) → Протокол ПИРС → Корпоративный сервер (база данных, SCADA, АИИС КУЭ)

Разберём каждый этап.

Этап 1: Сбор данных в ZB-сеть

Координатор (или серверное ПО, управляющее координатором) периодически опрашивает счётчики. Опрос может быть:

Инициированный сервером (poll): сервер отправляет запрос через ПИРС, координатор транслирует его в ZCL-запрос к конкретному счётчику, счётчик отвечает, координатор формирует ответ по ПИРС.

Инициированный счётчиком (report): счётчик по расписанию или по событию (например, начало нового интервала учёта) отправляет показания координатору, координатор буферизует их и передаёт серверу при следующем опросе.

В АСКУЭ чаще используется периодический опрос (каждые 15 минут, каждый час — в зависимости от требований к интервалу учёта). Координатор последовательно запрашивает каждый счётчик или группу счётчиков, собирает ответы и формирует пакет данных для передачи на сервер.

Этап 2: Преобразование ZCL → ПИРС

Координатор (или УПД — устройство передачи данных) выполняет роль протокольного моста. Он принимает данные в формате ZCL-кластеров (например, атрибуты кластера Metering: текущее показание, единицы измерения, множитель/делитель, время последнего обновления) и преобразует их в формат ПИРС.

Структура сообщения ПИРС включает:

Заголовок: идентификатор сообщения, тип (запрос/ответ), адрес отправителя и получателя.

Данные: показания приборов учёта, статусы, диагностическая информация.

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

Этап 3: Передача на сервер

От координатора до корпоративного сервера данные могут идти по разным каналам:

Ethernet (проводной) — если координатор или УПД подключены к локальной сети предприятия.

GPRS/4G (сотовая связь) — для удалённых объектов, где нет проводной инфраструктуры.

RS-485 — если координатор подключён к концентратору, который уже передаёт данные на сервер по проводному каналу.

Выбор канала зависит от инфраструктуры объекта. На практике часто используется комбинация: Zigbee внутри здания (от счётчиков до шлюза) + Ethernet или 4G от шлюза до сервера.

Ретрансляция: как данные доходят от счётчика до координатора

Ретрансляция — это процесс передачи пакета через промежуточные узлы (роутеры) от источника до конечного получателя. В mesh-сети Zigbee каждый роутер, получив пакет не для себя, проверяет таблицу маршрутизации и пересылает пакет следующему узлу на пути к адресату.

Механизм маршрутизации в Zigbee PRO работает так:

Счётчик (источник) формирует пакет с адресом координатора.

Если счётчик — роутер, он ищет координатора в таблице маршрутизации. Если записи нет — запускается процедура обнаружения маршрута (Route Discovery): широковещательный запрос Route Request (RREQ), на который отвечают промежуточные роутеры, формируя маршрут.

Пакет передаётся по найденному маршруту. Каждый промежуточный роутер подтверждает приём на MAC-уровне (ACK).

Если ACK не получен, роутер повторяет передачу (до 3 раз). Если все попытки неудачны — пакет отбрасывается, инициируется новый Route Discovery.

Для инженера АСКУЭ ключевое значение имеет время Route Discovery — от нескольких сотен миллисекунд до нескольких секунд. Если сеть стабильна и маршруты уже известны, передача пакета занимает единицы миллисекунд на каждый хоп. Но если сеть перестраивается (выпал роутер, изменилась топология), Route Discovery добавляет задержку, и опрос счётчиков может «растянуться» по времени.

> На практике: если координатор опрашивает 100 счётчиков за 15 минут, на каждый счётчик остаётся 9 секунд. При 3 хопах и стабильных маршрутах передача занимает 100–200 мс — запас огромный. Но если половина маршрутов требует Route Discovery (по 2–5 секунд каждый), опрос может не уложиться в интервал.

Поток данных: от счётчика до базы данных

Разберём конкретный сценарий: сервер АСКУЭ запрашивает показания счётчика №47 (серийный номер SN-0047), расположенного на 3-м этаже здания.

Сервер формирует запрос по ПИРС: «Прочитать текущее показание прибора SN-0047».

Запрос поступает на УПД (координатор) по Ethernet.

УПД по внутренней таблице соответствия определяет, что SN-0047 имеет короткий Zigbee-адрес 0x1A3F и подключён через роутер 0x0B22 (счётчик на 1-м этаже).

УПД формирует ZCL-запрос Read Attributes к кластеру Metering, атрибуту Current Summation Delivered (0x0000).

Запрос передаётся по Zigbee: координатор → роутер 0x0B22 → счётчик 0x1A3F (2 хопа).

Счётчик отвечает: текущее показание = 15 432.56 кВт·ч.

Ответ идёт обратно по тому же маршруту.

УПД формирует ответ по ПИРС: «SN-0047, текущее показание 15432.56 кВт·ч, время 14:30:00».

Сервер записывает данные в базу.

Вся цепочка занимает от 200 мс до 5 секунд в зависимости от стабильности маршрутов.

Буферизация и повторная передача

Если сервер недоступен (обрыв канала Ethernet, проблемы с сотовой связью), УПД буферизует данные в собственной памяти. Объём буфера зависит от модели УПД — от нескольких тысяч записей до нескольких дней данных при 100 счётчиках с интервалом опроса 15 минут.

При восстановлении связи УПД передаёт накопленные данные на сервер. Важно, чтобы сервер корректно обрабатывал «исторические» данные с метками времени — иначе показания «задним числом» могут исказить расчёты.

Если из этой главы запомнить три вещи — это:

ПИРС — это протокол между шлюзом (УПД) и сервером АСКУЭ. Zigbee работает «до шлюза», ПИРС — «после шлюза». Это два разных уровня, и проблемы на одном уровне не обязательно связаны с другим.

Ретрансляция в mesh-сети работает автоматически, но Route Discovery (поиск нового маршрута) добавляет задержку в несколько секунд. Стабильная топология с известными маршрутами — ключ к быстрому опросу.

УПД буферизует данные при обрыве связи с сервером. Убедитесь, что объём буфера достаточен для покрытия типичного времени простоя канала, и что сервер корректно обрабатывает данные с ретроспективными метками времени.

Диагностика, балансирование нагрузки и нештатные ситуации: методы поиска и устранения проблем в ZB-сети АСКУЭ

Представьте: 80 счётчиков стабильно работали полгода, а в последние две недели сервер получает данные только от 60. Остальные 20 то появляются, то пропадают. Координатор на месте, антенна целая, питание в норме. Где искать проблему — в радиоканале, в топологии, в координаторе, в прошивке или в серверном ПО? Именно такие задачи решает системная диагностика Zigbee-сети, и для их решения нужно понимать, какие данные собирать, на какие индикаторы смотреть и в каком порядке действовать.

Первая линия диагностики: что показывает сеть

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

Link Quality Indicator (LQI) — показатель качества приёма пакета, измеряемый принимающим узлом. Шкала от 0 до 255 (в некоторых реализациях — от 0 до 100 или от 0 до 20). LQI зависит от отношения сигнал/шум (SNR) и силы принятого сигнала (RSSI). Значения:

LQI (или на шкале 0–20) — отличная связь.

LQI от 100 до 150 (8–15) — приемлемая связь, возможны редкие потери.

LQI (или ) — плохая связь, регулярные потери пакетов, требуется вмешательство.

> Важно: LQI показывает качество связи на конкретном участке маршрута, а не по всему пути. Счётчик может иметь LQI = 180 к своему роутеру, но если роутер плохо связан с координатором — данные всё равно будут теряться.

RSSI (Received Signal Strength Indicator) — уровень принятого сигнала в дБм. Типичные значения:

RSSI дБм — отличный сигнал (устройства в 1–3 метрах).

RSSI от до дБм — хороший сигнал (помещение, 5–15 метров).

RSSI от до дБм — удовлетворительный сигнал, возможны потери при помехах.

RSSI дБм — слабый сигнал, высокая вероятность потерь.

Карта сети (Network Map) — визуальное представление топологии: какие устройства подключены к каким роутерам, через сколько хопов до координатора, какое качество связи на каждом участке. В Zigbee2MQTT карта доступна через веб-интерфейс. В реальном кейсе отмечается, что карта сети «редко помогает определить изменения» — она полезна для первичного анализа топологии, но не для поиска динамических проблем.

Счётчики ошибок — количество неудачных передач, повторных попыток, потерянных пакетов. Доступны через диагностические кластеры ZCL или логи координатора. Растущий счётчик ошибок на конкретном участке — прямой индикатор проблемы.

Методика диагностики: от простого к сложному

Диагностику нужно проводить последовательно, от лёгких проверок к сложным.

Шаг 1: Проверить физический уровень

Убедиться, что координатор и все роутеры питаются и индицируют работу.

Проверить, не закрыты ли модули металлическими корпусами, шкафами, дверями. В кейсе с 50 устройствами проверка металлической двери шкафа автоматизации показала разницу LQI всего в 1–4 единицы — физические препятствия не всегда являются главной проблемой, но проверить стоит.

Проверить расстояния между устройствами и наличие прямой видимости.

Шаг 2: Проверить загруженность эфира

Диапазон 2.4 ГГц — общий для Zigbee, Wi-Fi и Bluetooth. На объекте с плотной застройкой (офисный центр, жилой комплекс) эфир может быть сильно загружен.

Просканировать Wi-Fi-сети (через приложение на смартфоне или интерфейс роутера) и определить, какие Wi-Fi-каналы заняты.

Сопоставить Wi-Fi-каналы с каналами Zigbee. Wi-Fi-канал 1 перекрывается с Zigbee-каналами 11–14, Wi-Fi-канал 6 — с 15–20, Wi-Fi-канал 11 — с 21–26.

Если Zigbee работает на «забитом» канале — перенести на свободный (например, канал 25 или 26, которые реже пересекаются с Wi-Fi).

> Однако, как показывает практика, смена канала часто даёт лишь незначительное улучшение. Если после смены канала проблема не ушла — причина не в помехах, а в архитектуре или конфигурации.

Шаг 3: Проверить топологию и балансировку

Открыть карту сети и проверить:

Сколько устройств подключено напрямую к координатору? Если большинство — это проблема: координатор перегружен прямыми подключениями. Решение — перестроить топологию в древовидную структуру, назначив «ближние» роутеры как промежуточные узлы.

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

Какова максимальная глубина маршрутов? Если есть устройства на 5 хопах и более — рассмотрите добавление промежуточных роутеров или ретрансляторов.

Балансирование нагрузки — это распределение подключений так, чтобы ни один роутер не был перегружен, а глубина маршрутов была минимальной. В mesh-сети Zigbee балансирование происходит автоматически, но «автоматика» руководствуется простым правилом: устройство подключается к роутеру с лучшим LQI. Если координатор стоит ближе всех и имеет лучший LQI — все устройства подключатся к нему, даже если рядом есть свободные роутеры.

Решение: принудительное управление топологией. Открывать Permit Join не на координаторе, а на конкретных роутерах, к которым должны подключаться определённые группы устройств. Например, Permit Join на роутере 1-го этажа — для счётчиков 1-го этажа, Permit Join на роутере 3-го этажа — для счётчиков 3-го этажа. Так формируется осознанная древовидная структура, а не хаотичная «звезда».

Шаг 4: Проверить нагрузку на контроллер/координатор

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

Проверьте:

Загрузку CPU на контроллере/сервере, где работает координатор.

Количество MQTT-сообщений в секунду (при 100 счётчиках с интервалом 15 минут — небольшое, но при частом опросе или большом количестве событий — может быть значительным).

Наличие «тяжёлых» скриптов или правил, обрабатывающих данные Zigbee в реальном времени.

Шаг 5: Проверить прошивку координатора

Устаревшая прошивка — частая причина нестабильности. В кейсе переход с Zigbee2MQTT v2.5.1 на v2.9.2 и обновление прошивки координатора дали заметное улучшение. Перед обновлением:

Сделать резервную копию текущих настроек (Network Key, PAN ID, таблицу устройств).

Проверить совместимость новой прошивки с вашим оборудованием.

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

Шаг 6: Замена координатора

Если все предыдущие шаги не помогли — проблема может быть в самом координаторе. Разные чипы ведут себя по-разному:

CC2530 — устаревший чип, ограниченные ресурсы, не рекомендуется для сетей более 20–30 устройств.

CC2652P — современный чип от Texas Instruments, поддерживает до 60+ прямых подключений, хорошая производительность.

EFR32MG21 (Silicon Labs) — используется в Sonoff Dongle Plus E, на практике показывает более стабильную работу в сетях с высокой плотностью устройств.

Нештатные ситуации и как с ними работать

Ситуация 1: Счётчик «потерялся» после отключения питания

После отключения питания счётчик может получить другой короткий 16-битный адрес при повторном подключении. Сервер, знающий старый адрес, не может найти счётчик. Решение: сервер идентифицирует счётчик по серийному номеру (IEEE-адресу, 64 бита), а не по короткому адресу. Если сервер привязан к короткому адресу — нужно обновить таблицу соответствия.

Ситуация 2: Массовая потеря связи после смены канала

При смене канала координатора все устройства должны переподключиться. Если Permit Join закрыт — устройства не смогут вернуться в сеть. Перед сменой канала нужно:

Открыть Permit Join на координаторе (или на всех роутерах).

Сменить канал.

Дождаться переподключения всех устройств (может занять 5–30 минут).

Закрыть Permit Join.

Ситуация 3: Роутер «захватывает» все подключения

Роутер с сильным сигналом (например, установленный рядом с координатором) может притянуть к себе все устройства, став «бутылочным горлышком». Его таблица соседей переполняется, часть устройств не может подключиться, а подключённые — страдают от задержек. Решение: отключить Permit Join на этом роутере, удалить устройства и переподключить их через другие роутеры.

Ситуация 4: Периодические потери данных в вечернее время

В жилых и офисных зданиях вечером увеличивается активность Wi-Fi (люди приходят домой, включают роутеры, стримят видео). Это повышает уровень помех в диапазоне 2.4 ГГц. Если Zigbee работает на пересекающемся канале — вечером linkquality падает. Решение: перенос на «чистый» канал или увеличение мощности передачи.

Ситуация 5: Счётчик передаёт данные, но сервер их не получает

Проблема может быть не в Zigbee, а в ПИРС или в серверном ПО. Проверьте:

Доходят ли данные до координатора (логи координатора/Z2M).

Формирует ли УПД корректный пакет ПИРС (логи УПД).

Принимает ли сервер пакет (логи сервера, сетевой трафик через Wireshark).

> Частая ловушка: инженер часами диагностирует Zigbee-сеть, а проблема оказывается в неправильной конфигурации MQTT-брокера или в перегруженном сервере, который не успевает обрабатывать входящие сообщения.

Структура принятия решений: ставить ретранслятор или нет

Когда инженер видит «слабое звено» в сети, вопрос «ставить ретранслятор?» возникает естественно. Но не всегда ретранслятор — правильное решение.

Ставить ретранслятор имеет смысл, когда:

Устройство находится за пределами зоны покрытия всех существующих роутеров (RSSI дБм от ближайшего роутера).

Между устройством и ближайшим роутером — серьёзное препятствие (бетонная стена, металлический экран), которое нельзя обойти.

Глубина маршрута достигает MaxDepth, и устройство не может подключиться.

Ретранслятор НЕ поможет, когда:

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

Проблема в загрузке CPU координатора — нужно оптимизировать серверное ПО или менять координатор.

Проблема в помехах на выбранном канале — нужно менять канал, а не добавлять ретранслятор на том же «грязном» канале.

Если из этой главы запомнить три вещи — это:

Диагностику начинайте с данных (LQI, RSSI, карта сети, счётчики ошибок), а не с догадок. Симптомы «потеря данных» и «задержки» одинаковы для проблем с радиоканалом, топологией, CPU и серверным ПО — нужен последовательный анализ.

Балансирование нагрузки в mesh-сети не происходит автоматически оптимально. Принудительно управляйте топологией через Permit Join на конкретных роутерах, формируя осознанную структуру, а не хаотичную «звезду» вокруг координатора.

Ретранслятор — не универсальное решение. Если проблема в архитектуре (переполненные таблицы, перегруженный координатор, неправильный канал), добавление ещё одного узла только усугубит ситуацию. Сначала устраните корневую причину.