Конфиг из JSON-строки: старт, проверка, дефолты

Плата в щитке на третьем этаже, а порог сработки меняется по телефону: договорились, что thr будет 26, вписали в переменную через монитор и разошлись. Через неделю мигнуло питание — и плата проснулась с заводским значением: переменные живут в RAM и со стартом обнуляются. Конфиг одной JSON-строкой закрывает это: при изменении настроек сериализуем документ в строку и кладём её в EEPROM, при старте — вычитываем и разбираем. Сценарий один и тот же от термостата до счётчика: поменялся порог — записали; мигнуло питание — прочитали; пришла новая плата — выкатили дефолты и доработали. Ячейки EEPROM и их ресурс — 1024 байта на Uno и около 100 000 циклов записи на ячейку — разобраны в уроке про конфиг в EEPROM; здесь я не про ячейки, а про конвейер строка → документ → настройки.

Почему строкой, а не готовой структурой в памяти? Строка самонесущая: добавили в конфиг новое поле — старый блоб всё равно разбирается, а недостающие ключи закрываются дефолтами. Структура в EEPROM жёстко связана с раскладкой полей конкретного компилятора: поменяете порядок или тип — прочитаете мусор, и никакой containsKey не спасёт. Версию формата тоже держите в строке: поле v с номером — одна буква в документе, а при будущей миграции вы будете знать, с чем имеете дело, без раскопок в истории правок. Цена вопроса копеечная: конфиг из трёх полей — строка под 45 байт, в 1024 байтах EEPROM Uno она занимает один кадр из двадцати с небольшим.

Четыре шага, всегда в этом порядке. Вычитать строку из памяти — на плате это цикл по ячейкам EEPROM до нуля-терминатора, в симуляторе — переменная-эмулятор. Разобрать: deserializeJson либо даёт документ, либо нет, и третий шаг раздваивается. На удаче — проверить каждый ключ через containsKey и применить найденное; на неудаче — выкатить полный набор дефолтов и пометить это в мониторе, чтобы спор с памятью был виден глазами. Четвёртый шаг один в обоих случаях: применить настройки к железу — порог в переменную, режим в состояние выхода. Пока конвейер не отработал целиком, к железу ничего не применяется: наполовину загруженный конфиг хуже заводского, потому что смешивает старое с новым.

Стёртая EEPROM — самый частый гость на новой плате: ни разу не писанные ячейки читаются байтами 0xFF, то есть 255 в каждой позиции. Строка из таких байтов парсером не переварится — и это отличная новость: сработает ветка дефолтов, а не случайные значения из мусора. Симулятор ниже делает ровно этот сценарий честной кнопкой: память очищается в пустой объект, конвейер выкатывает заводские значения, и светодиод показывает, что режим вернулся в manual. Запись в ячейки движок не рисует — это граница модели, а на плате она зеркальна чтению: собрать документ, serializeJson в буфер, дописать ноль-терминатор и разложить байты по ячейкам update-ом.

На настоящей плате дефолты ставятся тремя способами, и полезно держать в голове все три. Оператор по умолчанию: int thr = doc["thr"] | 24; — если ключа нет или в нём null, вернётся 24; коротко и покрывает большую часть случаев. containsKey честнее там, где ноль легитимное значение: порог в ноль градусов, счётчик в ноль событий — разница между «ключа нет» и «ноль в ключе» становится существенной. Третий способ — проверка типа is<int>(): ключ есть, но в нём строка вместо числа; механика в уроке про is и as. Три способа не враги: оператор покрывает простые поля, containsKey — критичные, is — подозрительные; я смешиваю их в одном конвейере свободно, и код от этого только честнее.

И правило, которое я выучил на той самой плате в щитке: писать конфиг в EEPROM можно только по событию — команда из монитора, изменение кнопкой. Запись в каждом loop убивает ячейки арифметически: 100 000 циклов при записи раз в 100 мс — меньше трёх часов непрерывной работы, раз в секунду — около суток. EEPROM.update() вместо write() помогает частично: он пропускает перезапись байта тем же значением, но реальные изменения порога изнашивают ячейку так же честно, как и пустые перезаписи. Практический маркер: если запись конфига стоит внутри loop без условия — это уже недоработка, а не стилистика, и видна при чтении кода за секунду; в ревью чужого скетча это мой первый вопрос.

Печать при старте — половина отладки. Я печатаю сырую строку из памяти и разобранный итог: первая реплика показывает, что лежит в памяти, вторая — что конвейер из этого понял. Сырую строку печатаю в кавычках и с длиной в байтах — тогда обрезка видна сразу: строка в 45 байт, а в памяти лежит 38, значит хвост съеден. Спорные случаи из жизни: строка обрезана нулём посреди поля — ячейка с терминатором оказалась раньше конца; в поле порога попала запятая вместо точки после правки с телефона; в name уехала кириллица, и монитор показал кракозябры. Каждое из этих состояний видно в печати за секунду и невидимо в цифрах на выходе — пока не начнёшь сравнивать строку и итог, они живут отдельной жизнью.

Размер строки под буфер считайте через measureJson: методика в уроке про оценку памяти — я отводлю под конфиг 96 байт при фактических 45 и не жалею: запас съедает рост конфига на пару полей. Если конфиг правится человеком, помните про экранирование кавычек и спецсимволов в строках — урок про экранирование показывает, как одна непарная кавычка в имени выключает половину настроек. А полный порядок инициализации с сохранёнными настройками собран в уроке про конфиг файлом — там же и про версию конфига в самом документе. Реплика про дефолт при старте — не повод для паники, а приглашение проверить, чем именно память ответила: с двумя печатями из совета выше спор решается за минуту.