artem.kokos/ignis_app
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases 1 Wiki Activity
Files
feat/wiz-provisioning-master
ignis_app/docs/wiz_provisioning_master_plan.md
Artem Kokos 866a074c03 Add WiZ provisioning wizard
2026-05-16 17:24:28 +07:00

40 KiB
Raw Permalink Blame History

WiZ Provisioning Master Plan

Статус: design / implementation brief
Актуально на: 2026-05-16
Основной проект: ignis_app
Связанный проект: ../ignis-core

Зачем нужен этот документ

Этот документ нужен как рабочий implementation brief для добавления в Ignis мастера первичной посадки новых WiZ-ламп на домашний Wi-Fi без официального приложения WiZ.

Цель документа:

  • быстро восстановить контекст через недели или месяцы без повторного ресерча;
  • понимать, что именно реализуем сначала, а что откладываем;
  • иметь точную карту действий по Flutter, Android native и интеграции с ignis-core;
  • заранее зафиксировать технические риски и места, где потребуются ручные проверки и апрувы.

Краткий вывод

Сделать это реально, но нужно разделять минимум два поколения/режима onboarding:

  • SoftAP / manual setup: лампа поднимает сеть вида WiZConfig_xxxx, телефон временно подключается к ней и передаёт домашние Wi-Fi credentials.
  • BLE setup: часть более новых устройств рекламируется и настраивается по Bluetooth.

Дополнительно у части устройств есть Matter, но его не стоит брать как первый путь реализации внутри Ignis.

Почему задача вообще выглядит решаемой

Официальные материалы WiZ подтверждают:

  • есть режим Manual setup через Wi-Fi лампы WiZConfig_xxxx;
  • есть Bluetooth-based setup для новых устройств;
  • есть отдельный локальный commissioning-порт UDP 18266, который используется только во время ввода устройства в строй.

Это означает, что задача не упирается в принципиальную закрытость экосистемы. Главная неизвестная не в том, можно ли это сделать, а в том, какой именно payload нужно передать лампе при commissioning.

Границы задачи

Что считаем целевым результатом

Пользователь открывает ignis_app, запускает мастер, выбирает домашнюю Wi-Fi сеть, вводит пароль, переводит лампу в pairing mode, приложение временно подключается к лампе, передаёт credentials, ждёт появления лампы в домашней сети и затем вызывает POST /devices/rescan на локальном сервере ignis-core.

Что не входит в первую фазу

  • полноценный iOS onboarding;
  • Matter commissioner внутри Ignis;
  • cloud-интеграции WiZ;
  • поддержка всех возможных поколений устройств одновременно;
  • идеальный cross-platform UX.

Что делаем в первую очередь

  1. Android-only onboarding.
  2. Сначала SoftAP-ветка.
  3. После неё BLE-ветка.
  4. Matter рассматривать только как отдельный fallback/будущее расширение.

Текущий статус реализации

По состоянию на 2026-05-16 в ignis_app уже есть первая рабочая Android-first реализация мастера, но она закрывает только часть общей задачи.

Что уже реализовано

  • отдельный экран мастера в ignis_app;
  • Android environment inspection через platform channel;
  • проверка Wi-Fi контекста, системных permissions и активного дома;
  • Android-first smart pairing flow на базе esp_smartconfig;
  • post-provision POST /devices/rescan через уже существующий backend ignis-core;
  • release build, flutter analyze и тесты проходят;
  • entrypoint мастера перенесён в SettingsScreen, в секцию Дом и подключение.

Что это означает на практике

Сейчас в проекте есть не "полноценный универсальный мастер WiZ", а первый технический клин в эту задачу: Android-only путь через smart pairing с последующим discovery в Ignis.

Что критично ещё не реализовано

  • нет SoftAP-ветки через WiZConfig_xxxx;
  • нет reverse engineering и production-реализации commissioning-протокола UDP 18266;
  • нет BLE-ветки для новых ламп;
  • нет Matter-fallback;
  • нет iOS-реализации;
  • нет подтверждения на реальном железе, что текущий smart pairing путь покрывает нужные пользователю модели ламп.

Честная оценка текущего состояния

