Bonjour,
Lorsque le serveur redémarre (et uniquement apres ça) au redémarrage
de linknx et apres une demande d'etat du groupe ecl_ch1. Si la sortie
est physiquement ouverte, linknx ferme cette sortie et me reponds que
cette sortie est bel est bien fermé alors qu'avant cette demande
d'etat la sortie etait bien ouverte.
Quelq'un aurait-il deja rencontré ce probleme et comment l'avez vous
solutionné?
Cordialement,
Yannick
Bonjour,
Si l'objet est configuré avec les paramètres par défaut, il va
demander la valeur actuelle sur le bus en envoyant un télégramme de
lecture pour l'adresse de groupe configurée. Le problème n'est donc
probablement pas dû à linknx mais a la configuration de ton
installation. Comme tu le décris dans la discussion "Configuration
ETS", l'état de la sortie change quand tu fais une opération de
lecture avec ETS. C'est donc probablement la même chose qui se passe
lorsque linknx fais une opération de lecture.
Bien à toi,
Jean-François
On 30 avr, 01:10, Casi <supp...@magikdo.com> wrote:
> Bonjour,
>
> Lorsque le serveur redémarre (et uniquement apres ça) au redémarrage
> de linknx et apres une demande d'etat du groupe ecl_ch1. Si la sortie
> est physiquement ouverte, linknx ferme cette sortie et me reponds que
> cette sortie est bel est bien fermé alors qu'avant cette demande
> d'etat la sortie etait bien ouverte.
>
> Quelq'un aurait-il deja rencontré ce probleme et comment l'avez vous
> solutionné?
>
> Cordialement,
> Yannick
(...)
D'ou l'utilité de séparer "adresse de groupe pour la commande" et
"adresse de groupe pour le retour d'état", ainsi que de correctement
configurer les flags pour CHAQUE objet de CHAQUE participant, pour
CHAQUE adresse de groupe ...
Un exemple est sans doute plus parlant que de la théorie :
En gros, voici la bonne config des flags pour un "bête" circuit ON/OFF
(une lampe par exemple).
Pré-requis : les objets "retour d'état" ou "information d'état" NE
doivent PAS être dans la même adresse de groupe que les objets de
commande.
1) Objets de communication reliés l'adresse de groupe (=A.G.) de
commande :
- boutons poussoirs (et tout ce qui peut "envoyer" un ordre sur cette
A.G.) : activer les flags "communication", "transmit" et
"write" (ainsi, éventuellement que "update") ; mais absolument
désactiver "read".
Il faut aussi que le flag "send" soit actif pour cette A.G.
- acteur(s) (ou tout ce qui doit "exécuter" l'ordre) : activer les
flags "communication", "read" et "write" (ainsi que, éventuellement,
"transmit") ; mais absolument désactiver "update".
En principe, le flag "send" devrait aussi être actif pour cette A.G.,
sauf dans le cas ou la (ou les) A.G. est destinée à une "commande
centrale" et agit donc sur plusieurs acteurs simultanément (comme par
ex. un "Tout OFF pour le RdC")
2) Objets de communication reliés l'A.G. de "retour d'état" :
- LED des boutons poussoirs (et tout ce qui peut afficher l'état,
comme un canal de visu.) : activer les flags "communication",
"update" et "write" ; mais absolument désactiver "read" et "transmit".
Pour cette A.G., le flag "send" doit aussi être actif (cet objet de
communication ne doit envoyer aucune valeur sur le bus, mais le flag
"send" est nécessaire pour pouvoir envoyer des message de type "read
request" vers l'A.G., ce qui particulièrement nécessaire dans le cas
d'une visu.).
- état de l'acteur (au singulier, car un retour d'état n'a de sens que
pour un acteur unique, donc il ne peut y avoir qu'une seule A.G. liée
à cet objet de communication) : activer les flags "communication",
"read" , ainsi que "transmit" ; mais désactiver "update" et "write".
Pour cette A.G., le flag "send" doit aussi être actif.
- - -
Avec cette config, il est impossible pour une visu de faire s'allumer
ou s'éteindre un lampe lors du démarrage de la visu ; mais, si la visu
doit aussi pouvoir commander la lampe, idéalement cela suppose que la
visu propose 2 objets de communication différents par lampe : un objet
"commande" et un autre objet pour l'affichage de l'état ...
Je ne pense malheureusement pas que ce soit le cas de toutes les
visu. :-(
Dans le cas des visu qui ne proposent qu'un seul objet de
communication, on peut y associer les deux A.G. (commande et retour
d'état) mais il faut absolument veiller à ce que le flag "send" soit
actif pour l'A.G. "commande" et non pour l'autre A.G.
Maintenant, si la visu ne propose pas non plus de flag "send" et
envoit d'office un télégramme sur toutes les G.A. reliées à l'objet de
communication, mieux vaut ne rien commander avec cette visu ... ou
bien en changer ... ;-)
- - -
Si l'on ne désire pas utiliser une seconde A.G., dédiée au retour
d'état, c'est aussi possible mais c'est moins "propre" et il faut un
petit peu modifier mon explication sur les flags.
(mais la, ce sera pour une autre fois, j'ai les doigts qui
fatiguent ... ;-)).
N.B. : Ne pas oublier que les flags "read" et "update" sont toujours
mutuellement exclusifs (= il ne faut JAMAIS les activer en même temps)
sur un même objet de communication.
Merci pour cette explication trés complete!
Je pense que ça servira a d'autres débutants du monde knx car c'est
effectivement mal documenté.
Cordialement,
Yannick
On 1 mai, 01:09, keldo <kelderm...@ibelgique.com> wrote:
> (...)
> D'ou l'utilité de séparer "adresse de groupe pour la commande" et
> "adresse de groupe pour le retour d'état", ainsi que de correctement
> configurer les flags pour CHAQUE objet de CHAQUE participant, pour
> CHAQUE adresse de groupe ...
>
> Un exemple est sans doute plus parlant que de la théorie :
>
> En gros, voici la bonne config des flags pour un "bête" circuit ON/OFF
> (une lampe par exemple).
> Pré-requis : les objets "retour d'état" ou "information d'état" NE
> doivent PAS être dans la même adresse de groupe que les objets de
> commande.
>
> 1) Objets de communication reliés l'adresse de groupe (=A.G.) de
> commande :
>
> - boutons poussoirs (et tout ce qui peut "envoyer" un ordre sur cette
> A.G.) : activer les flags "communication", "transmit" et
> "write" (ainsi, éventuellement que "update") ; mais absolument
> désactiver "read".
> Il faut aussi que le flag "send" soit actif pour cette A.G.
>
> - acteur(s) (ou tout ce qui doit "exécuter" l'ordre) : activer les
> flags "communication", "read" et "write" (ainsi que, éventuellement,
> "transmit") ; mais absolument désactiver "update".
> En principe, le flag "send" devrait aussi être actif pour cette A.G.,
> sauf dans le cas ou la (ou les) A.G. est destinée à une "commande
> centrale" et agit donc sur plusieurs acteurs simultanément (comme par
> ex. un "Tout OFF pour le RdC")
>
> 2) Objets de communication reliés l'A.G. de "retour d'état" :
>
> - LED des boutons poussoirs (et tout ce qui peut afficher l'état,
> comme un canal de visu.) : activer les flags "communication",
> "update" et "write" ; mais absolument désactiver "read" et "transmit".
> Pour cette A.G., le flag "send" doit aussi être actif (cet objet de
> communication ne doit envoyer aucune valeur sur le bus, mais le flag
> "send" est nécessaire pour pouvoir envoyer des message de type "read
> request" vers l'A.G., ce qui particulièrement nécessaire dans le cas
> d'une visu.).
>
> - état de l'acteur (au singulier, car un retour d'état n'a de sens que
> pour un acteur unique, donc il ne peut y avoir qu'une seule A.G. liée
> à cet objet de communication) : activer les flags "communication",
> "read" , ainsi que "transmit" ; mais désactiver "update" et "write".
> Pour cette A.G., le flag "send" doit aussi être actif.
>
> - - -
>
> Avec cette config, il est impossible pour une visu de faire s'allumer
> ou s'éteindre un lampe lors du démarrage de la visu ; mais, si la visu
> doit aussi pouvoir commander la lampe, idéalement cela suppose que la
> visu propose 2 objets de communication différents par lampe : un objet
> "commande" et un autre objet pour l'affichage de l'état ...
> Je ne pense malheureusement pas que ce soit le cas de toutes les
> visu. :-(
> Dans le cas des visu qui ne proposent qu'un seul objet de
> communication, on peut y associer les deux A.G. (commande et retour
> d'état) mais il faut absolument veiller à ce que le flag "send" soit
> actif pour l'A.G. "commande" et non pour l'autre A.G.
> Maintenant, si la visu ne propose pas non plus de flag "send" et
> envoit d'office un télégramme sur toutes les G.A. reliées à l'objet de
> communication, mieux vaut ne rien commander avec cette visu ... ou
> bien en changer ... ;-)
>
> - - -
>
> Si l'on ne désire pas utiliser une seconde A.G., dédiée au retour
> d'état, c'est aussi possible mais c'est moins "propre" et il faut un
> petit peu modifier mon explication sur les flags.
> (mais la, ce sera pour une autre fois, j'ai les doigts qui
> fatiguent ... ;-)).
>
> N.B. : Ne pas oublier que les flags "read" et "update" sont toujours
> mutuellement exclusifs (= il ne faut JAMAIS les activer en même temps)
> sur un même objet de communication.
Mathieu Gallissot
Unregistered
Normalement, une trame de lecture ne doit provoquer aucune commande, quelque
soit la configuration, et quelque soit la nature du datapoint que l'on veut
lire (IOO, OO...).
Cela viens probablement des couches plus hautes de Linknx.
2009/4/30 jef2000 <jef2000@ouaye.net>
>
> Bonjour,
>
> Si l'objet est configuré avec les paramètres par défaut, il va
> demander la valeur actuelle sur le bus en envoyant un télégramme de
> lecture pour l'adresse de groupe configurée. Le problème n'est donc
> probablement pas dû à linknx mais a la configuration de ton
> installation. Comme tu le décris dans la discussion "Configuration
> ETS", l'état de la sortie change quand tu fais une opération de
> lecture avec ETS. C'est donc probablement la même chose qui se passe
> lorsque linknx fais une opération de lecture.
>
> Bien à toi,
>
> Jean-François
>
> On 30 avr, 01:10, Casi <supp...@magikdo.com> wrote:
> > Bonjour,
> >
> > Lorsque le serveur redémarre (et uniquement apres ça) au redémarrage
> > de linknx et apres une demande d'etat du groupe ecl_ch1. Si la sortie
> > est physiquement ouverte, linknx ferme cette sortie et me reponds que
> > cette sortie est bel est bien fermé alors qu'avant cette demande
> > d'etat la sortie etait bien ouverte.
> >
> > Quelq'un aurait-il deja rencontré ce probleme et comment l'avez vous
> > solutionné?
> >
> > Cordialement,
> > Yannick
>
> Normalement, une trame de lecture ne doit provoquer aucune commande, quelque
> soit la configuration, et quelque soit la nature du datapoint que l'on veut
> lire (IOO, OO...).
Une requète de lecture ne provoque aucune commande en elle même, mais
la réponse à celle ci est reçue par tous les participants et, suivant
la configuration des flags, peut provoquer le changement de valeur
d'un actuateur.
> Cela viens probablement des couches plus hautes de Linknx.
Je ne pense pas, et je pense être relativement bien placé pour en
juger.
Bien à vous,
Jean-François
Je ne peut que confirmer les dires de Jef2000.
Voici très probablement le cas de figure auquel Casi est confronté :
1)
- L'acteur est en position ON, la lampe est allumée.
- L'objet de communication "commande ON/OFF" de l'acteur (=une sortie
binaire, dans ce cas-ci) de la lampe a son flag "update" actif (ce qui
est une erreur dans ce cas-ci), ainsi que son flag "write" (ce qui
correct) , par contre, le flag "read" est probablement inactif (ce qui
est une erreur, surtout si on n'utilise pas une adresse de groupe
séparée pour le retour d'état).
- Cet objet de comm. est relié à l'adresse de groupe 4/2/17 (exemple
pris au hasard).
2)
- La visu LinKNX est éteinte.
- Dans la config. de la visu, un objet de communication est relié à
4/2/17.
- Dans la config. de la visu, cet objet de communication a les flags
"write", "transmit" et "update" actifs (ce qui correct), ainsi que le
flag "read" (et ça, c'est une grosse erreur).
3)
- On allume la visu.
- La visu envoit un télégramme "read value" sur 4/2/17 pour mettre à
jour son affichage du statut de la lampe.
- L'acteur, qui est pourtant le seul à détenir une information
pertinente, NE répond PAS vu que son flag "read" est inactif.
- La visu, qui est la seule à avoir son flag "read" actif, se répond à
elle-même en donnant sur le bus la seule valeur dont elle dispose, à
savoir, "0", qui est la valeur par défaut de toutes ses variables en
mémoire juste après l'initialisation du programme de visu ...
- L'acteur voit sur le bus cette réponse erronée et, comme le flag
"update" de son objet de comm. est actif, il met à jour la valeur de
son objet, écrasant la précédente valeur ("1" = allumé), correcte, par
la valeur "par défaut" de la visu ("0" = éteind).
4)
- L'utilisateur se demande pour il vient de se retrouver dans le noir
sans avoir touché à ses boutons poussoirs.
;-)
Les flags EIB, ce n'est pas compliqué à comprendre, mais cela demande
un certain temps pour bien saisir toutes les subtilités ...
Bonjour,
Merci pour ces emplications qui ont pu me conduire à la solution.
Effectivement le problème ne venait pas de LINKNX mais de la
configuration de mes flags comme expliqué par keldo
Cordialement,
Yannick
On 2 mai, 00:04, keldo <kelderm...@ibelgique.com> wrote:
> Je ne peut que confirmer les dires de Jef2000.
>
> Voici très probablement le cas de figure auquel Casi est confronté :
>
> 1)
> - L'acteur est en position ON, la lampe est allumée.
> - L'objet de communication "commande ON/OFF" de l'acteur (=une sortie
> binaire, dans ce cas-ci) de la lampe a son flag "update" actif (ce qui
> est une erreur dans ce cas-ci), ainsi que son flag "write" (ce qui
> correct) , par contre, le flag "read" est probablement inactif (ce qui
> est une erreur, surtout si on n'utilise pas une adresse de groupe
> séparée pour le retour d'état).
> - Cet objet de comm. est relié à l'adresse de groupe 4/2/17 (exemple
> pris au hasard).
>
> 2)
> - La visu LinKNX est éteinte.
> - Dans la config. de la visu, un objet de communication est relié à
> 4/2/17.
> - Dans la config. de la visu, cet objet de communication a les flags
> "write", "transmit" et "update" actifs (ce qui correct), ainsi que le
> flag "read" (et ça, c'est une grosse erreur).
>
> 3)
> - On allume la visu.
> - La visu envoit un télégramme "read value" sur 4/2/17 pour mettre à
> jour son affichage du statut de la lampe.
> - L'acteur, qui est pourtant le seul à détenir une information
> pertinente, NE répond PAS vu que son flag "read" est inactif.
> - La visu, qui est la seule à avoir son flag "read" actif, se répond à
> elle-même en donnant sur le bus la seule valeur dont elle dispose, à
> savoir, "0", qui est la valeur par défaut de toutes ses variables en
> mémoire juste après l'initialisation du programme de visu ...
> - L'acteur voit sur le bus cette réponse erronée et, comme le flag
> "update" de son objet de comm. est actif, il met à jour la valeur de
> son objet, écrasant la précédente valeur ("1" = allumé), correcte, par
> la valeur "par défaut" de la visu ("0" = éteind).
>
> 4)
> - L'utilisateur se demande pour il vient de se retrouver dans le noir
> sans avoir touché à ses boutons poussoirs.
> ;-)
>
> Les flags EIB, ce n'est pas compliqué à comprendre, mais cela demande
> un certain temps pour bien saisir toutes les subtilités ...
|
