Як працює інтеграція 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.
Ми інтегрували Thread у додатки для iOS та Android з моменту активного впровадження цього протоколу на ринку, накопичивши досвід більш ніж у 15 проектах різного масштабу — від управління одиничними датчиками до 50+ пристроїв в одній мережі. Завдання — не просто відправити команду, а зрозуміти топологію мережі, обробити недоступність Router'а і не спалити батарею на пристроях з живленням від CR2032. Економія на батарейках сягає 30-40% порівняно з Wi-Fi: один елемент служить до 2 років, що дає до 2000 ₴ економії на рік на заміну.
Чому Border Router — вузьке місце?
Border Router — точка відмови і основна біль. Якщо HomePod mini пішов на оновлення прошивки о 3 ночі, всі Thread-пристрої за ним недоступні. Додаток, який не вміє розрізняти «пристрій офлайн» і «Border Router недоступний», показує користувачеві безглузду помилку. Типова проблема: команда не доходить, а додаток пише «пристрій недоступний», хоча пристрій справний — недоступний саме роутер. У наших рішеннях ми завжди додаємо моніторинг стану Border Router через таблицю маршрутизації та окремий статус для 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-тайаутами. Різниця в затримці між iOS та Android може сягати 30% — це важливо при проектуванні синхронних команд.
Як комісіонувати Thread-пристрій з додатка?
Додавання нового пристрою в 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.
| Платформа | API/інструмент | Особливості |
|---|---|---|
| iOS | HomeKit Accessory Setup (QR) | Автоматичне отримання PSKd з QR-коду, вбудована підтримка DTLS |
| Android | Matter Commissioning API (Google Play Services) | Вимагає CommissioningClient.commissionDevice() з CommissioningParams |
| Власний OTBR | REST API + OpenThread Joiner Router | Повний контроль, але потрібно реалізувати безпечне зберігання Network Key |
Важливий момент безпеки: Thread Network Key не можна зберігати у відкритому вигляді в додатку. Якщо додаток працює з власним OTBR, API Border Router'а має бути доступний тільки з локальної мережі та захищений mTLS або хоча б Bearer-токеном.
Чому Thread кращий за Wi-Fi і BLE для IoT?
Thread споживає в 10 разів менше енергії, ніж Wi-Fi, і покриває до 30+ пристроїв без єдиної точки відмови, на відміну від BLE, де потрібен шлюз для кожного кластеру. Швидкість передачі (250 кбіт/с) достатня для команд управління і телеметрії. Mesh-топологія автоматично перебудовується при виході вузла з ладу — це забезпечує гарантію доставки команд навіть при нестабільній мережі.
Архітектура інтеграції
Робоча схема для крос-платформенного додатка на 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);
}
}
}
Що входить в роботу (deliverables)
При замовленні інтеграції Thread у мобільний додаток ми надаємо:
- Документація з архітектури інтеграції: схема мережі, специфікація API Border Router'а, діаграма станів пристроїв.
- Реалізований модуль комунікації: для iOS (Swift) та Android (Kotlin) або крос-платформенний на Flutter/React Native.
- Комісіонування пристроїв: підтримка QR-кодів, ручного введення PSKd, автоматичне додавання в мережу.
- Обробка станів: offline, sleeping, available — з індикацією недоступності Border Router.
- Тестування на 3+ реальних Thread-пристроях (датчики, лампи, вимикачі).
- Доступ до демо-додатка для відладки: перегляд таблиці роутерів, логів та діагностика.
Типові помилки при інтеграції Thread
- Ігнорування стану Border Router: додаток показує «пристрій офлайн», хоча насправді недоступний роутер. - Неправильна обробка ACK від SED: команда відправлена, але не виконана, а додаток вважає її успішною. - Зберігання Network Key у SharedPreferences — груба вразливість. - Відсутність retry-логіки при перезавантаженні Border Router.Оцінка та терміни
Обсяг залежить від того, що вже є на стороні заліза. Якщо Border Router наданий клієнтом з готовим REST API — інтеграція в мобільний додаток займає 2–4 тижня: проектування шару комунікації, реалізація комісіонування, обробка станів пристроїв, тестування на реальному обладнанні. Якщо потрібно розгортати власний OTBR і налаштовувати мережеву інфраструктуру — від 6 тижнів. Вартість розраховується після аналізу схеми мережі та вимог до платформ.
Ми гарантуємо стабільний зв'язок і відсутність раптових відключень — всі рішення проходять навантажувальне тестування до 50 пристроїв. Зв'яжіться з нами для обговорення вашого проекту — ми підберемо оптимальну архітектуру під ваш пристрій та платформу. Отримайте консультацію безкоштовно.