reconnect без блокировки: цикл с millis

На дачном щитке жили вместе счётчик воды с импульсным выходом и датчик протечки с реле на кран. Связь с брокером держал скетч из урока про публикацию с ESP32 — с честным блокирующим reconnect(): while, внутри connect, между попытками delay(3000). Пока сеть была ровной, он меня устраивал. Ночью повис роутер, и к утру в журнале протечки обнаружились дырки: плате было не до кнопки — она сидела в reconnect, а сирена, слава богу, молчала не потому, что воды не было, а потому что скетч до неё в тот час просто не доходил.

Виновата не пауза, а связка. client.connect() к недоступному брокеру блокирует loop до того, как закроется TCP-попытка: на практике это секунды, у меня выходило от пяти до пятнадцати на круг. Плюс три секунды delay — и так по кольцу. Счётчик воды даёт импульс на литр, открытый кран льёт до двенадцати литров в минуту — импульс каждые пять секунд; один круг блокирующего reconnect пропускал два-три импульса, а ночь таких кругов — ведро воды мимо учёта. И вторая половина боли была не в счётчике: журнал протечки строится по моментам событий, а события, которые плата не успела опросить, в нём не появляются вовсе — это не опоздание, а дыра.

Лечение — перевести восстановление связи в фоновую задачу: две переменные состояния, millis-таймер попытки и backoff. Скетч вырос на десяток строк — датчики, кнопки и индикация при этом живут без остановки. Именно им reconnect без блокировки нужнее всего: сеть рано или поздно вернётся сама, а пропущенные импульсы и неопрошенная кнопка не вернутся никогда.

Сначала честность ради: блокирующий reconnect не порочен. Если в loop нет ничего срочного, while с паузой — простейшее рабочее решение, и я ставлю его во все узлы без исполнительных механизмов. Менять его стоит, когда в плате живёт что-то, что не может ждать: сирена, счётчик импульсов, мигалка статуса, опрос кнопки из кооперативного цикла.

Идея перевода на millis та же, что в уроке про millis вместо delay: вместо паузы — отметка времени и проверка. Появляется переменная состояния online и метка следующей попытки nextTry; loop каждый оборот решает, пора ли пытаться, а между попытками остаётся свободным целиком. Попытка раз в пять-десять секунд — компромисс, к которому я пришёл на своих узлах: чаще долбить незачем, реже — заметно запаздывание команд.

Стоит увидеть это в коде глазами: условие if (!online && now >= nextTry) срабатывает один раз за период — одну итерацию loop, — остальное время идут датчики и индикация. Внутри ветки — один вызов connect и разбор его результата; висячего while больше нет. client.loop() и публикация при этом живут под if (online): обслуживать мёртвое соединение бессмысленно, а датчики от этого условия не зависят — они вне сети.

Попытка — это один вызов connect, а не цикл: не подключился — вышли из ветки и вернулись в loop, датчики доработали до следующей метки. Именно здесь теряется главная боль: каждая попытка стоит в расписании, как публикация по таймеру, только с переменной паузой.

Backoff — удвоение паузы с потолком — нужен не плате, а брокеру. Представьте ночь, когда малина перезагрузилась: сотни клиентов, у каждого waitMs 5000, ломанутся reconnect почти одновременно — брокер, едва поднявшись, получит шторм подключений и может лечь второй раз. Пауза, растущая от пяти секунд до тридцати, растаскивает попытки по времени; у моих узлов потолок тридцать секунд, у батарейных — минута. Есть и обратная сторона медали: после рестарта брокера карточки в доме висят офлайн до первой успешной попытки, и чем короче стартовая пауза, тем быстрее дашборд оживает — отсюда и форма 5, 10, 20, 30, а не сразу тридцать.

Каждую попытку я пишу в журнал с уровнями: попытка — info, успех — отдельной строкой, а полчаса одних attempt подряд видны в логе с первого взгляда — это признак мёртвого брокера, а не короткого флапа Wi-Fi. Успех сбрасывает waitMs на стартовые пять секунд: следующая беда снова начнётся с быстрой реакции, а не с тридцатисекундного ожидания. И сразу после connect — subscribe: при чистой сессии брокер забыл старые подписки, мы разбирали это в уроке про callback; в этой машине подписка стоит ровно в одном месте — в ветке успеха.

Диагностика здесь та же, что в уроке про статусы подключения: после неудачной попытки печатаю state и код в журнал — минус два направит в конфиг брокера, четвёрка напомнит про пароль. И не путайте этажи: Wi-Fi со своим автореконнектом — отдельная история из урока про статус сети; пока WL_CONNECTED нет, попытки connect бессмысленны, и взрослый скетч ставит их за проверкой сети.

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

Сирена протечки — верхняя строка таблицы и мой главный аргумент за всю эту переделку: реакция на воду не должна зависеть от роутера. Реле и зуммер подключены к датчику напрямую, опрос сирены стоит в каждом обороте loop — её реакции не нужны ни брокер, ни Wi-Fi, ни человек за дашбордом; MQTT только докладывает о происшествии, с лагом в секунды. Если бы кран закрывался по команде из брокера, ночь с повисшим роутером стоила бы мне ремонта пола. Локальная логика — локально, сеть — для уведомлений и команд, потерю которых пережить можно.

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