subscribe и callback: подписка на команды

Лампа на веранде слушала дашборд исправно — до первой ночи с моргнувшим Wi-Fi. Утром кнопка «включить» нажималась, интерфейс услужливо мигал, а лампа молчала. Показания температуры при этом шли как ни в чём не бывало: публикация работала, разрыв соединения скетч пережил сам. Я перепрошил плату — помогло до следующего разрыва. Так я познакомился с подпиской, которая живёт только до первого reconnect.

Причина была в одной строке не в том месте. Subscribe я вызвал один раз в setup(), и брокер действительно подписал меня. Но у PubSubClient по умолчанию чистая сессия: при новом подключении брокер считает подписки прежней сессии несуществующими. В моём reconnect() соединение восстанавливалось, а подписка — нет: публикация шла, приём умирал. Перенёс subscribe внутрь reconnect(), сразу после успешного connect — и лампа перестала зависеть от погоды на роутере.

В этом уроке — обратный поток данных: как broker кладёт команду в плату, что происходит внутри callback и почему payload там не строка, а байты, которые надо собрать. Разберём разбор сообщений по топику, флаг-паттерн, спасающий от зависаний, и валидацию: сообщения с брокера приходят из внешнего мира, а внешнему миру я верю примерно как незнакомцу с ножницами у моего провода.

Механика такая. client.subscribe(топик) отправляет брокеру запрос SUBSCRIBE, тот подтверждает и запоминает: любой PUBLISH в этот топик — и копия летит вашему клиенту. Библиотека принимает пакет, разбирает его и вызывает вашу функцию-callback с тремя аргументами: имя топика, массив байтов и длина. Регистрируется функция вызовом client.setCallback(callback) в setup — один раз, она живёт до конца работы. Важная развилка: маски из первого урока здесь работают, подписка dacha/pump/# накрывает и dacha/pump/on, и dacha/pump/status одним вызовом.

Топиков у подписки может быть несколько: второй, третий subscribe() просто добавляются рядом. А различать входящие сообщения нужно внутри callback по имени топика — обычным сравнением строк. Один callback обслуживает весь дом: пришло dacha/pump/on — щёлкаем реле, пришло dacha/led/brightness — крутим ШИМ. Строковые сравнения и сборка сообщений — это те же приёмы из уроков про String и Serial: здесь ничего нового, просто источник другой.

Payload — главный сюрприз для новичка. В callback он приходит как массив байтов, а не как строка с нулём на конце: String(topic) — потому что топик нуль-терминирован, а вот сообщение собираем в цикле по length, байт за байтом. Пропустить length и сравнить массив со строкой — классическая ошибка, которая компилируется и работает ровно до первого сообщения с хвостом мусора.

Теперь про то, что callback — это чужая территория. Вашу функцию вызывает client.loop() посреди разбора входящих пакетов. Внутри callback нельзя публиковать через client.publish — библиотека может заблокироваться, ведь она ещё не закончила приём прошлого пакета. Нельзя и тянуть время: delay, длинные циклы, обращение к медленной периферии. Моё правило: callback только фиксирует факт — записывает значение во флаг или переменную, — а вся работа происходит в loop(). Сто миллисекунд работы внутри callback — это сто миллисекунд, когда соединение не обслуживается; при потоке сообщений легко словить каскад.

Флаг-паттерн выглядит скучно и работает безотказно: volatile-переменная, в callback присвоили, в loop проверили и исполнили. Для реле из примера можно и прямо в callback — digitalWrite занимает микросекунды, и я допускаю такое для одиночных быстрых действий. Граница: всё, что дольше пары миллисекунд или вызывает publish — только через флаг. Если в проекте есть планировщик задач на millis, обработка команды становится просто задачей в очереди — и callback вырождается до одной строки.

И вернёмся к подписке из-за которой лампа молчала. Правило звучит так: каждый вызов connect() обнуляет подписки, значит каждый успешный connect завершается блоком subscribe. В reconnect() из прошлого урока это уже встроено — теперь вы знаете, почему там клиент подписывается на dacha/pump/on именно после connect, а не где-то в setup.

Последний столбец таблицы — самое важное. Сообщение с брокера — данные из внешнего мира, с тем же статусом, что ввод с клавиатуры или строка из Serial. Никаких переходов модуля реле от произвольного текста: если ждём 1 или 0, всё остальное игнорируем. toInt() при мусоре вернёт ноль — для яркости это просто выключенный свет, но тот же ноль для насоса может значить «слей воду» — поэтому для исполнительных механизмов я сравниваю payload со строками явно, а не конвертирую наивно.

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

Модель, на которой я отлаживаю весь этот конвейер без железа, — ниже. Монитор порта играет роль брокера — приём сообщений по строке тут работает как в командном парсере из Serial: вы печатаете сообщение вида топик пробел payload, а скетч разбирает его ровно так, как это делает настоящий callback: выделяет топик, выделяет payload, прогоняет через белый список и щёлкает реле. Плюс к тому же видно, как ведёт себя скетч при чужом топике и мусорном payload.