Migration conbee2 vers smzb06-M : aucun appairage à refaire!

Plugins Protocole domotique
1

Bonsoir à tous,

je me permet un petit post pour comprendre. j’ai toujours lu qu’un appairage de l’ensmeble des equipememtns était à refaire lorsqu’on changait de clé. A minima, dans certaines configs, recharger le paramétrage de l’ancienne vers la nouvelle (ex : conbee2 → conbee3)

Et là, decision est prise de migrer de conbee2, plus officiellement supportée par z2m vers slzb06-M. je me prevois mon week-end pour faire celà sur 2 maisons, environ 80 équipements
Je sors tout le matos necessaire, un tournevis, 1 pack de bieres et je suis parti, je parametre le nouveau dongle (ethernet), j’enleve ma conbee2, et je reparamètre zigbee2mqtt …
et là, oh surprise, TOUS LES EQUIPEMENTS SE RE-APPAIRENT AUTOMATIQUEMENT, sans rien faire !!!

Bref, je ne comprends pas pourquoi tout s’est reapparé automatiquement (tant mieux d’ailleurs), mais POOOOURQUOI
… plus qu’à boire le pack de bières

Norbert

1 « J'aime »
Migration coordinateur Conbee2 vers SLZB-06M
Conbee 2 et debian11
Serveur à la cave + raspberry déporté + plugin zigbee
Z2m 2.5.1 : une semaine et plouf!
2

Bonsoir
La réponse m’intéresse également…
PS: J’ai pas de bières au frais !!

3

Bonjour

En principe pour un réseau zigbee, si le canal, les identifiants réseau (étendu compris) et la clé de chiffrement réseau ne sont pas modifiés dans la configuration, il n’est pas nécessaire de réappairer les équipements.
Autrement dit si le dossier data est conservé (plugins/z2m/data pour le plugin Jeezigbee, en particulier configuration.yaml et database.db).
En effet, au cas particulier, lors d’une bascule conbee2 vers SLZB-06M (firmware 7.4.x minimum), type d’adapter/contrôleur de deconz vers ember, la plupart des appairages ne sont pas à refaire.

akenad :slight_smile:

4

Merci pour ces élements. c’ets en tout cas ce que je constate

Et c’est assez destabilisant lorsqu’on lit ceci : FAQ | Zigbee2MQTT

What does and does not require re-pairing of all devices?

Requires re-pairing

You need to re-pair all you devices when:

  • Changing the network key (network_key) or panID (pan_id) in configuration.yaml.
  • Changing the Zigbee channel (channel) in the configuration.yaml might require re-pairing some devices, read the documentation for more info.
  • Switching between adapters requires re-pairing, except when:
    • When the serial.adapter in the configuration.yaml is zstack or ember and the serial.adapter stays the same; e.g. zstack → zstack re-pairing is not required.
      • There is one exception, when switching from a CC2531 or CC2530 (Z-Stack 1.2) to a CC2652/CC1352 (Z-Stack 3) re-pairing is required.
    • When switching from zstack → ember or ember → zstack re-pairing might not be required, however results might vary as this is not officially supported.
      • After switching, check if all devices are working and re-pair the ones that are not. In case pairing new devices is not working, re-pair some routers close to the coordinator while only permitting joining via the coordinator. Pairing should then work via routers that have been re-paired.

et conbee2 → ember n’est pas concerné par l’exception

J’ai fini par demandé à ChatGPT :

Tu soulèves un point très intéressant, et ta constatation est possible mais mérite quelques précisions techniques importantes.

:white_check_mark: Pourquoi tes appareils se sont « réappairés » automatiquement

Dans certains cas spécifiques, Zigbee2MQTT permet une transition fluide vers une nouvelle clé coordinateur, à condition que le fichier coordinator_backup.json ait été utilisé lors du changement.

Voici ce qui a probablement permis la continuité :

1. Utilisation d’une sauvegarde du coordinateur précédent

  • Zigbee2MQTT sauvegarde automatiquement le coordinateur via le fichier :

    data/coordinator_backup.json

  • Lors de la migration vers le SLZB-06M, si ce fichier est conservé et le nouveau coordinateur est compatible EmberZNet (comme c’est le cas ici), Zigbee2MQTT restaure les paramètres réseau critiques :

    • Extended PAN ID
    • Network key
    • Channel
    • Device table

  • Résultat : les appareils Zigbee croient toujours parler au même coordinateur.

2. Compatibilité EmberZNet entre ConBee II et SLZB-06M

  • Même si la ConBee II n’utilise pas une puce Silicon Labs, son firmware expose une interface EmberZNet compatible.
  • Le SLZB-06M utilise, lui, un EFR32MG21 de Silicon Labs, donc natif Ember.
  • Cette compatibilité de stack facilite la restauration des paramètres réseau communs.

:exclamation: Ce n’est pas une migration sans précaution

Par défaut :

  • Remplacer la clé sans backup = réappairage obligatoire.
  • Avec coordinator_backup.json et un coordinateur compatible = migration possible sans réappairage.

:mag: Comment vérifier si tu as bénéficié de ça

  1. Regarde dans /opt/zigbee2mqtt/data (ou autre dossier selon ta config) si un fichier coordinator_backup.json est présent.

  2. Dans les logs de Zigbee2MQTT au démarrage, tu devrais voir quelque chose comme :

    Loaded backup from previous coordinator

Conclusion

Tu as raison : une migration ConBee2 → SLZB-06M peut fonctionner sans réappairage, mais seulement si :

  • Tu conserves les données Zigbee2MQTT
  • Le nouveau coordinateur utilise EmberZNet
  • Et que Zigbee2MQTT peut restaurer les identifiants réseau à l’identique.

