ETS et Flags

[Kevlille]

Hello la compagnie

Je cherche a résoudre des soucis de retour d'informations sur mon install KNX que j'ai depuis l'installation. Je sais d'ou vient le problème (les flags) mais je n'arrive pas à m'en sortir.

Ci-dessous l'exemple de la gestion de mon volet de la chmabre d'amis.

Mes GA:

* MVT:
   

* STOP:
   

* POSITION:
   

* POSITION STATE:
   

En l'état cela fonctionne mais les retours d'état des boutons ne fonctionnent pas bien (certains restent allumés d'autres nom) et le bien que je puisse piloter depuis le Z35, si je le fais depuis les boutons, le %age d'ouverture n'est pas mis à jour sur le Z35.

Ayant beaucoup joué avec les flags, je ne sais même plus comment ils étaient par defaut du coup je tourne en rond et je suis paumé...

Vous voyez des énormité dans mon paramètrage? des oublis?

A l'avance merci

[filou59]

Petit conseil :
Dans ETS tu peux réorganiser les colonnes moi j'aime bien avoir les AG avant les flags


Sinon c'est de la logique
Ton statut que doit envoyer ton actionneur, c'est de la lecture (Read = R), l'ecriture (W=Write) tu peux l'oublier. ensuite T=Transmission tout qui n'a pas de T ne serra jamais emis sur le bus.

[Kevlille]

Hello Filou

Pas compris ton conseil désolé

Ok donc je laisse les W par défaut sur les objets et les T si ils doivent être transmis sur le bus.

Du coup mon problème vient potentiellement de 2 cas possibles:
* les R mal paramétrés
* les objets mal positionnés sur les GA

Si je prends ma GA "MVT", le R est sur l'actionneur et les W/T sur les capteurs (poussoir et Z35) pour transmettre l'ordre sur le bus vers l'actionneur.

J'ai le bon raisonnement?

Du coup cette GA est correcte?

[Nitro24]

Les objets qui émettent des ordres sur une GA doivent avoir le flag T
Les objets qui reçoivent doivent avoir le flag W

Le flag R est réservé aux objet qui répondent sur la GA à une interrogation ( un seul R par GA).
Le flag U sert à mettre à jour un objet lorsqu'une réponse circule sur le bus.
Il faut mettre des U sur le retour d’état de tes poussoirs et Z35.

Dans ta GA "Position State"
112 Indication position actionneur: CR-T-
7, 21, 21, 254 : C-W-U

Regarde ce sujet ICI

Vérifie aussi comment ton actionneur envoi la mise à jour de la position.
Certains l envoie durant le déplacement, d'autres à la fin du mouvement.

[Kevlille]

Hello Nitro

Merci beaucoup. Je pense que mon soucis viens des T mis un peu partout..

Je fais des modif selon ton exemple et je teste. Merci aussi pour le lien

[ouily]

Bonjour,

Merci Nitro pour ce résumé concis.

Petite question parallèle, quelqu'un peut il m'expliquer la colonne Envoi avec le S.

Merci

[Nitro24]

Bonjour,

Merci Nitro pour ce résumé concis.

Petite question parallèle, quelqu'un peut il m'expliquer la colonne Envoi avec le S.

Merci

Bonjour,

Le S c’est Send : envoyer
Un objet ne peut émettre que sur une seule GA mais peut écouter plusieurs GA.
Lorsqu'on associe l'objet avec une GA, le S se positionne.
Si l objet est associé à plusieurs GA, il ne pourra émettre que dans la première (S ... C-WTU) et recevoir dans les autres (- ... C-WTU) par exemple.

[Nitro24]

Un exemple simple avec le flag S : la commande groupée de plusieurs points lumineux

Deux points lumineux commandés par 3 boutons: 1 pour chaque point et 1 commun au deux:
(je ne traite pas les retours d'état pour simplifier)

1/0/1 GA 1 commande lumière 1
Poussoir ON/OFF n°1          S ... C - - T - 
TOR n°1                                  S ... C R W - -

1/0/2 GA 2 commande lumière 2
Poussoir ON/OFF n°2          S ... C - - T - 
TOR n°2                                  S ... C R W - -

1/0/3 GA 3 commande lumières 1 & 2
Poussoir ON/OFF n°3          S ... C - - T - 
TOR n°1                                  -  ... C R W - -
TOR n°2                                  -  ... C R W - -

Poussoir ON/OFF n°1     1/0/1     C - - T -
Poussoir ON/OFF n°2     1/0/2     C - - T -
Poussoir ON/OFF n°3     1/0/3     C - - T -

TOR n° 1                1/0/1; 1/0/3     C R W - -
TOR n° 2                1/0/2; 1/0/3     C R W - -

Le positionnement du flag S est automatique sur la première GA associée à l'objet.

[Kevlille]

Hello Nitro

Merci beaucoup. Dans ton exemple tu n'as pas du tout indiqué de flag U. On l'utilise uniquement pour les retours d'état afin que tous les capteurs récupère le état final?

Sais-tu ou on peut trouver des exemples concret de gestion des flags sur ETS? Car j'ai regardé des vidéos (anglais) ou des pdf de synthèse mais cela reste très théorique... rien de tel que la pratique pour assimiler les différents cas de figure.

[Nitro24]

Le flag U est utilisé pour mettre à jour un objet en cas de réponse sur une GA à une question posée par un autre objet .

Exemple:un capteur de température et 3 affichages:

GA
objet thermomètre        S ... C R - T -
objet afficheur 1            S ... C - W - U
objet afficheur 2            S ... C - W - U
objet afficheur 3            S ... C - W - U

L'objet thermomètre a le flag T pour transmetre la température et le flag R pour répondre aux interrogations du bus.
les objets afficheurs ont le flag W pour autoriser l'écriture de la température sur l'objet et le flag U pour mettre à jour l'objet.

Cas 1: le capteur transmets la température sur le bus avec le flag T, tous les objets avec le flag W prennent en compte la valeur.
Cas 2: l'afficheur n°2 interroge la température sur le bus. l'objet thermomètre avec le flag R répond. les objets afficheur avec le flag U se mettent à jour.

Il est important de n'avoir qu'un objet avec le flag R dans une GA, sinon tous les objets avec le flag R répondent chacuns leur tour et c'est le dernier qui a parlé qui a raison, si un objet répond 5°C et l'autre 7°C ...  

Pour savoir comment positionner les flags R, W, U il faut s'imaginer etre du coté du bus:
Tu veux ecrire dans un objet alors flag W (Write)
Tu veux lire un objet alors flag R (Read)
Tu veux que l'objet se mette à jour lorsqu'une valeur change alors flag U (Update)

un objet doit transmettre une information sur le bus : flag T

A part les documents que je t'ai conseillé ici, je n'ai rien d'autre. Le reste c'est souvent du bon sens. il faut prendre le temps de bien visualiser les GA pour déterminer qui détient l'information et dans quel sens elle doit circuler sur le bus.

[ouily]

Cette démonstration me perd dans le mélange des flags RW dans le même objet . Je ne comprend pas bien comment fonctionne le R dans ton exemple sur les éclairages. Dis moi si je me trompe mais les objets TOR de la GA 1/0/3 prennent l'info avec le W sans agir car pas de S et se la transmette eux mêmes dans la GA 1/0/1 et 1/0/2 pour agir car ils ont le S.

J'avoue également avoir du mal à faire la différence entre R / T , et W / U, car ce qui est lu transmet et ce qui est écrit à besoin d'être mis à jour. Dans quelle circonstance un R n'a pas de T et un W n'a pas de U ?

[Nitro24]

Pour résumer:

S: l’objet peut émettre et recevoir, sans S il ne peut que recevoir.
T: l’objet transmet une info de sa propre initiative.
R: l’objet répond à la question d’un autre objet.
W: l’objet se met à jour sur une donnée transmise par un objet avec T
U: l’objet se met à jour sur une réponse d’un objet avec R

Un objet peut avoir R et W en même temps, exemple une sortie TOR: W pour accepter la commande d'un bouton et R pour répondre à la question sur son état ( mais pas de T car il ne change pas d'état tout seul )

[ouily]

Merci Nitro, il faut que murisse le truc.

[richardpub]

Je suis avec attention ce post, car tout n'est pas très propre dans mon installation.

[Dibou]

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...

[Nitro24]

Bonjour Dibou,

De mémoire, si un objet est dans deux GA 1/1/1 et 1/1/2, dans la première GA le flag S est présent mais pas dans la deuxième. Donc ton objet ne pourra répondre que dans la GA 1/1/1 où le S est positioné.
Si dans une GA il y a plusieurs objets avec R mais qu'un seul a le tag S ( cas des commandes groupées) il sera le seul à répondre à la requête read.
A vérifier quand même, je n’ai pas ETS sous la main pour faire l’essai.

[ouily]

Bonjour,

En suivant toutes ces précieuses informations, j'en déduis l'importance cruciale des flags.

J'ai un exemple à vous soumettre et je ne comprend pas pourquoi il ne marche pas en test avec un bonton poussoir et 2 TOR

1/0/1 GA 1 commande lumière 1
Poussoir ON/OFF S ... C - W T -
TOR n°1 S ... C - W - -

1/0/2 GA 2 commande lumière 2
Poussoir ON/OFF - ... C - W T -
TOR n°2 S ... C - W - -

Quelqu'un peut il résoudre ce petit problème?

[Nitro24]

Bonsoir,

Un même objet ne peut pas émettre une commande dans deux GA.
Regarde ton bouton dans la GA 1/0/2, il n'a pas de S !

Essaie ça:

1/0/1 GA commande lumière 1 & 2
Poussoir ON/OFF S ... C - W T -
TOR n°1 S ... C - W - -
TOR n°2 S ... C - W - -

[ouily]

Bonsoir,

Un même objet ne peut pas émettre une commande dans deux GA.
Regarde ton bouton dans la GA 1/0/2, il n'a pas de S !

Essaie ça:

1/0/1 GA commande lumière 1 & 2
Poussoir ON/OFF S ... C - W T -
TOR n°1 S ... C - W - -
TOR n°2 S ... C - W - -

Salut Nitro.

Effectivement pas de S donc ça ne marche pas. J'essayai juste de trouver une solution pour émettre sur plusieurs GA.

A quoi sert alors le W du poussoir. J'ai des participants qui me propose les Flags - W T - en émission.

Et cette solution:

1/0/1 GA 1 commande lumière 1
Poussoir ON/OFF S ... C R - T -
TOR n°1 S ... C - W - U

1/0/2 GA 2 commande lumière 2
Poussoir ON/OFF - ... C R - T -
TOR n°2 S ... C - W - U

[Dibou]

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¹)
  

