je me suis mis au mode design. J’ai essayé d’intégrer une simple commande, chose qui ne devrait poser aucun problème particulier. Sauf que cette commande est un éclairage, fruit de la fusion en interne de la commande on, de la commande off et de l’état de l’allumage. Il n’existe donc aucune « commande » simple à intégrer. Soit on intègre l’équipement, ce qui pose un problème de recouvrement des appuis, soit on intègre l’état seulement et on crée une zone par dessus pour déclencher on/off mais il n’y a alors aucun changement graphique quand on appui sur l’écran et on n’est pas sûr que l’appui a fonctionné, il faut attendre que l’état change, ce qui peut prendre un certains temps.
J’ai donc deux suggestions à vous proposer :
1- intégrer le plugin virtuel dans le core de jeedom. On devrait pouvoir créer des commandes ou info virtuelles dans n’importe quel équipement. Aujourd’hui, quand on veut personnaliser un équipement zigbee ou script ou knx…il faut créer un équipement virtuel et faire une copie intégrale des commandes de l’équipement pour ensuite personnaliser et ajouter les commandes personnelles.
2- arrêter avec la fusion automatique de jeedom des on/off/etat. Vous devriez créer dans le core jeedom un commande toggle (virtuel) similaire à la fonction « ajouter une zone » de design. On entre la commande on, la commande off, l’état. On n’a alors qu’à personnaliser l’affichage de cette commande et on retrouve son ampoule qui s’allume et s’éteint quand on appuie dessus exactement comme la fusion automatique de jeedom, à la seule différence qu’on pourra cette fois ajouter la commande toggle dans un design beaucoup plus simplement.
Éventuellement, vous pouvez toujours conserver la fonction fusion automatique, si c’est trop compliqué de remettre en question toute la structure de jeedom et vous ne créez que la possibilité de créer une commande toggle supplémentaire. Si vous le faîtes, je suis persuadé que d’ici peu de temps, plus personne n’utilisera la fonction fusion automatique de jeedom que je ne trouve absolument pas intuitive : Il faut suivre une codification d’appellation des commandes, ne pas oublier de lier l’état à chaque commande, personnaliser l’affichage des deux commandes. Avec toggle, une seule commande à paramétrer.
Non clairement ca n’a rien a y faire le core n’est pas censé geré d’équipement de commande ou autre. En plus ce plugin virtuel est souvent très mal utilisé, il ne faut pas s’en servir pour dupliquer des commandes ou équipement, c’est une catastrophe niveau perf du core quand vous faite ca. A la base il est la pour faire de l’agrégation de commande (un bouton pour plusieurs actions, un calcul sur des commandes info) mais rien de plus. Et clairement faut limiter son utilisation au plus possible.
Tu peux très bien utiliser des widgets qui ne masque pas les commandes, pour ta demande de toggle je vois pas comment faire. Ca demanderai a forcer des normes (on c’est ca, off c’est ca, état on c’est forcement 1 off c’est 0), j’ai essayé de le faire il y a quelques années je me suis ramassé des commentaires tu imagines même pas donc je vais surtout pas me réaventurer la dedans. Le mieux serait que les modules domotique gerent le toggle mais c’est rarement le cas, mais si c’était le cas tu peux très bien faire ton widget toi meme, tous les outils son dans le core.
les virtuels accessibles dans n’importe quel équipement est une nécessité quand on a plusieurs protocoles dans une maison. Certes j’ai principalement du knx mais la position du portail n’était pas gérée par NICE. Donc j’ai dû installer un capteur zigbee sur le portail pour avoir son état réel d’ouverture/fermeture.
Je me retrouve avec deux équipements : Ouverture/fermeture avec KNX, etat avec Zigbee. Avoir deux tuiles pour un même objet, c’est moche. D’où l’utilisation aujourd’hui de virtuel pour fusionner ces deux tuiles. Oui, ça ralentit jeedom, c’est stupide, peut-être, mais c’est comme ça que je veux mon jeedom. Si j’avais eu la possibilité d’intégrer un virtuel dans knx, cela aurait été beaucoup plus simple. (Cela est en fait possible en ne mettant aucune adresse dans une info knx mais dans ce cas il faut créer un scenario qui va alimenter l’info au changement de la véritable source de l’info, encore du calcul pour rien). S’il existait une fonction « surtuile » pour agréger plusieurs tuiles sou la forme d’une seule tuile, ce serait plus facile et plus efficace en terme de performance mais ça n’existe pas pour le moment.
Jeedom est une plateforme multiprotocole. Il faut l’assumer, tout comme il faut aussi accepter qu’un outil, ici le plugin virtuel, a été récupéré, utilisé et apprécié pour un usage autre que celui pour lequel vous l’avez créé.
Cet outil permet de casser les frontières et fusionner les protocoles sous une même tuile.
Enfin, puisque tu parles des widgets, depuis la V4 de jeedom, la personnalisation par un widget, c’est la plaie. Avant il y avait une bibliothèque de widgets, chacun pouvait y contribuer. Quand on voulait personnaliser son jeedom, on pouvait rechercher un widget. Aujourd’hui c’est terminé, plus de bibliothèque, il faut fouiller les forums, trouver des icônes pour créer son widget, bonjour la perte de temps.
Pour ce qui est du toggle, regarde comment vous avez créé « ajouter une zone » type « macro binaire » dans design. On définit une commande état binaire (il manquerait éventuellement une coche « inverser » au cas où), une ou des actions on, une ou des actions off. Il faudrait exactement la même chose mais sous la forme d’une commande. Dans la page « commandes » d’un équipement, à côté de « ajouter une commande », vous créez un bouton « ajouter une macro » avec pour types possibles « macro unitaire » ou « macro binaire » ou autres si vous avez d’autres idées. L’avantage d’une macro, elle ne se limite pas au protocole de la tuile dans lequel on est. Exemple : dans un équipement script, on ne peut pour l’instant pas créer de commande non script.
Si dans n’importe quel équipement, on peut ajouter une commande macro, on accède au multiprotocole dans une même tuile.
Sans aucun doute plus facile à dire qu’à faire…
Je comprends la demande effectivement les meta widget seraient top mais ca ferait un gros big bang dans jeedom, quand je vois les sujets ou quand on espace un peu les texte sur certain widget c’est la fin du monde alors la j’ose pas imaginer. Techniquement c’est faisable en pratique je suis désolé mais j’ai pas le courage d’affronter les utilisateurs et de defendre ce changement.
Peut-être qu’un système de referendum sur certains gros changements serait bien.
Tâter le terrain en lisant le site c’est bien, demander l’avis des utilisateurs sur des gros changements, ça permet de légitimer ou non une grosse évolution.
Quant à l’ajout d’une commande macro, sérieusement, j’ai vraiment du mal à voir qui aurait à redire à cela, tant que ça n’enlève rien à ceux qui préfèrent utiliser jeedom comme ils l’utilisent jusqu’à maintenant. Ca ouvrirait juste le champ des possibles.
Avant pour faire un trou, il y avait la perceuse à manivelle, un jour quelqu’un a mis un moteur à la place de la manivelle et tout le monde a ri…aujourd’hui, qui songerait à percer un trou avec une perceuse à manivelle?
S’il te plait, prend le temps d’en causer avec la team jeedom. S’ils fustigent ma proposition, et bien tant pis, je resterai à la manivelle (des virtuels pour fusionner des tuiles, des scenarios pour recopier des infos dans des tuiles).
Je ne t’embête pas plus.
Bonne journée et merci pour ton temps
Yaura forcement des effets de bords yen a toujours, je les vois pas maintenant mais une fois dans le code yaura des impacts (deja niveau perf c’est sur).
Pour le referundum c’est en place depuis janvier sur le github vous pouvez soumettre des issues, voter pour celle ci et tous les 4 à 6 mois on les reprends en réunion avec jeedom et celle avec le plus de vote sont ajouté a la roadmap.