Bonjour,
J’ouvre ce post car je m’interroge de manière très néophyte sur le pourquoi de ces deux plugins en remplacement de OpenZwave et Zigbee.
J’ai passé des heures carrées à lire le forum et le blog et si quelque chose m’a échappé, je m’en excuse d’avance.
A travers plusieurs posts, je crois comprendre que Jeedom SAS s’est convaincu qu’implémenter les différentes configurations étaient devenus une charge de travail trop importante, alors qu’il existe pour vulgariser une très large communauté centralisant les différentes configurations. Je lisais par ailleurs que Loic indiquait assumer avoir pris une mauvaise direction. (y a que ceux qui ne testent pas qui n’évoluent pas, et je trouve qu’il est plutôt bien d’avoir une équipe qui ose plutôt que de rester sur un système sans évolution).
Pour en revenir au sujet, je teste les deux plugins ZwaveJS et Z2m sur un environnement de test avant de me lancer.
Je m’aperçois que certains équipements ne sont pas fonctionnels et qu’il faille remonter un tas d’informations pour qu’ils soient implémenter dans une future release à travers les dépendances.
J’en arrive à ma(mes) question(s) :
- ne retombe pas dans les travers d’Openzwave et Zigbee qu’à chaque équipement non reconnu ou mal reconnu de devoir remonter un tas d’information à Jeedom SAS et qu’au final ils n’aient plus la bande passante pour suivre.
- n’aurait-il pas été possible d’inclure l’intégralité des équipements connus des communautés ZwaveJs et Zigbee sans avoir une surcouche jeedom, ou avoir une implémentation Jeedom pour un confort / simplicité utilisateur et quelques choses de plus brut pour les utilisateurs plus avancés (je ne me considère pas forcément dans le deuxième cas
)
J’ai bien noté les workaround côté ZwaveJS de créer les commandes qu’on retrouve dans les valeurs, mais ça demande toujours du boulot aux équipes pour l’intégration de base.
Je veux pas rentrer dans une polémique, juste comprendre les choix et la direction de ces deux nouveaux plugins.
Merci à vous !