Adresses physique

• 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)
    

Actions réalisées :

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)
  

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)
  

Le flag T de l'objet 1 de 1.1.1 est actif, donc 1.1.1 envoie un télégramme ON à l'adresse de groupe 1/1/1.
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)
  

Comme l'objet 1 du 1.1.3 est passé à ON, la lampe s'éclaire. Alléluia !

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)
  

Comme le flag T de l'objet 1 de 1.1.2 est actif, 1.1.2 envoie un télégramme OFF à l'adresse de groupe 1/1/1.
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)
  

La lampe s'éteint, c'est formidable...  
... 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)
  

Le flag T de l'objet 1 de 1.1.1 est actif, donc 1.1.1 envoie un télégramme ON à l'adresse de groupe 1/1/1.
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)
  

Comme l'objet 1 du 1.1.3 est passé à ON, la lampe s'éclaire. Jusque là tout va bien.

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)
  

Comme le flag T de l'objet 1 de 1.1.2 est actif, donc 1.1.2 envoie un télégramme ON à l'adresse de groupe 1/1/1
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)
  

Et donc la lampe reste allumée ! Argh.
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)
  

Comme cet objet 1 du 1.1.2 a un flag T, il en voie un télégramme avec sa valeur (OFF) à l'adresse de groupe 1/1/1.
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)
  