Тема не закрыта. Закрыт только первый этап.

Если текущий smart pairing на реальных лампах пользователя не сработает, основной следующий шаг -- это не косметика и не polish, а возврат к базовому плану:

  1. SoftAP / WiZConfig_xxxx
  2. commissioning через UDP 18266
  3. затем BLE-ветка

Что ещё не добито по UX и диагностике

  • нет выбора provisioning mode (smart pairing / WiZConfig_xxxx / BLE);
  • нет явного fallback UX для ламп, которые не поддерживают текущий путь;
  • нет финального успешного сценария "создать группу / мигнуть лампой / открыть пульт";
  • нет отдельного protocol notes файла с результатами reverse engineering;
  • нет полной ручной test matrix по реальным устройствам разных поколений.

Почему основной объём живёт в ignis_app

Onboarding должен жить в ignis_app, а не в ignis-core, потому что именно телефон:

  • видит nearby Wi-Fi/BLE устройства;
  • может временно переключаться на AP лампы;
  • может работать с Android Wi-Fi / Bluetooth API;
  • может запросить системные permissions и показать пользователю platform dialogs.

ignis-core нужен только после успешного provisioning:

  • сделать POST /devices/rescan;
  • обнаружить лампу в домашней сети;
  • дальше работать обычным локальным API, который уже реализован.

Связанные текущие точки в коде:

  • ignis_app/lib/main.dart
  • ignis_app/lib/screens/homes_screen.dart
  • ignis_app/lib/screens/remote_screen.dart
  • ignis_app/android/app/src/main/kotlin/ru/akokos/ignis_app/MainActivity.kt
  • ignis_app/lib/services/api_client.dart
  • ignis-core/app/api/routes/devices.py

Подтверждённые факты из источников

1. У WiZ есть ручной setup через WiZConfig_xxxx

Официальная legacy-справка WiZ говорит, что если обычное pairing не сработало, нужно идти в Manual setup, где телефон подключается напрямую к Wi-Fi сети лампы.

Источник:

Дополнительный важный нюанс: WiZ отдельно пишет, что у некоторых ламп сеть WiZConfig_xxxx может отсутствовать вообще. Это значит, что SoftAP-путь нельзя считать универсальным.

Источник:

2. У новых устройств есть Bluetooth-based setup

Новая справка WiZ V2 указывает, что Bluetooth permission нужен для Bluetooth-enabled products и что приложение может автоматически находить такие лампы после включения питания.

Источник:

Дополнительное косвенное подтверждение: в даташитах WiZ/WiZ Pro встречается Wi-Fi + BLE и явная фраза про setup via Bluetooth.

Источники:

3. У WiZ есть отдельный commissioning-порт UDP 18266

Это ключевой технический сигнал. В официальном документе по сети WiZ указано, что порт 18266/UDP используется локально и только во время commissioning.

Источник:

Вывод: существует локальный commissioning-протокол, который, вероятно, и использует официальное приложение во время первичной посадки лампы в Wi-Fi.

4. Android официально поддерживает bootstrap к локальной Wi-Fi accessory network

Для Android 10+ есть штатный путь для peer-to-peer Wi-Fi bootstrap через WifiNetworkSpecifier.

Источник:

5. iOS тоже поддерживает accessory Wi-Fi setup, но не это наш первый приоритет

Для iOS есть NEHotspotConfiguration / NEHotspotConfigurationManager, а также accessory-oriented Wi-Fi configuration APIs. Это делает iOS-ветку возможной, но отдельной и более дорогой по времени.

Источники:

6. Matter есть не на всех WiZ-устройствах

WiZ пишет, что Matter поддерживают только lights/smart plugs, выпущенные после Q2 2021. Поэтому Matter нельзя использовать как универсальный onboarding-path.

Источник:

Принятая стратегия реализации

Основной план

  1. Реализовать Android-only SoftAP onboarding.
  2. Через reverse engineering добыть локальный commissioning payload для UDP 18266.
  3. Встроить это в ignis_app как отдельный мастер.
  4. После успешного provisioning вызывать existing rescanNetwork() через текущий IgnisApi.
  5. Затем добавить BLE onboarding как вторую ветку.

