04/02/2012, 18:41:54
J'ai trouvé 
!!!!!!!!!!!!
Merci à tous pour vos réponses, idées et conseils !
C'est grace à seb@leon qui m'a mis sur la piste avec son dernier message, merci infiniment à toi !
Le problème : Les coupleurs de ligne, ces putains de coupleurs de ligne...
Je ne sais pas si c'est spécifique aux coupleurs de ligne de mon installation (Siemens 5WG1 140-1AB13) ou si le problème est le même avec toutes les marques, mais les raisons de mon problème pourraient peut-être servir à d'autres.
Tout d'abord, pour répondre à la remarque de seb@leon concernant la configuration des coupleurs, voici comment ça fonctionne (du moins, dans le cas des Siemens) : Il n'y a pas de paramètre pour définir le mode de fonctionnement, c'est l'adresse de bus qui lui est attribuée qui définit comment il doit travailler. Si on lui donne une adresse de niveau 3, du genre "x.x.64", "x.x.128" ou "x.x.192" il fonctionnera comme un répeteur de ligne. Par contre, si on lui donne une adresse de niveau 2, comme "x.x.0" (c'est le cas chez moi avec 1.1.0 et 1.2.0), il fonctionnera comme un coupleur de ligne. Enfin, si l'adresse qu'on lui attribue est de niveau 1 "x.0.0", il fera office de coupleur de zone.
Cette explication n'a rien à voir avec mon problème, mais elle permet de comprendre comment le coupleur fonctionne.
Ce qu'il faut également savoir, c'est que par défaut, les coupleurs sont configurés pour filtrer les trames qui passent sur le bus entre les deux "pôles" qu'ils interconnectent. Pour ce faire, ils utilisent une table contenant les adresses de groupes autorisées à traverser le coupleur. Cette table, c'est ETS qui la configure au moment du téléchargement de l'application dans le coupleur, en se basant sur les adresses de groupes déjà configurées. C'est ce qui explique qu'une modification dans les adresses de groupe implique TOUJOURS un re-téléchargement de l'application dans les coupleurs de bus. J'étais bien conscient de ce problème puisque je l'avais déjà rencontré lors de la configuration des lumières (et c'est pour ça que j'ai écris dans mon premier message : "Je sais également que le coupleur de bus peut parfois poser problème si les adresses de groupe sont modifiées, j'ai donc retéléchargé l'application dans les deux coupleurs de mon installation afin d'écarter tout problème de ce genre.")
Les deux autres configurations possibles sont "Block", pour bloquer toute transmission de données (si on veut isoler une partie de l'autre) ou "Transmit all", pour tout transmettre sans le moindre filtre. Pour cette dernière configuration, il est bien spécifié que son utilisation ne doit être choisie qu'à des fins de test (pour des raisons évidentes de traffic sur le bus) !
Jusque là, tout va bien... Mais c'est ici que ça se gâte !
Lorsque j'ai créé les adresses de groupe nécessaires pour la commande des stores, je n'ai lié à ces adresses que les objets correspondants des modules JMG; je n'ai donc qu'un seul participant sur ces adresses de groupe. Pour mes tests, j'utilise le "Moniteur de groupes" d'ETS pour envoyer les commandes et elles passent à travers l'interface USB ou la passerelle IP pour accéder au bus. Comme ces interfaces sont sur la ligne 1.0 alors que les modules sont sur la ligne 1.1, le coupleur de ligne devrait laisser passer les trames si je veux que les commandes fonctionnent. Hors, je croyais que le fait de créér les adresses de groupe, avant de re-télécharger l'application dans le coupleur, était suffisant pour laisser passer les trames. Eh bien NON, grande erreur pauvre ignorant. Il s'avère, en effet, que ce "très cher" ETS (dans tous les sens du terme!) ne transfère dans la table d'adressage des coupleurs que les adresses de groupes pour lesquelles un objet lié à un participant d'une autre ligne que la sienne est présent. Il faut donc que j'ajoute dans chacun de mes groupes un objet d'une autre ligne (comme un BP par exemple, qui se trouvent chez moi sur la ligne 1.2) pour que les tables soient correctement mises à jour.
Vous suivez ?
Là où ça me pose problème, c'est que je n'ai pas prévu de BP pour tous les stores ! J'utilise deux écrans tactiles fixes et deux "wireless" pour la commande des lumières et des stores dans toute la maison. Leur configuration est loin d'être terminée, mais c'est largement suffisant et ils seront complétés par quelques BP dont beaucoup me manquent pour l'instant. Du coup, pour que ça marche, j'ai passé les coupleurs en mode "Transmit all" et là, plus de problème !!!
Je ne vois pas comment résoudre le problème autrement étant donné que mes écrans tactiles (de marque Vity) ont une interface KNX qui est dite transparente. Par conséquent, impossible de les voir dans ETS et donc impossible de les utiliser dans les adresses de groupe !!!
Pour finir, deux petites questions :
1. Est-ce que vous voyez une autre solution ?
2. Est-ce que vous pensez que le fait de laisser les coupleurs en mode "Transmit all" pourrait me poser des problèmes ?
Merci encore à tous et j'espère que cela pourra permettre à d'autres de rapidement comprendre et résoudre le problème si ils y sont confrontés...
!!!!!!!!!!!!Merci à tous pour vos réponses, idées et conseils !
C'est grace à seb@leon qui m'a mis sur la piste avec son dernier message, merci infiniment à toi !
Le problème : Les coupleurs de ligne, ces putains de coupleurs de ligne...
Je ne sais pas si c'est spécifique aux coupleurs de ligne de mon installation (Siemens 5WG1 140-1AB13) ou si le problème est le même avec toutes les marques, mais les raisons de mon problème pourraient peut-être servir à d'autres.
Tout d'abord, pour répondre à la remarque de seb@leon concernant la configuration des coupleurs, voici comment ça fonctionne (du moins, dans le cas des Siemens) : Il n'y a pas de paramètre pour définir le mode de fonctionnement, c'est l'adresse de bus qui lui est attribuée qui définit comment il doit travailler. Si on lui donne une adresse de niveau 3, du genre "x.x.64", "x.x.128" ou "x.x.192" il fonctionnera comme un répeteur de ligne. Par contre, si on lui donne une adresse de niveau 2, comme "x.x.0" (c'est le cas chez moi avec 1.1.0 et 1.2.0), il fonctionnera comme un coupleur de ligne. Enfin, si l'adresse qu'on lui attribue est de niveau 1 "x.0.0", il fera office de coupleur de zone.
Cette explication n'a rien à voir avec mon problème, mais elle permet de comprendre comment le coupleur fonctionne.
Ce qu'il faut également savoir, c'est que par défaut, les coupleurs sont configurés pour filtrer les trames qui passent sur le bus entre les deux "pôles" qu'ils interconnectent. Pour ce faire, ils utilisent une table contenant les adresses de groupes autorisées à traverser le coupleur. Cette table, c'est ETS qui la configure au moment du téléchargement de l'application dans le coupleur, en se basant sur les adresses de groupes déjà configurées. C'est ce qui explique qu'une modification dans les adresses de groupe implique TOUJOURS un re-téléchargement de l'application dans les coupleurs de bus. J'étais bien conscient de ce problème puisque je l'avais déjà rencontré lors de la configuration des lumières (et c'est pour ça que j'ai écris dans mon premier message : "Je sais également que le coupleur de bus peut parfois poser problème si les adresses de groupe sont modifiées, j'ai donc retéléchargé l'application dans les deux coupleurs de mon installation afin d'écarter tout problème de ce genre.")
Les deux autres configurations possibles sont "Block", pour bloquer toute transmission de données (si on veut isoler une partie de l'autre) ou "Transmit all", pour tout transmettre sans le moindre filtre. Pour cette dernière configuration, il est bien spécifié que son utilisation ne doit être choisie qu'à des fins de test (pour des raisons évidentes de traffic sur le bus) !
Jusque là, tout va bien... Mais c'est ici que ça se gâte !
Lorsque j'ai créé les adresses de groupe nécessaires pour la commande des stores, je n'ai lié à ces adresses que les objets correspondants des modules JMG; je n'ai donc qu'un seul participant sur ces adresses de groupe. Pour mes tests, j'utilise le "Moniteur de groupes" d'ETS pour envoyer les commandes et elles passent à travers l'interface USB ou la passerelle IP pour accéder au bus. Comme ces interfaces sont sur la ligne 1.0 alors que les modules sont sur la ligne 1.1, le coupleur de ligne devrait laisser passer les trames si je veux que les commandes fonctionnent. Hors, je croyais que le fait de créér les adresses de groupe, avant de re-télécharger l'application dans le coupleur, était suffisant pour laisser passer les trames. Eh bien NON, grande erreur pauvre ignorant. Il s'avère, en effet, que ce "très cher" ETS (dans tous les sens du terme!) ne transfère dans la table d'adressage des coupleurs que les adresses de groupes pour lesquelles un objet lié à un participant d'une autre ligne que la sienne est présent. Il faut donc que j'ajoute dans chacun de mes groupes un objet d'une autre ligne (comme un BP par exemple, qui se trouvent chez moi sur la ligne 1.2) pour que les tables soient correctement mises à jour.
Vous suivez ?
Là où ça me pose problème, c'est que je n'ai pas prévu de BP pour tous les stores ! J'utilise deux écrans tactiles fixes et deux "wireless" pour la commande des lumières et des stores dans toute la maison. Leur configuration est loin d'être terminée, mais c'est largement suffisant et ils seront complétés par quelques BP dont beaucoup me manquent pour l'instant. Du coup, pour que ça marche, j'ai passé les coupleurs en mode "Transmit all" et là, plus de problème !!!
Je ne vois pas comment résoudre le problème autrement étant donné que mes écrans tactiles (de marque Vity) ont une interface KNX qui est dite transparente. Par conséquent, impossible de les voir dans ETS et donc impossible de les utiliser dans les adresses de groupe !!!
Pour finir, deux petites questions :
1. Est-ce que vous voyez une autre solution ?
2. Est-ce que vous pensez que le fait de laisser les coupleurs en mode "Transmit all" pourrait me poser des problèmes ?
Merci encore à tous et j'espère que cela pourra permettre à d'autres de rapidement comprendre et résoudre le problème si ils y sont confrontés...