# Migration Z-Wave série 500 → série 800 sans ré-appairage
Retour d’expérience : HUSBZB-1 → Home Assistant Connect ZWA-2, via *Controller Shift*
Avertissement
Cette procédure **n’est pas une méthode officiellement documentée ni garantie** par Silicon Labs ou les fabricants de contrôleurs. Elle s’appuie sur une fonction native du protocole Z-Wave (le transfert de rôle primaire), mais son taux de réussite n’est pas connu précisément et un échec reste possible.
- Faites une **sauvegarde NVM** de votre contrôleur actuel avant de commencer (filet de sécurité, même si elle ne se restaure pas directement sur un contrôleur 800).
- Prévoyez du temps devant vous et un accès physique à vos équipements en cas de problème.
- Gardez votre ancien contrôleur sous la main jusqu’à ce que vous ayez validé le bon fonctionnement du nouveau pendant plusieurs jours.
Pourquoi pas simplement une restauration de backup NVM ?
C’est la première chose qu’on a envie de tenter, mais **ça ne fonctionne pas** entre séries 500 et 700/800 : le format mémoire (NVM) diffère structurellement entre ces générations de puces, et les fabricants (Zooz, HomeSeer, etc.) déconseillent formellement cette manipulation — au mieux ça échoue proprement, au pire ça peut rendre le nouveau contrôleur inutilisable.
La bonne nouvelle : il existe une alternative qui passe **par le protocole Z-Wave lui-même** plutôt que par un fichier binaire — le **Controller Shift** (transfert du rôle de contrôleur primaire). C’est une fonctionnalité native et ancienne du protocole, indépendante de la génération de puce.
Prérequis
- Un **PC Windows** (l’outil utilisé ne fonctionne que sous Windows).
- **Simplicity Studio 5** (Silicon Labs), avec l’outil **Z-Wave PC Controller** (Tools → PC Controller). Compte Silicon Labs gratuit requis.
- Votre ancien contrôleur (série 500) et le nouveau (série 700/800), tous les deux branchables en USB sur le même PC.
- Côté Jeedom : le plugin **Z-Wave JS** (pas l’ancien plugin OpenZWave, qui ne gère pas correctement les séries 700/800). Si vous êtes encore sur OpenZWave, migrez d’abord vers Z-Wave JS via l’outil de migration intégré à Jeedom.
Vue d’ensemble de la méthode
- Sauvegarde de sécurité de l’ancien contrôleur.
- Inclusion du nouveau contrôleur dans le réseau existant, **en tant que contrôleur secondaire** — cette étape réplique toute la topologie réseau (liste des nodes, routage) par voie radio.
- **Controller Shift** : transfert du rôle de primaire vers le nouveau contrôleur.
- Bascule de Jeedom (ou Home Assistant) sur le nouveau contrôleur.
Aucun exclusion/ré-inclusion des devices n’est nécessaire : ils gardent leurs node IDs et donc leurs fiches équipements existantes.
Étape 1 — Sauvegarde de sécurité
Dans PC Controller, connectez-vous à l’ancien contrôleur (COM du contrôleur 500) puis allez dans **Backup/Restore (NVM)** → **Backup**. Conservez ce fichier de côté.
**Cas particulier : clé Everspring SA413-1 (et autres dongles non estampillés Silicon Labs)**
Sur ce type de contrôleur, l’outil officiel PC Controller peut se montrer capricieux, voire échouer, pour la sauvegarde NVM. Préférez dans ce cas l’outil communautaire **[Zwave Cloner](Zwave Cloner (Backup / Restore de vos contrôleurs Zwave))**, développé spécifiquement pour le backup/restore de contrôleurs Z-Wave (UZB1, RaZberry, Everspring SA413, etc.), avec de bons retours d’expérience de la communauté Jeedom sur ce type de matériel.
Étape 2 — Connecter les deux contrôleurs
Il faut **deux instances de PC Controller ouvertes simultanément**, une par contrôleur :
- Relancez l’outil PC Controller une deuxième fois depuis Simplicity Studio pour ouvrir une seconde fenêtre.
- Dans chaque fenêtre, cliquez sur l’icône **
Settings** en haut à droite, sélectionnez le port COM correspondant à chaque clé.
*Le menu principal de PC Controller, avant qu’un port COM ne soit sélectionné (« Not connected »).*
Une fois les deux clés connectées, vous devriez voir deux fenêtres actives, chacune affichant le nombre de nodes inclus sur son réseau respectif :
*À gauche/en haut : l’ancien contrôleur (33 nodes déjà inclus). En bas : le nouveau contrôleur, encore seul sur son propre réseau (1 node = lui-même).*
Étape 3 — Inclure le nouveau contrôleur comme secondaire
Cette étape inclut le nouveau contrôleur **et** réplique toute la topologie réseau en une seule opération (contrairement à l’inclusion d’un device classique) :
- Sur la fenêtre connectée à l’**ancien contrôleur** (primaire) : Network Management → section Node Actions → cliquez **Add**.
- Immédiatement après, sur la fenêtre connectée au **nouveau contrôleur** : Network Management → Controller View → cliquez **Classic Learn Mode**.
Attendez la fin du transfert (peut prendre 15 à 60 secondes selon la taille du réseau). Vérifiez ensuite que le nombre de nodes affiché est identique des deux côtés.
Point de vigilance : échec possible du handshake de sécurité (S0/S2)
Regardez attentivement le message de fin d’opération sur la fenêtre du nouveau contrôleur. S’il indique quelque chose comme **« Learn mode Added (Security Failed) »**, la topologie s’est répliquée mais **les clés de sécurité S0/S2 n’ont pas été transférées** — le nouveau contrôleur ne pourra pas piloter les équipements sécurisés tant que ce n’est pas corrigé.
*Le message en bas de la fenêtre du nouveau contrôleur indique « (Security Failed) » : la topologie est répliquée (34 nodes des deux côtés) mais les clés S0/S2 n’ont pas suivi.*
**Comment corriger :**
- Sur le nouveau contrôleur : Network Management → Controller View → **Reset** (retour à l’état d’usine).
- Sur l’ancien contrôleur : repérez le node du contrôleur qui vient d’être reseté (il reste enregistré malgré le reset côté distant), sélectionnez-le, cliquez **Is Failed** puis **Remove Failed** pour le purger proprement.
- Recommencez l’inclusion (Add + Classic Learn Mode), en gardant les deux fenêtres visibles simultanément cette fois — une popup de confirmation des clés de sécurité peut apparaître brièvement et doit être validée sans délai.
Le message final doit alors être exempt de la mention « (Security Failed) », et le nouveau contrôleur doit apparaître taggué **[S2]** dans la liste des nodes, comme l’ancien :
![Inclusion réussie : le nouveau contrôleur porte bien le tag [S2]](illustrations/03-inclusion-reussie-s2.png)
*Reprise réussie : « Add Node completed » côté ancien contrôleur, « Learn mode Added completed » (sans mention Security Failed) côté nouveau, qui affiche désormais le tag [S2] comme le node 1.*
Étape 4 — Controller Shift (transfert du rôle primaire)
- Sur le **nouveau contrôleur** : Network Management → Controller View → cliquez **Classic Learn Mode**.
- Immédiatement après, sur l’**ancien contrôleur** (encore primaire à ce stade) : Network Management → Controller View → cliquez **Shift**.
Une fois terminé, vérifiez le champ « Network Role » de chaque contrôleur :
- Le **nouveau** doit afficher **RealPrimary**.
- L’**ancien** ne doit plus l’afficher.
*Après le shift : le nouveau contrôleur (en bas) affiche « RealPrimary », l’ancien (en haut) ne l’affiche plus mais garde encore « SUC, SIS » — voir Étape 5.*
Étape 5 — Limite connue : le rôle SIS ne suit pas automatiquement
Le Controller Shift transfère le rôle « primaire opérationnel » (inclusion/exclusion de devices), mais **pas** le rôle SUC/SIS (serveur d’ID de nœuds), qui reste une désignation à part. Il est probable que le bouton **« Set as SIS »** échoue avec une erreur du type *« In the network can be only one SUC/SIS »*, quel que soit le contrôleur depuis lequel vous l’essayez — c’est une limitation protocolaire connue, pas un bug de manipulation.
**Ce n’est pas bloquant** pour l’usage quotidien : le nouveau contrôleur étant déjà « RealPrimary », il pilote normalement tous les équipements. Le SIS ne sert que pour permettre à d’éventuels contrôleurs secondaires additionnels d’inclure des devices.
*« In the network can be only one SUC/SIS, Node Id = 1 » — cette erreur apparaît quel que soit le contrôleur ou le node ciblé.*
Piste de nettoyage (à faire une fois l’ancien contrôleur définitivement mis de côté) : depuis le nouveau contrôleur, marquez le node de l’ancien contrôleur comme **Is Failed** puis **Remove Failed**. La suppression complète du node devrait effacer la référence SIS fantôme.
Étape 6 — Basculer Jeedom sur le nouveau contrôleur
- Débranchez les deux clés du PC Windows, fermez PC Controller.
- Branchez le **nouveau contrôleur** sur la machine Jeedom.
- Dans Jeedom : **Plugins → Z-Wave JS** → arrêtez le démon si besoin, mettez à jour le champ **port série** pour pointer vers le nouveau contrôleur (repérable via son nom dans `/dev/serial/by-id/` sous Linux), puis redémarrez le démon.
*Le port doit clairement identifier le nouveau matériel (ici un contrôleur Nabu Casa ZWA-2).*
Un message *« Le driver Z-Wave n’est pas initialisé, veuillez patienter »* peut s’afficher un moment le temps que le démon réinterroge chaque node — c’est normal, surtout avec des équipements sur pile qui ne répondent qu’à leur réveil périodique.
Étape 7 — Vérification finale
Dans le plugin Z-Wave JS de Jeedom, onglet **Santé Z-Wave** : vérifiez que la majorité des nodes affichent **« Complete »** en interview, avec une « Dernière activité » récente. Testez ensuite une commande sur un équipement filaire simple pour confirmer le pilotage effectif.
*La quasi-totalité des nodes repassent « Complete » avec une activité récente, preuve que le nouveau contrôleur communique bien avec le réseau existant.*
Il est normal de retrouver quelques nodes « fantômes » (statut ProtocolInfo, sans équipement associé, activité très ancienne ou inexistante) — ce sont généralement des restes d’inclusions ratées ou de devices retirés il y a longtemps sur l’ancien réseau, fidèlement répliqués par la migration. Ils n’affectent pas le fonctionnement des équipements réels.
Résumé des points de vigilance
| Point | Risque | Parade |
|---|---|---|
| Échec du Controller Shift | Les deux contrôleurs peuvent rester « secondaires » simultanément | Refaire depuis une sauvegarde ; repartir de zéro si besoin |
| Échec du handshake sécurité S2 | Devices sécurisés injoignables après bascule | Reset + Remove Failed, puis refaire l’inclusion en surveillant les popups |
| SIS ne suit pas le shift | Erreur sur « Set as SIS » | Sans impact quotidien ; nettoyage possible après retrait définitif de l’ancien contrôleur |
| Associations « Lifeline » | Certains devices peuvent continuer de pointer vers l’ancien Node ID pour les remontées instantanées | À vérifier/mettre à jour device par device si des remontées instantanées cessent de fonctionner |
*Procédure testée avec succès sur une migration HUSBZB-1 (série 500) → Home Assistant Connect ZWA-2 (série 800), réseau de 32 équipements, sous Jeedom avec le plugin Z-Wave JS.*