Почему не начинать с BLE

  • SoftAP-path подтверждён официальной справкой WiZ.
  • Android Wi-Fi bootstrap API проще и стабильнее, чем reverse engineering GATT-профиля с нуля.
  • BLE вероятно потребуется для новых ламп, но SoftAP даст первый рабочий end-to-end flow быстрее.

Почему не начинать с Matter

  • не все устройства его поддерживают;
  • внутри собственного Flutter-приложения Matter commissioner сильно увеличивает объём работ;
  • для цели Ignis нужен именно практичный локальный onboarding WiZ-лампы, а не параллельный smart-home стек.

Архитектурное решение по проекту

High-Level Flow

Flutter UI
  -> MethodChannel
    -> Android provisioning manager
      -> connect to WiZConfig_xxxx AP
      -> send commissioning payload to lamp over UDP 18266
      -> wait for device to leave AP / join home Wi-Fi
  -> call ignis-core POST /devices/rescan
  -> show discovered device / success state

Что добавляем в ignis_app

Новая feature-зона:

  • lib/features/provisioning/models/
  • lib/features/provisioning/providers/
  • lib/features/provisioning/services/

Новый экран:

  • lib/screens/wiz_provisioning_screen.dart

Новые Android native классы:

  • android/app/src/main/kotlin/ru/akokos/ignis_app/WizProvisioningManager.kt
  • android/app/src/main/kotlin/ru/akokos/ignis_app/WizSoftApProvisioner.kt
  • android/app/src/main/kotlin/ru/akokos/ignis_app/WizUdpCommissioningClient.kt
  • android/app/src/main/kotlin/ru/akokos/ignis_app/WizProvisioningModels.kt

Вторая очередь, не первая:

  • android/app/src/main/kotlin/ru/akokos/ignis_app/WizBleProvisioner.kt

Что не нужно делать в ignis-core

Не нужно переносить туда onboarding-логику. Сервер не должен:

  • управлять Wi-Fi телефона;
  • принимать пароль от домашней сети как основную часть provisioning;
  • реализовывать platform-specific transport.

В ignis-core достаточно использовать уже существующий:

  • POST /devices/rescan

Текущая клиентская точка входа:

  • ignis_app/lib/services/api_client.dart -> rescanNetwork()

Фактическая реализация против плана

Изначальный план первой полноценной фазы предполагал старт с SoftAP onboarding. В коде сейчас первой реализованной веткой стал smart pairing.

Почему это важно помнить

  • это ускорило появление первого рабочего мастера;
  • но это не доказывает, что задача "подключение любых новых WiZ-ламп без официального приложения" уже решена;
  • исходный SoftAP + UDP 18266 путь по-прежнему остаётся вероятно более универсальным и по-прежнему нужен, если smart pairing не перекрывает нужные модели устройств.

Предлагаемая модель состояния мастера

Нужна явная state machine, а не набор bool-флагов.

Состояния

  • idle
  • checkingCapabilities
  • requestingPermissions
  • waitingForHomeSelection
  • waitingForPairingMode
  • scanningForSoftAp
  • connectingToLampAp
  • connectedToLampAp
  • commissioning
  • waitingForLampToJoinHome
  • rescanningIgnis
  • success
  • failure
  • cancelled

Данные состояния

  • selectedHomeSsid
  • selectedHomePassphrase
  • selectedIgnisHomeId
  • lampApSsid
  • attempt
  • lastError
  • debugTimeline
  • startedAt
  • finishedAt

Почему нужен debugTimeline

Provisioning без timeline очень трудно дебажить. Минимум нужен список событий:

  • permission granted/denied;
  • lamp AP discovered;
  • Wi-Fi request sent;
  • Wi-Fi request accepted/rejected;
  • UDP payload sent;
  • ack received / timeout;
  • device disappeared from AP;
  • rescan started/finished.

UX-структура мастера

Экран 1. Введение

Показывает:

  • что мастер пока Android-only;
  • какие лампы могут не поддерживать SoftAP;
  • что телефон временно переключится на сеть лампы;
  • что нужен локальный сервер Ignis и доступный активный дом.

