Інтеграція Matter у мобільний додаток: покрокове керівництво

Як інтегрувати 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

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 — на практиці ми використовуємо перевірку статусу пристрою перед кожним комісіонуванням.

Типові помилки при інтеграції

На практиці найчастіше витрачається час на наступне:

1. Версіонування Matter SDK — Matter 1.0 та 1.3 несумісні на рівні деяких кластерів. Фіксуйте версію SDK в залежностях та тестуйте на конкретних прошивках пристроїв.
2. BLE Commissioning на Android — якщо телефон не має BLE-з'єднання з пристроєм у момент комісіонування, Google Play Services запитує дозволи заново та скидає процес.
3. 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-інтеграцій для різних галузей. Замовте консультацію, щоб обговорити деталі.

^[1] Офіційна документація CSA Matter 1.3, 2024