Інтеграція 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 тижнів. Вартість розраховується після аналізу схеми мережі та вимог до платформ.