(10/12/2021, 00:33:35)richardpub a écrit : Je suis avec attention ce post, car tout n'est pas très propre dans mon installation.
Puisque nous partageons des subtilités sur les tags, je voudrais juste vous indiquer qu'il existe une situation perturbante lorsqu'un objet est associé à deux adresses de groupe, donc à 2 fonctions différentes, et qu'on voudrait que les tags dépendent de l'adresse.
En effet, les tags correspondent un objet et non à l'association objet-adresse.
Je précise ma pensée :
Soit un objet A, d'un participant 1.1.1, associé à 2 adresses 1/1/1 et 1/1/2 et imaginons qu'on ait envie que ce soit ce participant 1.1.1 qui réponde aux requêtes READ adressées sur l'adresse 1/1/1 mais que ce soit un autre participant qui réponde à celles adressées à l'adresse 1/1/2.
Et ben on ne peut pas le faire, car les tags sont forcément communs aux deux adresses.
Ce qui est amusant, c'est que j'ai pris conscience de ce petit détail le jour où j'ai voulu mettre de l'ordre dans mes tags, en passant en revue toutes les adresses de groupe, une par une, dans le but de m'assurer que, pour chaque adresse susceptible de faite l'objet d'une requête READ¹, il y avait bien un seul objet avec le tag R et tous les autres avec le tag U. Or, à chaque fois que j'avais fini de passer toutes les adresses de groupe en revue, je m'apercevais qu'il en restait encore à mettre au propre. Et pour cause : comme j'agissais, non pas sur des associations adresse-objet, mais sur le objets eux-mêmes, et que j'avais des objets communs à plusieurs adresses, c'est moi-même qui remettait, par ex, le tag R à un objet que je venais de passer en U... et ainsi de suite.
¹ toutes ne le sont pas, notamment celles qui servent uniquement à envoyer des ordres instantanés : par exemple ordre de dimming (type 3.007), de step/stop (type 1.007). Aucun sens à vouloir mettre un R ou un U...