Интеграция 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 подходов
| Критерий | 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) устройству, чтобы второй контроллер мог провести 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. Закажите консультацию, чтобы обсудить детали.