Экран 2. Проверка контекста

Проверки:

  • выбран ли активный HomeConfig;
  • доступен ли auth/me текущего дома;
  • есть ли Wi-Fi на телефоне;
  • есть ли необходимые Android permissions;
  • Android API level >= 29.

Экран 3. Выбор домашней сети

Варианты:

  • ручной ввод SSID и пароля;
  • позже, если потребуется, попытка показать текущий SSID как подсказку.

Важно: не делать магии вокруг чтения текущего SSID как обязательного пути. На Android это permission-sensitive и OEM-dependent.

Экран 4. Инструкция перевода лампы в pairing mode

Нужно явно объяснить:

  • включить лампу;
  • если не находится, несколько раз выключить/включить до мигания;
  • если лампа не поднимает WiZConfig_xxxx, значит этот путь может не поддерживаться и нужен BLE-path.

Экран 5. Подключение и provisioning

Показывать по шагам:

  • поиск WiZConfig_xxxx;
  • подключение;
  • передача настроек;
  • ожидание возврата лампы в домашнюю сеть;
  • запрос rescan.

Экран 6. Итог

Успех:

  • показать, что лампа найдена;
  • предложить перейти к созданию группы или вернуться на пульт.

Ошибка:

  • показать, на каком шаге упало;
  • дать actionable retry;
  • предлагать BLE-path только когда он будет реализован.

Точки встраивания в текущее приложение

Минимально логичное место входа:

  • HomesScreen: отдельная кнопка "Добавить лампу WiZ"
  • или RemoteScreen в overflow menu

Рекомендуемый вариант первой версии:

  • вход из HomesScreen, потому что provisioning логически относится к конкретному дому/серверу.

Причина:

  • мастер зависит от выбранного активного дома;
  • после provisioning всё равно нужен rescan именно этого дома;
  • onboarding новой лампы ближе по смыслу к инфраструктуре дома, чем к управлению существующими группами.

Android implementation plan

Phase 1: Platform Bridge Skeleton

Цель

Подготовить безопасный мост Flutter <-> Android без реальной provisioning-логики.

Изменяемые файлы

  • ignis_app/android/app/src/main/kotlin/ru/akokos/ignis_app/MainActivity.kt
  • новые Kotlin-файлы из секции выше
  • новые Dart provider/service/screen файлы

MethodChannel

Использовать отдельный channel, не смешивать с geofence.

Предлагаемое имя:

  • ignis/wiz_provisioning

Методы канала v1

  • getProvisioningCapabilities
  • requestProvisioningPermissions
  • startSoftApProvisioning
  • cancelProvisioning

Формат getProvisioningCapabilities

Возвращать map:

  • platform: android
  • androidApiLevel
  • supportsWifiNetworkSpecifier
  • supportsBle
  • supportedModes: ["softap"] на первой фазе

Формат startSoftApProvisioning

Вход:

  • homeSsid
  • homePassphrase
  • lampApPrefix default WiZConfig_
  • timeoutSeconds
  • activeHomeBaseUrl
  • activeHomeApiKey

На первой фазе activeHomeBaseUrl и activeHomeApiKey можно вообще не передавать в native и оставить rescan на Flutter-стороне.

Phase 2: Android Wi-Fi Connect to Lamp AP

Цель

Научиться гарантированно подключать телефон к WiZConfig_xxxx.

Android APIs

  • WifiNetworkSpecifier
  • ConnectivityManager.requestNetwork()
  • NetworkCallback

Источник:

Требуемые permissions и manifest changes

Проверить и добавить по необходимости:

  • android.permission.NEARBY_WIFI_DEVICES для Android 13+
  • существующие location permissions уже частично есть

Текущий manifest:

  • ignis_app/android/app/src/main/AndroidManifest.xml

Что нужно реализовать

  • запрос permissions из Flutter;
  • поиск/выбор AP по префиксу WiZConfig_;
  • запрос на временное подключение;
  • ожидание onAvailable();
  • bind сокетов к этой Network, если потребуется;
  • корректный release callback после завершения или отмены.

