(20/12/2021, 22:41:48)ouily a écrit : A quoi sert alors le W du poussoir. J'ai des participants qui me propose les Flags - W T - en émission.
Bonjour
Le flag W sur un émetteur sert à régler un problème, récurrent en KNX, que je qualifierai de "synchronisation de l'état des émetteurs".
Il s'agit de s'assurer que plusieurs émetteurs partageant la même adresse de groupe pour agir sur un même récepteur se synchronisent.
Explications :
Description du banc d'essai :
Participant n° 1
- Bouton poussoir (un unique bouton pour allumer/éteindre donc paramétré en "toggle").
- Adresse physique : 1.1.1
- Objet 1 : émission d'un ordre marche/arrêt (type 1.001 Switch), associé à l'adresse de groupe 1/1/1, avec les flags CTWU (et S¹)
Participant n° 2
- Bouton poussoir (un unique bouton pour allumer/éteindre donc paramétré en "toggle").
- Adresse physique : 1.1.2
- Objet 1 : émission d'un ordre marche/arrêt (type 1.001 Switch), associé à l'adresse de groupe 1/1/1, avec les flags CTWU (et S¹)
Participant n° 3
- Un actionneur tout ou rien agissant sur une lampe.
- Adresse physique : 1.1.3
- Objet 1 : réception d'un ordre marche/arrêt (type 1.001 Switch), associé à l'adresse de groupe 1/1/1, avec les flags CRW (et S¹)
- 1/1/1 type type 1.001 Switch, associée à
- Objet 1 du 1.1.1 (flags CTWU S)
- Objet 1 du 1.1.2 (flags CTWU S)
- Objet 1 du 1.1.3 (flags CRW S)
Au départ, admettons que tout est synchronisé :
- l'objet 1 du 1.1.1 vaut 0 (OFF)
- l'objet 1 du 1.1.2 vaut 0 (OFF)
- l'objet 1 du 1.1.3 vaut 0 (OFF)
Comme il est en "toggle", le fait d'appuyer inverse l'état de l'objet, donc son objet 1 passe à ON.
- l'objet 1 du 1.1.1 vaut 1 (ON)
- l'objet 1 du 1.1.2 vaut 0 (OFF)
- l'objet 1 du 1.1.3 vaut 0 (OFF)
L'objet 1 de chacun des autres participants a son flag W actif, donc l'objet 1 de chaque participant est mis à jour par la réception du télégramme 1/1/1. Et il passent tous à ON.
- l'objet 1 du 1.1.1 vaut 1 (ON)
- l'objet 1 du 1.1.2 vaut 1 (ON)
- l'objet 1 du 1.1.3 vaut 1 (ON)
Maintenant si on appuie sur 1.1.2.
Comme il est aussi en toggle, son objet 1 va passer à 0-OFF.
- l'objet 1 du 1.1.1 vaut 1 (ON)
- l'objet 1 du 1.1.2 vaut 0 (OFF)
- l'objet 1 du 1.1.3 vaut 1 (ON)
Et rebelote, tout le monde la reçoit
- l'objet 1 du 1.1.1 vaut 0 (OFF)
- l'objet 1 du 1.1.2 vaut 0 (OFF)
- l'objet 1 du 1.1.3 vaut 0 (OFF)
... et tous les participants "le savent".
Imaginons maintenant qu'on n'ait pas mis de W sur l'objet 1 des participant 1.1.1 et 1.1.2 (uniquement sur le 1.1.3). Voilà ce qui pourrait se passer :
J'appuie sur le 1.1.1.
Comme il est en "toggle", le fait d'appuyer inverse l'état de l'objet, donc son objet 1 passe à ON.
- l'objet 1 du 1.1.1 vaut 1 (ON)
- l'objet 1 du 1.1.2 vaut 0 (OFF)
- l'objet 1 du 1.1.3 vaut 0 (OFF)
L'objet 1 de du 1.1.3 a son flag W actif, donc est mis à jour par la réception du télégramme 1/1/1. Il passe à 1-ON. Par contre, l'objet 1 du 1.1.2, n'ayant pas de flag W, il n'est pas modifié et reste à 0-OFF (c'est là que tout se joue !) :
- l'objet 1 du 1.1.1 vaut 1 (ON)
- l'objet 1 du 1.1.2 vaut 0 (OFF)
- l'objet 1 du 1.1.3 vaut 1 (ON)
Mais regardons ce qui se passe si on appuie maintenant sur 1.1.2 (a priori pour éteindre la lampe).
Comme 1.1.2 est aussi en toggle, son objet 1 va s'inverser et passer à 1-ON.
- l'objet 1 du 1.1.1 vaut 1 (ON)
- l'objet 1 du 1.1.2 vaut 1 (ON)
- l'objet 1 du 1.1.3 vaut 1 (ON)
Du fait des paramétrages de flag W, seul l'objet 1 du 1.1.3 la reçoit, mais ça ne change rien car il était déjà ON
- l'objet 1 du 1.1.1 vaut 1 (ON)
- l'objet 1 du 1.1.2 vaut 1 (ON)
- l'objet 1 du 1.1.3 vaut 1 (ON)
Il faut rappuyer une 2e fois sur 1.1.2 pour l'éteindre.
Je détaille.
Comme 1.1.2 est paramétré en toggle, son objet 1 s'inverse à nouveau et passe à 0-OFF (enfin...) :
- l'objet 1 du 1.1.1 vaut 1 (ON)
- l'objet 1 du 1.1.2 vaut 0 (OFF)
- l'objet 1 du 1.1.3 vaut 1 (ON)
Seul l'objet 1 du 1.1.3 la reçoit (je rappelle que c'est le seul à avoir un W parmi tous les abonnés à l'adresse 1/1/1)
- l'objet 1 du 1.1.1 vaut 1 (ON)
- l'objet 1 du 1.1.2 vaut 0 (OFF)
- l'objet 1 du 1.1.3 vaut 0 (OFF)
Je pense que tu comprendras maintenant pourquoi je parle de "synchroniser les émetteurs" : du fait du W, les objets 1 des participants 1.1.1 et 1.1.2 sont sûr de rester synchronisés.
À retenir :
- Les objets sont des "cases mémoires", modifiées soit par le participant lui-même, soit par réception d'un télégramme (si le flag W est actif !)
- Si le flag T d'un objet est actif, alors la modification de la valeur de cet objet par le participant lui-même, déclenche l'envoi d'un télégramme à l'adresse de groupe associée à l'objet (ou, s'il y en a plusieurs, à la première des adresses associées affichée dans ETS, c'est à dire celle avec le flag S. Voir note 1)
- Dans mon contre-exemple ci-dessus, c'est le fait de passer d'un émetteur à l'autre qui pose problème. J'ai commencé par allumer avec 1.1.1 et après j'ai voulu éteindre avec 1.1.2. Si j'avais voulu éteindre avec 1.1.1, ça se serait bien passé, ce qui conduit les débutant à souvent penser à ce que ces doubles appuis sont un truc aléatoire... en fait, c'est juste le fait de ne pas toujours commander depuis le même endroit qui les fait apparaître.
- Je n'ai pas utilisé d'objets et d'adresse ce groupe de retour d'état dans mon exemple. Ici ce n'est pas utile. Les retours d'état ne seraient ici nécessaire que si 1.1.3 pouvait être allumé autrement que via l'adresse de groupe 1.1.1 (télégramme de scène, variation relative, etc. sur une autres adresse de groupe et d'autres objets...)
- Concernant le choix des tags U et R dans mon exemple : j'ai choisi de mettre un flag R sur 1.1.3 car c'est lui qui me semble apporter la valeur la plus pertinente à un participant tiers (typiquement une visu, ou ETS lui-même) qui voudrait interroger l'adresse 1/1/1... Puis, j'ai mis un U sur les 2 autres, de façon que si jamais, pour une raison quelconque (type coupure de courant ou bidouillage quelconque) il y avait eu une désynchronisation, la réponse à cette interrogation de l'adresse 1/1/1, resynchroniserait tout le monde.²
Mais en réalité, ici, comme les trois participants sont synchronisés, le choix de celui qui aura le tag U importe peu : n'importe lequel des 3 participants apportera la bonne valeur. Si j'ai choisi ici le participant 1.1.3, c'est à dire l'actionneur, c'est plus par anticipation d'évolutions futures
¹ le flag S, ici on s'en fout car il n'y a qu'une adresse de groupe par objet, donc c'est forcément à celle-ci que le participant transmet les télégrammes. Mais je rappelle que S n'est pas vraiment un flag comme les autres... C'est juste que quand on a plusieurs adresses de groupe associées à un même objet et le tag T (transmettre) activé sur cet objet, il faut choisir à laquelle des adresses le participant doit transmettre la valeur de l'objet.
² Le principe général, pour une adresse de groupe donnée, est donc de mettre à R un seul des objets auxquels cette adresse est liée et U à tous les autres. Maintenant, les plus aguerris d'entre nous se sont certainement déjà aperçus que ça n'est pas toujours évident lorsqu'un objet est associé à plusieurs adresses de groupe. En effet, ce n'est pas l'association [objet-adresse] qui se voit affecté un tag, mais l'objet, quelle que soit l'adresse de groupe. Parfois, on aimerait bien qu'un objet associé à deux adresses de groupe se comporte comme un U pour l'une et un R pour l'autre, et bien ce n'est pas possible : il sera soit U pour les 2, soit R pour les 2.