Merten: çà commence à bien faire...

[keldo]

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).
- En général, tous les objets d'une supervision.


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é à
l'adresse de groupe de destination du télégramme) en envoyant une
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".