Acceptance criteria

  • приложение может подключиться к реальной сети WiZConfig_xxxx;
  • есть надёжный таймаут и понятный error mapping;
  • повторный запуск после неудачи не оставляет висящих network requests.

Phase 3: Reverse Engineering Commissioning Payload

Это главный риск проекта

Пока нет публичного официального описания payload для UDP 18266.

Нужно добыть его экспериментально.

Практический план reverse engineering

  1. Взять лампу, которая точно поддерживает WiZConfig_xxxx.
  2. Перевести лампу в pairing mode.
  3. Запустить официальный WiZ app и пройти Manual setup.
  4. Снять трафик между телефоном и лампой во время provisioning.
  5. Отделить трафик к лампе от фонового шума.
  6. Найти обмен по UDP 18266.
  7. Зафиксировать:
    • формат payload;
    • есть ли ответ/ack;
    • есть ли checksum/nonce/session id;
    • передаётся ли SSID/пароль в открытом виде, JSON, protobuf, бинарнике и т.д.
  8. Повторить пару раз с разными SSID/password, чтобы понять структуру.

Что именно нужно получить в результате

  • пример сырого запроса;
  • пример сырого ответа;
  • описание полей;
  • минимальный payload, достаточный для посадки лампы;
  • список обязательных и необязательных параметров.

Какие инструменты могут понадобиться

  • Android device + официальный WiZ app;
  • отдельная тестовая Wi-Fi сеть;
  • Wireshark / tcpdump / mitm на уровне точки доступа;
  • при необходимости второй Android с hotspot/sniffer схемой;
  • возможно adb bugreport / network diagnostics как вспомогательный путь.

Решение по хранению результата

После расшифровки протокола создать отдельный внутренний документ:

  • ignis_app/docs/wiz_commissioning_protocol_notes.md

Если там будут чувствительные детали или сырые бинарные дампы, можно держать файл локально и не коммитить, но лучше иметь хотя бы структурированное описание в репозитории.

Phase 4: Implement UDP Commissioning Client

Цель

Собрать Kotlin-клиент, который:

  • открывает UDP socket в сети лампы;
  • отправляет commissioning payload на 18266;
  • ждёт подтверждение или фиксирует timeout;
  • отдаёт во Flutter понятный result object.

Предлагаемый класс

  • WizUdpCommissioningClient.kt

Предлагаемый API

  • suspend fun sendCredentials(network: Network, targetIp: InetAddress, payload: ByteArray): CommissioningResult

Что нужно предусмотреть

  • bind сокета именно к Network, через которую подключились к AP лампы;
  • configurable timeout;
  • раздельные ошибки:
    • socket_open_failed
    • payload_build_failed
    • send_failed
    • ack_timeout
    • malformed_ack

Phase 5: End-to-End Flutter Flow

Цель

Сделать законченный пользовательский мастер.

Новые Dart сущности

Предлагаемые файлы:

  • lib/features/provisioning/models/wiz_provisioning_mode.dart
  • lib/features/provisioning/models/wiz_provisioning_state.dart
  • lib/features/provisioning/models/wiz_provisioning_failure.dart
  • lib/features/provisioning/services/wiz_provisioning_platform_service.dart
  • lib/features/provisioning/providers/wiz_provisioning_providers.dart
  • lib/screens/wiz_provisioning_screen.dart

Поведение после успешного provisioning

  1. Flutter получает успех от native-слоя.
  2. Flutter ждёт короткое окно на переподключение лампы к домашней сети.
  3. Flutter вызывает текущий IgnisApi.rescanNetwork().
  4. Flutter обновляет список устройств/групп.
  5. Flutter показывает success и, если возможно, имя/IP/MAC найденной лампы.

Текущая клиентская точка:

  • ignis_app/lib/services/api_client.dart

Текущий backend route:

  • ignis-core/app/api/routes/devices.py

Phase 6: BLE Branch

Когда переходить к BLE

Только после того, как SoftAP-path уже рабочий end-to-end.

Что нужно выяснить перед реализацией

  • advertise name/service UUID лампы в pairing mode;
  • GATT services/characteristics;
  • какой transport и payload используются для передачи Wi-Fi credentials;
  • есть ли там тот же commissioning payload, что и в SoftAP-path, или совсем другой протокол.

