Агрегатор статусов: home/+/state и сводка с устройств в одну строку

В квартире пять узлов, каждый раз в десять секунд пишет своё home/<комната>/state: температура, влажность, состояние двери. Монитор порта агрегатора превращается в поток из тридцати строк в минуту, а ответ на вопрос «что у нас сейчас» требует листать историю глазами. Мой выход из этого потока — отдельная роль: узел-агрегатор, который подписан одним шаблоном home/+/state, держит в памяти последние значения всех узлов и по команде печатает одну строку: kitchen 22.4 | bedroom 19.8 | door closed. Одна строка вместо пяти окон — и внезапно вся картина дома видна целиком.

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

Почему агрегатор — отдельное устройство, а не ещё один экран панели? Панель показывает то, что есть сейчас, и не обязана помнить историю. Агрегатор же держит состояние дома в памяти между сообщениями, умеет замечать тишину и решать, кому гореть светодиодом, а кому печатать old. Такой узел удобно иметь один на квартиру: он один ходит в брокер с широкой подпиской, а остальной софт читает его сводку — или те же статусы напрямую, если решите, что агрегатор нужен только для диагностики.

В сообщении home/kitchen/state агрегатору нужна только середина — kitchen. Классический разбор по слэшам работает, но у String-версии indexOf с начальной позицией на разных ядрах ведёт себя по-разному, поэтому я режу проще: откусываю фикс пять символов home/ через substring(5), в остатке ищу первый слэш — всё до него имя узла, всё после обязано быть /state. Хвост проверяю жёстко: home/kitchen/temp в агрегатор не попадёт, хотя подписка home/+/state его бы и не принесла, — двойная проверка бесплатна и спасает при смене шаблона подписки в будущем.

Слоты храню параллельными массивами: имена узлов, последние значения, millis последнего приёма и флаг «видели ли узел вообще». Так на Uno живёт до десятка узлов без динамической памяти: десять имён по двенадцать символов, десяток float и long — десятки байт, никакой кучи. Новое имя занимает первый свободный слот, поиск по кругу. Это то же хранилище последнего значения, что у брокера с retain, только живёт оно у вас в RAM: почему retain выручает панель после рестарта, показано в уроке про retained-статус.

Цифры по памяти для спокойствия: четыре узла — это четыре String по десятку символов, четыре float и четыре отметки времени. Итого меньше ста байтов со служебными полями. Десяток узлов на Uno тоже уместится, а дальше начинается плата за удобство: каждая строка в String тянет аллокацию, и на двух килобайтах кучи частые переименования узлов бьют больно. Если узлы фиксированы и известны заранее, имена можно вынести в массив const char* — тогда память расходуется ровно по числу символов, и фрагментации нет.

Последнее значение без метки времени врёт так же уверенно, как его отсутствие: узел мог умереть час назад, а в слоте лежит его свежий на тот момент 22.4. Поэтому вместе со значением храню seen — millis приёма, и всё, что старше девяноста секунд, печатаю с пометкой old. Порог привязан к периоду публикации узлов: при отправке раз в десять секунд три пропуска подряд — уже подозрение, а 90 секунд дают запас на два-три сбоя Wi-Fi. Сами таймеры публикации и разницу между delay и millis-планировщиком я разбирал в уроке про millis вместо delay — здесь она же, только потребитель другая.

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

Три способа печати в скетче выше живут одновременно, и это не избыточность. Сводка на каждое сообщение удобна при отладке и раздражает в бою: пять узлов умножить на десять секунд — тридцать строк в минуту. Таймер на тридцать секунд — фон для занятого человека. Запрос командой sum в служебный топик — моментальный снимок, когда хочется взглянуть прямо сейчас; для этого агрегатору нужна ещё подписка на home/agr/cmd и ветка в диспетчере из первого урока про маршрутизацию. Мой боевой выбор: таймер плюс запрос, печать на каждое сообщение выключаю через флаг. И светодиод D12 в скетче не украшение: он горит, пока все известные узлы присылают свежие значения, — индикатор дома целиком на одном пине.

Что происходит с хранилищем после рестарта агрегатора? Оно пустое: все слоты сброшены, сводка печатает прочерки, пока узлы не пришлют по новому сообщению — при периоде в десять секунд картина собирается за те же десять секунд, но при редких статусах (дверь рапортует только при событии) прочерчивание затянется. Лекарство уже есть в экосистеме: пусть узлы публикуют статусы с retain, тогда брокер отдаст агрегатору все последние значения в первую секунду после подписки — ещё до вашего первого client.loop(). Требование к соседям одно: статус — это обязательно retain-публикация, иначе агрегатор после каждого рестарта слепнет. Заодно держите в голове, что агрегатор — обычный подписчик: он врёт ровно так, как врут его источники, и лечится это меткой времени в payload, как в уроке про публикацию по millis.

Агрегатор сам по себе тоже узел со статусом, и о его здоровье надо сообщать. Я публикую с него раз в минуту два числа: сколько узлов известно и все ли свежие — в топик home/agr/state. Панель, подписанная на этот топик, видит, что сводка вообще живёт: без пульса мёртвый агрегатор выглядит как экран с честными, но навсегда застывшими числами. При переподключении не забывайте восстанавливать подписку home/+/state — брокер не хранит её для нового подключения, а паузы между попытками у меня на millis с растущим интервалом, как в уроке про reconnect.

И сводка — не единственный выход. Ту же структуру слотов удобно кормить в Serial для отладки, на LCD для стены и в отдельный JSON-топик для панели, если она хочет парсить. Хранилище одно, представления три — случай, когда разбор и печать разделены правильно: slotOf() и массивы ничего не знают о том, кто и куда их напечатает.