Preferences: настройки, которые переживают вилку из розетки

Кормушка для кота с расписанием: ESP32, часы реального времени, шнек от степпера. Порции и порог граммов я хранил по привычке с Uno — через EEPROM.h, и всё работало ровно до того вечера, когда мне понадобился ещё один ключ: буфер стал больше, половина значений уехала, кот остался без ужина. Вскрытие показало скучную правду: на ESP32 привычного EEPROM нет вовсе, а EEPROM.h — эмуляция с буфером в оперативной памяти и одним блобом во флеше. С тех пор вся память настроек на моих платах живёт в Preferences, и урок — о том, как я этот инструмент устроил для себя: namespace под задачу, ключи с типом в имени, заводские дефолты в одном месте.

Физику NVS и семантику begin/end — журнал записей, уплотнение страниц, износ секторов — я разбирал в разделе про EEPROM, в уроке про Preferences оттуда же; там же лежит словарь миграции с EEPROM.h, повторять его не буду. Здесь — этаж выше: как спроектировать набор ключей, чтобы через полгода в собственном коде не заблудиться, какие ловушки таит типизация и где Preferences уместен, а где избыточен. Кода немного, решений много.

Preferences — хранилище ключ-значение. begin("имя") открывает namespace — группу ключей с именем до пятнадцати символов; putUChar, putShort, putFloat, putString кладут значения, а зеркальные get-вызовы принимают дефолт прямо в аргументе: ключа нет — вернётся ваша заводская цифра, без обвязки из проверок. Главная деталь, о которой tutorials пишут вскользь: с каждым ключом хранится метка типа. getType("porog") вернёт числовой тег, isKey("porog") подскажет, есть ли ключ вовсе, — и чтение чужим типом проходит молча: getFloat по ключу, записанному putShort, честно вернёт ваш дефолт, а не сохранённое значение.

Моя грабля из кормушки: порог писал putShort, через месяц читал getFloat — получил дефолт и неделю подозревал питание. Диагноз скучный: тип не совпал, функция молча отдала запасную цифру. С тех пор тип живёт прямо в имени ключа: porog_i16, svet_u8, imya_str — и чтение всегда тем же вызовом, что и запись. Вторая привычка: putXX возвращает размер записанного — ноль означает отказ: namespace открыт только для чтения, ключ длиннее пятнадцати символов или раздел забит. Ноль легко не заметить, а это единственный намёк, что запись прошла мимо.

Разделение на namespace — не эстетика, а страховка. clear() стирает только открытый namespace: фабричный сброс пользовательских настроек не задевает калибровки и счётчики — я именно так и сбрасываю кормушку, долгим нажатием кнопки, и номер платы при этом цел. Счётчики в отдельном stats живут своей жизнью: у батарейных узлов счётчик снов удобнее держать в RAM, в RTC_DATA_ATTR, — это бесплатно и без износа, но живёт только пока есть питание; расклад у меня в уроке про RTC-память и счётчик снов. Всё, что обязано пережить вилку из розетки, — в cfg и stats.

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

Структуры настроек переезжают через putBytes и getBytes: указатель, размер, ключ — и чемодан байтов лежит в одном ключе. Только помните: это сырые байты, поэтому при изменении состава полей подписывайте версию прямо внутри структуры, иначе старая прочтётся в новую как чемодан без замка. А калибровки в read-only namespace я наполняю отдельным скетчем: он открывает тот же namespace уже с правом записи, разово кладёт коэффициенты и закрывает. Рабочий скетч никогда не получает права писать в cal — случайно испортить калибровку становится физически невозможно, и отдельный плюс: журналом прошивок служит та самая версия в ключе.

Не пишу в loop «на всякий случай» и не храню то, что обязано умирать с питанием: безопасный стартовый уровень реле задан кодом, а не сохранённым значением — иначе после сбоя плата проснётся с чужим состоянием выходов. Не кладу в ключи большие массивы: NVS — дом мелких значений и коротких строк, где каждая запись — отдельный журнал; логи и таблицы — во флеш-файловую систему, это другой механизм с другими граблями. И не храню в Preferences то, что должно быть приватным, без нужды: SSID и пароль WiFi там лежать умеют, но для моих самоделок проще строка в скетче — на прошитом устройстве их и так достать несложно.

EEPROM.h на ESP32 я оставил ровно в одном месте: перенос старого скетча с Uno, где адреса зашиты в логику так глубоко, что переписывание страшнее эмуляции. Там буфер с блобом и явный commit() — приемлемая плата за малую кровь. Для любого нового кода путь один: Preferences с ключами, которые читаются через полгода как текст, и типом, который видно в имени. А после каждой перезагрузки конфиг читается заново — и если рестарты стали частыми, виноват не хранилище: причины перезагрузок я раскладывал в отдельном уроке про аптайм.

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

Домашнее задание: найдите в своём скетче одну переменную, которую вы мечтаете пережить вилку из розетки. Заведите namespace, пропишите ключ с типом в имени, сделайте первый запуск с дефолтами через isKey и проверьте возврат put — он должен быть больше нуля. А если в проекте есть Serial-команды вроде set и get из симулятора, разбор чтения чисел из монитора ждёт в уроке про Serial.parseInt — там же про таймауты чтения, на которые наткнётесь сразу.