Почему батарейный датчик не расширяет сеть Thread
Разбираем роли узлов, сон радиомодуля и разделение сети на участки. Что проверить, если устройств много, а связь по-прежнему пропадает.
В комнате добавили ещё несколько батарейных датчиков, но устройство за дальней стеной продолжает терять связь. Такая ситуация возможна даже в mesh-сети: роль каждого узла определяет, будет ли он передавать сообщения соседей. Количество коробок само по себе ничего не говорит о доступных маршрутах.
Кто передаёт чужие пакеты
В документации OpenThread узел с ролью Mesh Extender пересылает пакеты других устройств и постоянно держит радиотрансивер включённым. Конечное устройство, End Device, связано ровно с одним родительским Mesh Extender, через него общается с сетью и чужие пакеты не пересылает. Эти роли объясняют, почему добавление датчика может никак не изменить покрытие.
Sleepy End Device большую часть времени выключает трансивер, периодически просыпаясь для опроса родителя. У Full Thread Device радио постоянно включено, однако и среди таких устройств встречаются конечные узлы. Возможность стать ретранслятором предусмотрена у Extender-Capable Device, поэтому тип питания и внешняя форма устройства служат лишь поводом заглянуть в документацию модели.
Что происходит на границе покрытия
Группа узлов может потерять радиосвязь с остальной сетью и образовать отдельный участок, который в документации называется partition. У каждого участка появляется собственный Leader и свои сетевые данные, при этом учётные данные безопасности остаются общими. Когда радиосвязь восстанавливается, участки автоматически объединяются. Leader управляет набором Mesh Extender в своём участке, эта роль выбирается самой сетью.
Из этого следует редакционная рекомендация: при разборе пропаданий связи полезно выяснять, какие узлы действительно пересылают сообщения и где они стоят. Карта комнат с отмеченными устройствами помогает сформулировать вопрос точнее, чем общее описание "в дальней спальне плохо работает умный дом". Отдельно подпишите модели, которые регулярно отключаются от питания.
Проверка без случайных покупок
Начните с одного проблемного датчика и зафиксируйте условия его обычной работы. Посмотрите, доступна ли в используемой системе информация о родителе и состоянии сети, затем проверьте руководство датчика и соседних устройств на предмет их роли. Производитель может скрывать эти сведения за техническим описанием или вообще не показывать их в пользовательском интерфейсе, тогда стоит запросить подтверждение у поддержки.
При временном переносе датчика ближе к остальным узлам сохраняйте одинаковый способ проверки и отмечайте результат после того, как устройство успеет подключиться. Не назначайте универсальный срок ожидания: конкретное поведение зависит от устройства и реализации. Если перенос меняет результат, это основание исследовать связь и размещение, но ещё не доказательство причины сбоя.
Добавление подходящего постоянно питаемого узла имеет смысл после проверки его способности участвовать в пересылке. При этом бытовые сценарии, приложение и доступ к облаку требуют собственной проверки: описание сетевой роли охватывает только участок передачи данных. Сохраните карту и названия моделей вместе с настройками дома, чтобы следующая перестановка мебели или отключение розетки оставляли понятный след в истории изменений.
Источник и права
Исходник: Node Roles and Types, Google, документация OpenThread. Язык оригинала: английский. Режим: сокращённый перевод и редакционная адаптация. Использованы разделы Forwarding roles, Device types, Thread Leader, Partitions.
Текст оригинала опубликован по Creative Commons Attribution 4.0 International. Материал переведён на русский, сокращён и перестроен; программные примеры и тестовые задания опущены, добавлены пояснения и бытовые ситуации редакции. Адаптацию подготовило издание команды sentibox. Google и участники OpenThread не проверяли и не одобряли эту публикацию. Оригинальная схема редакции также доступна по CC BY 4.0.
