Интеграция Thread-устройств через IoT-хаб в мобильное приложение
Thread — меш-протокол поверх IEEE 802.15.4, работающий в диапазоне 2.4 ГГц. Телефон напрямую с Thread-устройством не говорит: между ними всегда стоит Border Router — Apple HomePod mini, Google Nest Hub 2nd gen, или собственный OTBR (OpenThread Border Router) на Raspberry Pi. Мобильное приложение управляет устройствами через этот роутер, используя Thread over IP (TOIP) или Matter поверх Thread. Задача — не просто отправить команду, а понять топологию сети, обработать недоступность Router'а и не сжечь батарею на устройствах с питанием от CR2032.
Где обычно всё ломается
Border Router — точка отказа и основная боль. Если HomePod mini ушёл на обновление прошивки в 3 ночи, все Thread-устройства за ним недоступны. Приложение, которое не умеет различать «устройство офлайн» и «Border Router недоступен», показывает пользователю бессмысленную ошибку.
На iOS работа с Thread Border Router идёт через NetworkExtension framework и NEAppPushManager для локальных уведомлений от устройств в том же сегменте сети. Для полноценного взаимодействия с Thread через HomeKit нужны HMAccessory и HMCharacteristic — уровень абстракции, который скрывает физический транспорт, но добавляет задержку HAP (HomeKit Accessory Protocol) порядка 100-300 мс на команду.
На Android прямой поддержки Thread нет на уровне системного API вплоть до Android 15, где появился ThreadNetworkController в android.net.thread. До этого — только через Matter SDK (com.google.android.gms:play-services-home) или собственный OTBR с REST API. Приложение общается с Border Router по CoAP через UDP, что требует аккуратной работы с DatagramChannel в неблокирующем режиме и ручного управления ACK-тайаутами.
Архитектура интеграции
Рабочая схема для кросс-платформенного приложения на Flutter:
Мобильное приложение
↓ Matter/Home API или REST CoAP
Border Router (OTBR)
↓ IEEE 802.15.4 mesh
Thread-устройства
На Flutter используем matter_dart (unofficial) или нативные Platform Channels к Matter SDK. Для собственного OTBR — HTTP-клиент к REST API Border Router'а: GET /api/v1/node/dataset/active возвращает Thread Network Dataset в TLV-формате, POST /api/v1/steering-data управляет комиссионированием новых устройств.
class ThreadBorderRouterClient {
final Dio _dio;
Future<ThreadDataset> getActiveDataset() async {
final response = await _dio.get('/api/v1/node/dataset/active');
return ThreadDataset.fromTlv(
Uint8List.fromList(hex.decode(response.data['ActiveDataset'])),
);
}
Future<void> commissionDevice(String eui64, String pskd) async {
await _dio.post('/api/v1/commissioner/joiner', data: {
'EUI64': eui64,
'PSKd': pskd,
'Timeout': 120,
});
}
}
Состояние меш-сети получаем через GET /api/v1/node/router-table — список роутеров с RLOC16 адресами и качеством линк (Link Quality In/Out). Это важно для отладки: если устройство пропадает, сначала смотрим таблицу роутеров, а не логи приложения.
Управление питанием Sleepy End Device
Thread-устройства класса Sleepy End Device (SED) просыпаются раз в 240-1000 мс для проверки очереди сообщений у родительского роутера. Если команда пришла между опросами — устройство получит её на следующем poll-цикле. Приложение должно учитывать это при отображении статуса: «команда отправлена» и «команда выполнена» — разные состояния. Хранить их в Bloc/Cubit:
enum DeviceCommandState { idle, sent, acknowledged, failed }
class DeviceCommandCubit extends Cubit<DeviceCommandState> {
DeviceCommandCubit() : super(DeviceCommandState.idle);
Future<void> sendCommand(String deviceEui64, Command cmd) async {
emit(DeviceCommandState.sent);
try {
await _repository.send(deviceEui64, cmd);
// Ждём ACK из push-уведомления или polling
final ack = await _repository
.awaitAcknowledgement(deviceEui64, timeout: const Duration(seconds: 5));
emit(ack ? DeviceCommandState.acknowledged : DeviceCommandState.failed);
} catch (_) {
emit(DeviceCommandState.failed);
}
}
}
Комиссионирование и безопасность
Добавление нового устройства в Thread-сеть — комиссионирование через DTLS-туннель. Commissioner (приложение или Hub) и Joiner (новое устройство) аутентифицируются по PSKd (Pre-Shared Key for the device) — обычно это 8-символьный код на наклейке устройства. После успешного DTLS-хендшейка устройство получает Thread Network Credential: Network Key, PAN ID, Extended PAN ID, Channel.
На iOS этот процесс автоматизирован через HomeKit Accessory Setup с QR-кодом. На Android — через Matter Commissioning API в Google Play Services: CommissioningClient.commissionDevice() принимает CommissioningParams с кодом устройства.
Важный момент безопасности: Thread Network Key нельзя хранить в открытом виде в приложении. Если приложение работает с собственным OTBR, API Border Router'а должен быть доступен только из локальной сети и защищён mTLS или хотя бы Bearer-токеном.
Оценка и сроки
Объём зависит от того, что уже есть на стороне железа. Если Border Router предоставлен клиентом с готовым REST API — интеграция в мобильное приложение занимает 2-4 недели: проектирование слоя коммуникации, реализация комиссионирования, обработка состояний устройств, тестирование на реальном оборудовании. Если нужно разворачивать собственный OTBR и настраивать сетевую инфраструктуру — от 6 недель. Стоимость рассчитывается после анализа схемы сети и требований к платформам.