LWT: Last Will и статус офлайн устройства

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

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

Лекарство встроено в протокол и называется Last Will — завещание. Клиент при подключении оставляет брокеру сообщение про запас: если я исчезну некрасиво, опубликуй это за меня. В этом уроке заводим пару статусов online/offline на отдельном топике, разбираем, когда завещание срабатывает, а когда его отменяют, и почему без retained-флага вся конструкция разваливается на первом же перезапуске дашборда.

Механика прячется в пакет CONNECT — тот самый, которым клиент представляется брокеру. Кроме имени клиента в нём можно указать четыре поля завещания: топик, payload, QoS и retain-флаг. Брокер складывает их в память сессии и терпеливо ждёт. Публикация произойдёт, если соединение рухнуло без DISCONNECT — выдернули питание, завис роутер, клиент утонул в бесконечном цикле. А если клиент ушёл красиво, сам вызвал disconnect, — брокер завещание молча уничтожает: уход штатный, помощь не нужна.

Второй нюанс — терпение. Брокер не публикует завещание в ту же секунду, как пропал клиент: спецификация даёт полтора окна keepalive на всякий случай, вдруг клиент опоздал, но жив. При окне в 15 секунд это до 22–23 секунд тишины, при окне 60 секунд — до полутора минут. Отсчёт идёт с последнего любого пакета: телеметрия тоже продлевает жизнь сессии, поэтому активный датчик может вообще не пинговать. Откуда берётся окно и что происходит внутри, разбирается в уроке про keepalive и PingReq — там же о том, почему раздувать окно значит откладывать статус offline.

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

Разбор — по аргументам connect, потому что каждый выбирался не сразу. Пятый аргумент, payload offline, — это и есть завещание. QoS 1 у него, чтобы сообщение доехало хотя бы раз даже по дрожащей сети: статус устройства слишком важен, чтобы терять его на последнем хмеле, поэтому нулевой QoS для завещания я не ставлю никогда. Retain true — вторая половина магии: брокер запомнит offline и отдаст его каждому новому подписчику мгновенно.

Retain-флаг обязан стоять у обеих половинок пары. После каждого успешного connect скетч сам публикует online с retain — и перезапустившийся дашборд или Home Assistant, перечитавший конфиг, получает статус сразу после подписки, не дожидаясь событий. Ровно тот же флаг -r у mosquitto_pub мы трогали, когда ставили брокер в уроке про Mosquitto. Арифметика для сравнения: два retained-сообщения в сутки против рассылки статуса раз в 30 секунд — это 2880 сообщений и постоянный шум в логе, а результат тот же.

Отсюда правило пары, короткое: online всегда руками после connect, offline всегда завещанием, и никто не пишет в статус-топик в промежутке. Как только появляется третий автор — например, watchdog решил честно сообщить offline перед рестартом, — пары рассыпаются: retained-кэш начинает помнить то, чего нет. Одно значение на публикацию, зашитое в топик, — то же правило, что и для телеметрии из урока про публикацию показаний, просто применённое к статусу.

Парности ради — почему статус в отдельном топике, а не флагом внутри телеметрии. Подписчики разные: графику нужен поток показаний, а логике доступности — один бит живости. Смешивать их значит заставлять каждый инструмент резать строки, а заодно лишать завещание места: will публикует один payload в один топик, а не правит кусок JSON. Слова online и offline вместо 1/0 — тоже договор: их читают люди в логах, и Home Assistant из коробки понимает их в поле payload_available.

Тупик, который я распутывал дольше, чем стоил бы сам LWT: статус мигал online/offline каждые несколько секунд без видимой причины. Wi-Fi был ровный, брокер живой, а в логе шли пары connect/disconnect с одним именем — две платы с одинаковым clientId воевали за паспорт, как в уроке про clientId и статусы подключения. Брокер отрезал старое соединение, у старого срабатывало завещание, новая плата публиковала online — и по кругу. Диагноз тот же: чинить паспорт устройства, а не лезть в логику статуса.

И последняя деталь, о которой забывают: завещание живёт до следующего connect. Если в setup() вы подключаетесь с will, а в reconnect() — обычным connect без него, после первого же переподключения устройство молча осталось без завещания, и ничего не подскажет об этом. Выносите подключение в одну функцию вроде connectWithWill() из скетча выше и зовите её отовсюду — я держу такое правило с тех пор, как нашёл у себя эти два разных connect.

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

Завещание у соединения одно. На плате может жить хоть пять логических сенсоров — статус всё равно общий, на уровне платы: will описывается в CONNECT одним топиком и одним payload. Нужна индивидуальность — заводите отдельных клиентов на сущность, но чаще это лишнее: дашборду достаточно знать, что узел жив. MQTT пятой версии добавил свойство will delay interval — брокер выжидает заданные секунды перед публикацией завещания, и краткое моргание связи перестаёт врать статусом; mosquitto второй версии протокол 5.0 умеет, но мои скетчи на PubSubClient по-прежнему живут на 3.1.1 — просто знайте, что там дальше есть.

И про цену вопроса: статус — самый дешёвый трафик в доме и самый ценный. Пара сообщений в сутки весом в десятки байтов, а решает главное — отличает сломанный прибор от работающего. После истории с лужей под раковиной я вешаю availability на каждое своё устройство, от насоса до почвенного датчика, и проверка дома сводится к одной карточке: кто в сети, кто молчит. Дешевле страховки в протоколе не нашёл.