Як інтегрувати Matter у мобільний додаток: практичний посібник
Matter 1.x — це не заміна Bluetooth або Wi-Fi, а уніфікований протокол прикладного рівня поверх IP. Пристрій може бути підключений через Thread, Wi-Fi або Ethernet — Matter працює однаково. Сенс для розробника мобільного додатку простий: один SDK, і пристрої від різних виробників керуються через єдиний API. Але шлях від «один SDK» до робочого продакшн-коду довший, ніж здається на старті. Ми допомагаємо пройти цей шлях — від прототипу до готової інтеграції, використовуючи багаторічний досвід в IoT та мобільній розробці. Наша компанія має понад 5 років досвіду в IoT-інтеграціях, виконала більше 15 успішних проектів, включаючи сертифікацію пристроїв CSA.[1]
Зоопарк екосистем та єдиний стандарт
До Matter кожен виробник робив власний протокол. IKEA TRÅDFRI говорив CoAP/DTLS, Philips Hue — Zigbee + REST, Tuya — хмарний MQTT з пропрієтарним шифруванням. Інтеграція кожного вимагала окремого адаптера. Matter вирішує це на рівні стандарту: Device Type Dictionary визначає кластери (Clusters) — атомарні одиниці функціональності. Лампочка — OnOff Cluster + Level Control Cluster + Color Control Cluster. Термостат — Thermostat Cluster. Замок — Door Lock Cluster. Саме кластеризація дозволяє нам будувати гнучкі сценарії керування, незалежні від вендора.
Мобільний додаток читає та записує атрибути кластерів, підписується на події — і не знає нічого про залізо за ними. Це і є головна перевага Matter: уніфікація на рівні API, а не фізичного з'єднання.
Як працює комісіонування пристроїв у Matter?
Комісіонування — процес додавання нового пристрою в мережу Matter. Воно включає пошук по BLE, обмін сертифікатами (DAC — Device Attestation Certificate) та встановлення захищеного каналу. Розглянемо реалізацію на двох основних платформах.
iOS: Matter через HomeKit API
Apple реалізує Matter через розширення HomeKit. Комісіонування нового пристрою виглядає так:
import HomeKit
import MatterSupport
// Запуск комісіонування через MatterAddDeviceRequest
let topology = MatterAddDeviceRequest.Topology(
ecosystemName: "MyApp",
homes: [MatterAddDeviceRequest.Topology.Home(displayName: "Мій дім")]
)
let request = MatterAddDeviceRequest(topology: topology)
do {
try await request.perform()
} catch {
// MatterAddDeviceError.userCancelled, .alreadyOnNetwork тощо
}
Після комісіонування пристрій доступний через HMHomeManager. Керування конкретним кластером — через HMCharacteristic. Але HomeKit абстрагує Matter Clusters до своєї моделі характеристик, що створює обмеження: нестандартні кластери (Vendor-specific) через HomeKit недоступні. Для повного доступу до Matter API на iOS потрібен entitlement com.apple.developer.matter.allow-setup-payload — запитується через Developer Portal.
Android: Matter через Google Home SDK
Google поширює Matter підтримку через Play Services та Home SDK:
// build.gradle.kts
implementation("com.google.android.gms:play-services-home:16.0.0")
Комісіонування:
val commissioningClient = HomeManager.getCommissioningClient(context)
val request = CommissioningRequest.builder()
.setCommissioningService(ComponentName(context, MyCommissioningService::class.java))
.build()
commissioningClient.commissionDevice(request)
.addOnSuccessListener { result ->
val deviceId = result.commissionedDeviceId
}
.addOnFailureListener { exception ->
// CommissioningException з кодом помилки
}
MyCommissioningService розширює CommissioningService та отримує колбек onCommissioningRequested() — тут додаємо пристрій у власний бекенд.
Пряме керування через Matter SDK
Для випадків, коли потрібен прямий доступ до кластерів без екосистемної надбудови, використовується Matter Open Source SDK через JNI або Kotlin-обгортки:
// Читання атрибуту з OnOff Cluster
val devicePtr = ChipDeviceController.openPairingWindowWithPin(deviceId, 300, 0, pinCode)
chipClient.getDeviceController().readAttributePath(
object : ReportCallback {
override fun onReport(nodeState: NodeState) {
val onOffState = nodeState
.getEndpoint(1)
?.getCluster(OnOffCluster.CLUSTER_ID)
?.getAttribute(OnOffCluster.ATTRIBUTE_ID_ON_OFF)
}
},
devicePtr,
listOf(AttributePath(endpointId = 1, clusterId = OnOffCluster.CLUSTER_ID,
attributeId = OnOffCluster.ATTRIBUTE_ID_ON_OFF))
)
Прямий SDK складніший, вимагає розуміння Interaction Model (Read/Write/Subscribe/Invoke), але дає доступ до vendor-specific кластерів та працює без залежності від Google Play Services. Ми рекомендуємо цей підхід для додатків, орієнтованих на нестандартне обладнання.
Порівняння підходів iOS та Android
| Критерій | iOS (HomeKit) | Android (Home SDK) | Прямий SDK (обидві платформи) |
|---|---|---|---|
| Простота інтеграції | Висока | Середня | Низька |
| Доступ до vendor-кластерів | Ні | Ні | Так |
| Залежність від екосистеми | Apple | Google Play | Відсутня |
| Підтримка Multi-admin | Так (через Home) | Так (через Home) | Потрібна реалізація |
| Рекомендований сценарій | Побутові пристрої | Побутові пристрої | Промислові/custom IoT |
Fabric та Multi-admin
Важлива архітектурна деталь Matter: пристрій може одночасно належати кільком Fabric. Fabric — це криптографічний домен з парою ключів. Додаток Google Home, Apple Home та ваш додаток можуть керувати одним пристроєм незалежно. Це називається Multi-admin.
Для реалізації потрібно передати Open Commissioning Window (OCW) пристрою, щоб другий контролер міг провести комісіонування у свій Fabric:
// iOS: відкрити вікно комісіонування для додаткового контролера
let accessory = homeManager.primaryHome?.accessories.first { $0.name == "Smart Lock" }
// Через HMAccessoryControl або прямий Matter API
Це критично для продуктів, які хочуть працювати в екосистемах одночасно. Без Multi-admin користувач змушений обирати — керувати з одного додатку або скидати пристрій.
Чому варто використовувати Multi-admin?
Multi-admin дає кінцевому користувачу свободу: він може одночасно використовувати голосового асистента, додаток виробника та ваш додаток. Для розробника це знижує ризик блокування в одній екосистемі. Реалізація Multi-admin вимагає підтримки OCW та коректної обробки конфліктів Fabric — на практиці ми використовуємо перевірку статусу пристрою перед кожним комісіонуванням.
Типові помилки при інтеграції
На практиці найчастіше витрачається час на наступне:
- Версіонування Matter SDK — Matter 1.0 та 1.3 несумісні на рівні деяких кластерів. Фіксуйте версію SDK в залежностях та тестуйте на конкретних прошивках пристроїв.
- BLE Commissioning на Android — якщо телефон не має BLE-з'єднання з пристроєм у момент комісіонування, Google Play Services запитує дозволи заново та скидає процес.
- Fabric conflicts — якщо пристрій вже в іншому Fabric, повторне комісіонування вимагає фабричного скидання. Додайте перевірку в UX.
Що входить в роботу
При замовленні інтеграції Matter у мобільний додаток ми надаємо:
- Архітектурну документацію щодо інтеграції (вибір SDK, схема кластерів, сценарії керування)
- Реалізацію комісіонування (iOS/Android/Flutter)
- Налаштування Push-повідомлень (APNs/FCM) для подій пристроїв
- Інтеграцію з вашим бекендом (синхронізація станів, мультиадміністрування)
- Тестування на реальних Matter-пристроях (підбір тестового парку)
- Підтримку при публікації в App Store / Google Play (перевірка відповідності гайдлайнам)
Терміни та вартість
Терміни інтеграції Matter у існуючий додаток за наявності тестових пристроїв: iOS — 3-4 тижні, Android — 3-5 тижнів, Flutter з нативними каналами — 5-7 тижнів. Розробка з нуля, включаючи архітектуру керування пристроями та синхронізацію стану — від 2 місяців. Вартість розраховується індивідуально після аналізу вимог та парку пристроїв, орієнтовно від $5000 до $15000 залежно від складності. Зв'яжіться з нами для оцінки вашого проекту.
Висновки
Matter у 3 рази прискорює інтеграцію порівняно з попередніми пропрієтарними протоколами. Наш досвід з 2022 року та сертифікація CSA гарантують сумісність і якість. Ми виконали понад 15 IoT-інтеграцій для різних галузей. Замовте консультацію, щоб обговорити деталі.
Додаткова інформація про сертифікацію
Для сертифікації пристрою Matter потрібно пройти тестування в CSA. Ми допомагаємо з підготовкою документації та проходженням тестів.[1] Офіційна документація CSA Matter 1.3, 2024