Bluetooth Mesh: provisioning завершён, почему лампа не реагирует?

Устройство появляется в списке сканирования. Нажимаем «Добавить», журнал сообщает об успешном provisioning, в шлюзе возникает новая запись. Кажется, всё готово.

Но отправляем команду включения — лампа не реагирует.

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

В предыдущей статье речь шла о превращении собственного вещания в многошаговую сеть. Здесь проследим добавление одной лампы в SIG Mesh: обнаружение, provisioning, ключи, привязка моделей, публикации и подписки. Это объяснение механизмов, а не отчёт о выполненных аппаратных испытаниях и не инструкция к конкретному UART-протоколу.

Обнаружение говорит лишь о доступности

Устройство вне сети может передавать Unprovisioned Device Beacon. Телефон или шлюз обнаруживает его, а компонент в роли Provisioner начинает процедуру.

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

Найденное объявление не доказывает, что это нужная лампа. Ещё необходимы подтверждение личности и подходящая процедура безопасности. Если рядом несколько одинаковых светильников, установщику нужен способ выбрать правильный: кнопка, сведения с изделия или поддерживаемый ввод/вывод. Этот сценарий лучше продумать до появления списка одинаковых имён.

Provisioning создаёт сетевую идентичность

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

После процедуры устройство становится узлом с начальным NetKey, IV Index, выделенными unicast-адресами и DevKey. DevKey обе стороны вычисляют независимо; он не передаётся по радио как открытый параметр настройки. Его назначение отличается от общего NetKey.

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

Три ключа выполняют разную работу

Ключ	Основная задача	Чего это не означает
NetKey	Безопасность сети/подсети и обработка сетевого уровня	Чтение содержимого всех приложений
AppKey	Защита сообщений приложения вместе с привязкой моделей	Автоматическое использование ключа каждой моделью
DevKey	Защита конфигурации конкретного узла	Общий ключ повседневного управления группой

Лампа в коридоре может ретранслировать чужие сообщения, не получая доступ ко всем приложениям. Разделение NetKey и AppKey отделяет перенос сообщения от понимания его смысла. Способность ретранслировать не доказывает наличие разрешения и модели для исполнения команды.

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

Сначала состав устройства, потом адреса

Configuration Client общается с Configuration Server узла, читая и меняя его настройки. Composition Data показывает элементы, модели и связанные возможности.

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

В нашем примере нужно найти элемент лампы и проверить Generic OnOff Server. Контроллер должен отправлять соответствующие сообщения и обрабатывать нужные ответы. Обнаружение и provisioning не подтверждают наличие требуемой модели. Увеличением мощности передачи это не исправить.

AppKey Add и Model App Bind — разные шаги

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

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

Не все модели работают через AppKey. Модели Configuration используют DevKey; нельзя настраивать их точно как модели освещения.

В Configuration Client API Silicon Labs добавление ключа и привязка модели разделены, у каждого действия свои события результата. Принятие запроса локальным API, подтверждение удалённой настройки и работоспособность функции — три разных факта.

Дожидайтесь результата по правилам SDK, проверяйте узел, элемент, модель и статус. Тайм-аут оставляет исход неизвестным, а не доказывает отсутствие выполнения на устройстве.

Сначала одна лампа, затем группа

Начните с unicast-команды на подтверждённый элемент и соответствующего ответа о состоянии.

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

Когда этот путь работает, добавьте группу. Чтобы настенный выключатель управлял несколькими лампами коридора:

• его клиентская модель публикует команды на адрес группы;
• соответствующие серверные модели ламп подписываются на этот адрес;
• обе стороны имеют согласованные AppKey и настройки моделей.

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

Имя «Свет коридора» — только подпись для человека. Подписка относится к конкретной модели. Перемещение устройства в комнату приложения ещё не доказывает выполнение беспроводной настройки.

Публикация определяет и путь состояния

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

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

«Шлюз включает свет» и «шлюз знает актуальное сообщённое состояние» проверяются отдельно. Для Matter Bridge это особенно важно: потерянное локальное изменение оставляет в верхнем приложении последнюю команду вместо свежего состояния.

Даже отчёт имеет пределы: включённый выход не доказывает физическое свечение без соответствующей обратной связи.

Конфигурация должна восстанавливаться

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

Сохраняйте желаемую конфигурацию и подтверждённые результаты. При восстановлении запрашивайте нужные состояния и устраняйте расхождения. После тайм-аута AppKey Add используйте доступные запросы протокола/SDK прежде, чем решать о повторе. Повторяемость зависит от команды: не всякая операция безвредна при повторении.

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

Сброс на заводские настройки не должен быть первым ответом на любую ошибку: он меняет состояние и может разрушить связи. Различайте ещё не подключённый узел, подключённый без настройки и настроенный узел с утраченными записями управления.

Соотнести симптомы со слоями

Симптом	Что проверять первым
Обнаруживается, provisioning не проходит	Режим подключения, bearer, аутентификацию и ошибки
Подключён, конфигурация не отвечает	Адреса, DevKey/сетевой контекст, достижимость, связь ответов; расписание приёма LPN
Конфигурация работает, unicast нет	Элемент/модель, добавление и привязку AppKey, передатчик
Unicast работает, группа нет	Реальный адрес, подписки, ключи, отправку
Управление работает, интерфейс не обновляется	Ответы, самостоятельные публикации, приём и отображение
Отказ после перезапуска	Хранение, адреса, восстановление конфигурации и ключевой контекст

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

Сначала подтвердите unicast и обратную связь, затем группы и отчёты после локальных изменений, потом прерванную настройку и перезапуск. Явные критерии по этапам полезнее одной отметки «лампа загорелась».

Добавление устройства — процесс

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

Их разделение позволяет честно показать завершённое, оставшееся и точку продолжения, не заставляя пользователя изучать протокол. SIG Mesh даёт общие механизмы, а не автоматическую совместимость любых марок, моделей и экосистем после provisioning. Работа шлюза включает переход от членства узла в сети к надёжному управлению устройством.

Следующая статья вернётся к Xiaomi Mesh: какие определения продукта, идентичности и требования платформы Xiaomi Home добавляются поверх стандартной сети и моделей?

Источники

• Bluetooth SIG: Mesh Networking Primer — адреса, публикации/подписки, ключи, provisioning и configuration.
• Silicon Labs: Configuration Client API — состав, ключи, привязки, подписки и публикации. Сверяйтесь с версией используемого SDK.