Конфиг на лету: вложенные настройки без перепрошивки

Порог сработки термостата пришлось менять третий раз за месяц, а плата висела под потолком цеха. Ритуал каждый раз один и тот же: ноутбук, кабель, сборка, прошивка, лестница — полчаса ради одной цифры. Пока настройки зашиты в код, перепрошивка — единственный способ их поменять. Вытащите настройки в документ, который прилетает одной строкой по уже открытому каналу, — и ритуал сжимается до ввода {"heat":{"thr":22}}: плата применит новый порог на следующем проходе loop, без перезагрузки и без поездки.

Канал приёма строк я собирал в уроке про JSON-команды из монитора — там available, readStringUntil и диспетчер по ключу cmd. Загрузка конфига при старте с вычиткой из EEPROM и заводскими дефолтами — в уроке про конфиг из строки: там плата только просыпается, и конфликтов с работающим железом нет. Новое здесь — два: настройки едут вложенными группами и применяются по ходу работы, когда loop уже крутится и датчики опрашиваются.

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

Один порог живёт в конфиге без групп. Второй прибор на той же плате — и в документе встречаются два thr: порог нагрева и порог вентилятора. Плоские имена расползаются в heat_thr и fan_thr, документ перестаёт читаться глазами, а код обрастает сравнениями префиксов. Вложенная группа решает это структурой: {"heat":{"thr":22,"hyst":1},"fan":{"thr":30}} — у каждой настройки свой этаж, имена внутри короткие, и принимающий код ходит по своей группе, не глядя на соседнюю. Вторая выгода проявится позже: группу целиком можно печатать в ответе, применять целиком и сохранять целиком — группа как единица живёт во всех трёх конвейерах одинаково. Как выглядят цепочки ключей при разборе — в уроке про вложенные объекты.

С проверками вложенность подкидывает ловушку. containsKey отвечает только за корень документа: doc.containsKey("heat") скажет, что группа приехала, но молчит о том, что внутри неё. Ключ проверяется вторым вызовом уже на самой группе — на реальной плате это doc["heat"].containsKey("thr"). Пропустите второй этаж — и чтение по отсутствующему ключу молча вернёт ноль, а ноль станет порогом. В седьмой версии библиотеки механика та же, меняется только запись вложения: createNestedObject там записывается как to<JsonObject>() — переезд разобран в уроке про миграцию v6 в v7.

Конвейер применения я держу из четырёх шагов. Первый: строка разобралась — иначе ничего не трогаем вовсе. Второй: проверили группу, приехала ли heat. Третий: внутри группы проверили каждый ключ и подставили дефолт там, где ключа нет — int newThr = doc["heat"]["thr"] | thr; оператор возвращает правую часть на отсутствующем ключе — механика из урока по ссылке выше. Четвёртый: зажать числа в рабочую вилку и присвоить живым переменным. Отсутствие группы целиком — тоже норма: частичный конфиг правит только то, что в нём принесено, остальное живёт как жило. Обратная сторона частичности — дисциплина источника: если шлёте конфиг скриптом, печатайте в его лог ту же строку, что уехала в плату, тогда спор с платой сведётся к сравнению двух строк, а не к раскопкам кода скрипта.

Спорный вопрос — применять группу по частям или целиком. Моё правило: одна строка — одна группа целиком; не хватило ключа — группа остаётся старой целиком. Порог и гистерезис образуют пару: новый гистерезис поверх старого порога даёт гибрид, который хуже обоих исходных состояний, и поймать это в работающем логе трудно. Для одиночных настроек вроде имени узла правило можно ослабить — там пара не образуется. А чужие руки в канале — повод добавить проверку типов is<T>() на каждое поле: механика в уроке про is и as.

Порядок пробы: сначала {"heat":{"thr":22}} — реплика и сдвиг точки срабатывания на ручке; потом {"heat":{"thr":35,"hyst":2}} — порог и гистерезис вместе; потом {"heat":{"hyst":2}} без порога — и группа не применится целиком; потом {} — реплика про незнакомые группы; потом строка без фигурной скобки. Плата на каждый случай отвечает конкретной репликой и продолжает работать: промах по конфигу — ветка вежливого отказа, а не перезагрузка.

Честная оговорка про движок: поимённое чтение doc["heat"]["thr"] в симуляторе не эмулировано — значение вытащено из печати документа через serializeJson и indexOf, и в коде помечено комментарием. На настоящей плате это одно чтение по цепочке ключей, как в скетче для платы. Проверка формы строки — предохранитель движка: битую строку он считает аварией; на плате она просто вернётся из deserializeJson с кодом, который вы печатаете.

Кто шлёт конфиг на практике — у меня было три источника, и все они шли в одну ветку. Наладчик вводил строку из монитора при пусконаладке: порог, гистерезис, имя узла. Скрипт ночной калибровки слал пересчитанный порог раз в сутки по своему расписанию. Бригада на объекте меняла уставку через брокера — та же строка приезжала из MQTT-топика, и плата не отличала её от ручного ввода. Общее у всех трёх одно: после применения печатается факт — thr, hyst — и этот факт потом хранится в логе наладки. Без реплики спор «а какой порог стоит сейчас» решается только перечитыванием скетча, с репликой — одним взглядом в журнал.

Монитор — канал человека; постоянный партнёр платы — второй скетч или брокер. Конвейер от транспорта не зависит: та же строка прилетает по UART со второй платы или из MQTT-топика, и ветки применения не меняются. Меняется источник неразумных цифр: человек хотя бы иногда смотрит на значение, скрипт — никогда, поэтому зажим в рабочую вилку перед присваиванием — не украшение, а обязательный шаг конвейера.

Хотите, чтобы конфиг пережил вилку из розетки, — после применения его надо сохранить: serializeJson в буфер, запись в EEPROM по событию; ресурс ячеек и порядок записи разобраны в уроке про конфиг в EEPROM, а валидация каждого поля — в уроке про валидацию входа. Здесь я умышленно остаюсь в RAM: применение на лету не требует ни одной записи в память, и это его главное достоинство — цена та же, что у любой переменной: сброс питания вернёт заводские значения.