13/09/2010, 21:27:58
> Premièrement, il n'y a pas d'obligation de séparer les zones, comme il
> n'y a pas d'interdiction de le faire, ...
Il y a des spécifications tout de même, et elles recommandent une
architecture hiérarchique (15 zones, 15 lignes par zone, 255 devices
par ligne). Avant de transgresser les spécifications, même si c'est
techniquement faisable, il vaut mieux avoir une vraie bonne raison de
le faire.
> ... Il n'est pas plus nécessaire d'ajouter des coupleurs
> de ligne sinon pour augmenter la puissance (2 alim) ...
Pas tout à fait. Vu que l'on ne peut pas placer un participant à plus
de 350m de l'alimentation, on peut être amené à placer deux
alimentations sur un même segment de ligne afin de dépasser cette
longueur. Et ceci sans ajout de coupleur. Une seule contrainte, les
deux alimentations doivent être distantes d'au moins 200m. En les
plaçant à chaque extrémité de la ligne, on peut donc atteindre 700m.
En revanche, le coupleur est requis dès que l'on place plus de 64
participants sur une ligne, même sur une ligne courte. Ce n'est alors
pas une question de puissance mais de charge sur le bus.
> ... Mais tout ceci n'influence pas la numérotation
> physique.
Un peu quand même. En présence d'un coupleur, ETS calcule une table de
filtrage et la télécharge dans le coupleur. L'objectif est d'éviter
qu'un message ne soit diffusé sur une ligne ou il n'a aucun
destinataire. L'ajout d'un coupleur nécessite donc de respecter les
règles d'adressage physique.
> L'adressage physique est essentiel pour le fonctionnement de
> l'installation. Elle fait partie intégrante du message EIB transmis
> (byte 2 et 3 si je ne m'abuse). Sans cette info, comment l'émetteur
> pourra contrôler si le message est bien arrivé ? ...
Oui, l'adresse physique de l'émetteur est dans le message. Et elle
permet effectivement au destinataire de transmettre un acquit (ACK) ou
un "non acquit" (NACK), ou encore l'information d'occupation (BUSY) si
le destinataire n'a pas été capable de traiter le message. En revanche
l'adresse du destinataire est en général une adresse de groupe (c'est
ce qui permet d'avoir plusieurs destinataires). Bien pratique pour
éteindre tout l'éclairage de la maison à partir d'un seul bouton
poussoir. Et au final ce sont bien les noms associés aux adresses de
groupe qui permettent de s'y retrouver dans ETS. Les adresses
physiques attribuées sont moins importantes pour la compréhension que
les adresses de groupes.
> ... Je rappelle ici que
> le protocole EIB est basé sur le "colision detect" (base du protocole
> Ethernet), et que par conséquent, chaque message doit avoir un retour
> de confirmation pour que l'émetteur arrête d'émettre si l'info est
> bien passée.
Pas du tout. Ethernet utilise le CSMA/CD (collision detection) tandis
que KNX utilise le CSMA/CA (collision avoidance). La différence est
qu'Ethernet, en cas de collision, oblige chaque émetteur à réémettre
son message, tandis que KNX permet au message le plus prioritaire
d'être transmis malgré la détection de collision. Le participant qui
émettait le message le moins prioritaire sera le seul à le répéter.
Enfin, sur Ethernet, l'émetteur n'émet pas jusqu'à confirmation de la
réception. Il émet une seule fois. C'est d'ailleurs le principe de
base en UDP. C'est soit la réception d'une demande de répétition, soit
un time-out qui conduira l'émetteur à réitérer son message.
> Par conséquent et étant obligatoires, autant que les adresses
> physiques correspondent à qqe chose de concret.
Oui, des zones, des lignes et des devices...
> Dans la pratique, il est plus facile de s'y retrouver dans une
> topologie "simple" où lieux géographiques coïncident avec la
> numérotation dans ETS, que d'implémenter des "zones" virtuelles, ne se
> trouvant que dans ETS.
>
> Je récupère régulièrement (et de plus en plus) de vielles
> installations EIB, faites il y a 10 ans ou plus, et conçue "à la dure"
> selon la méthode du classeur de court EIB. Eh bien je peux vous dire
> que le client est tout à fait "satisfait" de me voir perdre plusieurs
> heures à faire le lien entre éléments réels (les interrupteurs) et
> éléments virtuels (les fonctions), pour simplement pouvoir dépanner ou
> modifier /ajouter des fonctions. Si donc il est choisi une méthode
> comme décrite plus haut, par pitié DOCUMENTEZ au max votre
> installation avec des références compréhensibles entre ETS et les
> plans.
Quelque soit la méthode de numérotation, la documentation, c'est le
nerf de la guerre. Le reverse engineering est effectivement très
couteux.
> Pour conclure : ne vous mettez pas de limites si ETS ne vous en impose
> pas ...
Ne transgressez pas les préconisations KNX pour des raisons qui seront
le plus souvent mauvaises. Celui qui reprendra votre installation plus
tard vous en sera reconnaissant... d'autant plus si vous n'avez pas eu
malgré tout le courage de documenter votre installation.
PS : Je ne cherche pas la polémique, mais juste à donner mon avis. Je
n'ai nullement la prétention de détenir quelque vérité que ce soit. A
chacun de juger et d'appliquer la méthode qui lui convient le mieux.
> n'y a pas d'interdiction de le faire, ...
Il y a des spécifications tout de même, et elles recommandent une
architecture hiérarchique (15 zones, 15 lignes par zone, 255 devices
par ligne). Avant de transgresser les spécifications, même si c'est
techniquement faisable, il vaut mieux avoir une vraie bonne raison de
le faire.
> ... Il n'est pas plus nécessaire d'ajouter des coupleurs
> de ligne sinon pour augmenter la puissance (2 alim) ...
Pas tout à fait. Vu que l'on ne peut pas placer un participant à plus
de 350m de l'alimentation, on peut être amené à placer deux
alimentations sur un même segment de ligne afin de dépasser cette
longueur. Et ceci sans ajout de coupleur. Une seule contrainte, les
deux alimentations doivent être distantes d'au moins 200m. En les
plaçant à chaque extrémité de la ligne, on peut donc atteindre 700m.
En revanche, le coupleur est requis dès que l'on place plus de 64
participants sur une ligne, même sur une ligne courte. Ce n'est alors
pas une question de puissance mais de charge sur le bus.
> ... Mais tout ceci n'influence pas la numérotation
> physique.
Un peu quand même. En présence d'un coupleur, ETS calcule une table de
filtrage et la télécharge dans le coupleur. L'objectif est d'éviter
qu'un message ne soit diffusé sur une ligne ou il n'a aucun
destinataire. L'ajout d'un coupleur nécessite donc de respecter les
règles d'adressage physique.
> L'adressage physique est essentiel pour le fonctionnement de
> l'installation. Elle fait partie intégrante du message EIB transmis
> (byte 2 et 3 si je ne m'abuse). Sans cette info, comment l'émetteur
> pourra contrôler si le message est bien arrivé ? ...
Oui, l'adresse physique de l'émetteur est dans le message. Et elle
permet effectivement au destinataire de transmettre un acquit (ACK) ou
un "non acquit" (NACK), ou encore l'information d'occupation (BUSY) si
le destinataire n'a pas été capable de traiter le message. En revanche
l'adresse du destinataire est en général une adresse de groupe (c'est
ce qui permet d'avoir plusieurs destinataires). Bien pratique pour
éteindre tout l'éclairage de la maison à partir d'un seul bouton
poussoir. Et au final ce sont bien les noms associés aux adresses de
groupe qui permettent de s'y retrouver dans ETS. Les adresses
physiques attribuées sont moins importantes pour la compréhension que
les adresses de groupes.
> ... Je rappelle ici que
> le protocole EIB est basé sur le "colision detect" (base du protocole
> Ethernet), et que par conséquent, chaque message doit avoir un retour
> de confirmation pour que l'émetteur arrête d'émettre si l'info est
> bien passée.
Pas du tout. Ethernet utilise le CSMA/CD (collision detection) tandis
que KNX utilise le CSMA/CA (collision avoidance). La différence est
qu'Ethernet, en cas de collision, oblige chaque émetteur à réémettre
son message, tandis que KNX permet au message le plus prioritaire
d'être transmis malgré la détection de collision. Le participant qui
émettait le message le moins prioritaire sera le seul à le répéter.
Enfin, sur Ethernet, l'émetteur n'émet pas jusqu'à confirmation de la
réception. Il émet une seule fois. C'est d'ailleurs le principe de
base en UDP. C'est soit la réception d'une demande de répétition, soit
un time-out qui conduira l'émetteur à réitérer son message.
> Par conséquent et étant obligatoires, autant que les adresses
> physiques correspondent à qqe chose de concret.
Oui, des zones, des lignes et des devices...
> Dans la pratique, il est plus facile de s'y retrouver dans une
> topologie "simple" où lieux géographiques coïncident avec la
> numérotation dans ETS, que d'implémenter des "zones" virtuelles, ne se
> trouvant que dans ETS.
>
> Je récupère régulièrement (et de plus en plus) de vielles
> installations EIB, faites il y a 10 ans ou plus, et conçue "à la dure"
> selon la méthode du classeur de court EIB. Eh bien je peux vous dire
> que le client est tout à fait "satisfait" de me voir perdre plusieurs
> heures à faire le lien entre éléments réels (les interrupteurs) et
> éléments virtuels (les fonctions), pour simplement pouvoir dépanner ou
> modifier /ajouter des fonctions. Si donc il est choisi une méthode
> comme décrite plus haut, par pitié DOCUMENTEZ au max votre
> installation avec des références compréhensibles entre ETS et les
> plans.
Quelque soit la méthode de numérotation, la documentation, c'est le
nerf de la guerre. Le reverse engineering est effectivement très
couteux.
> Pour conclure : ne vous mettez pas de limites si ETS ne vous en impose
> pas ...
Ne transgressez pas les préconisations KNX pour des raisons qui seront
le plus souvent mauvaises. Celui qui reprendra votre installation plus
tard vous en sera reconnaissant... d'autant plus si vous n'avez pas eu
malgré tout le courage de documenter votre installation.
PS : Je ne cherche pas la polémique, mais juste à donner mon avis. Je
n'ai nullement la prétention de détenir quelque vérité que ce soit. A
chacun de juger et d'appliquer la méthode qui lui convient le mieux.