Android tech stack для BLE

  • BluetoothManager
  • BluetoothAdapter
  • BluetoothLeScanner
  • ScanCallback
  • BluetoothGatt

Дополнительные permissions

  • android.permission.BLUETOOTH_SCAN
  • android.permission.BLUETOOTH_CONNECT

Важное ограничение

Пока нет сведений, что BLE-path у WiZ можно поднять без reverse engineering. Официальные источники подтверждают наличие Bluetooth setup, но не описывают низкоуровневый протокол.

Что менять в UI и навигации

Первая версия

Добавить в HomesScreen вторую FAB-entry или secondary action:

  • Добавить дом
  • Добавить лампу WiZ

Если не хочется перегружать основной FAB, сделать extended bottom sheet / speed dial / отдельную кнопку в пустом состоянии.

Более аккуратный вариант

Добавить на HomesScreen card/banner:

  • "Новая лампа WiZ? Открыть мастер подключения"

Что не делать

  • не прятать этот flow глубоко в SettingsScreen;
  • не запускать onboarding из RemoteScreen по умолчанию, если активный дом ещё не выбран и невалиден.

Безопасность и хранение Wi-Fi credentials

Минимальные правила

  • пароль домашней Wi-Fi сети не хранить в SharedPreferences;
  • не класть пароль в обычные debug-логи;
  • не записывать пароль в event log приложения;
  • держать пароль только в runtime memory на время onboarding-сессии;
  • по завершении или ошибке занулять/очищать state.

Что можно хранить

  • только SSID как UX convenience, если это вообще нужно;
  • debug timeline без секретов;
  • machine-readable error codes.

Тестовая стратегия

Unit / Widget Tests

Покрыть:

  • state machine;
  • error mapping native -> Flutter;
  • retry/cancel logic;
  • post-success переход к rescan.

Предлагаемые test-файлы

  • test/wiz_provisioning_state_test.dart
  • test/wiz_provisioning_notifier_test.dart
  • test/wiz_provisioning_screen_test.dart

Android Native Tests

Минимум:

  • локальные unit tests на payload builder;
  • по возможности instrumentation tests на permission/result mapping.

Но главное здесь всё равно manual verification на реальном устройстве.

Manual Test Matrix

Обязательные ручные сценарии:

  1. Успешная посадка лампы через WiZConfig_xxxx.
  2. Таймаут при отсутствии pairing mode.
  3. Ошибочный пароль домашней сети.
  4. Повторный запуск мастера сразу после ошибки.
  5. Отмена пользователем system dialog подключения к Wi-Fi.
  6. Потеря Wi-Fi во время provisioning.
  7. Успешный rescan после provisioning.
  8. Provisioning success, но rescan не находит лампу.
  9. Лампа без WiZConfig_xxxx и корректный UX fallback.
  10. Проверка на Android 13+ с новыми permission flows.

Acceptance Criteria для первой поставляемой версии

Первая версия считается завершённой, если:

  • мастер доступен из ignis_app;
  • Android 10+ устройство умеет подключиться к WiZConfig_xxxx;
  • приложение умеет отправить commissioning payload и получить воспроизводимый результат;
  • лампа уходит в домашнюю сеть;
  • Ignis после rescan видит лампу;
  • пользователь получает понятный success/failure UX;
  • чувствительные данные не остаются в persistent storage;
  • есть тесты на Dart state machine и минимум ручной regression checklist.

Пошаговая карта действий

Шаг 0. Подготовка перед кодом

  1. Подтвердить наличие тестовой WiZ-лампы с WiZConfig_xxxx.
  2. Подготовить Android-девайс для ручных прогонов.
  3. Подготовить отдельную тестовую Wi-Fi сеть 2.4 GHz.
  4. Подготовить стенд с рабочим ignis-core.
  5. Решить, где и как снимать provisioning traffic.

