OTA, safe mode и проверяемый откат

До OTA-обновления нужно доказать не сам факт беспроводной загрузки, а наличие отдельного пути восстановления. Для этого заранее фиксируют платформу, схему разделов, доступ к последовательному интерфейсу или иной физический способ перепрошивки, сохраняют последнюю заведомо рабочую конфигурацию и образ, а затем проверяют обновление сначала на доступном устройстве. Безопасный режим ESPHome и откат загрузчиком считаются разными результатами: первый даёт сокращённую среду с сетью, журналированием и OTA, второй действительно запускает прежнее допустимое приложение.

Новая прошивка должна подтверждаться только после ограниченной по времени самопроверки с наблюдаемыми критериями. Устройство проверяет безопасное состояние выходов, запуск обязательных узлов, ожидаемую работу сети и сторожевого таймера, а затем помечает образ допустимым. Если поддерживаемый загрузчик, схема OTA-разделов и настройка отката подготовлены, неподтверждённый или неудачный первый запуск может вернуть предыдущее допустимое приложение. Без второго действительного образа это не откат, а лишь надежда на другой способ восстановления.

Три механизма, которые нельзя складывать в одно слово

OTA отвечает за передачу и установку новой прошивки по сети. В ESPHome компонент OTA также включает безопасный режим, а доступ к обновлению следует защищать отдельной сильной уникальной аутентификацией. Это не следует смешивать с шифрованием собственного API устройства: ключ API защищает один канал взаимодействия, а канал OTA должен иметь свои учётные данные и свой порядок хранения. Наличие шифрованного API не доказывает защищённость обновления. Успешная аутентификация OTA также не подтверждает подпись прошивки, наличие двух загрузочных слотов или работающий откат.

Безопасный режим ESPHome нужен для восстановления связи после повторяющихся неудачных запусков. В нём обычные компоненты отключены, а доступными остаются последовательное журналирование, сеть и OTA. Наблюдаемый признак такого состояния — устройство доступно для диагностики и повторного обновления, но его прикладные датчики и исполнительные функции не работают как в штатной прошивке. Точные условия зависят от платформы, хранения состояния и версии ESPHome. Это полезная среда ремонта, однако она не сообщает, что загрузчик выбрал предыдущий образ.

Откат загрузчиком относится к другой цепочке. На поддерживаемой конфигурации ESP32 он требует подходящей схемы OTA-разделов, включённой возможности отката и сохранённого предыдущего допустимого приложения. Новый образ запускается как ожидающий проверки. После самопроверки приложение либо помечает себя допустимым, либо остаётся неподтверждённым; тогда загрузчик может выбрать прежний допустимый образ. Если альтернативного допустимого приложения нет, вернуть его невозможно независимо от того, присутствует ли безопасный режим.

Рабочее правило: доступная сеть и OTA после сбоя подтверждают среду восстановления, а не возврат прежней прошивки. Откат считается доказанным только после чтения идентификатора реально загруженного образа.

Инвентаризация до сборки

Проверка начинается не с кнопки обновления, а с карточки устройства. В ней записывают точную платформу, способ первоначальной прошивки, доступные контакты или разъёмы восстановления, источник питания, назначение выходов и ожидаемое безопасное состояние каждого исполнительного канала. Для платформы отдельно выясняют, поддерживает ли её загрузчик описанную схему отката. Поведение ESP-IDF нельзя автоматически переносить на ESP8266, RP2040 или произвольную сборку ESPHome.

Для ESP32 нужно установить фактическую схему разделов, а не предполагать её по названию платы. Доступ к сведениям о таблице разделов в ESPHome является отдельной возможностью и по умолчанию не включён. Поэтому отсутствие такой информации в обычной конфигурации не доказывает ни наличие двух OTA-слотов, ни сохранность прежнего приложения. В журнале должно быть явно указано, откуда получено подтверждение схемы и какой образ сейчас считается допустимым.

Что сохранить перед обновлением

• последнюю заведомо рабочую конфигурацию с привязкой к конкретному устройству;
• соответствующий ей собранный образ с понятным идентификатором;
• зафиксированную версию ESPHome и параметры, влияющие на загрузку и подтверждение старта;
• описание физического пути восстановления без зависимости от текущей сети;
• исходное состояние выходов и способ проверить, что после перезапуска они не вышли из безопасного режима;
• идентификатор работающей прошивки до OTA и ожидаемый идентификатор новой сборки.

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

Самопроверка до подтверждения образа

Критерии самопроверки формулируют до сборки новой прошивки. Иначе подтверждение превращается в формальность: образ успевает пометить себя допустимым сразу после старта, а отказ проявляется позднее, когда загрузчик уже не обязан возвращать прежнее приложение. Проверка должна быть ограниченной по времени и состоять только из признаков, которые можно однозначно наблюдать на конкретном устройстве.

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

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

Третий критерий — наблюдаемая связь. Одного появления устройства в сети недостаточно, потому что краткий доступ не доказывает устойчивость. Критерий должен описывать ожидаемое состояние сети в пределах выбранного окна проверки и наличие журналирования, по которому видно, что устройство не входит в повторяющийся цикл загрузки. Отдельно отмечают поведение сторожевого таймера: самопроверка не должна маскировать повторные перезапуски как успешный старт.

