Восстановление настройки Wi-Fi через AP и приёмочные испытания
Сценарий настройки Wi-Fi готов к продуктовой поставке, когда пользователь восстанавливается после неверных реквизитов, отсутствия маршрутизатора, прерванной настройки и отключения питания без перепрошивки. Проектируйте настройку как ограниченный по времени автомат состояний с видимым результатом, защитой реквизитов и предусмотренным возвратом к настройке. Успешная HTTP-отправка устройству — лишь один этап.
Статья рассматривает точку доступа устройства для настройки с последующим подключением к маршрутизатору заказчика. Подход применим к Linux и MCU; API зависят от драйвера и SDK. Все временные значения и проверки являются предлагаемыми проектными условиями, а не измеренными характеристиками.
Определите успех до разработки экрана
Разделите четыре этапа: телефон передал кандидатную конфигурацию; устройство прошло ассоциацию и аутентификацию; получило пригодную IP-конфигурацию; достигло требуемого прикладного сервиса. Для локального контроллера последним условием может быть обнаружение в LAN. Для облачного продукта — аутентифицированная регистрация или проверочный обмен. Зафиксируйте, какой этап разрешает окончательно сохранить настройки.
Отказ облака не доказывает неверный пароль Wi-Fi. Если Wi-Fi и DHCP работают, но сервер недоступен, сохраняйте отдельное состояние «сеть настроена, сервис недоступен». Допустимость завершения установки в этом состоянии определяет политика продукта; не заставляйте пользователя снова и снова вводить пароль.
Укажите диапазоны маршрутизатора, режимы защиты, кодировку и длину SSID, работу со скрытыми сетями и требования корпоративных сетей. Повторы не позволят модулю только 2,4 ГГц подключиться к сети только 5 ГГц. WPA-Enterprise, внешние captive portal и управляемые корпоративные сети требуют явно заявленной поддержки либо исключения.
Сделайте изменение настроек транзакционным
Храните последнюю проверенную конфигурацию отдельно от испытываемой кандидатной. Каждая попытка получает ID. Повторная передача того же ID должна возвращать состояние той же попытки, а не запускать параллельные подключения. Новая попытка должна контролируемо отменять или заменять прежнюю.
Если платформа позволяет, проверяйте новые реквизиты без немедленной замены сохранённой рабочей конфигурации. После согласованного успеха атомарно фиксируйте запись с версией. Храните данные контроля целостности и версию схемы, определите загрузку при отключении питания во время фиксации. Шифрование хранимых данных требует подходящего хранения ключей и не заменяет аутентифицированную настройку.
Некоторые менеджеры SDK сохраняют реквизиты до окончания собственной проверки приложения. Например, ESP-IDF 5.2.6 описывает проверку сохранённых данных и поведение при отказе/перезапуске в руководстве по настройке Wi-Fi. Это ограничение интеграции конкретной версии. Проверьте API сброса и повторной настройки выбранного менеджера и постройте вокруг них модель продукта; наличие реквизитов не равно успешной установке.
Сохраните намеренный вход в восстановление
Определите, что снова открывает настройку: аутентифицированная команда, последовательность физической кнопки или инструмент монтажника. Укажите длительность удержания, индикацию LED и последствия случайного короткого нажатия. Сетевой сброс обычно должен сохранять калибровку, идентичность устройства и независимые параметры приложения. Заводской сброс — отдельное действие с ясной индикацией.
Пример политики: десятиминутное окно настройки, настраиваемый предел одной попытки подключения, затем повтор или восстановление прежних параметров. Числа следует выбирать по поддерживаемым маршрутизаторам и процессу установки. Не оставляйте неограниченную сеть настройки открытой постоянно только из-за первой неудачи.
При автоматическом завершении телефон должен однозначно узнать результат. Возможны опрос статуса пока устройство доступно, подтверждение успеха перед переключением, LED или повторное обнаружение в целевой сети. Сам разрыв TCP не отличает успех от сбоя.
Учитывайте потерю связи с телефоном
Телефоны могут предпочитать мобильный Интернет, покидать Wi-Fi без Интернета или показывать ограниченный браузер captive portal. Проверяйте поддерживаемые Android/iOS с мобильными данными и без них. Предоставьте документированный локальный URL или приложение, работающее без автоматического обнаружения портала. Страница, необходимая офлайн, не должна зависеть от интернет-скриптов и шрифтов.
Совместная работа AP и STA ограничена конкретным радио. Для ESP32 документация указывает общий рабочий канал с приоритетом станции; подключение к маршрутизатору на другом канале может затронуть настройку. Сверьтесь с руководством Wi-Fi-драйвера, затем проверьте реальные версии SDK и модуля. Чипсетам Linux также нужны поддерживаемые драйвером комбинации интерфейсов; отдельные демонстрации AP и STA не подтверждают их одновременную работу.
Сделайте статусный endpoint устойчивым к переподключениям. Храните последний результат независимо от HTTP-соединения и возвращайте ID попытки, этап и безопасный код причины. Старая вкладка браузера не должна перезаписывать более новую успешную попытку.
Защитите передачу реквизитов и диагностику
Используйте индивидуальный секрет ввода устройства в эксплуатацию или другой подходящий аутентифицированный механизм. Открытый AP и неаутентифицированная форма пароля раскрывают чувствительный путь настройки. Совместно оценивайте защиту транспорта и проверку идентичности устройства; случайный самоподписанный сертификат без схемы доверия и обнаружения может лишь приучить монтажников игнорировать предупреждения.
Не копируйте примеры журналирования, печатающие пароль Wi-Fi. Записывайте этап, прошедшее время, причину отключения SDK, число повторов, версию прошивки и обезличенный сетевой идентификатор. Ограничьте экспорт диагностики и удаляйте временные кандидатные реквизиты после использования. Ограничьте попытки и одновременные сеансы, определите право управления при настройке двумя телефонами.
Разным причинам соответствуют разные действия. Отказ аутентификации требует проверки реквизитов или режима защиты. Отсутствие AP — диапазона, расстояния, скрытого SSID или политики поиска. Тайм-аут DHCP указывает на службу адресации или LAN. Ошибки TLS и регистрации относятся к приложению и могут затрагивать часы, сертификаты или правила учётной записи.
Докажите восстановление приёмочной матрицей
| Проверка | Ожидаемое восстановление | Сохраняемые доказательства |
|---|---|---|
| Неверный, затем исправленный пароль | Новая попытка без перепрошивки и удаления идентичности | ID попыток, причина и итоговое состояние |
| Маршрутизатор исчезает при подключении | Ограниченный тайм-аут; восстановимы старые рабочие настройки или вход настройки | Хронология этапов и счётчики повторов/ресурсов |
| Ассоциация успешна, DHCP заблокирован | Ошибка адреса отдельно от аутентификации | Wi-Fi-события и захват DHCP |
| Сеть работает, облачный сервис недоступен | Определён отказ сервиса; рабочие параметры Wi-Fi сохранены по политике | Статусы IP, DNS и приложения без секретов |
| Питание отключается при приёме, проверке и фиксации | Загрузка со старой/новой действительной конфигурацией либо в предусмотренное восстановление | Журнал загрузки, версия записи, контроль целостности |
| Телефон покидает AP, подключается второй | Право управления попыткой сохранено; последний результат доступен | Клиентский статус и конкурентные запросы |
| Истечение окна и физический сетевой сброс | Закрытие в срок; разрешённое повторное открытие без потери калибровки | Радиосканирование, кнопка/LED и сравнение настроек |
Повторяйте отказы вокруг переходов состояний, а не только в произвольные моменты. Включите смену канала, слабый сигнал и одновременную радио-/прикладную нагрузку. Считайте успешные восстановления относительно всех попыток, фиксируйте каждый отказ и время до работоспособного состояния. Одного среднего недостаточно: немногие бесконечно зависшие попытки могут определять стоимость поддержки.
Предоставьте компактный диагностический контракт
Следующий документ статуса — пример прикладного контракта, а не API SDK. Словарь этапов и причин следует версионировать вместе с мобильным приложением:
{
"schema": 1,
"attempt_id": "setup-0042",
"phase": "waiting_for_ip",
"result": "pending",
"elapsed_ms": 12400,
"reason": null,
"can_retry": false
}Используйте монотонное время для сроков, чтобы коррекция часов неожиданно не продлевала и не сокращала повтор. Watchdog должен обнаруживать застрявший обработчик, но не перезагружать исправное устройство лишь из-за отсутствия внешнего маршрутизатора. Отслеживайте память и сокеты при многократных неудачах, выявляя утечки, невидимые при однократной демонстрации.
Согласуйте полный комплект ввода в эксплуатацию
Услуга подключения устройств Obeita помогает определить интеграцию устройства, телефона и маршрутизатора. Завершённый проект шлюза ESP32 Wi-Fi и Bluetooth описывает работы AP/STA; отдельная роль Mesh не доказывает, что этот сценарий уже реализован или квалифицирован.
Предоставьте версии модуля и SDK, список телефонов, поддерживаемые маршрутизаторы и защиту, текущие журналы отказов и требуемый путь монтажника. Поставка должна включать определения состояний, видимые ошибки, обращение с реквизитами, семантику сброса и воспроизводимые испытания отказов наряду с экраном успешной настройки.
