Bonjour,
Du coup ou peut-on trouver une liste des contrôleurs et modules compatibles ?
Perso je ne la trouve pas. Et j’aimerai vérifier les compatibilités avec de migrer.
Dans la documentation il y a bien un chapitre compatibilité mais il est vide.
Merci
Merci pour la réponse, mais cela indique la compatibilité avec zwave-js qui est effectivement essentielle. Mais ma demande concerne la compatibilité côté Jeedom (en gros savoir si les configuration sont correctes et savoir si tout les modules bien reconnu par Jeedom).
Si je prend le chapitre " Migration depuis OpenZwave" de la documentation du plugin il parle de je cite
« il faut impérativement s’assurer que l’ensemble des modules du réseau est totalement pris en charge »
Et ma question et comment m’en assurer avant de migrer.
Car pour moi il faut valider la compatibilité de chaque module côté zwave-js (via votre lien) mais il faut également le faire côté Jeedom avec les configurations. A moins que je dise n’importe quoi.
En fait, tu es confronté au même pb que tt le monde.
On migre et on voit ce que ça donne.
S’il manque des modules ou si certains sont incomplets, tu demandes à ce qu’ils soient intégrés.
Ou alors des bonnes âmes t’aident à faire en sorte que ces modules fonctionnent.
Des fois, c’est assez surprenant.
Sur certains modules, des process particulièrement chiadés m’ont été fournis.
Bon courage.
A partir du moment où le module est reconnu par zwave-js, si le module n’est pas encore complètement intégré au plugin ca ne prend que 2 clics (par commande) pour créer les commandes qu’ils manquent manuellement sans devoir attendre quoi que ce soit ni qui que ce soit.
Il n’y a aucune procédure compliquée à suivre, aucun marabout à contacter ni aucune prière à connaître.
Sans oublier qu’il est possible de tout tester sans aucun risque d’impact car si la moindre chose ne fonctionne pas il suffit de couper le démon du #plugin-zwavejs et de redémarrer celui de #plugin-openzwave .
Je recommande même de ne pas se précipiter, de bien prendre le temps de valider tout ce qu’on veut avant de réellement migrer définitivement;
cette phase va demander plusieurs séances reparties sur plusieurs jours probablement où il faut se permettre de couper pendant plusieurs heures votre réseau zwave (car openzwave coupé); ne comptez pas avoir tout fini en 10min
Essayer d’installer le #plugin-zwavejs, le démarrer et lui faire reconnaître les modules n’est pas une migration.
La migration c’est après lorsqu’on est rassuré que tout fonctionne et selon le nombre de modules, le nombre de scénarios il faut compter de nouveau potentiellement une demi journée max pour migrer et stopper définitivement ozw.
Aucun marabout… ni, quelquefois, aucune logique dans l’obtention du résultat en comparant OZW et Zwavejs.
Heu y’a bien juste 2 clics pour créer la commande dans ton lien. Le reste concerne la création d’un widget.
Et accessoirement la suppression de l’info créée originellement qui ne fonctionne pas correctement pour la remplacer par une autre.
Ça, sans faire des dizaines d’essais, c’est difficile à trouver.
En plus le widget créé ne sert qu’à pallier le fait que l’on passe d’une info binaire à une info numérique.
Ça change pas mal de chose pour un détecteur de présence.
Aucun essai à faire vu qu’il suffit de regarder quelles valeurs changent… Tout cela est expliqué…
En tout cas j’ai bcp ri encore une fois
Je n’ai pas bien vu les 1190 installations du plugin avoir des problèmes c’est même plutôt l’inverse car comme @Mips l’a expliqué (encore une fois), le plugin fourni d’office tous les outils pour créer les commandes à volonté.
Mais oui, mais oui, tout est parfait, comme d’habitude.
Je n’ai jamais parlé de comparer les config ozw et zwavejs, au contraire j’ai déjà expliqué plusieurs fois de ne pas essayer de le faire.
Tu voulais dire l’inverse probablement car passer de binaire a numérique n’apporte rien, on ne va pas inventer des valeurs mais soit.
Plutôt parce que la proposition faite est plus compliquée que nécessaire ? Car (attention spoiler) il n’y avait aucune contrainte à changer le sous-type directement plutôt que de créer quoi que ce soit.
Mais si tu as comparé les deux et trouve que openzwave répond mieux à ton besoin, gardes ce plugin surtout 
Je n’ai aucun besoin ni aucun intérêt de te convaincre, l’important c’est que tu sois satisfait de tes choix.
Par contre si tu exprimes des idées que je considère erronées, que j’estime que tu induits en erreur d’autres utilisateurs, je rectifierai.
Totalement d’accord, c’est même une régression que je dois gérer mais je sais faire. Dans opz l’info présence est binaire dans zjs numérique, en fait 0 ou 8.
Aucun problème avec ça… tant que j’ai le droit de donner mon avis.
Entre parenthèses, je n’ai jamais dit qu’il ne fallait pas migrer vers zjs ou même qu’il était mauvais. Sans ça, est-ce que je continuerais ma migration ?
Ce qui m’interpelle c’est de lire que ça se passe sans difficulté en 2 coups de cuillères à pot.
J’apprécie d’ailleurs ton post précédent disant que cette migration devait se faire lentement en plusieurs étapes bien maîtrisées et sans prendre de risques.
C’est exactement ce que je fais.
Sur ma soixante de modules, j’en ai encore 5-6 qui réclament mon attention même si je sais comment les mettre en oeuvre et je prends mon temps.
Bonjour à tous,
Juste pour information Jeedom vient de mettre à jour leur site de compatibilité interne en ajoutant Zwave JS.
https://compatibility.jeedom.com/index.php?v=d&p=home&search=&plugin=zwavejs&version=stable
Bonjour,
Juste un mot pour dire que le passage d’openZwave à ce plugin s’est passé parfaitement bien chez moi, et que ça fonctionne maintenant à merveille.
Une seule chose à savoir : si comme moi vous aviez déjà jMQTT d’installé, avec un broker local configuré sans authentification, il sera automatiquement modifié avec un identifiant et mot de passe, il faudra donc reconfigurer vos appareils publiant sur ce broker en y indiquant ces id/mdp.
Merci bien pour ce très beau boulot !
Un message a été scindé en un nouveau sujet : Les températures du FGBS001 ne remontent pas sur le dashboard. Comment faire?
Bonjour à tous
Petit retour sur ma migration vers ZWAVE-JS en prod
Mon Jeedom 4.3 est hébergé sur une VM Debian buster 10 (à laquelle j’a affecté 1 processeur+2 Go RAM+100 Go disque) sur un NAS Synology DS216+II DSM 7.1 celeron N3060 dual core 1,6 Ghz avec extension à 8 Go de RAM et 2x4 To HDD WD RED en SHR BTFRS. Je dispose de 52 nœuds ZWAVE sur controleur USB AEON Labs Z‐Stick Gen5 USB Controller ZW090
Mon réseau OpenZwave était bien fonctionnel et redémarrait sans soucis dans 95% des cas (malgré l extrême lenteur). J’ai un seul nœud en mode sécurisé S0 (POPP Solar Outdoor Siren 2)
Pour la migration :
J’ai cloné la VM, arrêté la source et démarré la clone. C’est celle-là sur laquelle j’ai fait la migration en toute sécurité avec redémarrage possible sur l’ancienne VM pendant la phase de migration.
Une remarque d’importance : Il faut obligatoirement démonter la clé Zwave dans la VM originale (même si elle est éteinte) pour pouvoir l’activer dans la nouvelle.
Une fois la nouvelle VM démarrée, la procédure jeedom peut commencer.
On trouve les explications : sur la doc jeedom, sur la communauté et sur
Sur YouTube (voir les 3 vidéos de GuiPoM) et l’excellent webinaire organisé par Domadoo avec Ludovic Sarakha.
Donc, installation des plugins plugin MQTT Manager (MQTT2), Docker Manager et enfin Zwave JS
Ensuite arrêt du démon OpenZwave
Démarrer MQTT2 et Zwave-JS et lancer les dépendances (longues à installer, mais ça le fait).
Réveil des modules sur pile
Les modules commencent à apparaitre
Tous les modules ont été reconnus et commande créées, saufs quelque-un que j’ai du ré inclure, car génération commande JS incomplète.
Mon seul module sécurisé S0 a été reconnu sans pb (POPP Solar Outdoor Siren 2)
Utilisation de l’excellent outil remplacer équipement/commande de la 4.3 (bravo aux dev 
) permettant de remplacer partout les noms des commandes données en auto par le plugin zwavejs vers les noms utilisés avec openzwave dans tous les scénarios, virtuels, etc. C’est juste énorme le travail fait
J’ai dû utiliser l’outil « crée info ou commande » sur quelques modules.
Vérification et reprise des virtuels et scénarios, surtout au niveau des déclencheurs
Tests unitaires et d’ensemble
En environ une dizaine d’heures étalée sur 15 jours (j’ai 52 nœuds et une centaine de scénarios) la migration est terminée. La passage en revue détaillée de tous mes scénarios, dont mes 2 groupes critiques liés à l’alerte incendie et à la sécurité d’intrusion m’a d’ailleurs permis de corriger des bug 
Le résultat est juste époustouflant !! 
En termes de réactivité et de stabilité, que ça soit en termes de passage des ordres, de remontée d’info mais aussi en termes de re démarrage du serveur quasi instantané.
Au niveau UI/UX c’est nettement mieux qu’OpenZwave. La présentation est claire, les superflus ont été enlevés. La configuration des modules est beaucoup plus simple et surtout plus complète.
Par la prise en charge des nouvelles classes de sécurité et les modules ZW les plus récents (mode 700) Le couple Zwave-JS+MQTT2 est évolutif ce que n’est plus OPENZWAVE qui reste en v1.4
Au final je me félicite de cette migration et j’encourage tout le monde à le faire (sous réserve de disposer de la version 4.3 et d’un réseau openzawe stable sans nœud fantôme
Alors GRAND BRAVO et MERCI aux développeurs et testeurs de Jeedom. 
J’ai quelques remarques/questions à l’attention de la communauté et développeurs :
Je remarque qu’avec zwaveJS+MQTT2 l’activité disques de mon syno est devenue quasi constante. En fait, ils ne s’arrêtent jamais de gratter, faiblement certes, même s’il n’y a pas de commande envoyée ou de changement d’état sur le réseau). J’ai vérifier la mémoire ram ds jeedom ca semble ok.
En cas de redémarrage complet du Syno ou de la VM, le zwave n’est pas opérationnel. Bien que les 2 démons soient au statut démarré, je suis obligé de le redémarrer celui de zwjs pour que ça marche. Est-ce un souci de synchronisation des démarrage des démons des 2 plugins jmqtt2 et zwave js ?
il me manque la photo du HKZW-MS02 - Motion Sensor de HANK ELECTRONIC
En termes de consommation de ressource est-il préférable d’installer JMQTT2 en local ou en local Docker (j’ai testé les 2, qui marchent) étant entendus que je n’ai pas d’autre utilisation de docker sur la VM
Encore une fois BIG CLAP à la team Jeedom pour l’énorme travail fait !
Pour remettre le couple jeedom +zwave à niveau de la concurrence.
Cela rassure les nombreux utilisateurs ayant investi en argent et temps sur ces 2 technologies.
petit up pour les questions posées
Bonjour,
Vous devriez ouvrir un fil à part pour vos questions, elles n’ont pas vraiment de places dans une annonce sur un blog.
Merci pour votre excellent retour.
Bonjour
ok, fait nouveau fil