Когда образ можно пометить допустимым

1. выходы находятся в заранее записанном безопасном состоянии;
2. обязательные компоненты завершили предусмотренную инициализацию;
3. сеть достигла ожидаемого наблюдаемого состояния без признаков цикла загрузки;
4. журнал не показывает отказ, который делает дальнейшую работу недопустимой;
5. все критерии уложились в установленное проектом окно проверки.

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

Проверка на доступном контрольном устройстве

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

Перед OTA сверяют исходный идентификатор прошивки, наличие прежнего допустимого образа и работоспособность физического восстановления. Затем устанавливают новую сборку и наблюдают последовательность: старт ожидающего проверки образа, выполнение критериев, момент подтверждения и последующий обычный запуск. В журнал заносят не только итог «работает», но и признаки, по которым этот вывод сделан.

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

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

Как отличить безопасный режим от отката

Различие устанавливают по трём наблюдениям. Сначала читают идентификатор активной прошивки. Затем проверяют набор доступных функций. Наконец, сопоставляют журнал загрузки с ожидаемым состоянием. Если устройство запустило сокращённую среду, сохраняет сеть, журналирование и OTA, но обычные компоненты отключены, это безопасный режим. Если загружен идентификатор прежнего допустимого приложения и оно работает в своём штатном составе, это откат.

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

Как записать результат без двусмысленности

• Новая прошивка принята: активен её идентификатор, все заранее заданные критерии выполнены, а подтверждение произошло после завершения самопроверки.
• Безопасный режим достигнут: доступна сокращённая среда с журналированием, сетью и OTA, а прикладные компоненты отключены; идентификатор прежнего штатного образа при этом не подтверждён.
• Откат выполнен: после проверки загружено прежнее допустимое приложение, его идентификатор совпадает с записью до обновления, а старый слот не был удалён.
• Результат не определён: идентификатор прочитать нельзя, устройство недоступно либо наблюдения противоречат друг другу; тогда автоматическое восстановление не засчитывают и переходят к физическому пути.

Только первый результат открывает путь к следующему этапу испытаний новой версии, а третий доказывает способность загрузчика вернуться к прежнему приложению. Второй подтверждает ремонтопригодность по сети, но не откат. Неопределённый результат нельзя улучшать формулировкой в журнале: до выяснения причины он остаётся критерием остановки.

Версия ESPHome входит в протокол проверки

Семантика подтверждения успешной загрузки зависит от версии. Начиная с версии ESPHome 2026.8.0 изменена семантика успешного запуска для глубокого сна и корректного завершения работы. Поэтому запись «safe mode настроен» без версии недостаточна. В карточке обновления фиксируют версию ESPHome, используемые условия подтверждения старта и то, как устройство с глубоким сном либо штатным завершением должно проходить проверку именно в этой версии.

Обновление самой среды сборки нельзя незаметно объединять с изменением логики устройства. Если одновременно меняются версия ESPHome, схема разделов, правила подтверждения и прикладная конфигурация, причина сбоя становится неразличимой. Для проверяемого процесса изменения разделяют настолько, насколько это позволяет проект, а журнал указывает, какой слой менялся в каждом прогоне.

Критерии остановки

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

Отдельная причина остановки — конфликт с защитой от понижения версии. Такая защита может намеренно запрещать возврат к образу с более низкой версией безопасности. Она решает иную задачу, чем эксплуатационный откат, и способна сделать прежний образ недоступным даже при наличии второго слота. Нельзя обещать одновременно свободный возврат и запрет возврата, не проверив конкретную политику загрузчика.

Журнал, который превращает обновление в доказательство

Для каждого прогона записывают устройство, платформу, схему разделов, версию ESPHome, исходный и новый идентификаторы образов, наличие прежнего допустимого приложения, состояние физического восстановления, способ защиты OTA, критерии самопроверки, наблюдения по выходам, сети и сторожевому таймеру, факт подтверждения новой прошивки и идентификатор после повторной загрузки. Отдельно отмечают, был ли замечен безопасный режим и был ли реально загружен предыдущий образ.

Итог формулируют узко. «OTA прошло» означает только, что образ был передан и установлен. «Безопасный режим доступен» означает, что сокращённая среда восстановления достигнута. «Откат подтверждён» означает, что при сохранённом прежнем слоте загрузчик выбрал предыдущее допустимое приложение, а его идентификатор записан. «Новая прошивка принята» означает, что она прошла заранее заданную ограниченную самопроверку и была помечена допустимой после последнего обязательного критерия.

Такой порядок делает обновление инспектируемым и заранее сохраняет отдельный путь восстановления после обесточивания, а слово «откат» относит к наблюдаемому действию загрузчика, а не к надежде на доступный OTA. До доказательства всех трёх путей — обновления, безопасного режима и возврата прежнего образа — физическое восстановление остаётся обязательной частью конструкции.