Интеграция Matter-протокола для IoT-устройств в мобильное приложение

Интеграция Matter-протокола для IoT-устройств в мобильное приложение

Matter 1.x — это не замена Bluetooth или Wi-Fi, а унифицированный протокол прикладного уровня поверх IP. Устройство может быть подключено по Thread, Wi-Fi или Ethernet — Matter работает одинаково. Смысл для разработчика мобильного приложения прост: один SDK, и устройства от разных производителей управляются через единый API. Но путь от «один SDK» до рабочего продакшн-кода длиннее, чем кажется на старте. Мы помогаем пройти этот путь — от прототипа до готовой интеграции, используя многолетний опыт в IoT и мобильной разработке.

Зоопарк экосистем и единый стандарт

До 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) устройству, чтобы второй контроллер мог провести comissioning в свой 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 месяцев. Стоимость рассчитывается индивидуально после анализа требований и парка устройств. Свяжитесь с нами для оценки вашего проекта.

Мы работаем с Matter с 2022 года, выполнили более 15 IoT-интеграций для различных отраслей. Наш опыт включает сертификацию устройств CSA и оптимизацию взаимодействия с экосистемами Apple и Google. Закажите консультацию, чтобы обсудить детали.