Avec zigbee2mqtt les objets crées sont avec un statut unique pour l’ensemble des boutons c’est plutôt pas mal mais cela nécessite un scenario par objet
le second plugin zigbeelinker est équipé d’une interface pour corriger cela et ne plus crée de scenario :
Et le developpeur de zigbeelinker, il en pense quoi. La situation est déjà un poil particulière, comprendre que jeezigbee se base sur le même concept que zigbeelinker.
après le plus gros boulot c’est zigbee2mqtt les 2 interface zigbeelinker / jeezignee font le liens avec jeedom.
zigbee2mqtt est libre donc situation particulière pas vraiment, jeedom cherche une solution stable et zigbee2mqtt est un bon choix.
Pour être honette, je n’aurais pas payé 6€ pour le plugin Zigbee de base ( jeezigbee gratuit ! ) j’aurais choisi zigbeelinker sans contester mais c’est un autre débat.
Après Jeezigbee sera suivit, si l’auteur de zigbeelinker arrête de coder le plugin est obselete.
La façon de penser / coder zigbelinker est beaucoup plus user friendly que jeedom brut
Faut un scenario par objet
mettre répéter les valeurs pour les télécommandes
etc…
Quand tu expliques cela a quelqu’un qui se lance dans la domotique, c’est du japonnais pour lui
ZigbeeLinker, tu as tout sur l’objet faut avouer que c’est top !
Je comprends qu’au premier abord cela semble plus ‹ complexe › mais on sent bien que jeezigbee est un plugin officiel, il suit de manière logique l’approche des autres plugins officiels et du moteur de Jeedom qui a déjà son système de scénario. Et je dirais d’ailleurs que c’est plutôt Jeezigbee qui a une approche plus « saine », en mon sens les plugins de protocoles sont là pour apporter la passerelle avec le protocole en question et non pas créer des interactions.
Les scénarios sont justement là pour faire interragir tes objets entre eux, pour le coup j’ai souvent migré des objets de zwave vers deconz, puis vers zigbee et maintenant vers jeezigbee, j’ai casiment jamais revu mes scénarios. Utiliser les fonctions de scénarios proposés par zlinker c’est finalement lui donner trop « d’importance » dans la répartition des tâches. Au moins en allant dans l’écran des scénarios tu as une vision présice de toutes les interractions, sans en avoir des cachés dans des popups des actions avancés au fin fond d’un plugin
Ca c’est mon avis perso d’utilisation, par contre pour la suite je croie que d’un point de vu perf c’est pas la même…Il me semble avoir lu dans d’autres post lointain de @Loic, qu’il faut absolument éviter les « actions » sur les commandes.
Pour faire simple, le processus qui gère le plugin jeezigbee ou zlinker est unique, le deamon assigné au plugin va avoir un thread unique et va donc enclencher des actions avec son propre thread, faut imaginer que sur la machine il ne va pas donc pas pouvoir paralleliser les actions car il va devoir se charger lui même des actions sur le processus qui lui a été dédié. Si tu as beaucoup de changement d’état et d’actions, c’est un seul et même thread qui va tout prendre dans les dents et engendrer des latences.
Tandis que les scénarios vont justement pouvoir démarrer leurs actions sur des threads séparés et ainsi pouvoir paralleliser les actions et surtout libérer le plugin jeezigbee pour qu’il ne se charge que de son rôle, à savoir piloter ses composants et ainsi éviter les goulots d’étranglement.
Je reconnais que ca peut sembler lourd au premier abord mais cela permet de bien rentrer dans la phylosophie de jeedom.
A voir ce que la commu en pense et voir si j’ai pas dit de bétises . Sinon pour faire une demande de dev officielle, tu dois passer par le support (un ticket) sur ton profil en ligne du market. Les devs analysent ta demandent et te feront un retour
Bonjour
Non c’est tout a fait tu ne fais pas d’erreur.
Et pour répondre à la question du poste non ça ne sera pas possible ce n’est pas la philosophie de jeedom. Déjà les actions sur valeur ça me hérisse le poils et si ça ne tenais qu’à moi ça n’existerait pas. En gros le mieux c’est toujours de faire un scénario c’est fait pour, c’est plus sûr et plus fiable.