Bonjour,
pas très convaincu que ce soit à Jeedom de coder et/ou documenter tous les nombreux cas d’usages existants de migration.
La solution la plus simple, si ont veut éviter de réinclure les modules, et de débrancher la carte Zwave de la Smart et de la brancher sur l’Atlas.
La nécessité de la méthode de migration est liée à la technologie Z-Wave, qui n’a pas été développée par Jeedom.
Le retour d’expérience que j’ai décrit est la méthode la plus simple, si ont veut éviter de réinclure les modules, dans le cas d’usage particulier pour passer d’une carte contrôleur Z-Wave intégré à la Smart à une clé USB Aeotec Z-Stick Gen5.
Le plugin openzwave est déjà installé sur les Smart Z-Wave. Ce n’est donc pas génant s’il n’est plus sur le market.
Le plugin openzwave n’est plus accessible par défaut sur le Market parce qu’il est obsolète, remplacé par le plugin ZwaveJS, pour éviter de sélectionner un plugin Zwave obsolète car développé en python2, qui n’est plus supporté à partir de Debian 11 bullseye.
Ce qui n’exclut pas de pouvoir encore installer le plugin openzwave (Obsolète, gratuit) directement depuis github, ou le Market moyennant la recherche appropriée (voir la procédure dans le premier post).
Le plugin zwavejs s’appuie sur Zigbee2Mqtt qui propose une fonctionnalité de sauvegarde/restauration qui fonctionne bien pour des controleurs Zwave ayant un SDK posterieur à v6.61, ce qui n’est pas le cas pour la carte controleur Z-Wave intégré à la Smart, qui est antérieur à 2018.
voir plus de détails ici : [RTEX] Box Jeedom Atlas - plugin MQTT Manager (mqtt2) Mode Broker local - avec plugins abonnés Z-Wave JS (zwavejs) et JeeZigbee (z2m)
Nous parlons donc d’un hardware qui a plus de 5 ans. Pas très convaincu qu’un programme (qui plus est gratuit) se doivent de conserver une compatibilité de reprise de données avec d’anciennes versions.
akenad 