Как работают OTA‑обновления в Zigbee и как их выполнять

Коротко: OTA (Over‑The‑Air) в Zigbee — это механизм доставки и установки прошивок по радиоканалу через ZCL‑кластер OTA Upgrade (0x0019): устройство запрашивает индекс образов, скачивает нужный файл блоками, проверяет CRC/подпись и применяет обновление.

Основы работы и структура OTA‑образа

Процесс сводится к четырём этапам:

  1. Image Query — клиент (устройство) спрашивает сервер о доступных образах.
  2. Согласование — сервер отвечает метаданными: Manufacturer ID, Image Type, File Version, Zigbee Stack Version, Total Image Size.
  3. Передача блоками — клиент запрашивает блоки; сервер отсылает chunks. Для батарейных устройств используются режимы с опросом/временны́ми окнами.
  4. Проверка и применение — контрольная сумма/подпись, запись и перезагрузка.

Файл OTA состоит из заголовка (OTA header с перечисленными полями), опциональных sub‑elements (bootloader, сертификаты) и собственно бинарника прошивки в формате производителя. Некоторые устройства требуют цифровой подписи — без неё обновление будет отвергнуто.

Manufacturer ID и Image Type в индексе должны точно совпадать с данными устройства — частая причина отказов.

Практическая инструкция для популярных стеков

Zigbee2MQTT:

  • В интерфейсе: Devices → выбрать устройство → секция OTA → Check for updates → Update.
  • Полезные настройки: интервал проверок, таймауты запросов блоков, размер блока, задержка между блоками.
  • Рекомендация: обновлять по одному устройству; следить за логом.

ZHA (Home Assistant):

  • ZHA показывает доступные обновления для ряда производителей как сущности Update.
  • Если производитель не публикует образы, ZHA не увидит обновлений.
  • Инициируйте установку из UI и наблюдайте логи Home Assistant.

deCONZ / Phoscon:

  • Поддержка зависит от интеграции и плагинов; часто ориентирована на официальные образы производителей.
  • Процесс похож: проверка → загрузка → установка, но возможности кастомизации ниже.

Если сеть нестабильна — уменьшите размер блока и увеличьте задержку между отправками; это повышает шанс успешной передачи.

Подготовка кастомного OTA‑образа и безопасность

  1. Создайте бинарник прошивки в формате, понятном загрузчику устройства.
  2. Сформируйте OTA‑header с корректными Manufacturer ID, Image Type и File Version.
  3. Если устройство требует подписи — добавьте сертификат/подпись в конец файла и укажите security credential version в индексе.
  4. Сгенерируйте OTA‑index (JSON) с записями для каждого образа: manufacturerId, imageType, fileVersion, url/имя файла, size.

Загрузка неподписанного или неверно сформированного образа может привести к отказу устройства или «окирпичиванию» — делайте резервные планы и используйте только проверенные инструменты.

Чек‑лист перед OTA:

  • Резерв списка устройств и текущих версий.
  • Батарея ≥70% для портативных устройств или питание от сети.
  • Обновлять по одному устройству.
  • Включён подробный лог на хабе.
  • Индекс содержит корректные Manufacturer ID / Image Type.
  • План отката (если возможен).

Частые ошибки

  • Device didn't respond to OTA request — устройство не проснулось или низкий заряд.
  • Несовместимый Manufacturer ID / Image Type — индекс некорректен.
  • Передача прерывается — нестабильный маршрут, перегрузка сети.
  • Образ отвергнут загрузчиком — неправильный внутренний формат или отсутствует подпись.

FAQ

  • Как долго длится OTA? Обычно 10–30 минут, но зависит от размера образа и стабильности сети.
  • Можно ли откатиться на старую версию? Зависит от устройства — многие не поддерживают downgrade.
  • Нужно ли подписывать образ? Если устройство требует подпись (security credential version), да — иначе образ отвергнут.
  • Можно ли обновлять несколько устройств одновременно? Технически можно, но рекомендуется по одному, чтобы снизить нагрузку и вероятность ошибок.

Если нужно — подготовлю пошаговую инструкцию под вашу платформу (Zigbee2MQTT / ZHA / deCONZ) или помогу собрать корректный OTA‑index и файл по параметрам вашего устройства (Manufacturer ID, Image Type, текущая версия).