Мобільний додаток для IoT provisioning (налаштування пристроїв)

Клієнт приходить з ESP32 і хоче, щоб користувачі налаштовували його через мобільний додаток. Через два тижні з'ясовуємо, що BLE-provisioning не працює на iOS через невідповідність App Store Review Guidelines — Section 4.2 вимагає, щоб додаток працював без зовнішнього пристрою. Таке трапляється в кожному третьому проекті. Ми розробляємо мобільні додатки для IoT provisioning під ключ: від вибору протоколу до публікації в сторах. За 5+ років ми накопичили досвід вирішення таких задач: понад 100 проектів, включаючи складні кейси з мультивендорною підтримкою. Важливо не просто передати Wi-Fi пароль, а зробити це надійно та зручно для користувача — інакше конверсія просяде, а в сторах відхилять.

Що таке IoT Provisioning технічно

Пристрій «з коробки» не знає Wi-Fi пароль і не прив'язаний до облікового запису. Потрібно передати:

• Мережеві credentials (SSID + password)
• Ідентифікатор власника (user_id або token з платформи)
• Початкову конфігурацію (часовий пояс, ім'я пристрою, endpoint сервера)

Технічно це робиться через BLE, Wi-Fi Soft AP, комбо BLE+SoftAP або QR-код. Вибір методу залежить від заліза. Наприклад, Bluetooth Low Energy — стандарт для більшості IoT-модулів, але вимагає правильної реалізації GATT-сервера.

Як вибрати метод передачі credentials: BLE, Soft AP чи QR?

Якщо пристрій на ESP32 — можна будь-який. nRF52 — тільки BLE. RTL8710 — тільки Wi-Fi. Для B2C-пристроїв краще BLE або QR: користувач не перемикає мережі. SoftAP виправданий для промислового обладнання, де важлива надійність з'єднання.

З практики: в проекті з датчиками температури (nRF52) наш клієнт вибрав BLE — provisioning займає 15 секунд, конверсія 92%. Конкуренти використовували SoftAP — 30% користувачів кидали через зміну мережі на Android. Економія часу на підтримку склала близько 40%.

ESP-IDF Provisioning: практичний кейс

Espressif надає готовий esp_prov компонент на стороні прошивки та офіційні SDK. Ми використовували їх в проекті для ESP32-S3. Флоу через 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 — бінарний, компактний. На iOS використовуємо ESPProvision через Swift Package Manager.

Типова проблема: searchBleEspDevices не знаходить пристрій — воно вже пройшло provisioning і не рекламує сервіси. Рішення — кнопка «скидання до заводських» в інструкції.

Як налаштувати Wi-Fi Provisioning через Soft AP на Android?

Пристрій піднімає точку PROV_XXXXXX. Телефон має підключитися — це нетривіально, система може вирішити, що мережа «без інтернету», і переключитися назад на стільникові дані. На 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 запити підуть через стільникову мережу — з'єднання не встановиться. На iOS SoftAP не підтримується, тому для крос-платформених проектів вибираємо BLE.

Чому користувачі не можуть підключитися: часті помилки та рішення

• 2.4 vs 5 ГГц: пристрій підтримує тільки 2.4 ГГц, користувач вводить пароль від 5 ГГц мережі. Детектуємо через WifiManager.scanResults — перевіряємо частоту SSID. На Android 30+ потрібен ACCESS_FINE_LOCATION або NEARBY_WIFI_DEVICES.
• BLE не знаходить пристрій: пристрій вже налаштовано або не в режимі provisioning. Додаємо в інтерфейс перевірку стану та кнопку скидання.
• Таймаут підключення: на кожну стадію (пошук, відправка credentials, підключення до Wi-Fi) ставимо таймаут 30 секунд. При помилці — чітке повідомлення та варіанти дій.

Процес розробки: від аналітики до релізу

1. Аналітика: вибір методу, заліза, протоколу. Перевірка вимог App Store (Section 4.2) та Google Play.
2. Проектування: архітектура, дизайн UX (3-4 кроки), прототипи.
3. Реалізація: інтеграція SDK, кастомний flow, обробка помилок.
4. Тестування: реальні пристрої, сценарії з різними мережами, час роботи.
5. Деплой: публікація в сторах, налаштування code signing, push-сповіщення.