Подключение к Wi-Fi и режим настройки

Устройство получает пароль от сети двумя путями: по проводу из веб-установщика (протокол Improv) и по воздуху из мобильного приложения iDryer для Android и iOS (протокол ESPTouch v2). Дальше пароль лежит в NVS и переживает перезагрузки.

Протоколы несовместимы между версиями: приложение обязано слать именно ESPTouch v2. В первой версии данные передавались длинами кадров, и они ломались, когда роутер ретранслировал broadcast между полосами 2.4 и 5 ГГц — одна mesh-сеть с общим именем срабатывала через раз.

Этим занимается EspTouchProvisioner (platform/arduino/). Продукту вызывать ничего не нужно — Link поднимает и крутит его сам; колбэки нужны только для показа хода настройки на экране.

Разобраться в поведении стоит по одной причине: устройство должно молча возвращать связь, когда это возможно, и звать человека, когда без него не обойтись. Ошибиться легко в обе стороны — либо дёргать хозяина при каждом чихе роутера, либо молча висеть офлайн с неверным паролем.

Четыре фазы

Провижинер живёт только до первого успешного подключения. Link::loop() вызывает его, пока не поднялся Wi-Fi; после первого WL_CONNECTED управление уходит облачному автомату, и режим настройки больше не включается никогда — до следующей перезагрузки.

Фаза 1. Загрузка, пароль в памяти есть

Настойчивый режим, без диагностики.

Каждые kBootRetryMs (6 секунд) — новый заход в сеть. Так продолжается kConnectFallbackMs (90 секунд). Подключились — работаем; не подключились — поднимаем режим настройки.

Почему без диагностики: пароль не новый, когда-то он работал. Незачем выяснять, слабый сигнал или сменили пароль — если за отведённое окно связи нет, зовём человека, и он разберётся на месте.

Почему нужны повторы: WiFi.begin() вызывается один раз, из Link::begin(). Облачный автомат до WL_CONNECTED не работает, а авто-повтор Arduino не покрывает reason 202 и 205. Без повторов попытка ровно одна, и при слабом сигнале устройство уходит в настройку с исправным паролем в памяти.

Почему 90 секунд — считаем от худшего сценария, когда свет дали и всё поднимается одновременно:

• до 60 секунд — загрузка роутера. Отраслевое требование Broadband Forum TR-124 Issue 9, пункт GEN.OPS.9: «The RG MUST complete power up in 60 seconds or less». Оговорка: требование про полную загрузку шлюза, отдельного норматива на появление SSID в нём нет. Измерения на массовом оборудовании дают 34–49 секунд до эфира, так что 60 — разумная верхняя граница, а не среднее;
• плюс наше подключение — обычно 2–5 секунд, но при RSSI около −85 dBm затягивается до двадцати.

Отсюда 90: шестьдесят на роутер и тридцать на себя. Меньше — рискуем позвать человека, когда сеть вот-вот появится; заметно больше — человек слишком долго смотрит на устройство без связи и без объяснений.

Роутер и точка доступа, включённые вместе, грузятся параллельно, а не по очереди — складывать их время не нужно. Если же считать по строгому критерию «клиент получил адрес и вышел в интернет», счёт идёт на 90–120 секунд: там ещё WAN, DHCP или PPPoE и синхронизация модема. Нам этого ждать незачем — устройству достаточно попасть в локальную сеть.

Фаза 2. Загрузка, пароля в памяти нет

Режим настройки включается сразу — ждать нечего.

Фаза 3. Пароль только что получен

Умный режим, driveConnect().

Здесь пароль свежий и может быть неверным — человек мог ошибиться при вводе. Поэтому провижинер различает причины отказа:

• считает отказы авторизации подряд (kAuthFailLimit, 8);
• после пятого смотрит эфир и запоминает лучший RSSI;
• при RSSI хуже kWeakRssi (−80 dBm) сброс отменяется: те же reason 15 и 202 даёт потеря auth-кадров при верном пароле, а подключение может занять минуты. Там срок другой — kWeakSignalGiveUpMs (10 минут);
• при уверенном сигнале и восьми отказах возвращается в режим настройки: иначе из опечатки нет выхода без перепрошивки.

Плюс сторож на полную тишину (kWatchdogMs, 20 секунд): если нет ни событий, ни подключения, стек пинается esp_wifi_disconnect().

Фаза 4. Связь пропала во время работы

Провижинер уже не вызывается. Связь молча восстанавливает облачный автомат, режим настройки не включается — человека не дёргаем. С точки зрения устройства «роутер выключили на ночь» и «сменили роутер» неотличимы, и гадать оно не пытается.

Как сказать устройству, что сеть сменилась

Перезагрузить.

После перезагрузки начинается фаза 1: старый пароль не подходит, 90 секунд впустую, поднимается режим настройки — и можно прислать новый пароль с телефона или воткнуть провод. Никаких эвристик, обычное выключить-включить.

Особенность: из режима настройки сеть сама не подхватится

Пока устройство слушает эфир, оно не пытается подключиться к сохранённой сети: радио занято приёмом, и заходы в сеть прекращаются до тех пор, пока не придёт новый пароль.

Практическое следствие: если роутер поднимался дольше 90 секунд и устройство успело уйти в настройку, само оно в сеть не вернётся, даже когда сеть появится. Нужно либо прислать пароль, либо перезагрузить устройство.

Это свойство режима, а не недосмотр: слушать эфир и одновременно устанавливать соединение нельзя.

Таймауты

Константа	Значение	Что задаёт
kBootRetryMs	6 с	период повторного захода в фазе 1
kConnectFallbackMs	90 с	сколько пробуем, прежде чем звать человека
kReconnectDelayMs	700 мс	пауза после разрыва перед новым заходом (фаза 3)
kWatchdogMs	20 с	тишина в стеке, после которой его пинают
kAuthFailLimit	8	отказов авторизации подряд до возврата в настройку
kWeakRssi	−80 dBm	граница «слабого сигнала»
kWeakSignalGiveUpMs	10 мин	сколько терпим при слабом сигнале, прежде чем сдаться
kRestartMs	10 мин	перезапуск режима настройки, если пароль так и не пришёл

Что видит человек

Вход в режим настройки поднимает колбэк Notice:

• Listening — обычная настройка: сети в памяти нет либо связь уже была;
• CheckPassword — сеть задана, но ни разу не пустила. Единственное оставшееся объяснение — неверный пароль.

Продукт решает сам, как это показать. В idryer-touch это полноэкранное уведомление.