Подключение ESP32 к брокеру: ID клиента и статусы

Час ночи, на улице минус восемь, а я сижу с ноутбуком на веранде дачи и смотрю в монитор порта: esp32 в теплице пишет одну и ту же строку — connect failed, rc=-2. История началась невинно: я перенёс брокер со старого ноутбука на Raspberry Pi, подвинул шкаф — и всё. Wi-Fi в теплице подключался, пинг до роутера шёл, а брокер молчал, как будто его там не было.

Три часа я потратил впустую, потому что библиотека не говорит, почему не вышло: rc=-2 — и всё, разбирайся сам. Разобрался к двум часам: при переносе я поставил на Pi свежий mosquitto второй версии, а он по умолчанию слушает только localhost — извне на порт 1883 не постучишься. TCP-соединение не открылось, и PubSubClient честно вернул код -2: соединение не состоялось ещё до всякого MQTT. Одна строка в конфиге брокера решила то, на что я потратил вечер.

После той ночи я завел правило: любой скетч с MQTT печатает код состояния при каждой неудаче, а не просто «не вышло». В этом уроке разберём все коды от -4 до 5 — каждый оказывается диагнозом с конкретным подозреваемым. И вторая половина урока — clientId: по моим шрамам, половина загадочных проблем подключения это не сеть, а паспорта устройств: два одинаковых имени, пробел внутри, превышенная длина.

Как это читать на практике. client.connect() возвращает только да или нет, а подробности лежат в client.state() — он возвращает последний код из таблицы. Разница между -2 и -1 — это разница между «в дверь даже не постучали» и «постучали и не дождались»: минус два означает, что TCP-рукопожатие не состоялось, то есть проблема до брокера — адрес, порт, сеть, сам сервер выключен. Минус один — соединение открыли, а брокер не ответил за отведённое окно: сервер жив, но перегружен или это вообще не MQTT-порт.

Положительные коды 1–5 приходят уже от самого брокера: он получил запрос и отказал по делу. Это меняет направление поиска: с кодом 2 я лезу проверять имя клиента, с кодом 4 — пароль, с кодом 3 — логи сервера. Я не зазубривал таблицу: за месяц отладки она сама оседает в голове, потому что каждый код вы ловите руками. А пока — держите распечатку рядом, это рабочий инструмент.

Коды -3 и -4 заслуживают отдельного слова, потому что их путают между собой. Оба значат «связь пропала», но -3 вы получаете, когда соединение было и разорвалось в процессе — классика длинных пауз, когда client.loop() не успевает слать пинг и брокер отсекает молчуна по keepalive. Об этом окне в 15 секунд мы подробно говорили в уроке про публикацию с ESP32, там же — про reconnect-логику, без которой коды -3 и -4 превращаются из диагноза в приговор.

Одна тонкость в работе с state(): код живёт до следующей попытки подключения. Вызвали connect второй раз — state() уже показывает результат новой попытки, старый пропал. Поэтому расшифровку я печатаю сразу после неудачи, в том же вызове, а не где-то потом в loop: потом уже поздно. Именно так устроена tryConnect() выше: одна попытка — один диагноз.

Второй приём, который экономит вечера: код состояния — это строки в моём журнале уровней. Ошибка подключения — это уровень error с числом, попытка — info. Когда через неделю смотришь лог и видишь подряд десять строк state=-2, а потом state=0, картина читается без бутылочного анализа: брокер был недоступен, потом ожил. Без кодов это было бы просто «какое-то время не работало».

И не путайте коды состояния с тем, что печатает сам Wi-Fi: проверка WiFi.status() и ожидание WL_CONNECTED — отдельный этаж, и пока он не зелёный, любые коды MQTT бессмысленны, а автореконнект сети разбирали в отдельном уроке. Порядок «сначала сеть, потом брокер» мы проходили в уроке про WiFi.begin и подключение к роутеру — там же про ожидание с точками вместо немого зависания.

Имя клиента — это не подпись в дашборде, а технический идентификатор, по которому брокер различает абонентов. Правил немного, но каждое из них я нарушал лично. Первое: имя должно быть уникальным среди всех клиентов брокера — то же правило из первого урока про устройство протокола, и в паре с ним работает второе: имя живёт в логах сервера, поэтому в нём должно угадываться место и роль. Мой формат — место-роль-номер: dacha-pump-1, home-balcony-thermo. Через полгода лог читается как журнал.

Третье правило — алфавит. Буквы, цифры, дефис — безопасно; пробел внутри имени я ставил один раз и получил отказ с кодом 2: брокер обрезал имя по пробелу и счёл его некорректным. Четвёртое — длина: старые брокеры на MQTT 3.1 держат лимит в 23 символа, современные уже не зажаты, но я всё равно режу имена до двадцати — привычка дешевле проверки совместимости. И пятое, о котором забывают: если имя генерируется из чипа — например, суффикс из последних байтов MAC-адреса — убедитесь, что оно стабильно между перезагрузками, иначе в брокере накопится зоопарк мёртвых клиентов.

У connect() есть и второй, необязательный аргумент — флаг чистой сессии. Пока скажу только, что он решает, помнит ли брокер подписки вашего клиента после разрыва; по умолчанию PubSubClient просит чистую сессию, и это станет главной ловушкой урока про subscribe и callback — там и вернёмся к нему с пруфом в виде неработающей лампы.

А теперь тупик, который я распутывал два дня. Собрал второй термометр, скопировал скетч — само собой, вместе с connect(esp32-balcony). Обе платы работали... по очереди. Каждые пару минут то одна, то другая отваливались и переподключались, графики рвались, а на беглый взгляд всё было исправно: соединение же есть! Диагноз нашёлся в логах брокера: пары connect и disconnect с одним именем шли с интервалом в секунды. Брокер честно считал их одним абонентом: новое подключение рвёт старое, и так по кругу. С тех пор clientId у меня параметр скетча, а не копипаста, а перед запуском нового устройства я поднимаю mosquitto_sub на всё и смотрю, кто как представился.