jeedom est une solution tellement ouverte, qu’on peut s’y perdre facilement et en devenir frustré.
Petite expérience personnelle : j’ai cru bon migrer de zigbee2mqtt vers ce qui me paraissait être une solution bien plus robuste, à savoir une clé conbee2 et le plugin (payant) deconz.
Grave erreur !! tant de matériel incompatible, système opaque avec un support quasi inexistant. Bref, c’était une migration ratée.
Je suis donc retourné sous zigbee2mqtt et plus jamais je ne le quitterai. Associé à jmqtt tout fonctionne à merveille. D’ailleurs, j’ai une clé conbee2 à vendre…
en résumé, c’est par les expériences (bonnes, voire mauvaises) qu’on arrive à maitriser cet environnement et en tirer le profit escompté.
Si si, vous arrêterez les Zigbee’s quand ils n’existeront plus (le Thread de Matter sera bien plus performant ( « La Zigbee Alliance devient la Connectivity Standards Alliance (CSA) » c’est pas pour rien).
Bonjour,
Merci à tous ceux qui ont réagi à mon message quelque peu énervé ci-dessus.
Je n’ai pas de problème à mettre les mains dans le cambouis. J’ai passé un bon moment avant d’avoir mon installation Jeedom qui fonctionne correctement (hors Netatmo qui n’a jamais marché, et que j’ai du bidouiller). Je sors même le fer à souder de temps en temps.
Ce qui m’agace est de devoir remettre l’ouvrage sur le métier sans réelle valeur ajoutée. Mes plugins zwave et zigbee sont obsolètes et je vais devoir passer beaucoup de temps à les remplacer.
Ne pourrait on imaginer d’avoir une évolution transparente pour l’utilisateur ?
Par analogie, passer de Zwave_10 à Zwave_11, éventuellement moyennant finance ?
Mais bon, je vais continuer à utiliser, et donc à faire évoluer, mon Jeedom.
Les années précédentes vous avez bénéficié de plusieurs évolutions transparentes … que vous n’avez pas vu.
Le métier d’informaticien en général (il doit y en avoir d’autres) est assez ingrat pour ça: on doit faire des changements sans que l’utilisateur final ne le voit et parfois ce n’est possible ou cela plante et là tout le monde râle…
Pour le coup le passage à zwavejs j’ai trouvé ça assez simple avec l’outil Remplacer qui simplifie bien la vie. Et comme on peut préparer ça en amont on peu étaler la préparation sur une période et faire les remplacements lors de la phase finale.
Pour zigbee là oui c’est plus fastidieux car il faut ré-inclure tous les modules et donc ça dépend du nombre et de facilité d’accès. Ca m’avait étonné qu’il ne soit techniquement pas possible de reprendre les données stocké dans le plugin zigbee pour les injecter dans zigbee2mqtt après le passage dans une moulinette, mais bon j’ai supposé que les experts l’auraient fait si cela avait été possible.
Bonjour,
On a testé la moulinette mais c’était pas fiable et desfois les problemes arrivent quelques jours après et l’utilisateur devait réinclure c’était pas acceptable.
Il faudrait commencer par se demander si l’évolution est nécessaire.
On oublie trop souvent une part très importante du travail d’informaticien qui est de figer les systèmes développés.
En informatique industrielle, la modification d’un système sur une machine peut nécessiter une nouvelle visite de sécurité afin de rester conforme à l’évolution des normes et c’est en général totalement inenvisageable.
Il serait peut être utile de permettre de figer des parties fonctionnelles en interdisant toute mise à jour ; pour le fonctionnement de volets roulants, il n’y a pas de raison de faire évoluer les commandes tant que le matériel ne change pas.
Pouvoir concevoir la domotique de sa maison comme un réseaux de systèmes fonctionnels dont certains sont stables et figés alors que d’autres sont en développement et ainsi, avoir, pourquoi pas, plusieurs versions du même plugin par exemple !
Je loue depuis 10 ans des Zoe électriques comme voiture d’entreprise et j’interdis toute mise à jour pendant les 3 ans du contrat de location. Jamais aucune panne en plus de 250 000 km.
Pour zigbee c’est compliqué le plugin actuel avait de gros soucis de dépendances (oui du au changements de l’os…) mais surtout ce qui a pousser la migration c’est les utilisateurs qui n’étant pas content des modules supporté (pas tous supporté en particulier les tuya ainsi que les configurations pas complete).
C’est une bonne question de se demander si l’évolution est nécessaire et je me le demande souvent.
Pour illustrer :
Il ne se passe pas une journée sans que je traite de c.nnard le gars qui a pondu mon dernier iPhone. Car tout simplement plusieurs fois par jour en le prenant en main je fais une copie d’écran.
Ce c.n il a mis les 2 boutons presqu’en face l’un de l’autre et moi je suis gaucher. A chaque fois je me dis que sur son papier ça devais le faire mais qu’il ne se sert pas de ce qu’il invente et dessine et n’a pas pensé à le faire tester aux gauchers.
Alors pourquoi j’ai changé alors que mon ancien iPhone me convenait parfaitement et était « intelligent » lui. Il téléphonait parfaitement ce qui est son but premier, mais les photos n’étaient plus de la qualité qu’on cherche maintenant car le téléphone sert à tout. C’est mon appareil photo, mon gps, mon ordi portable avec les applications pour toutes mes transactions bancaires, santé etc … mon exigence de performance s’est accrue.
Bref je « on » lui demande tellement plus de chose que son rôle premier de téléphone que j’ai été obligé de le faire évoluer pour continuer à m’en servir sans que les services qu’il me rend au quotidien ne soient dégradés.
Et pour autant je n’en suis pas satisfait, je râle.
C’est pourtant une grande société qui vend des millions de téléphone et on est des millions à râler surement et à acheter quand même. On est maso
C’est clair: on va figer toute mise a jour du système et par conséquent
empêcher toute installation de plugin supplémentaire,
bloquer toute mise a jour de sécurité sur un système exposé sur internet,
bloquer toute mise à jour si un service cloud est mis à jour rendant obsolète une version actuellement installée.
Je m’arrête là, ca me parait être une super idée que je vous invite à tester par vous même car en fait c’est votre jeedom et vous êtes libre de ne faire aucune mise à jour.
je ne vais pas m’étendre sur l’aspect aberrant de faire la même chose sur une voiture, les contre-exemples sont évident à trouver.
en gros, ma réaction juste avant c’est d’éviter de faire des généralités: parfois on peut se permettre de faire qlqch de (relativement) statique, parfois on doit avancer avec le reste, je trouve que ca n’a pas de sens de dire « je ne fais aucune mise à jour comme ca jamais de problème », il y a forcément un contexte à mettre autour pour décider.
Faut lire après la ligne 1 !
Ai-je seulement écrit qu’il fallait figer tout le système ??
Êtes vous capable d’imaginer un système pouvant faire tourner le même plugin dans 2 versions différentes ? Une stable pour certains équipements et l’autre avec de nouvelles fonctionnalités pour d’autres équipements plus récents ?
Que je sache peu de gens changent les volets roulants de leur maison pour avoir droit aux dernières nouveautés !!!
(le Thread de Matter sera bien plus performant ( « La Zigbee Alliance devient la Connectivity Standards Alliance (CSA) » c’est pas pour rien).