Donc la lampe s'éteint. Ouf ! Mais vous noterez que 1.1.1 ne le "sait" pas... et que le même double-appui sera nécessaire si on tente à nouveau d'appuyer sur 1.1.1 pour éclairer (puisque l'objet 1 du 1.1.1 est resté à ON).

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)
  

Nota :

• 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.

[ouily]

Merci Didou, L'explication est plus que limpide.

[richardpub]

Très didactique
Vraiment bien comme explication

[Polo46]

Un exemple simple avec le flag S : la commande groupée de plusieurs points lumineux

Deux points lumineux commandés par 3 boutons: 1 pour chaque point et 1 commun au deux:
(je ne traite pas les retours d'état pour simplifier)

1/0/1 GA 1 commande lumière 1
Poussoir ON/OFF n°1          S ... C - - T - 
TOR n°1                                  S ... C R W - -

1/0/2 GA 2 commande lumière 2
Poussoir ON/OFF n°2          S ... C - - T - 
TOR n°2                                  S ... C R W - -

1/0/3 GA 3 commande lumières 1 & 2
Poussoir ON/OFF n°3          S ... C - - T - 
TOR n°1                                  -  ... C R W - -
TOR n°2                                  -  ... C R W - -

Poussoir ON/OFF n°1     1/0/1     C - - T -
Poussoir ON/OFF n°2     1/0/2     C - - T -
Poussoir ON/OFF n°3     1/0/3     C - - T -

TOR n° 1                1/0/1; 1/0/3     C R W - -
TOR n° 2                1/0/2; 1/0/3     C R W - -

Le positionnement du flag S est automatique sur la première GA associée à l'objet.

Salut et merci pour l'info car je n'y avais jamais prêté une attention particulière. Dont acte.

[thomas89]

bonjours a tous après avoir lu toute la conversation je me pose encore des question
quel est la solution pour émettre sur plusieurs GA sans avoir le problème du flag S
ou ils est peut être pas indispensable dans certain cas 

merci

[Dibou]

quel est la solution pour émettre sur plusieurs GA sans avoir le problème du flag S
ou ils est peut être pas indispensable dans certain cas 

Il me semble que c'est un peu contraire à la logique générale du KNX : si on a envie qu'une action agisse sur deux adresses de groupe, c'est probablement que ces deux adresses de groupe correspondent à la même fonction, et devraient être fusionnées.
Sans rentrer dans des considérations trop philosophiques, je me suis pour ma part fait à l'idée qu'une adresse de groupe représente une fonction et que qu'une telle fonction représente plus une action (ou un ensemble d'actions dont on attend les même conséquences) qu'un résultat.
Une fonction serait par exemple Appuyer sur un bouton poussoir, ou même Vouloir allumer la lumière (notamment en appuyant sur un bouton, mais pas que), et non pas Allumer la lumière. Mais là je m'égare un peu...

Quoi qu'il en soit, pour envoyer un télégramme à plusieurs adresses à la fois, je ne vois pas trop d'autres solutions que : disposer d'un participant physique qui le permette explicitement (il me semble en avoir vu avec deux objets en sortie, commandés par une seule action), ou utiliser un module logique programmé pour retransmettre l'état d'un objet A sur un objet B.
Ce qui est certain, c'est qu'il faut forcément deux objets différents pour envoyer une même information à 2 adresses de groupes différentes (Ces deux objets peuvent être sur le même participant ou sur deux participants différents...)