Безболезненная миграция Zigbee‑координатора — пошаговое руководство

Коротко: перенос возможен без перепаривания, если на новый координатор записать ключевые параметры сети — coordinator_ieee (MAC), pan_id/extended_pan_id, канал и network_key (с sequence/frame counters) — и корректно восстановить stack‑specific данные. Ниже — практический план и команды.

Когда перенос возможен и какие данные нужны

Перенос без массового перепаривания работает только при восстановлении тех же сетевых параметров и, в идеале, IEEE‑адреса координатора. Ключевые поля:

• coordinator_ieee (MAC), если устройства жестко привязаны;
• pan_id и extended_pan_id;
• channel и nwk_update_id;
• network_key + sequence_number + frame_counter;
• stack‑specific данные (TCLK/seed для Ember, NVRAM для Z‑Stack/ZNP). Некоторые стеки/проши сохраняют всё в NVRAM и позволяют клонировать; другие — ограничены. Всегда делайте резервную копию перед действиями.

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

Общая последовательность:

1. Обновите Zigbee‑сервис (Zigbee2MQTT/ZHA) до версии с поддержкой backup/restore.
2. Остановите сервис, который держит адаптер.
3. Сделайте полный бэкап (coordinator_backup.json или NVRAM dump).
4. Подключите новый адаптер и восстановите backup в NVRAM/через встроенный restore.
5. Перезапустите сервис, проверьте устройства и маршрутизацию.

Практические варианты:

• Zigbee2MQTT (open‑coordinator‑backup): запросите coordinator_backup.json в UI/директории данных. Если restore поддерживается для пары адаптеров — используйте встроенный инструмент. Иначе запишите JSON в NVRAM новым инструментом (см. ниже).

• ZHA / zigpy: используйте утилиты zigpy‑cli / специализированные модули для чтения/записи NVRAM. Примеры команд (на Linux, с правами доступа к /dev/serial):

  • Считать NVRAM (ZNP-пример): python3 -m zigpy_znp.tools.nvram_read /dev/serial/by-id/OLD_RADIO -o backup.json
  • Записать в новый адаптер: python3 -m zigpy_znp.tools.nvram_write /dev/serial/by-id/NEW_RADIO -i backup.json

• Низкоуровневое клонирование NVRAM (CC2531/CC2652, Z‑Stack/ZNP): используйте соответствующие утилиты для вашего стека. Учитывайте, что несовместимые версии прошивки могут блокировать восстановление.

Пример ключевой части JSON‑backup: { "coordinator_ieee": "00124b001caab5b4", "pan_id": "1a62", "extended_pan_id": "00124b001caab5b4", "channel": 11, "network_key": { "key": "00112233445566778899aabbccddeeff", "sequence_number": 0, "frame_counter": 1 }, "devices": [...] }

Проверка, откат и план Б

Чек‑лист после восстановления:

• Все устройства видны и отвечают на команды.
• Имена/идентификаторы совпадают с бэкапом.
• Автоматизации работают и логи не содержат ошибок маршрутизации.
• Просканируйте топологию/energy map, чтобы убедиться в маршрутизации.

План Б:

• Попробуйте перепарить только проблемные устройства вручную.
• Поднимите старый и новый координаторы параллельно в отдельных инстансах, переводя устройства по одному.
• Если restore разрушил NVRAM, восстановите из резервной копии или верните старый адаптер.

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

• Несовпадение channel/pan_id/extended_pan_id — устройства не подключатся.
• Неполный backup (отсутствует TCLK/stack data) — замки и устройства с APS link keys могут не работать.
• Попытка восстановить dump CC2531 на CC2652 без совместимых инструментов — частые сбои.
• Прошивка нового адаптера перед записью бэкапа — NVRAM может быть стерта.

FAQ

• Нужно ли сохранять coordinator_ieee? Если устройства зависят от MAC — да, иначе некоторые привязки не сработают.
• Могу ли я менять модель адаптера (CC2531 → CC2652)? Да, но совместимость зависит от стека и инструментов restore; вероятность успеха выше при использовании open‑backup и поддерживаемых стеков.
• Сколько времени займёт восстановление? Сама запись — минуты; ожидание восстановления маршрутов и стабильности — от нескольких минут до часа.

Если хотите, подготовлю конкретный пошаговый чек‑лист под вашу связку (укажите модель старого и нового адаптера, стек — Zigbee2MQTT или ZHA, и список критичных устройств).