Sinon, un réappairage est nécessaire.

J’ai vérifié et j’ai bien un « coordinator_backup.json » dans mes repertoires

Norbert

Jeezigbee NOK suite à installation de slzb-06M
5

Bonsoir,

Du coup un petit tuto sur ta méthode de migration ne serait pas de refus :wink:

Lydie

6

Il l’a déjà fait:

Si ca ne fonctionne pas, reprendre à l’étape 1)
ca finira par aller (faut juste prévoir des réserves)

5 « J'aime »
7

du coup, y a pas vraiment de procédure effectivement
1 - mise en route en ethernet de l’antenne slbz06-M (adresse IP / hostname / maj firmware et zigbee
IMPORTANT, il y a un outil de scan des reseaux WIFI / celà permet de controler qu’il n’y a pas ambouteillage sur le canal zigbee 11. de mon coté, j’ai deplacé les canaux wifi vers les canaux 7, 10 et 13 pour liberé le canal zigbee 11.

ex : CH 11 Zigbee = CH 1 WIFI

image
image1196×723 82.7 KB
image
image1235×670 127 KB

2 - une fois que le slzb06-M est OK, on verifie qu’il y a un fichier data/coordinator_backup.json dans le rep data de zigbee2mqtt (me demandez pas comment il apparait, je ne sais pas

3 - on modifie dans le fichier configuration.yml de zigbee2mqtt pour changer la configuration serial: avec la nouvelle antenne … on relance z2m et on attend avec une bière (important !) et on debranche l’ancienne antenne

De mon coté, la remontée a été assez rapide, et le last seen des equipemments z2m se remet à jour tout de suite

Norbert

3 « J'aime »
Stabilité Démon
8

Hello,
Bah oui, c’est bien ça ma question :smiley:
Je ne l’ai pas alors que j’attends d’avoir assez de courage (et de bières) pour changer ma clé.
J’ai essayé de rajouter les 2 commandes dans la conf zigbee2mqtt qui normalement déclenche cette sauvegarde mais rien n’y fait.
Je temporise mon changement de clé en me disant que le temps fait que des évolutions zigbee2mqtt et/ou des outils vont voir le jour.
Cordialement

9

Depuis la nouvelle interface de zigbee2mqtt (je n’ai pas testé sur l’ancienne) :

image
image1333×392 28 KB

Request ZM Backup

ici on voit le resultat de LS avant et apres la demande de backup :

image
image983×93 1.31 KB

une fois fait, on peut le télécharger :

image
image848×290 20.6 KB

image
image616×539 52.2 KB

10

Bonjour,
Merci, j’ai testé depuis l’ancien interface pour le moment.
Ca mouline, et fini par une erreur :
image

J’ai malgré tout un coordinator_backup.json qui s’est créé, mais il me semble bien vide, non ?

{
  "metadata": {
    "format": "zigpy/open-coordinator-backup",
    "version": 1,
    "source": "zigbee-herdsman@4.3.1",
    "internal": {
      "date": "2025-07-19T08:24:30.566Z"
    }
  },
  "stack_specific": {},
  "coordinator_ieee": "00212effff07cf9c",
  "pan_id": "cb3c",
  "extended_pan_id": "dddddddddddddddd",
  "nwk_update_id": 0,
  "security_level": 5,
  "channel": 25,
  "channel_mask": [
    25
  ],
  "network_key": {
    "key": "03f1ddb40ca5e5d44427227b5bcab6e0",
    "sequence_number": 0,
    "frame_counter": 0
  },
  "devices": []
}
11

Ou, tu n’as aucun device dedans

12

Oui comme le dit ngrataloup, tu n’as aucun device dedans.

La création du backup chez moi a pris moins de 10sc.

image

J’espère ne pas avoir à réappairer, j’ai reçu une MR1 et une 06M (qui sera en routeur).

13

De mon côté j’ai effectué la migration ce week-end de la conbee II vers la SLZB-06M et j’ai dû réappairer mes 80 appareils malgré le suivi des étapes des backup du restore sur une autre machine également, mais pas grâve car zinbeelinker ne perd strictement rien :slight_smile: , juste la nécessité d’accéder aux divers appareils et ne pas en oublier :wink:
J’en ai profité pour repartir de zéro au niveau de Z2M également (rien de perdu)
Migration coordinateur Conbee2 vers SLZB-06M - Plugins / Protocole domotique - Communauté Jeedom
Dans tous les cas je n’ai plus aucune latence sur le réseau zigbee, plus d’erreur de non prise en compte d’actions (même si aucun problème de portée) et mon coordinateur se trouve maintenant (après la migration) au centre de la maison (depuis le sous-sol de ma baie informatique) grâce au câblage RJ45 de chaque pièce effectué il y a bien longtemps.

Donc pour le moment un grand Positif sur cette clé qui n’est plus liée en USB à mon NUC.

PS : Lors des appairages juste 2 points de difficulté

  • Capteurs Aquara de type température, capteur de porte, il a fallu que je change certaines piles car même à 50% certain capteurs ne voulaient pas joindre le réseau et oh miracle après le change de pile inclusion directe. Merci Chatgpt :rofl:
  • Modules Atlantic GW003-AS-IN-TE-FC permettant de gérer chaque cassette de la PAC Air/Air, il faut impérativement effectuer un reset complet (appuyer 10 Sec sur le sélecteur) puis un appui bref pour lancer l’appairage. Lancer l’appairage directement ne fonctionne pas, même si le voyant clignote orange comme si l’appairage était en cours.