Flags KNX
auredor
J'avance tout doucement dans mon installation domotique et j'ai
programmé les participants de manières assez "simplistes" sans
vraiment regarder aux flags (je ne parle pas du SEND mode). J'aimerais
aller un peu plus loin et comprendre les subtilité de la programmation
KNX.
Y aurait-il quelqu'un qui pourrait m'expliquer l'intérêt de ces flags
et leur utilisation via des exemples concrets. J'ai bien trouvé de la
doc à ce propos sur Internet ou sur le files server de domotique-EIB
mais je ne trouve rien qui me donne vraiment une compréhension
APPLIQUEE de ces flags.
Merci.
fabrice
malheureusement je n'apporte aucune réponse mais se sujet m'intéresse
aussi et je suis d'accord avec toi j'ai beau lire pas mal de doc la
dessus cela ne m'éclaire pas vraiment
quel flag mettre pour les objet status par exemple :) ?
ses flags sont t-il vraiment important, je veux dire doit on "jouer a
les modifié" ou les paramètres par défaut sont ils suffisant ?
keldo
Par exemple : http://groups.google.com/group/domotique-eib/browse_thread/thread/2c7e9821af522b9b/14bea6b280b113d4
keldo
Je trouve l'explication du cours KNX un peu "légère", je vais donc compléter un petit peu.
Peut-être serait-il intéressant de copier cette info dans le WiKi, je suis sur que les flags sont un petit peu nébuleux pour beaucoup de
monde ...
(Je n'ai aucune idée de comment ajouter un truc dans le WiKi, par contre ...)
-------------------------------------
Flag Communication
- Actif : Cet objet de communication peut interagir avec le bus (lire,
écrire, etc ...), si un télégramme du bus correspond à cet objet (=
l'objet est lié à l'adresse de groupe de destination du télégramme),
le participant répondra sur le bus avec ACK, NACK ou BUSY selon ce
qu'il convient.
- Inactif : Si un télégramme du bus correspond à cet objet (= l'objet
est lié à l'adresse de groupe de destination du télégramme), le
participant répondra sur le bus avec ACK, NACK ou BUSY selon ce qu'il
convient, MAIS la valeur de l'objet n'est pas modifiée ni transmise,
quoi qu'il arrive.
Ce flag est quasiment toujours "Actif", sinon l'objet ne sert à
rien ...
Ce flag est néanmoins utile durant la phase d'installation /
configuration d'une installation, quand on veut préparer la config de
certain participants mais qu'ils ne doivent pas encore interagir avec
le bus ; ce flag peut aussi être utile pour désactiver certain objets
sans modifier toute leur config, dans le cadre d'une recherche
d'erreur par exemple.
-------------------------------------
Flag Lecture / Read
- Actif : Si le participant voit sur le bus un télégramme de type
"Lecture de la valeur" qui correspond à cet objet (= l'objet est lié à
l'adresse de groupe de destination du télégramme) alors le participant
va répondre en envoyant sur le bus la valeur actuelle de l'objet.
- Inactif : Le participant ne réagira à aucun télégramme de type
"Lecture de la valeur" qui correspond à cet objet.
Pour chaque adresse de groupe, au maximum UN seul objet doit avoir son
flag "Lecture/Read" actif, tous les autre objet de cette même adresse
de groupe doivent être inactifs, sinon une interrogation de la valeur
donnerait plus d'une réponse et on pourrait même obtenir des réponses
discordantes.
Exemples d'objets pour lesquels le flag "Lecture/Read" est
généralement actif :
- L'objet de commande d'une sortie Tout-ou-Rien (sur un bloc 4
sorties, par exemple).
- L'éventuel objet de "feed-back" de la ligne précédente.
- Tous les objets de "feed-back" en général.
- Les objets représentant la valeur mesurée par un capteur (luminosité
actuelle, température réelle mesurée, état (ouvert/fermé) d'un capteur
du style reed-relais dans une porte ou une fenêtre, ...)
Exemples d'objets pour lesquels le flag "Lecture/Read" est
généralement INACTIF :
- L'objet (ON/OFF) d'un bouton poussoir.
En général, la valeur stockée ou utilisée par les objets faisant
partie d'une même adresse de groupe représente une information
correspondant à quelque chose de réel / physique / mesurable dans
votre maison.
Pour déterminer lequel de tous les objets faisant partie de la même
adresse de groupe doit être celui qui aura son flag "Lecture/Read"
actif, il faut vous demander lequel de tous ces objets a le plus de
chance d'être en phase avec la réalité.
Cas simple : 3 boutons poussoirs et un acteur qui allume ou éteint un
lampe, la valeur de l'objet de l'acteur a de bien plus grandes chances
de réellement représenter l'état (allumé ou éteint) de la lampe,
surtout après une panne de courent ou un problème sur le bus ...
-------------------------------------
Flag Ecriture / Write
- Actif : La valeur de cet objet sera modifiée si un participant
envoie sur le bus un télégramme de type "Ecriture de la valeur" qui
correspond à cet objet (= l'objet est lié à l'adresse de groupe de
destination du télégramme).
- Inactif : La valeur de cet objet NE sera PAS modifiée, même si un
participant envoie sur le bus un télégramme de type "Ecriture de la
valeur" qui correspond à cet objet.
Pour une valeur d'adresse de groupe, plusieurs objets peuvent avoir
leur flag "Ecriture/Write" actif.
N'importe quel objet dont la valeur doit pouvoir être modifiée par un
autre doit avoir sun flag "Ecriture/Write" actif.
Exemples d'objets pour lesquels le flag "Ecriture/Write" est
généralement actif :
- L'objet de commande d'une sortie Tout-ou-Rien (sur un bloc 4
sorties, par exemple).
- L'objet (ON/OFF) d'un bouton poussoir.
- En général, tous les objets d'une supervision.
Exemples d'objets pour lesquels le flag "Ecriture/Write" est
généralement INACTIF :
- Tous les objets de "feed-back" (d'acteurs) en général.
- Les objets représentant la valeur mesurée par un capteur (luminosité
actuelle, température réelle mesurée, état (ouvert/fermé) d'un capteur
du style reed-relais dans une porte ou une fenêtre, ...).
Flag Transmission/Transmit
- Actif : Si pour une raison quelconque (sauf la réception d'un
télégramme « Ecriture/Write » vers cet objet) la valeur de cet objet
venait à être modifiée, le participant va envoyer sur le bus un
télégramme de type "Ecriture de la valeur" contenant la nouvelle
valeur de l'objet, vers la première adresse de groupe liée à cet
objet.
- Inactif : Le participant n'envoie aucun télégramme sur le bus quand
la valeur de l'objet est modifiée.
Exemples d'objets pour lesquels le flag "Transmission/Transmit" est
généralement actif.
Ce flag est généralement actif pour tous les objets ayant une
information à envoyer sur le bus, c-à-d :
- Tous les capteurs de grandeurs physiques (température, luminosité,
voltage, wattage, courent, humidité, ...) doivent envoyer sur le bus un
télégramme chaque fois que la valeur qu'ils mesurent s'écarte de la
mesure précédente.
- L'objet ON/OFF des boutons poussoirs (quand on pousse dessus, ils
doivent bien envoyer l'info sur le bus ...).
- Tous les objets de "feed-back" (d'acteurs) en général.
Exemples d'objets pour lesquels le flag "Transmission/Transmit" est
généralement inactif.
- L'objet de commande d'une sortie Tout-ou-Rien (sur un bloc 4
sorties, par exemple).
Pour rappel : Un objet peut être lié à plusieurs adresses de groupe,
il « recevra » les télégrammes destinés à ces diverses adresses de
groupes MAIS il ne pourra envoyer sa valeur (suite à un flag «
transmit » actif) que vers UNE SEULE adresse de groupe (la première de
la liste.
-------------------------------------
Flag Mise-à-jour/Update
- Actif : Si un autre participant répond à un télégramme de type
"Lecture de la valeur" qui correspond à cet objet (= l'objet est lié à
valeur différente de celle actuellement stockée dans l'objet, la
valeur de l'objet est remplacée par celle lue sur le bus dans le
télégramme de réponse. (= Les télégrammes de réponse de valeur sont
interprétés comme instruction d'écriture).
- Inactif : Le participant ne modifie pas la valeur de son objet tant
qu'il ne reçoit pas un télégramme "Ecriture/Write".
En théorie, ce flag ne semble pas très utile, mais en pratique, si il
est actif il permet de "re-synchroniser" plus rapidement tous les
participants d'un bus quand certains ont été redémarrés ou qu'une
coupure est survenue sur le bus (arrêt temporaire d'une liaison entre
2 étages ou 2 bâtiments par exemple), dans ce cas, il suffit de lancer
un script qui lit touts les groupes et hop tout est resynchronisé.
Exemples d'objets pour lesquels le flag "Mise-à-jour/Update" est
généralement actif :
- Tous les objets qui ont le flag "Lecture/Read" inactif.
- En général, tous les objets d'une supervision.
Exemples d'objets pour lesquels le flag "Mise-à-jour/Update" est
généralement inactif :
- Tous les objets qui ont le flag "Lecture/Read" actif.
-------------------------------------
Il existe encore un flag supplémentaire, il n'est pas présent dans
beaucoup de participants aujourd'hui mais devrait tout doucement se
généraliser je pense, au moins sur les modules de supervision.
Flag Read-on-Init
- Actif : Au démarrage du participant, un télégramme de type "Lecture
de la valeur" qui correspond à cet objet sera envoyé sur le bus de
donner à cet objet une valeur initial correcte.
- Inactif : Au démarrage du participant, cet objet recevra une valeur
par défaut.
Exemples d'objets pour lesquels le flag "Read-on-Init" est
généralement actif :
- Tous les objets qui ont le flag "Lecture/Read" inactif.
- En général, tous les objets d'une supervision.
Exemples d'objets pour lesquels le flag "Read-on-Init" est
généralement inactif :
- Tous les objets qui ont le flag "Lecture/Read" actif.
-------------------------------------
Etude d'un cas particulier : L'objet "Décalage de la consigne de base"
sur un thermostat de type Gira SmartSensor.
Sur cet objet, faut-il activer les flags suivants ?
- COMMUNICATION : oui, c'est évident si on veut que cela marche.
- READ : oui, car le lieu principal de stockage de l'information est
le thermostat lui-même, donc le SmartSensor.
- WRITE : oui, car le but est de pouvoir modifier le décalage à partir
du bus (un Gira HomeServer 3 par ex.)
- TRANSMIT : non, cet objet ne se modifie pas "de lui-même".
Attention, pour "transmit", ce serait le contraire si on utilisait un
Theben RAM713 qui possède lui une molette de décalage manuel.
- UPDATE : non, "read" est actif, donc cet objet est la source
d'information la plus fiable.
(Car c'est le SmartSensor qui contient la valeur par défaut à utiliser
lors d'un reset général du bus).
- READ-ON-INIT : non, pour les mêmes raisons que "Update".
keldo
L'info est là mais ... je suis fatigué et un peu fade ce soir . ;-)
marc.assin
> (Je n'ai aucune idée de comment ajouter un truc dans le WiKi, par contre
https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxkb21vdGlxdWVlaWJ8Z3g6MzQ5OTQ2YTk2MGU4YzRlZA
auredor
Je pense que maintenant il faut un peu jouer avec pour mieux saisir
toutes les subtilités...
On 23 mai, 15:28, "marc.assin" <raym...@warichet.com> wrote:
> On 23 mai, 17:43, keldo <nos...@keldermans.eu> wrote:> (Je n'ai aucune idée de comment ajouter un truc dans le WiKi, par contre
>
keldo
> toutes les subtilités...
ouvert, etc.) qui circulent sur le bus sont stockées dans les
différents OBJETS DE COMMUNICATION des différents participants , et
non dans les ADRESSES DE GROUPE !
L'erreur classique est, je pense, d'associer mentalement valeur/
information = adresse de groupe.
Les GA (adresses de groupes) ne sont que des canaux de communication
mais elles ne gardent aucune valeur ni information en mémoire.
D'un autre coté, plusieurs CO (objets de communication), bien que
reliés à une même GA, peuvent parfaitement, à un moment donné, garder
en mémoire des valeurs différentes de la même information ... (tout
comme le chat de Schrödinger pouvait être à la fois mort et vivant en
même temps ... mais là, je m'écarte du sujet).
Et, tout l'art de synchroniser correctement ces valeurs, c'est
précisément de bien configurer les flags de ces différents CO.
Joffrey
Il est vrai que la notion de flag était assez nébuleuse pour moi, et
tu m'éclaires copieusement :)
Je comprend maintenant pourquoi j'ai un BSO qui se baisse quand je
lance un "read" sur son indication d'état (j'ai probablement activé le
mauvais flag sur un participant de la GA).
Me reste une petite question :
Il m'est arrivé de changer des flags sous ETS4 justement pour voir
leur utilité.
Par contre, ETS4 ne demande pas de recharger les participants ensuite
(on a tjs les 5 coches vertes indiquant qu'il est à jour).
Je doute également qu'il le fasse à la volée, puisqu'un moniteur de
bus en parallèle ne voit rien passer de particulier.
Comment donc l'info peut arriver jusqu'au device ??
Il faut forcer un téléchargement ensuite ?
Joffrey
>
> read more »
keldo
> Il m'est arrivé de changer des flags sous ETS4 justement pour voir
> leur utilité.
> Par contre, ETS4 ne demande pas de recharger les participants ensuite
> (on a tjs les 5 coches vertes indiquant qu'il est à jour).
> Je doute également qu'il le fasse à la volée, puisqu'un moniteur de
> bus en parallèle ne voit rien passer de particulier.
participant, il faut obligatoirement faire une re-programmation
(partielle) des participants concernés pour activer une modification
de flag.
Je n'ai pas encore utilisé ETS4 mais ce que tu décris ressemble
furieusement à un bug.
> Comment donc l'info peut arriver jusqu'au device ??
> Il faut forcer un téléchargement ensuite ?
répondre.
C'est plutôt une question à envoyer aux gens du support ETS4 chez
"konnex.org".
Joffrey
coche "groupe" se désactive, indiquant qu'il faut effectivement faire
un téléchargement (complet ou partiel)
J'ai rien dit ! :)
seb@leon
Détourner les flage write et read peut avoir des conséquences de réaction non voulue, donc à manipuler si besoin.