Свет из брокера: цикл команда → действие → статус

Гаражный свет я перевёл на MQTT в первую зиму: реле-модуль, ESP32, кнопка в приложении. Полгода всё было прекрасно — до вечера, когда кнопка показывала «включено», а в гараже было темно. Причин у такого фокуса три, и все честные: команда не дошла, потому что Wi-Fi моргнул в момент отправки; дошла, но плата не успела применить; дошла и щёлкнула — а перегорела лампа. Без ответного статуса все три выглядят одинаково: кнопка врёт, и вы гадаете, стоя в гараже с фонариком. Фонарик в руке — честный индикатор того, что система не договаривает.

Классический скетч из первых уроков MQTT делает одну половину работы: дёргает пин по команде. О своём состоянии он молчит. Между тем в промышленных реле-модулях, тех же Wiren Board, устройство после каждого переключения само публикует фактическое состояние в топик канала — дашборд читает факт, а не заявку. Этот цикл «команда → действие → статус» собирается своими руками за полчаса, и после него кнопка в приложении перестаёт быть гадалкой — пара строк статуса разделяет кнопку и пульт с обратной связью.

Строим полный цикл: словарь значений в callback, щелчок реле из loop, статус в ответный топик с retain — и прогоняем его по краям: потерянная команда, повторная команда, статус без изменения. Половина шагов уже готова: callback мы писали в отдельном уроке, publish по таймеру — тоже; нового здесь словарь, pending-паттерн и статус с retain, примерно двадцать строк.

Payload с брокера — байты из внешнего мира, и доверять им слепо нельзя, мы это проходили в уроке про subscribe и callback. Здесь правило превращается в словарь: on и off, плюс цифровые 1 и 0 для ручных публикаций из консоли; всё остальное игнорируется молча и по делу. Никакой инверсии «получил что угодно — щёлкни наоборот»: при QoS 1 брокер гарантирует минимум одну доставку, дубликат — норма, и инверсия на дубле мигнёт светом в прямом эфире; тему дубликатов разбирали в уроке про уровни QoS. Цифровой ряд — не альтернатива словарю, а второй его ряд: панель шлёт слова, человек из терминала — единицы, скетч понимает оба.

Вторая стадия — разделение труда между callback и loop. Callback только записывает цель в переменную pending: он вызывается из недр client.loop(), и publish оттуда — известная ловушка с петлёй разрывов, на которой я обжёгся в уроке про свет из Home Assistant. Действие и статус делаются в loop, после client.loop(): реле щёлкает, статус уезжает — и всё это при живом соединении. Бонус разделения — очередь: три нажатия подряд обрабатываются по одному за оборот loop, без шторма публикаций.

Отдельный статус-топик — не эстетика, а защита от эха. Если публиковать факт в общий топик, на который плата подписана широкой маской garage/#, она получит собственный отчёт как команду: on в словаре есть, pending встанет, сравнение с reported промолчит — беды нет, но в каждом новом скетче придётся держать эту петлю в голове. Раздельные имена cmd и status дешевле, чем час с mosquitto_sub в поисках того, кто говорит сам с собой.

Число с условием: между командой и щелчком реле проходит максимум один оборот loop — на ESP32 доли миллисекунды, на Uno пара миллисекунд. Человек такой лаг не видит, а брокер узнаёт правду раньше, чем вы поднимаете глаза на лампу.

Статус — не эхо команды, а факт: скетч публикует то, что стало с пином, после того как стало. Публикация стоит за сравнением с переменной reported: вторая та же команда не рождает второй публикации — изменение и есть событие, а тишина тоже информация. Ответный топик — сосед команды: garage/light/cmd для приказов, garage/light/status для фактов; через год по именам видно, где ездят приказы, а где отчёты. Имена я держу константами рядом в начале скетча: подписка панели и publish платы должны совпасть до байта, а переименование — дело одной строки.

retain на статусе — вторая половина смекалки: новый дашборд или перезапущенная панель подписывается и мгновенно получает последнее фактическое состояние, не дожидаясь следующего переключения; механику разбирали в уроке про retained-сообщения. Со статусом в паре работает last will: status говорит «какой я», а завещание от брокера — «меня больше нет», мы настраивали его в уроке про LWT. Вместе они закрывают обе стороны правды, и граница между ними простая: retained-статус отвечает на вопрос «что сейчас», завещание — на «жив ли отвечающий».

Про железо одно число с условием: большинство реле-модулей с оптроном щёлкают от LOW — «включено» означает ноль на пине, и светодиод на плате модуля горит тоже при LOW. В скетче это константа RELAY_ON = LOW, чтобы смысл не потерялся в инверсиях; перепутаете — свет будет включаться наоборот, и статус при этом честно врёт вместе с вами. Про 220 вольт, клеммы и предохранитель — отдельный разговор из основ.

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

В симуляторе цикл виден целиком, с одной подменой, о которой честно скажет подсказка: движок не умеет входящих сообщений MQTT, поэтому роль брокера играет строка в мониторе. На реальной плате те же строки прилетят в callback — остальной код не изменится ни на символ.

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