Parti d’une image JeedomSmart-4.5.2_Bullseye-11.11.img propre sur l’EMMC
Restauration sauvegarde en core 4.3.23
Passage en 4.4.12
Installation plugin zwave Js
Démarrage Mqtt Ok
Démarrage ZW JS Ok
Arrêt OpenZwave
Remontée des équipements, numéro de Node identique Ok
Les commandes arrivent bien aux modules.
Par contre aucun nom des équipements; juste des références Fabricants. Compliqué pour les scénarios restés avec le nom et les commandes des équipements.
Comment s’effectue la mise à jour des noms de 52 équipements?
Le lien entre ancien et nouvel équipement, c’est l’id zwave dans le réseau.
Je t’invite à voir ce post Update Jeedom Smart - #95 par Aurel où j’ai montré une requête SQL qui te permet de lister les noms des équipements sur les deux plugins pour les faire matcher.
Merci Aurel, donc faut remettre les mains dans le cambouis …
J avais déjà un tableau reprenant les Id avec les libellés.
Donc, changer en manuel les noms, j’ai mis un point à la fin pour que ce ne soit pas le même libellé qu’Openzwave.
Faire le remplacement. Met à jour effectivement les scénarios avec les bons noms.
Reinclure la dizaine d’équipements dont les commandes ne sont pas remontées, pour éviter de les faire manuellement.
Faire le remplacement
Supprimer la dizaine d’équipement commandes absentes.
Aller dans certains équipements remettre les formules, notifications d’alarme …
Y a t’il un intérêt technique que je fasse tout cela en 4.5.3, ou je le fais en 4.4.12 et je passe en core supérieur une fois le remplacement effectué?
Oui il y a un peu de taff c’est certain …
Après perso je l’avais fait en plusieurs fois : j’étais resté sous openzwave et de temps en temps, j’arretais le daemon et je lançais celui de zwavejs pour faire remonter les équipements dessus et les renommer puis je rallumais le daemon openzwave.
Une fois que tous mes équipements étaient correctement remontés et renommés la j’ai fait la bascule à proprement parler.
Ben je vois pas forcément l’intérêt de le faire sur une vielle version du core même si dans l’absolu non ça n’a pas d’importance. Disons que certains bugs par exemple avec la fonction remplacer (c’est purement hypothétique hein, pas la réalité) pourraient avoir été corrigés avec la nouvelle version du core donc c’est bête de faire le boulot sur une vieille version.
Après oui cette migration c’est du boulot mais tu pars quand même de loin …
Clairement plus tu prend du delta, plus revenir à la dernière version du core sera compliquée. Je comprends qu’on ne puisse pas toujours être en dernière version mais clairement je pense qu’il faut au moins 1 fois par an faire un upgrade de version. C’est toujours plus compliqué de monter les marches d’un escalier 4 par 4 qu’une par une …
