Мобильное приложение для 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-уведомления.