NTP и RTC: синхронизация через ESP32

Узел полива в щитке построен на паре ESP32 плюс DS3231, и до недавнего времени эти двое жили врозь. ESP32 брала время из сети: соединение есть — часы точные, моргнул свет — плата перезагрузилась, системное время обнулилось, и журнал родил события 1970 года; ловушку нулевых часов и сам протокол NTP я разбирал в уроке про NTP-клиент на ESP32. DS3231 от батарейки время держала железно, но кто и когда заводил его руками — история умалчивает, и верить показаниям было страшно.

Помирились они на простой иерархии: истина — у сети, кэш — у таблетки. При старте скетч получает точную метку из сети и записывает её в DS3231; дальше часы идут от батарейки с уходом в минуту за год, а калибровка повторяется раз в сутки. Пропала сеть — устройство живёт по RTC. Моргнуло питание — при загрузке всё восстановилось из сети за секунды. В этом уроке собираем схему целиком: скетч для платы с настоящим NTP и симулятор, где роль пакета NTP играет HTTP-запрос.

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

Почему бы не синхронизироваться каждый час? Можно, но три причины говорят «реже». Первая — этикет NTP-пула: серверы точного времени кормят миллионы устройств, стек ESP32 после configTime сам повторяет синхронизацию раз в час, и лезть чаще незачем. Вторая — журнал: каждый rtc.adjust() сдвигает время, и в логе появляются дырки или дубли секунд — для отчётов это боль. Третья — бессмысленность: поправлять минуту за год ежечасно смешно. Моё правило: adjust при старте, затем раз в сутки, либо немедленно, если разница с сетевой меткой превысила пять секунд.

Механика записи метки на плате укладывается в пару строк. configTime поднимает фоновую синхронизацию с NTP-сервером; когда time() возвращает число больше миллиарда — метка пришла. Дальше конструктор DateTime принимает unix-время числом: rtc.adjust(DateTime(unix)) — и таблетка говорит тем же временем, что и сервер; полный разбор полей снимка я делал в уроке про объект DateTime. Часовой пояс решите один раз: я держу в RTC локальное время — для часов на LCD и расписаний так проще, а смещение зоны задаю в configTime, как в уроке про NTP.

Практика требует чисел, поэтому посчитаем окно между калибровками. Уход DS3231 при двух промилле — до 0,2 секунды за сутки, до 5 секунд за месяц, минута за год. Суточная калибровка держит расхождение в пределах долей секунды — для расписания полива и меток журнала это с огромным запасом. Даже если сеть уехала на неделю, часы от таблетки уйдут на полторы секунды, и дождеватель этого не заметит. Отсюда спокойствие про порог в пять секунд: он срабатывает не от дрейфа таблетки, а от событий — перезагрузки без сети, ручной подводки, севшего резерва.

Зачем вообще держать время на устройстве, которое само сидит в сети? Для меток. Каждая строка телеметрии выигрывает от честного таймштампа — связка с уроком про публикацию показаний по MQTT даёт готовый конвейер: датчики, метка из RTC, публикация в брокер. Серверу всё равно, откуда взялась метка, а вам через месяц разбора инцидента всё равно, была ли сеть в момент события: журнал, помеченный батарейными часами, внятнее журнала, замолчавшего на время моргания света.

Скетч для платы читается сверху вниз. WiFi подключаем по классике — механика begin, статусов и ожидания разобрана в уроке про подключение к роутеру. Дальше configTime с двумя серверами и порогом готовности по time(): второй сервер — страховка на случай, когда первый пул молчит. Метка уезжает в RTC одним вызовом: конструктор DateTime от unix-числа RTClib принимает нативно; до и после печатаем показания, чтобы в журнале остался след калибровки. Ветка lostPower() из урока про первый скетч здесь отдельно не нужна: суточная калибровка перезаписывает время и без неё, а когда сети нет, функция честно оставляет часы как есть — батарейка за это время не подведёт.

В loop живут две вещи: суточный таймер на millis и печать времени из DS3231 — ровно тот снимок, который читают будильник на RTC и журнал на карте памяти. Обратите внимание на слово единственная: печать и логика не пишут в часы, только syncRTC() имеет на это право — иначе вернётся спор двух хозяев из заметки выше. Таймер суток я собираю на сравнении millis с константой 86400000 — миллисекунд в сутках; перезагрузка сбрасывает его, но это не страшно: калибровка при старте и так происходит.

А если сети нет в принципе — дача без интернета, гараж за бетонными стенами? Пара продолжает жить: DS3231 тикает от батарейки, и единственная потеря — истинность. Метки журнала согласованы между собой, порядок событий сохранён, а абсолют сдвинут на неизвестную константу — ровно то, что было у всех механических часов до эпохи NTP. Подводится такая система один раз: выставить время в момент, когда вы точно знаете его по наручным часам, и дальше держать режим «сеть есть — калибруй, сети нет — молчи». Тот же скетч работает и с DS1307: меняется только класс объекта, а связка adjust с DateTime никуда не денется.

В симуляторе сеть настоящая: подключение к WiFi, адрес, GET-запрос с кодом 200 идут как на плате. Настоящего NTP в движке нет — это UDP-пакет на порту 123, и эмулировать его движок не умеет, поэтому роль метки сервера играет вычисление внутри скетча: стартовая отметка 9 утра 18 июня 2025 года плюс секунды, отмеренные millis(). Эта отметка и уезжает в RTC вызовом adjust — ровно то место скетча, где на плате стоит конструктор DateTime от числа из time(). Ответ HTTP в симуляторе — демо-заглушка с погодой, времени в ней нет: печатаем её в лог как есть и не делаем вид, что разобрали метку из сети. Такой контракт — сеть-транспорт отдельно, метка отдельно — к слову, спасает и на живой плате: если API времени переедет на другой адрес, каркас скетча не заметит подмены.

Что здесь переносится на плату один в один: порядок соединения, ожидание статуса, проверка кода ответа, единственная точка записи, тикающие часы и периодическая перекличка. Что заменяется: источник метки. На плате его даёт configTime с фоновым повтором раз в час, в симуляторе — арифметика от millis(). Смысловая часть — куда и когда писать метку — не меняется вовсе, поэтому скетч из симулятора можно собирать на макетке, глядя на него как на схему движения данных, и только потом подставлять настоящий источник времени.