Розробка мобільного додатку для настройки IoT-пристроїв (Provisioning)
Provisioning—перше, з чим зустрічаються користувачі при розпаковуванні нового IoT-пристрою. Якщо цей процес займає більше 2 хвилин або вимагає інструкції, конверсія в активних користувачів падає. Завдання розробки—зробити з технічного процесу (передача Wi-Fi credentials, реєстрація на платформі, первинна конфігурація) лінійний UX з 3–4 кроків.
Що таке IoT Provisioning технічно
Пристрій «з коробки» не знає Wi-Fi пароль та не привязаний до аккаунту користувача. Потрібно передати три речі:
- Мережеві credentials (SSID + password)
- Ідентифікатор власника (user_id або токен платформи)
- Первинну конфігурацію (часовий пояс, імя пристрою, endpoint сервера)
Технічно це робиться через:
- BLE (Bluetooth Low Energy)—пристрій у режимі provisioning піднімає GATT-сервер, мобільний додаток пишет дані в характеристики
- Wi-Fi Soft AP—пристрій піднімає власну точку доступу, телефон підключається та передає дані через HTTP
- SoftAP + BLE комбо—BLE для discovery та первинного обміну, Wi-Fi для передачі сертифікатів
- QR-код—базові credential зашиті в QR при виробництві, телефон сканує та доповнює даними аккаунту
Вибір методу залежить від залізосту пристрою. ESP32—підтримує всі варіанти. nRF52—тільки BLE. RTL8710—тільки Wi-Fi.
ESP-IDF Provisioning: практика
Espressif надає готовий esp_prov компонент на стороні прошивки та офіційні SDK для мобільних додатків:
- Android:
com.espressif:provisioning-android - iOS:
ESPProvision(Swift Package Manager)
Флоу через BLE з Android SDK:
ESPProvisionManager.getInstance(context).searchBleEspDevices("PROV_") { devices, error ->
// devices—знайдені пристрої з префіксом PROV_
val device = devices?.firstOrNull() ?: return@searchBleEspDevices
device.connectBLEDevice(bleScanResult) { session ->
device.provision(ssid, passphrase) { status ->
when (status) {
ProvisioningStatus.SUCCESS -> onProvisioned()
ProvisioningStatus.FAILURE -> onFailed(status.error)
ProvisioningStatus.CONFIG_SENT -> updateProgress(50)
}
}
}
}
Під капотом SDK встановлює зашифровану сесію через Session Security (протокол sec1—Curve25519 + AES-CTR), передає Wi-Fi credentials через protocomm layer. Протокол Protobuf—бінарний, компактний.
Типична проблема: searchBleEspDevices не знаходить пристрій, хоча він включений. Причина частіше всього—пристрій уже пройшов provisioning та не рекламує BLE-сервіси. Потрібна кнопка «сброс до заводських настроєк» в інструкції.
Wi-Fi Provisioning через Soft AP
Пристрій піднімає точку PROV_XXXXXX. Телефон повинен до неї підключитися—нетривіально на Android, тому що система може вирішити, що ця мережа «без інтернету» та переключитися на сотові дані.
На Android 10+ явне підключення через WifiNetworkSpecifier:
val specifier = WifiNetworkSpecifier.Builder()
.setSsid("PROV_${deviceSuffix}")
.setWpa2Passphrase(apPassword)
.build()
val request = NetworkRequest.Builder()
.addTransportType(NetworkCapabilities.TRANSPORT_WIFI)
.setNetworkSpecifier(specifier)
.build()
connectivityManager.requestNetwork(request, object : ConnectivityManager.NetworkCallback() {
override fun onAvailable(network: Network) {
// Всі HTTP-запити до пристрою потрібно робити через цей network об'єкт
val client = OkHttpClient.Builder()
.socketFactory(network.socketFactory)
.build()
sendProvisioningData(client)
}
})
Без явного network.socketFactory в OkHttp запити уйдуть через дефолтний інтерфейс (сотова сеть), а не через AP пристрою—з'єднання не встановиться.
UX-сценарій та обробка помилок
Поганий UX: бесконечний спіннер. Хороший: прогрес з конкретними кроками—«Пошук пристрою», «Підключення», «Відправка мережі», «Пристрій підключається до Wi-Fi», «Реєстрація». Кожен крок—таймаут. Якщо пристрій не підключився до Wi-Fi за 30 секунд—запропонувати перевірити пароль.
Найчастіша помилка користувачів: вводять пароль від 5 ГГц мережі, а пристрій підтримує тільки 2.4 ГГц. Детектувати це заранее—через WifiManager.scanResults перевірити, на якій частоті працює вибрана SSID. На Android 30+ для цього потрібні ACCESS_FINE_LOCATION або NEARBY_WIFI_DEVICES дозволи.
Тривалість
Provisioning через один канал (BLE або Soft AP) з використанням Espressif SDK: 2–4 тижні. Кастомний протокол, мультивендорна підтримка, повний flow з реєстрацією на платформі: 5–8 тижнів. Вартість розраховується індивідуально.