+- Forum KNX francophone / English KNX forum (https://www.knx-fr.com)
+-- Forum : Français (https://www.knx-fr.com/forumdisplay.php?fid=3)
+--- Forum : Archives eib-domotique (https://www.knx-fr.com/forumdisplay.php?fid=8)
+--- Sujet : Merten: çà commence à bien faire... (/showthread.php?tid=1585)
Merten: çà commence à bien faire... - keldo - 24/10/2007
On 23 oct, 08:06, mickg <mickael.gaut...@wanadoo.fr> wrote:
> Non non, il n'y a pas de conneries ;-) , pour conforter tes propos :
>
> Extrait du cours KNX :
> Communication : (actif) la liaison entre les objets de communication
> et le bus est normale
> (inactif) les télégrammes sont acquittés,
> mais l'objet n'est pas modifié
>
> Lecture : permet de lire la valeur de l'objet via le bus
>
> Ecriture : permet de modifier la valeur de l'objet via le bus
>
> Transmission : (actif) si (pour un capteur) la valeur de l'objet est
> modifiée, un télégramme correspondant est envoyé
> (inactif) l'objet n'émet un télégramme de
> réponse qu'en cas de demande de lecture (si read actif)
>
> Actualisation (Mise à jour) : Les télégrammes de réponse de valeur
> sont interprétés comme instruction d'écriture : la valeur de l'objet
> est actualisée
>
> Pour revenir au problème de Marc assin, personnellement quand il y a
> un objet "Etat", c'est celui que j'utilise pour mettre à jour un objet
> tiers.
>
> @+
>
> On 23 oct, 00:03, jef2000 <jef2...@ouaye.net> wrote:
>
> > D'après ce que j'en ai compris:
> > Le flag "write" fait en sorte que l'état de l'objet (interne au
> > participant) est mis à jour si un télégramme "write" passe sur le bus
> > pour son adresse groupe
> > Le flag "read" fait en sorte que si une requête de lecture passe sur
> > le bus, le participant y répond en envoyant son état interne.
> > Le flag "transmit" autorise le participant à envoyer son état sur le
> > bus lorsque le programme d'application chargé dedans le demande.
>
> > Donc j'en déduis les règles suivantes:
> > Le flag write est toujours activé sauf lorsque ça n'a pas de sens
> > (pour la température actuelle par ex.)
> > Pour le flag "read" je fais en sorte que pour une addresse de groupe
> > donnée, un seul participant aie le flag "read" activé. De préférence
> > celui qui représente le mieux l'état de la fonction (souvent c'est
> > l'actuateur)
> > Pour le flag "transmit", je l'active lorsque le participant est censé
> > envoyer quelque chose de sa propre initiative. Pour les modules
> > poussoir, il est toujours activé. Pour les modules de sortie pas.
> > Généralement, quand un module de sortie doit envoyer quelque chose sur
> > le bus de sa propre initiative, c'est via un objet séparé (retour de
> > status) qui lui a le flag "transmit" activé.
> > En tout cas, c'est comme ça que j'ai compris le problème... N'hésitez
> > pas à me corriger si je dis des conneries.
> > Je vais m'arrêter là parce que plus j'en dit, plus j'ai l'impression
> > d'embrouiller tout le monde.
>
> > On 22 oct, 13:59, Marc Assin <raym...@warichet.com> wrote:
>
> > > On 22 oct, 10:55, jef2000 <jef2...@ouaye.net> wrote:> Je pense que vous ne parlez pas tous de la même chose.
>
> > > Je crois bien que si, même si c'est un peu embrouillé
>
> > > > Si tu veut
> > > > pouvoir lire le mode actuel, il suffit comme Dfrog l'explique, de
> > > > mettre le flag "read".
>
> > > Oui, bien d'accord. Il se trouve que le flag "Communication" est mis
> > > par défaut, j'ai donc rajouté le flag "Read", puis "Transmit". Rien
> > > n'y fait. Et donc, c'est le point de départ du post.
>
> > > Est-ce que qq a une bonne explication des flags ? Ce que j'ai trouvé
> > > dans les specs est un peu "sec", c'est une description, pas une
> > > explication.
> > > Cette histoire de flag me turlupinne depuis le début, car enfin, voilà
> > > un flag qui s'apelle "Read" et lorsqu'il n'est PAS mis, on peut lire
> > > quand même ?!?
> > > Et j'ai cru comprendre que les flags dans le HS (qui portent le même
> > > nom) ne fonctionnent pas pareil.
>
> > > > Si par contre tu veut que le thermostat
> > > > t'envoie de lui-même son mode quand il en change, tu dois utiliser
> > > > l'objet 44 évoqué par mickg avec le flag "Transmit".
>
> > > Oui, c'est super chouette, mais je n'avais pas vu aussi loin. C'est
> > > p'têt la meilleure solution.
>
> > > > C'est 2 opérations complètement différentes,
>
> > > OK, bien d'accord
>
> > > > il reste à savoir si ta visu
> > > > effectue une opération de lecture du mode sur le bus ou bien si elle
> > > > se contente de stocker au fur et à mesure le mode qu'elle reçoit.
>
> > > Bonne question, je ne sais pas trop, je crois que le HS prend des
> > > initiatives, mais sur base de quoi ?
> > > Pour l'instant, dans la Visu, je peux forcer le mode du th, via des
> > > boutons (ces boutons envoient simplement des commandes de "mode" au
> > > th., mais le fonctionnement normal est contrôlé par l'horloge)
> > > Puis, je voudrais que dans la Visu, le thermostat affiche son mode
> > > "actuel" (nuit, confort, etc) via un objet dynamique. Cà ne marche
> > > pas.
> > > J'ai regardé au niveau ETS, et monitor, et là aussi, je constate que
> > > çà ne marche pas.
> > > Je viens de re-regarder à l'instant, çà marche, .... je n'ai rien
> > > modifié depuis hier, .... c'est à n'y rien comprendre (j'ai laissé les
> > > flags R,T sur tout les modes de fonctionnement du th).
Merten: çà commence à bien faire... - keldo - 24/10/2007
On 23 oct, 08:06, mickg <mickael.gaut...@wanadoo.fr> wrote:
> Non non, il n'y a pas de conneries ;-) , pour conforter tes propos :
>
> Extrait du cours KNX :
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, ...).
Suite dans le prochain post. ...
Merten: çà commence à bien faire... - keldo - 24/10/2007
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".
Merten: çà commence à bien faire... - Roby - 25/10/2007
Pour le wiki :
Connecte toi sur http://knx.trbr.eu
Tu as le sommaire, tu vas tout en bas et tu clique sur connexion puis
sur enregistrez vous ici.
Une fois enregistré, tu te connecte par le même endroit et tu peux
alors éditer les pages.
Je pourrais le mettre en ligne pour toi, mais je t'encourage à le
faire
Tiens moi au courant !
Merten: çà commence à bien faire... - olivier95800 - 30/10/2007
Bonjour,
A propos de http://knx.trbr.eu
Je rencontre quelques difficultés:
S'enregistrer comme nouvel utilisateur: olivier95800 => Désolé, ce nom
d'utilisateur appartient déjà à un autre utilisateur.
Connexion: olivier95800 => L'utilisateur ou le mot de passe est
incorrect.
Mot de passe oublié => je ne recois rien.
Les liens du patagraphes 3 renvoient vers la page des thermostats.
Olivier
Merten: çà commence à bien faire... - olivier95800 - 30/10/2007
C'est bon ! j'ai trouvé ce qui n'allait pas.
Olivier
Merten: çà commence à bien faire... - Marc Assin - 01/11/2007
Bonjour,
Est-ce que quelqu'un a un pointeur sur la doc technique, en français
ou en anglais du thermostat Merten 6288 ?
Merci
Merten: çà commence à bien faire... - mickg - 02/11/2007
Bonjour,
J'ai transféré dans les fichiers la doc Schneider sur le prog 1814.
Ca doit t'aider.
@+
On 1 nov, 21:45, Marc Assin <raym...@warichet.com> wrote:
> Bonjour,
>
> Est-ce que quelqu'un a un pointeur sur la doc technique, en français
> ou en anglais du thermostat Merten 6288 ?
>
> Merci
Merten: çà commence à bien faire... - Marc Assin - 02/11/2007
On 2 nov, 09:18, mickg <mickael.gaut...@wanadoo.fr> wrote:
> J'ai transféré dans les fichiers la doc Schneider sur le prog 1814.
Merci M'sieu, zêtes bien aimable
(Commetn y fait Mickg, pour toujours avoir la solution :-))
> Ca doit t'aider.
On n'est jamais trop aidé :-)
Je suis en train de faire la Visu, de manière à ce que la Visu reflète
le mode dans lequel se trouve le thermostat. Pas de problème pour les
6249, on peut lire le byte de status (çà marche bien, on associe une
valeur à un texte dynamique). Pour le 6288, j'ai pas vu. Je suppose
qu'il faut permettre le satut sur un byte (on dirait que le défaut,
c'est 1 bit), mais zenfin, ce petit changement supprime toutes les
associations existantes, c'est super casse-pieds, il n'y a pas un
truc ?
Merten: çà commence à bien faire... - mickg - 02/11/2007
Ah ok je vois le problème...
A ma connaissance, il n'y a pas de truc, c'est normal que ca casse au
moins les associations sur cet objet.
Mais bon remettre quelques adresses de groupe, c'est pas la mort...
On 2 nov, 14:18, Marc Assin <raym...@warichet.com> wrote:
> On 2 nov, 09:18, mickg <mickael.gaut...@wanadoo.fr> wrote:
>
> > J'ai transféré dans les fichiers la doc Schneider sur le prog 1814.
>
> Merci M'sieu, zêtes bien aimable
> (Commetn y fait Mickg, pour toujours avoir la solution :-))
>
> > Ca doit t'aider.
>
> On n'est jamais trop aidé :-)
>
> Je suis en train de faire la Visu, de manière à ce que la Visu reflète
> le mode dans lequel se trouve le thermostat. Pas de problème pour les
> 6249, on peut lire le byte de status (çà marche bien, on associe une
> valeur à un texte dynamique). Pour le 6288, j'ai pas vu. Je suppose
> qu'il faut permettre le satut sur un byte (on dirait que le défaut,
> c'est 1 bit), mais zenfin, ce petit changement supprime toutes les
> associations existantes, c'est super casse-pieds, il n'y a pas un
> truc ?
Merten: çà commence à bien faire... - Marc Assin - 02/11/2007
On 2 nov, 14:52, mickg <mickael.gaut...@wanadoo.fr> wrote:
> c'est normal que ca casse au
> moins les associations sur cet objet.
Oui, tout à fait.
Mais je viens de remarquer, qu'il n'y a QUE les objets concernés, dont
l'association est détruite. Avec d'autres modules, il fallait TOUT
recommencer, d'où ma remarque.
> Mais bon remettre quelques adresses de groupe, c'est pas la mort...
Exact. J'ai survécu :-)
(faut'il s'en plaindre ou s'en réjouir ?)
N'empêche ... (j'ai la critique facile) ... l'objet 44 refusait d'être
associé à nouveau au GA ad-hoc. J'ai remarqué que dans le panneaux
"adresses" il était resté "collé" à l'objet 1 bit. Détruire cette
association à la main et c'est reparti.