Bonjour et merci pour la démarche dans le cas « simple » où l’on conserve le hardware des controleurs. Je me penche pour ma part dans l’étude d’une migration d’un rpi 2 (oui, c’est vieux) avec clé Zwave.me sur les broches GPIO et module openzwave vers un jeedom sous docker sur mon synology avec clé Aeotec gen 7 en usb et zwave JS. L’install jeedom docker est parfaitement fonctionnelle, j’ai pu jouer avec le zwave les modules de tests répondent nickel.
Est-ce qu’un import de backup pourrait fonctionner malgré un matériel différent ? Je me suis dit que dans mon cas il vaudrait mieux utiliser le plugin Jeelink et data export pour réimporter l’historique. Vos avis ?
Hello agiain,
Je me réponds à moi même - du moins en partie 
En fait il y a plusieurs chantiers dans la migration :
- d’une part migrer les équipements avec l’historique des commandes
2 ) les objets, les scénarios, les designs etc. - rétablir le lien entre le nouveau matériel (clé gen 7) et les nouveaux équipements (ceux migrés sur la cible).
J’ai vu qu’il existait sur Jeedom :
-
Zwave : D’une part la possibilité de faire dialoguer 2 controleurs Zwave via la configuration du plugin pour transférer le role primaire d’un controleur à l’autre, comme ça a été a priori expérimenté ici et discuté ici. De ce que j’en comprends les modules iraient via ce procédé se rattacher au nouveau controleur. J’ai trop de modules et certains difficiles d’accès pour me permettre [une procédure de ce style]( Documentation Jeedom). J’ai trouvé aussi cette procédure
-
D’autre part un plugin jeelink qui permet de faciliter la migration d’une instance jeedom (source) à une autre (cible) (cf le tuto officiel de la doc officielle) D’un côté cela semble correspondre à mon besoin, de l’autre ce plugin est plusieurs fois dans ce forum désigné comme obsolète face à mqtt manager. Sauf que de mon point de vue Mqtt manager permet de faire appel aux commandes d’un jeedom depuis un autre, mais il ne permet pas de recréer l’équipement avec transfert des historiques de commandes, etc.
Enfin, je me demande si je devrais m’embêter à migrer mon instance jeedom de prod (celle sur le raspberry pi 2) d’openzwave à zwavejs avant de faire la migration du raspberry pi vers l’instance docker (sur laquelle j’ai zwaveJS d’opérationnel) ? est-ce que ça va apporter quelque chose ou je m’embête pour rien ?
En tout cas je ne peux à mon sens clairement pas tenter la restauration du backup du jeedom source sur le jeedom cible, à part tout me casser je ne vois pas l’intérêt.
Merci à celles et ceux qui auront la patience de jeter un oeil à mon problème, me confirmer ce que je pense avoir compris ou m’infirmer si je dis une sottise - et m’apporter quelques éléments de réponse, ou à défaut des pistes de réflexion 
Bonjour,
C’est pas très clair pour moi tout ca…
donc je vais juste rappeler les infos:
- les histoires de migrations controleur primaire/secondaire c’était avec openzwave, ca n’existe plus sur zwavejs
- il existe plusieurs autres approches avec zwavejs (voir community)
- ne plus aller sur l’ancien forum, l’info y est probablement obsolète
- aucun risque à restaurer un backup d’une box à une autre avec ou sans openzwave
- openzwave peut être installé et actif sur debian11 (ou présent via une restauration), c’est même nécessaire pour terminer la migration zwave sur zwavejs (remplacer les équipements) mais il sera impossible d’installer les dépendances ou de démarrer le démon (et il ne faut pas le faire)
1 « J'aime »
Merci pour ton intérêt Mips
- les histoires de migrations controleur primaire/secondaire c’était avec openzwave, ca n’existe plus sur zwavejs
Merdouille. Voilà qui ne m’arrange guère. Ceci dit mon installation actuelle EST sous openzwave.
il existe plusieurs autres approches avec zwavejs (voir community)
j’ai écumé les posts, je suis preneur si tu as d’autres posts en tête que ceux que j’ai indiqué. Donc ça présenterait un intérêt que je fasse la migration vers zwaveJS sur le rpi 2 finalement, si cela doit faciliter la transition vers ma nouvelle instance docker ?
Ceci dit mon installation sur raspberry pi est avec openzwave de l’époque… Donc y a probablement des choses applicables également, je me dis.
tu peux aussi d’abord migrer de controleur à l’aide d’openzwave, ensuite vers zwavejs et ensuite debian & machine, il suffira de rebrancher la clé zwave sur la nouvelle, ca sera transparent.
1 « J'aime »
Alors ça par contre, pas bête du tout. le rpi2 a bien des ports usb de dispo. Je m’en veux carrément de ne pas y avoir pensé. Donc en récap :
- Je switch la gen 7 de matériel : je la débranche du syno et je la connecte sur le rpi2
- Je crois qu’il me faut l’inclure dans le réseau du controleur razberry : correct ?
- Je transfère le rôle primaire / secondaire d’un controleur à l’autre, ça devrait migrer automatiquement tous les modules sur la gen 7, à voir combien de temps ça prend.
- Je rebranche la gen 7 sur le syno et je relance le jeedom avec zwaveJS
- Et là… je suis pas sûr de la suite : Je lance une synchro des équipements ? Je ne risque pas d’avoir perdu tout l’historique des commandes et compagnie ? A la rigueur l’historique des ouverture / fermeture des volets, allumage des prises, je m’en cogne. C’est surtout l’historique des températures et des consommations d’énergei, style les pinces ammpèremétrique etc.
Bonjour,
Si tu n’as pas beaucoup de modules, une exclusion/inclusion est peut être plus simple.
- Exclusion des modules en ne supprimant pas les équipements.
- Changement de contrôleur.
- Inclusion et remplacement des ID sur les anciens équipements.
- Suppression des nouveaux équipements qui ne servent plus.
Dans ce cas, pas besoin de migrer les historiques, scenario, … c’est « juste » un changement d’ID sur les équipements Zwave.
il faut faire la migration zwavejs sur le pi2 si encore possible, et voir procédure pour migration ozw=>zwavejs; utiliser l’outil « remplacer » du core pour migrer les équipements et leur historique
ensuite backup et restaure sur le nas et déplacer la clé.
Si, j’en ai pas mal justement… (une bonne quarantaine) et tous ne sont pas ultra faciles d’accès. Mais merci tout de même, chacune de vos suggestions m’ouvre un peu plus les chakras sur une piste à laquelle je n’avais pas pensé. Typiquement j’associais vraiment exclusion avec suppression de l’équipement, j’avais totalement occulté qu’on pouvait le conserver.
Ok donc dans l’ordre
- Je branche la gen 5 sur le rpi2, toujours avec ozw, je fais la bascule de controleur en espérant que le process ne me pète pas tous les historiques de commandes
- Je migre de ozw vers zwaveJS (c’est possible j’ai déjà tout installé, j’avais même synchro les équipements mais j’avais quelques trucs qui n’étaient pas remonté correctement, j’avais donc commencé à me faire un excel pour noter les id de chaque module et vérifier un par un, mais devoir à chaque fois couper le démon, relancer l’autre plugin ect, bref le swith de ozw à zwaveJS était trop fastidieux, j’ai remis à plus tard… donc je ne m’en suis jamais occupé).
- je fais le backup de mon jeedom sur le rpi
- je remets la clé sur le syno
- je fais un nouveau docker jeedom dans lequel j’injecte le backup du rpi. Techniquement si les historiques des commandes ont survécu au changement de controleur ça doit le faire. En fait toute la question est là avec ce process : est-ce que le changement de controleur en mode "je migre tout d’un coup - au lieu de faire module par module - va me chibrer l’historique de 8 ans de suivi conso, température etc ? Parce que dans ce cas là, plus de retour arrière avec un backup jeedom je suppose
impossible, les noeuds zwave dans le controleur et les équipements jeedom ce sont 2 choses bien distinctes
inutile, il suffit de laisser les 2 plugins actif mais de couper le démon de ozw
et tu as toujours accès aux équipements
et je répète, c’est nécessaire pour par la suite faire le « remplacer »
non, car lorsque migration du plugin finie il faut faire la migration des équipements via la fonction « remplacer » du core… on va y arriver 
donc la théorie est là
maintenant en pratique j’ignore ce que va donner l’install de zwave js sur le vieux pi en deb10…
non, car lorsque migration du plugin finie il faut faire la migration des équipements via la fonction « remplacer » du core… on va y arriver
Merci beaucoup Mips. désolé de te faire répéter des trucs, je suis du style à suranticiper les problèmes.
maintenant en pratique j’ignore ce que va donner l’install de zwave js sur le vieux pi en deb10…
Pour le coup c’est le seul truc sur lequel je suis confiant puisque ça tourne déjà sur le rpi (j’avais commencé la migration d’ozw vers zwJS c’était fonctionnel mais j’avais quelques trucs qui ne remontaient pas comme avant dans le dashboard et certains équipements sur pile qui n’étaient pas remontés), donc le plugin fonctionne déjà, j’ai même la plupart des équipements déjà créés dans zwaveJS.
Je me suis également posé cette question sur le transfert de controleur (role primaire) : j’avais compris à la lecture de la doc que c’était entre 2 instances jeedom justement. J’ai ensuite lu un post sur le forum ou peut-être ici ou il était finalement question « d’inclure » la clé sur le controleur razberry comme n’importe quel autre module… Je me demande ce que ça va donner, sachant que sur ma clé j’ai déjà inclus 2 modules de tests sur le jeedom docker… On verra bien.
Bon, j’ai voulu tenter de voir ce que donne le fait de mettre la gen7 sur le raspberry pi… manifestement le plugin openzwave voit qu’il y un nouveau controleur possible, il me l’ajoute dans la liste déroulante de choix du controleur sur la page de configuration du plugin. Par contre, comment fais-je pour le process de transfert du controleur ? pour le passer en primaire, ou en mode « j’attends de recevoir une configuration ? » tel que je le comprends il faut que ce soit sur 2 jeedom séparés, ou il y a quelque chose que je ne comprends pas ? je m’étais dit qu’il y aurait peut-être possibilité de faire inlure la gen7 comme un module du razberry, mais je ne vois pas comment.
De mémoire lorsque j’ai fait ca avec ozw c’était deux jeedom
Ok c’est bien ce qu’il me semblait donc je dois refaire un jeedom temporaire (je vais faire avec docker, pas bien compliqué normalement), installer ozw et faire ce process avec la gen7.
Bon j’aurais mieux fait de me taire. si mon install était fonctionnelle, j’ai eu une invitation à maj la librairie zwavejs, j’ai mis à jour les dépendances et depuis elles sont en NOK. J’aurais du laisser en l’état, ça fonctionnait… Parfois les maj peuvent vraiment apporter plus de régressions qu’autre chose. 
Autre chose, histoire de me faciliter la vie : je viens de monter un autre docker pour y installer openzwave… déjà il m’a fallu faire sauter ma box jeedom docker avec la gen 7 car je ne peux en avoir plus de 2 connectées au market (pourquoi restreindre le nombre de box connectées au market ?). Et à présent, je vois que openzwave n’apparait plus dans le market des plugins. Je ne parviens pas à le trouver même en sélectionnant le tag « legacy »… Je suis preneur d’un coup de main.
Bonjour,
Car pour en avoir plus il faut acheter un pack.
La licence gratuite est limitée à 2 Jeedom avec le même utilisateur. Pourquoi ? Penses au cas des plugins payants.
Bonjour,
Sur quelle version de Debian ?
Il faudrait créer un post dédié avec la page Santé et les logs des dépendances.
1 « J'aime »
Je ne comprends pas, quel rapport avec les plugins payants ?