Utilisation du plugin VIRTUEL - remise en cause

Pas forcement :wink:
Sur certain plugin tu as la possibilite d ajouter des cmd info/action toi meme. Rien ne t empeche d ajouter une cmd info sur ton equipement lumiere, et que ton scenario renseigne cette donnee :wink:

2 « J'aime »

Loïc, je pense que nous avons passé l’âge de jouer à Calimero, je n’ai pas cherché de responsable, encore moins désigné qqun, c’est moi qui est fait ce choix, qui n’était pas du tout déconnant à l’époque.

Maintenant il faut avancer et c’est la que j’attends une position claire de jeedom sur le périmètre de ce plugin.

A utiliser avec parcimonie, ça ne veut rien dire.

Ne pas l’utiliter pour faire une couche de substitution à des modules et plugins, ok, c’est compris, je vais corriger cette partie.

Mais, et cela concerne beaucoup de monde et ce n’est pas claire puisque la documentation l’autorise, puis-je l’utiliser avec des commandes faisant appel à d’autres commandes d’un virtuel, d’un module, d’un plugin, pour faire un calcul, une condition, ou simplement un regroupement.

Merci pour cet éclaircissement

La position a déjà été donnée et elle est la même depuis des années.
Le choix de tout dupliquer n’était pas approprié depuis le début.

On peut utiliser le virtuels pour ce qu’on veut.
Mais toutes actions, tout usage aura des conséquences.
Si vous avez un pi1 cela sera plus vite limite qu’une box plus grosse et si vous avez un nuc i25-gen5000 avec 100go de ram vous ne verrez pas la limite.

Je vais résumer ce qui a été dit (si besoin de compléter faite signe et je compléterai) et ensuite on complétera la doc et on fermera le post car celui-ci commence à être utilisé pour d’autres questions.

  • regroupe des infos, ok

  • séparer un équipement en deux, OK

  • stocker des infos calculées, ok

  • simuler des équipements pour faire des tests, ok

  • créer des « macro-équipement » qui vont faire des actions sur plusieurs autres équipements, ok

  • dupliquer systématiquement tous les équipements pour un faire une pseudo « couche d’abstraction », aucun sens et pas ok

A ceux ayant une question précise sur leur usage, veuillez ouvrir un nouveau post.

6 « J'aime »

Bonjour, c’est le problème de jeedom et de sont évolutions, en v3 c’etait la façon de faire pour avoir de beaux widgets et ça posait de nombres problèmes. La team jeedom a réfléchi à ça et à fait la v4 pour évite cela, maintenant on peut modifier le widget de basse par des plus jolis
Le problème une gros partie des user jeedom comme toi @Nemeraud, on fait la mise a jour et on pas modifier leur installation. Et aujourd’hui , on arrive à cette discutions

Faux!
On pouvait appliquer les widgets sur les équipements de base.

1 « J'aime »

Bonjour

Je ne vais pas commenter les propos ou la doc ou les versions passées et futures.

Je vais juste apporter mon expérience perso.
J’ai comme beaucoup écouté un vent de conseils à un moment de faire de manière systématique un virtuel pour un équipement.
La raison simplicité d’usage, si un équipement meurt il y a une as tout à refaire etc je passe toutes les raisons du monde.

Bref avec 140 équipements Zigbee 50 en zwave 30 en BT et 20 en RFXCom cela commence à faire du monde en virtuel.

Il faut donc avoir en tête que c’est 2 fois ce volumes qui joue dans Jeedom et bien vous me croirez ou pas mais mon NUC a eu un peu de mal à suivre

En // j’ai je ne sais combien de variable en plus qui n’arrange rien du tout je pense et voilà un cocktail qui n’a jamais crashé mais qui m’a fait passer du PI3B+ au PI4 au NUC !!!

Et maintenant j’ai tout supprimé plus de doublon équipement du tout et tout ronronne à merveille mais j’ai encore beaucoup de virtuel encore pour d’autres usages et ça marche très bien.

Je travaille à la suppression de plusieurs de mes variable et à la réécriture des scénarios en rapport et tout ça fait que la charge de mon NUC c’est de nouveau raisonnable et le log event lisible au défilé aussi.

Voilà mon expérience perso si cela peut servir

1 « J'aime »

Ça me fait plaisir de voir que je ne suis pas le seul abrutis demeuré à avoir été assez con pour avoir fait cet usage du plugin. (PS ce n’est pas une insulte pour vous mais le ressenti me concernant des derniers échanges)

Je vais aussi revenir en arrière concernant cet usage des virtuels, par contre je ne vois pas comment je pourrais me passer des virtuels pour tous les restes et ce même avec l’usage de commandes externes et il restera toujours ce dysfonctionnement, qui n’en ai pas un, dans la maj de certains commandes imbriqués.

1 « J'aime »

Je te vois plus comme la victime et que comme le responsable et certainement pas comme un abruti pour ma part.
Je sais que ce concept, ce type d’usage, a été (et est encore) fort plébiscité par des personnes influentes et donc c’est logique que beaucoup de personnes appliquent cela et suivent cette recommandation, mais moi je ne suis pas du même avis et je le dis :wink:

De nouveau, je comprend l’objectif initial de faire cette « couche d’abstraction » mais, comme déjà échangé précédemment, je doute de la pertinence: on y arrive pas vraiment (ce n’est pas tout a fait transparent), c’est compliqué à mettre en oeuvre et cela ne rapporte pas de réel avantage sur le long terme alors que cela apporte des désavantages:

en cas de soucis avec un module:

  1. le travail pour le remplacer reste important (mettre à jour le virtuel etc), ce n’est pas anodin malgré tout.
  2. le remplacement d’un module physique en gardant le même équipement jeedom est déjà prévu dans certains plugins (et je militerais plutôt pour que ce soit géré partout): en zwave ou rfx par exemple (pour ne parler que de ce que j’ai) il est très facile à faire: j’ai déjà fait des exclusions/inclusions de modules zwave sans remplacer l’équipement sous jeedom donc pourquoi s’embêter avec un virtuel? (et je ne parle pas volontairement des « nouvelles » fonctions prévues dans le core pour remplacer une commande par une autre qui peuvent aider)
  3. last but not least: combien de fois as-tu eu besoin de remplacer un module? moins de 10% je parie (moi 0%); donc tout complexifier pour peut-être un jour avoir « facile » à remplacer un module qui va peut-être tomber en panne… tu « paies » cher pour 0 retour sur investissement.
5 « J'aime »

Ce sujet a été automatiquement fermé après 8 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.