bon, je voulais faire quelque chose d’a priori simple: Je dispose d’une équipement zigbee (en l’occurrence des pinces ampèremétriques) auquel j’avais réussi à donner un design à peu près potable dans le Dashboard
Pris de folles espérances, je voulais en faire une présentation légèrement différente dans un Design, par exemple sans le graphique et sans la première ligne.
Je pensais qu’un même équipement pouvait être présenté différemment sur différents Dashboard. Or je n’ai pas trouvé comment faire.
J’ai donc dupliqué mon équipement Jeezigbee pour tripoter cette version modifié dans un Design. Effectivement, j’arrive à jouer avec les éléments de décors
sauf que… ce nouvel équipement n’est plus connecté à l’appareil physique (valeur 0 partout et pas de communication.
Ai-je employer la bonne méthode ? Si oui comment « reconnecter » ce nouvel équipement à l’équipement physique ? Ou y a-t-il des moyens insoupçonnés de modifier ce qu’on présente sur un équipement en fonction du contexte (dashboard, design 1, design2) en gardant l’équipement de base ?
Quelqu’un a-t-il la réponse à ces douloureuses questions ?
Ben non on ne peut pas. un équipement c’est un module qu’on inclus dans le réseau.
Donc le dupliquer est une ineptie puisque cela ne passe pas par une inclusion !
Par contre créer un virtuel avec les commandes dont on a besoin et y appliquer d’autre widget oui.
Merci mais, Purée… mais c’est horriblement complexe… Si on ne peut pas le faire, pourquoi y’a-t-il un bouton « dupliquer »…
Créer un virtuel… y appliquer des widgets… mais bon sang… on aurait pu imaginer une boite avec des cases à cocher où on sélectionne ce qu’on veut voir apparaître.
C’est pas contre vous mais je crois que je ne me ferai jamais à la logique sous-jacente de Jeedom. Y’en a dans tous les coins, c’est terrifiant.
Précisément, si j’utilise jeedom, c’est que je n’ai ni les compétences ni le temps de me mettre à la programmation.
Mais je peux vous garantir que ça ne risque pas de devenir un outil grand public (je vous concède que ce n’est peut-être pas le but recherché).
Pour revenir sur ce nouvel exemple, vous me proposer de créer un virtuel. Je ne pense pas que ce soit utile dans mon cas puisque les commande dont j’ai besoin existent de manière native sur l’équipe. Est-ce que je me trompe ?
En revanche, oui, je vais dupliquer un le widget que j’avais déjà fait pour en faire un autre ? ça j’ai le droit ?
Ceci explique peut-être cela. J’ai un peu l’habitude de quelques systèmes de programmation mais j’ai rarement vu quelque chose qui me soit aussi étranger (et étranger à tout ce que je connais)
Vu le temps que j’y passe, soit je suis complètement con (mais j’ai la faiblesse de ne pas le croire), soit ce n’est vraiment pas intuitif.
Bon… j’ai suivi vos conseils mais je crois que mon problème avec Jeedom via d’un chaînage logique inverse entre entre ma conception et celle de Jeedom:
J’ai créé un virtuel et j’y ai importé un équipement ( virtuel <= équipement). J’ai plutôt l’habitude de système où on applique un décor à un élément (virtuel => équipement)
ça va marcher (enfin j’espère) mais je n’ai pas eu besoin de créer un widget car j’en avais déjà un qui s’appliquait à l’équipement (celui qui fait des chiffres en rouge et vert). Dans ma logique, il aurait été certainement nécessaire de créer un tel widget puisqu’on y aurait appliqué un décor à un équipement. Comme dans la logique Jeedom on importe l’équipement (déjà muni de son widget) dans le virtuel, ce n’est pas nécessaire.
Pour tous les équipements qui ont beaucoup de commandes, je crée d’office un virtuel pour traiter mes designs/widgets car si à un moment le module venait à tomber en panne, c’est plus simple de relier les différentes commandes du virtuel au nouveau module que de tout remettre en place sur le nouveau module.
Je ne le fais pas pour les modules simples car ce n’est pas la peine. Le module virtuel est très puissant et il y a bcp de choses très puissantes dans Jeedom mais il faut un peu se faire la main sur le système.
Alors ce n’est pas pour relancer un débat, mais c’est la politique que j’appliquai moi aussi jusqu’à il n’y a pas si longtemps : je doublais chaque équipement physique (un module, une ampoule, un switch…) par un virtuel. Gain immédiat : plus besoin de me prendre la tête si je devais remplacer ce module en cas de panne en effet, ou en cas de remplacement par un autre modèle (scénario <> virtuel <> module).
Mais à la lecture de nombreux posts à ce sujet, j’ai acquis la conviction que ce n’était finalement pas une si bonne pratique : on ne fait qu’ajouter une couche entre les process et les équipements physiques, et donc on rajoute de la latence et encore de la charge là où il n’y en a pas forcément besoin…
Et ce qui m’a fini de me convaincre, c’est qu’effectivement en utilisant cette puissante fonction remplacer le jour où il y a besoin, et bien ça fonctionne tout aussi bien, c’est aussi rapide, et du coup ça simplifie aussi pas mal l’architecture globale…
Effectivement, c’est aussi une solution et c’est vrai que la fonction Remplacer est très puissante.
Dans mon cas, je n’utilise ces duplications par virtuel que pour certains équipements où la latence n’a guère de problème (pinces ampèremétriques, onduleur), pour les modules switch, je travaille en direct dessus.