Шаг 1. Скелет feature в ignis_app

  1. Добавить docs/ и этот план.
  2. Создать feature-папки lib/features/provisioning/*.
  3. Создать Dart-модели состояния.
  4. Создать WizProvisioningPlatformService.
  5. Создать новый MethodChannel.
  6. Добавить пустой экран мастера и точку входа из HomesScreen.

Шаг 2. Android bridge без реального provisioning

  1. Добавить WizProvisioningManager.kt.
  2. Подключить channel в MainActivity.kt.
  3. Реализовать getProvisioningCapabilities.
  4. Реализовать requestProvisioningPermissions.
  5. Протянуть результат в UI и показать capability gate.

Шаг 3. SoftAP connection layer

  1. Добавить WifiNetworkSpecifier flow.
  2. Сделать поиск/подключение к WiZConfig_.
  3. Вернуть во Flutter structured result.
  4. Обработать cancel/timeout.
  5. Проверить ручным прогоном на тестовой точке доступа.

Шаг 4. Reverse engineering commissioning payload

  1. Снять трафик официального WiZ app.
  2. Описать протокол.
  3. Зафиксировать findings в отдельном notes-файле.
  4. Только после этого писать production WizUdpCommissioningClient.

Шаг 5. Реальный commissioning

  1. Реализовать payload builder.
  2. Реализовать отправку на UDP 18266.
  3. Обработать ack/timeout.
  4. Завести детальные internal error codes.

Шаг 6. End-to-end flow с Ignis

  1. После native success вызвать rescanNetwork().
  2. Дождаться ответа backend.
  3. Показать найденное устройство или отдельную ошибку post-provision discovery.
  4. Протестировать повторяемость.

Шаг 7. Cleanup и hardening

  1. Удалить лишние debug-логи.
  2. Проверить, что пароль Wi-Fi нигде не сохраняется.
  3. Добавить unit/widget tests.
  4. Обновить README.md.

Открытые вопросы

Технические

  • Как именно выглядит payload для UDP 18266?
  • Нужен ли specific target IP на AP лампы или есть broadcast?
  • Есть ли обязательный ack и как он кодируется?
  • Нужен ли bind сокета к Network для всех Android OEM или только для части?
  • Как определить успешность до rescan: по ack или по исчезновению AP?

Продуктовые

  • Где именно располагать entrypoint мастера в UI?
  • Нужен ли в первой версии ручной ввод SSID, или можно сразу только auto-fill + редактирование?
  • Нужен ли отдельный экран выбора provisioning mode, если BLE ещё не реализован?

Операционные

  • Есть ли в наличии лампа старого поколения с WiZConfig_xxxx?
  • Нужны ли апрувы на Android permissions / реальные ручные прогоны / возможную установку вспомогательных инструментов для sniffing?

Что проверять первым делом при возвращении к задаче

Если вернулись к задаче через долгое время, стартовать так:

  1. Перечитать этот документ целиком.
  2. Проверить, не появились ли новые официальные WiZ материалы про local commissioning.
  3. Проверить, не изменились ли Android Wi-Fi/BLE permission требования.
  4. Уточнить, какая именно тестовая лампа есть на руках.
  5. Решить, можно ли сразу идти в reverse engineering или сначала поднимать только bridge/UI skeleton.

Рекомендуемый следующий practically useful шаг

Когда будет время на апрувы и ручные проверки, не начинать сразу с большого рефактора. Самый выгодный порядок:

  1. закоммитить UI skeleton и Android bridge;
  2. проверить Wi-Fi connect к WiZConfig_xxxx;
  3. только потом тратить время на reverse engineering UDP 18266.

Это минимизирует риск закопаться в неизвестный протокол до того, как станет ясно, что platform plumbing вообще работает на конкретном устройстве.

Источники

WiZ

Android

Apple

Связанные локальные файлы

  • ignis_app/lib/main.dart
  • ignis_app/lib/screens/homes_screen.dart
  • ignis_app/lib/screens/remote_screen.dart
  • ignis_app/lib/services/api_client.dart
  • ignis_app/android/app/src/main/AndroidManifest.xml
  • ignis_app/android/app/src/main/kotlin/ru/akokos/ignis_app/MainActivity.kt
  • ignis-core/app/api/routes/devices.py
  • ignis-core/README.md
Reference in New Issue View Git Blame Copy Permalink