Je tourne sur un RPI 3 B sous Debian 10.11 avec une vieille carte Zwave.me qui doit avoir au moins huit ans mais qui marche toujours aussi bien avec mes 40 modules plus ou moins récents…Beaucoup de modules Fibaro en fait…
J’ai récemment migré du plugin zwave vers zwaveJS, sans soucis soit dit en passant…
J’avais, comme d’habitude effectué une sauvegarde de ma carte zwave via l’outil de @Sattaz (Zwave Cloner (Backup / Restore de vos contrôleurs Zwave))
Très pratique et efficace, mais ça demande de démonter la carte du RPI 3B et brancher la carte zwave.me sur un PC windows (je suis sous MAC…) avec en plus une cage de Faraday.
Puis, en parcourant longuement le forum et en fouillant dans le nouveau plugin, je me rend compte que beaucoup de personnes se tournent vers des clé Aotec Zwave Gen 5 ou 7.
Je découvre aussi un outil dans le plugin Zwave JS appelé « gestion NVM » où il semblerait possible de faire une sauvegarde de sa carte Zwave beaucoup simplement. Sauf que ce message dans le plugin me dit « méfiance » : « Les sauvegardes NVM ne sont pas intercompatibles d’un contrôleur en version de SDK Z-Wave inférieure à 6.61 à un contrôleur en version supérieure et inversement »
Je me questionne donc :
Quel intérêts/avantages y-a-t-il a passer à une clé Aotec 5 ou 7?
Comment connaitre la version de mon SDK?
La migration de ma Zwave.me vers une autre est-elle risquée et/ou fastidieuse, si intérêt il y a…
Ayant récemment ajouté le protocole Zigbee avec une clé Conbee 2, quel protocole privilégieriez vous pour les futurs modules? Zigbee semble moins energivore mais sinon?
L’intérêt de la clef c’est de pouvoir la changer de machine facilement. Aeotec est un bon constructeur et la gen 5 est une référence. Cela ne semble pas être le cas de la 7… Part plutôt sur la zooz.
Pour la version de ton sdk il faut regarder dans l’interface zwavejs. Sinon peut-être avec le logiciel du constructeur de ta clef.
La migration se fait rapidement avec les outils de sauvegarde.
Le zwave et le zigbee ont chacun leurs avantages. Pour ma part je préfère le zwave mais si tu construis un bon reseau zigbee avec un bon maillage, un bon contrôleur et pas de chinoiseries c’est très fiable également.
Bonjour,
Qu’est-ce qui te permet de dire ça?
Vu le nombre de personnes ayant migré de la version 5 à la 7 sans difficulté et la qualité du réseau depuis le changement, il y a tout lieu de considérer cette clé comme une option plus que valable.
J’ai un retour qui m’importe beaucoup, le mien.
Depuis zwavejs et ztick gen 7 mon réseau n’a jamais été d’aussi bonne qualité.
Quasiment pas de dropped command, un réseau hyper stable, mes inclusions n’ont pas de problème.
Que demander de plus.
Oui ça fonctionne chez certains (dont moi) mais quand même le constructeur dis que la version EU a des soucis, je vois pas comment on peut la conseiller.
Après je viens de passer sur la zooz et hormis un soucis avec un module (qui semble plus venir de jeedom), le réseau est encore meilleurs. Donc même si on s’arrête aux expériences personnelles (ce qu’il ne faut jamais faire quoi qu’il arrive et dans tout les domaines) la zooz est au dessus.
Hello @Tom33700
Je me retrouve, un an plus tard que toi, dans le même cas de figure avec un nouveau post car un membre de la communauté me propose la piste de migration de controleur sur le même matériel (à ceci près que je suis un rpi2 contre un rpi 3 chez toi…). As-tu un retour d’expérience à me faire ?
Salut,
Si tu cherches un RTEX Aeotec gen 7 sur RPI2, ça risque d’être compliqué.
Sans vouloir être désobligeant, plus grand monde n’utilise cette plateforme
Heu non rien à voir. Je m’adresse à @Tom33700 , je souhaitais son retour d’expérience sur SA migration à lui : est-ce que les sdk étaient compatibles par exemple, s’il a eu des soucis sur des modules, des pertes de données etc.
Et le principe d’une recherche de retex pour migrer c’est précisément de quitter un matériel en voie d’obsolescence surtout qu’il y avait pas un gap de ouf entre le pi 2 et le pi 3 - mais on s’éloigne du sujet.
je l’ai cité dans mon message comme tu le préconises. Je pensais avoir cliqué sur répondre à son message, mea culpa si je me suis raté ; par contre je ne vois pas comment le rectifier à posteriori.
Alors en effet, depuis je suis passé sur un RPI 4 et j’ai remplacé ma carte Zwave.me par une clé Zooz (ZST10_700) pour la partie Zwave. je suis d’ailleurs entièrement satisfait de cette nouvelle configuration!
Lors de la migration j’en ai aussi profité pour passer de l’ancien plugin Zwave au plugin Zwave JS.
En suivant les tutoriels que l’on trouve sur le forum, je n’ai pas eu de difficultés notables autant pour passer du rspi 3 au 4 que de la carte Zwave.me à la clé USB Zooz.
Pour la partie Zwave, l’avantage que j’avais est que j’utilise énormément les virtuels, du coup je pense que j’ai gagné un peu de temps. Le plus long étant de réappairer chaque module Zwave à la clé Zooz.
Il faut être méthodique pour bien garder la trace de ton ancien équipement et utiliser ensuite l’outil de remplacement pour remplacer l’ancien ID par le nouveau. Mise à part ça, aucun souci!
Pour la partie RSPI 3 vs 4, je n’ai pas eu de difficulté et la seule « perte » que j’ai eu sont des icônes pour un design mais que j’ai pu les remplacer par ceux intégrés à Jeedom. 2 minutes montre en main!
Donc au final, j’ai été agréablement surpris de la facilité avec laquelle j’ai pu migré tout mon système!
Les tutos sont très bien fait et la communauté est très efficace. Il n’y a pas de raison que ça se passe mal si tu restes méthodique et que tu suis bien les tutos à la lettre!
Si je comprends bien tu encapsules tes modules dans des virtuels et tu historises les commandes de tes virtuels, donc il t’as « suffit » de switcher de l’ancien équipement sous ozw vers le nouveau sous zwJS (au final ce n’est qu’un équipement de controle hardware, tous tes scénarios, design etc se basent sur tes vrituels), et tu as utilisé l’outil de remplacement du core jeedom pour remplacer tes équipements ozw un par un par le nouveau du plugin zwaveJS. Et tu n’as pas procédé à un switch de controleur brut, tu as réappairé module par module… exactement ce que je souhaite éviter merci beaucoup pour ce retour d’expérience ! c’est chic de ta part.
Question subsidiaire : à chaque fois que tu inclus un module ZW tu crées un virtuel et une commande action / info par commande / action du module à la mano ou bien tu as automatisé ça ? Ce n’est pas la première fois que je lis cette manière de faire - d’encapsuler les équipements par des virtuels - au point que je me fais la remarque que ce devrait être natif au fonctionnement de jeedom, à défaut être préconisé dans la doc officielle comme bonne pratique.
c’est justement préconisé de ne PAS faire ca, c’est une mauvaise pratique qui n’offre aucun avantage et double la charge jeedom.
s’il faut remplacer un équipement jeedom par un autre équipement; du même plugin ou deux plugins différents (ex: ozw vers zwavejs) outils remplacer du core s’en charge (je pense que j’en ai déjà parlé…)
s’il faut remplacer une équipement zwave par autre du meme plugin si c’est exactement le même modèle (ex: exclusion/inclusion, module défectueux etc), il y a même plus simple:
faire l’inclusion
récupérer le nouveau nodeID sur le nouvel équipement
sauver cet ID sur l’ancien équipement
supprimer l’équipement qui vient d’être créé suite à l’inclusion
j’attends toujours le cas d’usage qui ne serait pas couvert et que la « méthode virtuel » gère.
Non, je ne crée pas des virtuels systématiquement. Je ne crée des virtuels que pour les commandes dont j’ai besoin dans mes design et pour lesquels le visuel est plus simple à géré via plusieurs virtuels.
Concrètement, si dans un même design je veux avoir un bouton Action pour un équipement donné et aussi son bouton Info, si je n’utilise pas des virtuels, ces 2 boutons seront sur la même tuile. Alors que peux vouloir le bouton Action en haut de mon design et le bouton Info en bas de mon design par exemple… Je ne sais pas si je suis très clair, mais c’est principalement pour ça que j’utilise des virtuels (bien que je les utilise aussi beaucoup pour des variables). A l’époque je n’avais pas trouvé d’autres astuces…
Comme autre exemple, j’ai un boitier qui gère mon arrosage à base de Arduino et de Pico pour faire l’interface avec Jeedom via MQTT.
Mon équipement ressemble à ça :
Si dans un même design je veux organiser chaque Action et Info comme je le souhaite, je n’ai pas d’autres moyens que d’utiliser des virtuels. Du moins je crois!
Mais je n’ai peut-être pas la meilleure méthode…
Pourquoi serais tu obligé ? J’ai certes abandonné les designs, trop de contraintes pour un résultat pas convaincant (chez moi). Mais je me souviens avoir entré les commandes d’où je voulais. Il n’est donc pas nécessaire de les avoir dans un virtuel pour les trier et rassembler.
Entre la commande info ou action que tu veux mais pas tout l’équipement.
Ajouter équipement : Permet d’ajouter un équipement
surtout qu’il y avait pas un gap de ouf entre le pi 2 et le pi 3 - mais on s’éloigne du sujet.
merci beaucoup pour ce retour d’expérience ! c’est chic de ta part.