Migration coordinateur Conbee2 vers SLZB-06M

Bonjour à tous,

j’utilise depuis plus de 3 ans maintenant zigbee2MQTT avec le coordinateur Conbee2 via zigbeelinker en mode « Client MQTT », j’ai MQTT et zigbee2mqtt sur d’autres machines.
J’ai aujourd’hui 80 équipements, je me retrouve avec beaucoup de latence de réponse voire pas de réponses des devices alors qu’il n’y a aucun problème de portée.
Souhaitant aussi s’affranchir de la connexion USB, j’ai pris la décision de basculer vers une techno « plus d’actualité » et donc aller vers le coordinateur SLZB-06M.

Pour info, l’ensemble de ma domotique fonction sous proxmox avec du grafana, influxdb et autres. Toute la plateforme est les briques sont à jour des release y compris Jeedom, le tout sur un réseau 2.5MBs redondé (le pourquoi du SLZB-06M), oui je sais pas nécessaire mais ses mon passé informatique infra qui me rattrape :wink:.

Afin d’effectuer des tests (LAB), j’ai installé Z2M et MQTT sur une autre VM (LXC) utilisant le coordinateur SLZB-06M en mode réseau, tout fonctionne parfaitement mais à ce stade pas d’intégration dans Jeedom.

Mais maintenant l’étape importante est la bascule de conbee2 vers SLZB-06M, sans perdre mes équipements là je galère, heureusement que je suis en virtuel, le retour arrière sur snapshot est un vrai plus :wink:

  • En effectuant un backup de la config Z2M, en la copiant vers mon nouveau Z2M et en modifiant les ports comme nécessaire - erreur au démarrage de Z2M - KO
  • en copiant le fichier « coordinator_backup.json » de la configuration de la machine avec le SLZB-06M, cela fonctionne, mais plus aucun appareil dans Z2MQTT - KO

Qui aurait déjà migré d’une conbee2 vers SLZB-06M sur réseau ?
Quelles étaient vos étapes pour y arriver ?
Autre question subsidiaire mais qui a son importance avec le plug-in zigbeelinker

  • Si la solution est de redémarrer Z2M à zéro mais en gardant le même serveur MQTT (mosquitto) et le même Topic Z2M
  • est ce que zigbeelinker (en mode MQTT Client) va conserver les équipements ?
  • Si les équipements sont conservés, lors de la réintégration un par un des équipements sur le nouveau Z2M, est-ce que zigbeelinker va bien refaire le lien directement à travers l’adresse IEEE de l’équipement ? Si ce n’est pas le cas, la vraie galère va commencer

Merci d’avance pour votre aide

je ne sais pas si ca pourra t’aider : Migration conbee2 vers smzb06-M : aucun appairage à refaire!

je pense de toute facon que tu ne peux pas avoir à la fois une conbee2 et une SLZB-06M sur le même réseau. tes appareils ne doivent pas savoir avec qui communiquer

coté z2m, il faut copier le fichier database.db, configuration.yml et coordinator_backup.json. verifier aussi qu’il y a bien du contenu dans le coordinator_backup.json

oui, c’est la base. changer le topic peut se faire, mais il faut bien le faire partout

Oui, si tu fai tune resto complete, il faut juste NE SURTOUT PAS SUPPRIMER LE PLUGIN.

le lien se fait sur les IEEE qui , eux, ne doivent pas changer

Pour resumer, une fois la migration de clé fait, avec ou sans reappairage, tu ne dois rien avoir à faire coté zigbeelinker ou jeedom

Norbert

Merci @ngrataloup pour ton retour,

J’avais bien vu ce poste mais comme mon comportement n’est pas similaire, j’ai posé ces questions.
Je vais refaire la procédure au cas où sinon je vais prévoir aussi les bières durant le weekend pour effectuer la migration et réapairer tous les équipements.
Pas mortel à effectuer mais il faut bien plusieurs tournevis pour ouvrir les volets et boitiers encastrés et surtout du temps :slight_smile:

Dans tous les cas le plus important est de ne rien perdre côté Jeedom avec zigbeelinker en gardant le même serveur MQTT et Topic Z2M.
La seule action à effectuer je pense sera le renommage des équipements dans Z2M car ils vont retrouver le nom IEE en lieu et place du nom modifié (mais facile :slight_smile: )
Je pense que d’avoir sorti Z2M et MQTT de Jeedom est un plus pour la flexibilité (surtout en virtualisation).

Merci encore, j’effectuerai un retour sur mon expérience, cela peut servir pour d’autres aussi

Je ne pense pas que tu aies besoin de renommer tes équipements si tu récupères le conf.yaml et le database.db
Z2m sera ok, le reappairage permettra juste d’associer tes équipements à la clé smzb-06m

Bon pas de chance, cela ne fonctionne pas.
Pour rappel, la clé SLZB-96M fonctionne parfaitement sur un autre serveur Z2M avec un MQTT de test également pour ne pas toucher à la prod.
Passé en prod

  • Arrêt de mon Z2M de test
  • sur le serveur de prod, changement de la configuration du port dans le fichier configuration.yaml et conservation du fichier coordinator_backup.json afin de conserver les clés réseau
  • clé conbee 2 débranchée
  • redémarrage, KO
  • le service Z2M n’est pas démarré, voici le LOG

Il semblerait qu’il y ait une erreur sur le fait que l’adaptateur du fichier n’est pas un ember, ma configuration avant pour la clé conbe2 était la suivante

adapter: deconz
port: >-
/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2686914-if00

