24/10/2007, 13:34:17
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).
> 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).
