Групповое управление Bluetooth Mesh: одна лампа не включилась — повторять команду всей группе?

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

Нажимаете снова — теперь светятся все. Но неужели после каждой групповой команды придётся проверять потолок?

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

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

Переговорная — условный пример, не полевой эксперимент. Речь о групповой передаче и сообщениях моделей SIG Mesh, а не реализации Mijia или других продуктов. Здесь нет измеренных задержек, процента успеха или ёмкости сети. Учёт состояний и компенсация ниже — инженерные рекомендации, а не готовая функция протокола.

1. До какого этапа дошла «успешная отправка»?

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

Разделите свидетельства на три уровня:

Отправитель принял задачу. Запрос дошёл до определённого этапа отправки. Получение целевой лампой это не доказывает.

Целевая модель сообщила состояние. Например, Generic OnOff Status сообщает Generic OnOff соответствующего элемента. Учитывайте источник, текущее и целевое значения и, где применимо, оставшееся время перехода.

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

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

Сначала проверьте: код или контракт интерфейса, породивший надпись. Это постановка в очередь, результат модуля или состояние цели? Без определения можно неверно посчитать даже показатель успешности.

2. Групповая команда — не ведомость с подписями всех участников

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

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

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

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

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

3. Разве ответы всех ламп не надёжнее?

На примере Generic OnOff:

• Generic OnOff Set требует ответа Generic OnOff Status.
• Generic OnOff Set Unacknowledged не требует ответа модели на этот запрос.

Это ответ уровня модели, а не общий «ACK», объединяющий транспортные подтверждения, ответ API шлюза и физическое выполнение.

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

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

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

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

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

4. Нет состояния — сначала «неизвестно», а не «ошибка»

Команда могла не дойти. Лампа могла выполнить её, но обратное сообщение потерялось. Переход ещё может продолжаться. Или контроллер принял старый отчёт за новый. Признак «ответ есть/нет» этих ситуаций не различает.

В приложении можно честнее показывать:

• Запрошено: намерение передано, но достаточного подтверждения цели пока нет.
• Состояние подтверждено: получено подходящее по критериям операции состояние, записаны источник и время.
• Требует проверки: за согласованное окно наблюдения достаточно данных не получено.

Это рекомендации для приложения, не новые стандартные состояния Mesh.

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

Кроме того, Generic OnOff Status не содержит TID из Set. Нельзя рассчитывать на однозначную связь запрос–ответ через идентификатор транзакции в ответе. При быстрых командах, публикациях и нескольких контроллерах учитывайте источник, значение, время получения и контекст. Недавно пришедшее «включено» само по себе не доказывает выполнение текущей операции.

5. Почему не повторять всей группе бесконечно?

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

Более управляемый подход: групповая команда, наблюдение, при необходимости ограниченные по темпу проверки небольшого числа неопределённых участников и ограниченная компенсация только там, где она обоснована.

Не превращайте это в немедленный опрос всех устройств после каждой команды: трафик лишь сдвинется во времени. Область проверки, темп, срок и число попыток нужно испытать с учётом масштаба и требований по времени.

Соблюдайте транзакционные правила модели. TID в Generic OnOff Set отличает новую транзакцию от повтора той же. Не увеличивайте его произвольно при каждом повторе и не используйте старое значение постоянно для независимых команд. Полные временные окна и правила сопоставления проверяйте в соответствующих спецификации и SDK; универсального интервала повторов здесь нет.

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

6. Возьмите эту таблицу на интеграционные испытания

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

Наблюдение	Что проверить сначала	Не спешите считать
Интерфейс сообщает успех, одна лампа тёмная	Смысл сообщения, подписки, питание	Выполнение всеми гарантировано
Лампа включена, интерфейс сообщает ошибку	Обратный путь состояния, обработку, окно наблюдения	Нет ответа — не было выполнения
Поодиночке работает, группой бывают сбои	Группу, ответы и публикации, параллельную нагрузку	Больше повторов обязательно лучше
Состояние «включено», света нет	Семантику, переход, драйвер и источник света	Программное состояние равно оптической проверке
После быстрых команд состояние скачет	Возраст сообщений, другие контроллеры, старые компенсации	Последнее полученное сообщение самое свежее
Один узел никогда не отвечает	Список, модель, ключи, подписку, питание, покрытие	Повтор группе всё исправит

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

Записывайте версию SDK, тип сообщения, источник, назначение, время и нужные настройки. Обезличивайте идентификаторы; не публикуйте NetKey, AppKey, DevKey и данные клиентов.

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

7. Надёжность — не только «в итоге загорелось всё»

Одна кнопка скрывает три задачи: эффективно передать, понимать имеющиеся свидетельства и устранять неопределённость без новых проблем.

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

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

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

Источники и границы

• Bluetooth SIG: Mesh Model v1.1, раздел 3.2.1: сообщения, TID и поля перехода. Учитывайте версию спецификации и SDK продукта.
• Bluetooth SIG: Mesh in large-scale networks, 2018-06-26: общий эфир и нагрузка ответов. Исторические примеры не являются современными характеристиками продукта.
• Silicon Labs: Lighting Demonstration, 11.0.1: публикация, подписка и групповое управление, не универсальное поведение всех реализаций.

Источники проверены 2026-11-06. Анализ механизмов и инженерные рекомендации, без аппаратных или полевых испытаний производительности.

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