KeepAlive и PingReq: почему клиент отваливается

Тепличный узел жил по графику, как студент по расписанию пар: три-четыре минуты данных — пауза — снова данные. Wi-Fi был ни при чём: пинг до роутера не рвал, скорость держал, сигнал палками не мигал. Клиент же в мониторе писал одно и то же: разрыв, reconnect, state=-3 — и так по кругу каждые четыре минуты, с хирургической точностью.

Я успел обвинить роутер, прошивку и саму библиотеку, прежде чем нашёл виновника: за неделю до того я добавил в loop() синхронизацию времени по NTP с ожиданием ответа до двадцати секунд. Блокировка дольше окна keepalive — и брокер закономерно отрезает молчуна. Диагноз занял бы минуту, если бы я с самого начала измерял, сколько длится один проход главного цикла.

В этом уроке вскрываем пульс MQTT: что за пакеты PINGREQ и PINGRESP, кто их шлёт и когда, зачем нужно окно keepalive и как его настраивать через setKeepAlive. Затем — вторая часть головной боли, которую не чинит никакой setKeepAlive: NAT-роутеры, выкидывающие «мёртвые» соединения из своих таблиц. И в финале — диагностический скетч, который сам говорит, стоял ли ваш loop.

TCP-соединение молча лежит, пока по нему не идут данные: сеть не отличает спящего клиента от умершего. Протокол MQTT добавляет свой пульс. В пакете CONNECT клиент объявляет окно keepalive в секундах — обещание, что в течение этого времени он проявит любую активность. Если трафика нет, клиент сам шлёт пустой пакет PINGREQ, брокер отвечает PINGRESP — и обе стороны довольны: связь жива.

Терпение у брокера нормированное: по спецификации он считает клиента мёртвым после полутора окон тишины. При окне в 15 секунд — до 22–23 секунд молчания, при 60 — до полутора минут. Отправку пинга при этом никто не вызывает отдельно: PINGREQ уходит изнутри client.loop(), той самой функции, которая обслуживает соединение. Не зовёте loop — пинга нет — и окно сгорает, даже если скетч выглядит занятым делом. Мы уже наступали на это в уроке про подключение ESP32, где цикл с delay(10000) умирал ровно на пятнадцатой секунде.

Окно задаёт клиент: у PubSubClient по умолчанию 15 секунд, меняется вызовом client.setKeepAlive(секунды) — до connect, раз и навсегда в сессии. Код -3 из таблицы состояний — MQTT_CONNECTION_LOST — это как раз тот случай, когда связь умерла посреди работы, и чаще всего по вине именно окна.

Счётчик gap из скетча — измеритель честности: он показывает самую длинную паузу между проходами loop за последние десять секунд. Пока gap_max меньше половины окна — пинг успевает уйти с запасом. Полсекунды на Serial-печать, секунда на чтение датчика — это нормальные гребни, за которыми окно не сгорает. Мой ориентир при выборе окна: ставь в три-четыре раза больше самой долгой плановой блокировки. Есть тяжёлый HTTP-запрос на 8 секунд — окно 30 секунд; читаете DS18B20 с конверсией 750 мс — хватит и 15. Выше 60–120 секунд окно я не поднимаю никогда: чем оно больше, тем позже брокер объявит клиента мёртвым и тем позже сработает завещание из урока про LWT — до полутора минут вранья online в дашборде.

Тупик, на котором я сидел два вечера: NTP-синхронизация из вступления. Запрос времени висел до двадцати секунд, окно было дефолтным — пятнадцать, и каждые пять минут связь рвалась с воем. Вторая версия той же беды — HTTP GET к медленному серверу: таймауты по 10–15 секунд съедали окно на границе. Лечение в обоих случаях одинаковое по духу: не делать долгих операций в теле loop, а выносить их в задачи планировщика на millis — тем самым цикл между операциями снова короткий, client.loop() дышит, а delay из главного цикла исчезает как класс.

С критерием не путать: пауза между публикациями — нормальная, хоть час. Опасна пауза между проходами loop, то есть между обслуживаниями соединения. Публикация раз в минуту при живом цикле — это пинг каждые 7–8 секунд внутри loop и ноль проблем; цикл, спящий минуту, — это мёртвый клиент, который ещё не знает о своей смерти.

Порядок диагностики у меня такой, после пары ночей по кругу. Первый шаг — client.state() сразу после разрыва: -3 говорит, что клиент увидел смерть соединения, и дальше вопрос только в причине. Второй — журнал брокера: в нём видно, кто закрыл соединение первым и с какой формулировкой; клиента, отсечённого по keepalive, там видно напрямую. Третий — gap_max из скетча: одна цифра, которая за десять секунд доказывает, стоял ли ваш цикл. Только когда все три показания чистые, я позволяю себе грешить на сеть и роутер — до этого подозреваемым номером один остаётся мой же код.

Всё это печатается в журнал платы по правилам из урока про уровни логов: разрыв — уровень error с кодом, отчёт gap_max — info. Пары имя=значение тут не прихоть: числа из журнала подхватываются тем же Serial Plotter, и разрыв видно как провал на графике. Через неделю такого журнала картина читается глазами: ровные ряды gap_max=20010 ms около отвала не оставляют NAT-у и провайдеру ни единого шанса стать подозреваемыми. Диагностика без цифр — это гадание, а гадание на железе дорого стоит.

Разрыв в журнале я печатаю одной строкой с тремя числами: время в секундах от старта, код state и текущий gap_max — например t=527s state=-3 gap=20010 ms. Штамп времени беру из millis()/1000: перезагрузку платы видно по нулевым секундам. Трёх-четырёх строк на разрыв хватает, чтобы через неделю листать журнал как протокол эксперимента, а не как берлогу. Без отметки времени разрывы из разных дней сливаются в кашу, и закономерность — каждые пять минут или раз в сутки — уже не видна.

Батарейным узлам — отдельный абзац. ESP32 в глубоком сне не шлёт пингов, поэтому связь для него — это короткая активная фаза: вышел из сна, подключился, опубликовал показания, забрал команды, попрощался через disconnect, уснул. Окно keepalive тут выбирают больше цикла сна — при сне десять минут ставят 1200 секунд, — иначе брокер объявит спящего мёртвым между пробуждениями, а завещание из урока про LWT выпишет offline прямо в дашборд. Постоянно подключённый клиент и спящий клиент живут по разным правилам — смешивать их в одном скетче не стоит.

И про чужие серверы: правила те же, окно другое. У облачных брокеров встречаются ограничения и снизу, и сверху: AWS IoT, например, ограничивает keepalive сверху 1200 секундами — двадцатью минутами, — и после полутора окон тоже объявляет клиента мёртвым. Свой mosquitto на малине терпеливее, но принцип один и тот же, поэтому навык диагностики переносится один в один: сначала журнал, потом сеть.