Maintenant avec la nouvelle (via la copie de la page web du coordinateur, ce que j’ai sur mon Z2M de test.

serial:
port: tcp://192.168.1.104:6638
baudrate: 115200
adapter: ember
advanced:
transmit_power: 20

Mon Z2M est à la dernière version installée en une installation complète (via le script LXC proxmox) il y a 15 jours afin justement de préparer cette migration, je n’avais que recopié le répertoire data (à travers le backup Z2M) et tout avait redémarré sans problème.

Je peux bien évidemment repartir de mon installation en LAB et mettre en prod (c’est fait en 2 secondes) mais je voudrais ne pas réaprérer mes 80 appareils, sinon le stock de bières ne va pas suffire et les tournevis vont chauffer.

Des idées sur ce que je pourrais corriger ?

Le LOG avec l’erreur.

[2025-08-09 14:46:38] info: 	zh:ember:ezsp: ======== EZSP started ========
[2025-08-09 14:46:38] info: 	zh:ember: Adapter EZSP protocol version (14) lower than Host. Switched.
[2025-08-09 14:46:38] info: 	zh:ember: Adapter version info: {"ezsp":14,"revision":"8.0.2 [GA]","build":397,"major":8,"minor":0,"patch":2,"special":0,"type":170}
[2025-08-09 14:46:39] error: 	z2m: Error while starting zigbee-herdsman
[2025-08-09 14:46:39] error: 	z2m: Failed to start zigbee-herdsman
[2025-08-09 14:46:39] error: 	z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html for possible solutions
[2025-08-09 14:46:39] error: 	z2m: Exiting...
[2025-08-09 14:46:39] error: 	z2m: Error: [BACKUP] Current backup file is not for EmberZNet stack.
    at EmberAdapter.getStoredBackup (/opt/zigbee2mqtt/node_modules/.pnpm/zigbee-herdsman@4.3.1/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:1162:23)
    at EmberAdapter.initTrustCenter (/opt/zigbee2mqtt/node_modules/.pnpm/zigbee-herdsman@4.3.1/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:924:29)
    at EmberAdapter.initEzsp (/opt/zigbee2mqtt/node_modules/.pnpm/zigbee-herdsman@4.3.1/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:707:18)
    at EmberAdapter.start (/opt/zigbee2mqtt/node_modules/.pnpm/zigbee-herdsman@4.3.1/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:1547:24)
    at Controller.start (/opt/zigbee2mqtt/node_modules/.pnpm/zigbee-herdsman@4.3.1/node_modules/zigbee-herdsman/src/controller/controller.ts:133:29)
    at Zigbee.start (/opt/zigbee2mqtt/lib/zigbee.ts:68:27)
    at Controller.start (/opt/zigbee2mqtt/lib/controller.ts:101:13)
    at start (/opt/zigbee2mqtt/index.js:149:5)

Bonjour,

Version de Zigbee2mqtt ?

akenad :slight_smile:

C’est la dernière, mise en prod il y a 15 jours pour preparer cette migration et justement ne pas avoir de retard de version.

2.5.1 ou 2.6.0 ?

akenad :slight_smile:

La dernière a été publiée il y a 9 jours et pas de version il y a 15 jours

J’imagine que c’est la 2.5.1 du 2 juillet

A essayer peut être avec la 2.6.0

Oui c’est la 2.5.1, ok je vais essayer demain soir de passer en 2.6 mais pas très confiant car cela ressemble fort à une incompatibilité.
A suivre

le problème est probablement la :

akenad :slight_smile:

Oui oui, justement c’est pourquoi je ne suis pas confiant que le changement de version puisse résoudre le problème

Bon … petit retour après le week-end au passage au coordinateur SLZB-06M.

J’ai du réappairer l’ensemble de mes 80 appareils (long mais facile) mais j’en ai profité pour partir sur un environnement vierge.

Du fait qu’il était nécessaire de réappairer tous les appareils, j’ai décidé de reconstruire une machine virtuel (LXC Proxmox Zigbe2mqtt) afin de ne pas trainer de vieux paramètres.
Lors de la construction du LXC via les templates de scripts de génération (Proxmox VE Helper-Scripts), j’ai mis l’option de ne pas reconnaitre d’appareils connecté ce qui fait que le Z2M est vierge de toute configuration et il suffit d’ajouter dans le fichier de configuration ce qui est donné sur la page web du coordinateur (rien de plus simple).
Par contre attention le channel par défaut est le 11 (car aucune indication dans le fichier), pas terrible vis à vis des perturbations avec le Wifi, donc avant de lancer Z2M, bien ajouter l’option Channel 20 dans advanced (c’est ce qui est préconisé).

J’ai gardé le même serveur MQTT, de ce fait dans jeedom rien à faire.
A chaque appairage d’appareil, changer le nom « familier » de l’appareil par le nom voulu dans Z2M, cela suit dans zigbeeLinker sans rien faire.

Maintenant le gros avantage lorsque l’on est dans une maison avec un câblage RJ45 dans chaque pièce, il est facile de placer ce coordinateur dans une pièce la plus centrale.
Les temps de réponses sont incroyables (plus de latence) et je n’ai plus aucune erreur de non réponse des appareils alors qu’aucun problème de portée.

Conclusion :

  • Le passage de la conbee2 vers le coordinateur SLZB-06M (en mode RJ45) m’a obligé le réaparraige de tous mes appareils, rien de rédhibitoire car on ne perd strictement rien (merci au blugin zigbeeLinker)
  • En profiter pour repartir sur une installation Z2M vierge en paramétrant le channel sur 20 pour une meilleur performance (11 par défaut dans Z2M)
  • Le réseau Zigbee est clairement plus performant avec moins de latence et plus d’erreurs de prise des actions.

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.

Une petite capture du réseau en cours d’appairage :wink:

2 « J'aime »