Устройства Bluetooth Mesh на батарейках: почему отчёт приходит быстро, а команда — не сразу?

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

Почему одно устройство может быстро сообщать, но медленнее принимать?

Причина не обязательно в плохом сигнале или зависшей программе. В Bluetooth Mesh с механизмами низкого потребления передача и приём могут работать по разному расписанию.

Короткий ответ: локальное событие может разбудить узел для передачи, а входящие во время сна сообщения Friend сохраняет до запроса узла. Разделите эти пути, чтобы понять источник задержки.

Разберём сокращение времени прослушивания, хранение сообщений у Friend и проверку влияния экономии на нужную реакцию.

Датчик — условный пример, не результат измерений. Речь о механизмах SIG Mesh Low Power и Friend; SDK, плату и платформу проверяют отдельно. Испытаний автономности и задержек не проводилось.

1. Сначала схема: передавать — не значит постоянно принимать

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

Сосед — Friend, устройство с низкопотребляющей функцией — Low Power Node, LPN. Аналогия объясняет режим приёма, а не гарантирует доставку или возможность дистанционно разбудить спящий чип.

Сначала проверьте: отдельно нарисуйте отчёт о событии и удалённую настройку. На стороне телефона возможны шлюз, облако и кэш; не относите всё ожидание к радио Mesh.

2. Почему кнопка отправляет, а изменение настройки ждёт?

Silicon Labs указывает: LPN может передавать, не дожидаясь следующего опроса сообщений. Быстрое пробуждение по кнопке или датчику зависит от аппаратуры и приложения.

• Локальное событие: событие → пробуждение и обработка → передача → обработка адресатом.
• Входящая команда: сообщение у Friend → ожидание получения → приём и обработка LPN → при необходимости отчёт.

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

Сначала проверьте: отметьте событие, передачу, очередь Friend, получение LPN и фактическое применение настройки. Не вычитайте метки несинхронизированных часов разных устройств.

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

Редко отчитывающийся датчик может тратить много энергии, если приёмник постоянно включён.

Bluetooth SIG объясняет Low Power снижением доли времени работы приёмника. После установления friendship LPN меньше слушает непрерывно, а Friend хранит подходящие сообщения до их получения.

Friend — не бесконечный ящик. Число LPN, сообщений и подписок ограничено реализацией и ресурсами. Очереди, повторы и частое повторное установление отношений увеличивают расход.

Сначала проверьте: чему соответствует ток — измерению, сканированию, передаче, получению или поиску Friend. Минимальный ток сна из документации не описывает всё изделие.

4. Увеличить PollTimeout — значит снизить потребление?

Не обязательно. Различайте частоту получения и допустимое отсутствие контакта до прекращения отношения.

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

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

ReceiveDelay описывает ожидание от запроса LPN до начала прослушивания, ReceiveWindow — окно приёма. Они также не являются автоматически периодом прикладной операции.

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

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

5. Почему выключение лампы может увеличить расход датчика?

Допустим, лампа с Friend обслуживает узел, но механический выключатель полностью снимает питание. Прежний приём больше не работает как раньше.

Silicon Labs отмечает необходимость повторного установления после рестарта Friend или LPN. Пограничный сигнал с постоянными обрывами тоже повышает расход. Поиск в непрерывном цикле не экономит энергию: нужны подходящие паузы и восстановление.

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

Friend, Relay и прикладной шлюз — разные роли. Ретрансляция не подразумевает очереди для LPN, название «шлюз» не гарантирует Friend. От батарейного узла также нельзя по умолчанию требовать постоянной ретрансляции.

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

6. Сначала средний ток изделия, потом срок батарейки

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

Средний ток ≈ сумма произведений тока каждого состояния на его длительность ÷ общее время.

При согласованном расчёте на стороне батареи: полезная ёмкость (мА·ч) ÷ средний ток (мА) ≈ часы работы. При преобразовании напряжения учитывайте КПД или используйте одинаковую энергетическую основу; не смешивайте стороны преобразователя.

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

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

7. Сохраните список для прототипа

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

Наблюдение	Что проверить сначала	Не спешите заключать
Отчёты идут, настройки ждут	Оба пути, опрос, очередь, применение	Обязательно плохой сигнал
Сон экономный, изделие расходует много	Измерение, слушание, передача, повторы, периферия	Достаточно сменить батарею или чип
Сбой после отключения Friend	Потерю отношения, паузы, восстановление	Очередь мигрирует, смена незаметна
Частые настройки дают неожиданный итог	Ограничения очереди, обработку, конечное состояние	Каждая старая команда хранится вечно
Пропадают групповые сообщения	Подписки модели и Friend, нагрузку	Мультикаст гарантирует успех всем
Сбои при низком заряде	Напряжение передачи, питание, восстановление	Доступна вся номинальная ёмкость

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

При выборе начните с трёх вопросов:

• Главным образом редкие исходящие события? Оцените LPN и Friend, измерив реальную нагрузку.
• Нужны своевременные входящие команды? Согласуйте ожидание и проверьте приём вместе с бюджетом энергии.
• Нужны долгий сон, мгновенный приём и постоянная ретрансляция? Сначала проверьте совместимость целей.

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

Дополнительно: выбор и приёмка Bluetooth Mesh.

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

• Bluetooth SIG: Bluetooth Mesh Networking: Friendship, 2017-08-24. Историческое введение в механизмы, не замена актуальной спецификации проекта.
• Silicon Labs: Bluetooth Mesh Node Power Consumption, 11.0.1. Передача, окна приёма, восстановление и потребление; ориентируйтесь на свой SDK.

Проверено 2026-11-06. Это анализ документов и инженерные рекомендации, не личный лабораторный опыт и не подтверждённая гарантия автономности, задержки или ёмкости.