JSON и плоттер: один документ, два формата

Узел климата в мастерской я долго отлаживал в каше: в одном потоке порта ехала JSON-строка телеметрии, следом реплики отладки, следом мои попытки рисовать график руками. Serial Plotter в Arduino IDE 2 честно пытался строить кривые по всему, что видел, и превращал каждую фигурную скобку в мусорный ряд. Канал при этом один, а потребителей двое: график нужен каждые две секунды, журнал — каждый пакет целиком и без потерь.

Формат плоттера мы разбирали в уроке про Serial Plotter: пары метка=значение закрывает println, проза среди чисел ряды ломает — JSON с его скобками и кавычками именно такая проза. Здесь угол другой: документ один, а кранов из него два — пары для плоттера и JSON-строка для журнала, и оба крана открываются из одного места скетча, без второй сборки значений.

План: почему JSON не доезжает до плоттера; документ как единственный источник чисел; второй кран в файл на SD через Print-интерфейс; симулятор с переключателем журнала кнопкой — и счётчик, который показывает, сколько байтов канала стоит каждый формат.

Документ собирается один раз за такт: up, t, lux — присваиваниями, как в уроке про телеметрию трёх датчиков. Дальше два потребителя. Плоттеру уходят пары через Serial.print по кускам: t=24 lux=51 up=120, кадр закрывает один println — без него кривые стоят, эта грабля уже разбиралась в уроке про плоттер. Журналу — та же телеметрия одной строкой: serializeJson(doc, приёмник), формат один в один с JSON Lines-логом: одна строка — одна запись, приёмник режет поток по переводам строки.

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

Файл на карте — тоже приёмник печати: serializeJson(doc, zurnal) работает с любым наследником Print, и File — наследник. Строку закрывает println, файл — close: без него буфер не добежит до карты, и хвост суток осядет в никуда. Журнал за сутки почасово — около двух десятков килобайтов, карта даже малого объёма принимает такие журналы годами; узкое место здесь не объём, а скорость записи, поэтому close после каждой строки я не пропускаю ни разу. Базовую сериализацию в String и в Serial мы проходили в уроке про serialize — здесь меняется только приёмник.

На Uno с её двумя килобайтами ОЗУ документ на 256 байт и хозяйство SD живут вместе спокойно: бюджет пары мы уже считали в уроке про два документа, здесь вторым потребителем служит файл, и место он берёт из того же кармана. Если плат две, журнал удобно уводить на вторую через UART — там он попадает в тот же разбор deserializeJson, и второй узел становится архивом без собственной памяти.

Счётчик bayt_json делает разницу наглядной: строка телеметрии с тремя полями стоит около шестидесяти байтов, кадр пар для плоттера — около двадцати. При 9600 бод и такте в две секунды это незаметно; на периоде в сто миллисекунд журнал уже съедает треть канала, и кривые начинают дохнуть на глазах — порт один, скорости потребителей складываются. Реплика между кадрами пар — та же цена: одна строка прозы превращает соседние числа в безымянные позиционные ряды, порядок которых скачет от кадра к кадру.

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

В симуляторе плоттер и монитор — вкладки одного Serial: кадр пар рисует три ряда с подписями, JSON-строка после нажатия кнопки падает в монитор целиком, и bayt_json показывает её цену против кадра пар. Кривые при включённом журнале не портятся: в симуляторе плоттер слеп к скобкам и молча их пропускает. В настоящей IDE 2 та же строка нарисует мусорные ряды — поэтому на плате второй кран ведёт в файл или на сервер, а не в общий порт.

Разбор скетча: документ собирается присваиваниями и читается обратно точечной формой doc.t и doc.lux — пары уходят в плоттер из документа, а не из переменных, вот где документ работает единственным источником. clear() перед сборкой держит состав ключей постоянным: кадр пар выходит одной длины от такта к такту, и кривые едут ровно, без ступенек от выросшего числа.

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

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