Bonjour,
Je me pose une question à propos des passerelles IP
Si j'ai bien compris tous les messages circulants sur le bus EIB sont
emis également sur le reseau IP
à grace à l'interface IP (genre N148)
Mais dans le cas de messages EIB emis sur une autre ligne que celle où
est connecté la passerelle?
(Cette ligne est donc séparée par un coupleur de ligne, et le rôle du
coupleur de ligne est aussi de filtrer les messages. non?)
Ce que j'essaye de savoir, avec ces questions, c'est si je peux
monitorer le bus EIB en entier (avec IP).
Peut importe la position de la passerelle?
--Cédric
On 28 août, 18:00, Ferllings <ferlli...@gmail.com> wrote:
> Ce que j'essaye de savoir, avec ces questions, c'est si je peux
> monitorer le bus EIB en entier (avec IP).
> Peut importe la position de la passerelle?
Perso, je ne crois pas. Avis tout à fait théorique, je n'ai pas essayé
Si tu veux monitorer *TOUT* le bus EIB, tu as intérêt à placer la
passerelle le plus haut possible dans l'architecture.
Si par exemple du as:
une ligne 1.1.x
une ligne 1.2.x
une main line 1.0.x
tu devrais placer la passerelle sur 1.0.x pour monitorer les 3 lignes
On 28 août, 18:00, Ferllings <ferlli...@gmail.com> wrote:
euuuh, nuance.... si les coupleurs de ligne sont programmés en "pass
thru" (pas une bonne idée), le traffic EIB se retrouve sur toutes les
lignes et donc tu devrais pouvoir placer ta passerelle n'importe où.
On 28/08/09 18:33, marc.assin wrote:
> On 28 août, 18:00, Ferllings<ferlli...@gmail.com> wrote:
> euuuh, nuance.... si les coupleurs de ligne sont programmés en "pass
> thru" (pas une bonne idée), le traffic EIB se retrouve sur toutes les
> lignes et donc tu devrais pouvoir placer ta passerelle n'importe où.
>
>
Merci, ca me donne déjà un début de réponse.
Il va falloir que je teste tout ça quand j'aurais mes modules.
--Cédric
On 28 août, 22:17, Ferllings <ferlli...@gmail.com> wrote:
> Il va falloir que je teste tout ça quand j'aurais mes modules.
Est-ce que tu as réellement l'intention d'implémenter une architecture
de cette envergure ?
Qui dit ligne, dit alim
Qui dit couplage, dit coupleur de ligne
çà commence à faire beaucoup dans le cadre d'une maison unifamiliale.
Comme mentionné dans un post précédent, du pourrais "limiter" les
exigences en te contentant de 2 lignes (line + main line), çà fait 2
alim et un coupleur (au lieu de 3 alim et 2 coupleurs)
Non, non, c'est seulement quelques essais dans le but de comprendre le
fonctionnement.
Je participe au projet Domogik. ( http://www.domogik.org/)
Et je reflechi à la possibilité de créer un client EIB/KNX pour le projet.
Personnellement je m'en tiendrais, comme toi, à 1 ou 2 lignes maximum.
--Cédric
On 28/08/09 23:08, marc.assin wrote:
> On 28 août, 22:17, Ferllings<ferlli...@gmail.com> wrote:
>
>> Il va falloir que je teste tout ça quand j'aurais mes modules.
>>
> Est-ce que tu as réellement l'intention d'implémenter une architecture
> de cette envergure ?
> Qui dit ligne, dit alim
> Qui dit couplage, dit coupleur de ligne
> çà commence à faire beaucoup dans le cadre d'une maison unifamiliale.
>
> Comme mentionné dans un post précédent, du pourrais "limiter" les
> exigences en te contentant de 2 lignes (line + main line), çà fait 2
> alim et un coupleur (au lieu de 3 alim et 2 coupleurs)
>
>
> Comme mentionné dans un post précédent, du pourrais "limiter" les
> exigences en te contentant de 2 lignes (line + main line), çà fait 2
> alim et un coupleur (au lieu de 3 alim et 2 coupleurs)
Je pensais réaliser cette architecture chez moi (une ligne pour
l'interieur et l'autre pour l'exterieur). Mais je n'avais pas pensé au
problème du coupleur IP.
Si j'ai bien compris, les messages sur la ligne extérieur ne seront
pas visible sur le coupleur IP qui est situé sur la ligne intérieur.
Idem pour une Varuna3, celle-ci ne pourra agir que sur les groupes de
la ligne où elle est connecté?
Si c'est ça et qu'il faut un coupleur IP par ligne faut que je revois
mon installation car cela risque de compliquer les choses pour ma visu.
Si le coupleur ne fait pas de filtrage quel que soit le point de
connexion on peut monitorer le bus sans problème.
On 29 août, 10:57, kraven <ohl.christo...@gmail.com> wrote:
> > Comme mentionné dans un post précédent, du pourrais "limiter" les
> > exigences en te contentant de 2 lignes (line + main line), çà fait 2
> > alim et un coupleur (au lieu de 3 alim et 2 coupleurs)
>
> Je pensais réaliser cette architecture chez moi (une ligne pour
> l'interieur et l'autre pour l'exterieur). Mais je n'avais pas pensé au
> problème du coupleur IP.
> Si j'ai bien compris, les messages sur la ligne extérieur ne seront
> pas visible sur le coupleur IP qui est situé sur la ligne intérieur.
> Idem pour une Varuna3, celle-ci ne pourra agir que sur les groupes de
> la ligne où elle est connecté?
>
> Si c'est ça et qu'il faut un coupleur IP par ligne faut que je revois
> mon installation car cela risque de compliquer les choses pour ma visu.
Merci.
Je suppose que sur des petites installations tel que des maisons
individuelles il n'y a aucune raison de filtrer.
On 29 août, 19:56, JC <411farenh...@gmail.com> wrote:
> Si le coupleur ne fait pas de filtrage quel que soit le point de
> connexion on peut monitorer le bus sans problème.
>
> On 29 août, 10:57, kraven <ohl.christo...@gmail.com> wrote:
>
>
>
> > > Comme mentionné dans un post précédent, du pourrais "limiter" les
> > > exigences en te contentant de 2 lignes (line + main line), çà fait 2
> > > alim et un coupleur (au lieu de 3 alim et 2 coupleurs)
>
> > Je pensais réaliser cette architecture chez moi (une ligne pour
> > l'interieur et l'autre pour l'exterieur). Mais je n'avais pas pensé au
> > problème du coupleur IP.
> > Si j'ai bien compris, les messages sur la ligne extérieur ne seront
> > pas visible sur le coupleur IP qui est situé sur la ligne intérieur.
> > Idem pour une Varuna3, celle-ci ne pourra agir que sur les groupes de
> > la ligne où elle est connecté?
>
> > Si c'est ça et qu'il faut un coupleur IP par ligne faut que je revois
> > mon installation car cela risque de compliquer les choses pour ma visu.
On 30 août, 21:49, kraven <ohl.christo...@gmail.com> wrote:
> Je suppose que sur des petites installations tel que des maisons
> individuelles il n'y a aucune raison de filtrer.
Mwoui et non.
Tout d'abord, "sur des petites installations tel que des maisons
individuelles" c'est très peu probable d'atteindre la limite des 64
devices et donc la nécessité d'une 2ième ligne.
Ensuite, dans le cas de 2 lignes, ce n'est pas la taille de
l'installation qu'il faut considérer mais bien la densité du traffic.
ETS bus monitor peut donner une indication utile à cet effet (nbre de
télégrammes par seconde)
Enfin, il derais judicieux d'organiser la topologie de manière a
minimiser le traffic à travers le coupleur. Par exemple, dans la
mesure du possible, s'arranger que l'emetteur et le récepteur soient
du même côté, çàd que le/les BP et le/les actuators du GA soient sur
la même ligne, càd tous en 1.1.x ou en 1.0.x
Il est clair que si un participant est en 1.1.x et son partenaire en
1.0.x çà va générer du traffic à travers le coupleur.
D'ailleur, y'a t'il besoin d'un coupleur?
D'après mon manuel KNX:
"Une ligne comporte 4 segments de ligne maximum, avec respectivement 64
participants maximum. Chaque segment doit avoir sa propre alimentation."
Ca fait donc 256 participants, avant d'avoir besoin de créer une
nouvelle ligne (et donc d'utiliser un coupleur).
On 30/08/09 21:49, kraven wrote:
> Merci.
> Je suppose que sur des petites installations tel que des maisons
> individuelles il n'y a aucune raison de filtrer.
>
> On 29 août, 19:56, JC<411farenh...@gmail.com> wrote:
>
>> Si le coupleur ne fait pas de filtrage quel que soit le point de
>> connexion on peut monitorer le bus sans problème.
>>
>> On 29 août, 10:57, kraven<ohl.christo...@gmail.com> wrote:
>>
>
On 31 août, 09:05, Ferllings <ferlli...@gmail.com> wrote:
> "Une ligne comporte 4 segments de ligne maximum, avec respectivement 64
> participants maximum. Chaque segment doit avoir sa propre alimentation."
> Ca fait donc 256 participants, avant d'avoir besoin de créer une
> nouvelle ligne (et donc d'utiliser un coupleur).
Tu as tout à fait raison, j'ai oublié de mentionner cette alternative,
mais çà ne change pas grand chose.
1) Comme tu dis "Chaque segment doit avoir sa propre alimentation".
Donc au point de vue alim, çà ne change rien.
2) Et comment est-ce que tu "connectes tes 4 segments ensemble ???
qu'est ce qu'il en dit ton manuel ? je pense qu'il faut un "repeater",
donc max 3 "repeater" pour attacher les 4 segments. Le repeater est
souvent le même device que le line coupler ou area coupler mais
configuré en repeater. Le repeater est un "bête" ampli, mais avec
séparation galvanique, et donc n'a pas la notion de filtrage, tout le
traffic des 256 devices se retrouve sur la même ligne.
Et donc pour finir ? ben çà ne change pas grand chose, si ce n'est la
manière de dessiner ton architecture.
On 31/08/09 09:21, marc.assin wrote:
> On 31 août, 09:05, Ferllings<ferlli...@gmail.com> wrote:
>
>> "Une ligne comporte 4 segments de ligne maximum, avec respectivement 64
>> participants maximum. Chaque segment doit avoir sa propre alimentation."
>> Ca fait donc 256 participants, avant d'avoir besoin de créer une
>> nouvelle ligne (et donc d'utiliser un coupleur).
>>
> Tu as tout à fait raison, j'ai oublié de mentionner cette alternative,
> mais çà ne change pas grand chose.
> 1) Comme tu dis "Chaque segment doit avoir sa propre alimentation".
> Donc au point de vue alim, çà ne change rien.
>
Non, effectivement.
> 2) Et comment est-ce que tu "connectes tes 4 segments ensemble ???
> qu'est ce qu'il en dit ton manuel ? je pense qu'il faut un "repeater",
> donc max 3 "repeater" pour attacher les 4 segments. Le repeater est
> souvent le même device que le line coupler ou area coupler mais
> configuré en repeater. Le repeater est un "bête" ampli, mais avec
> séparation galvanique, et donc n'a pas la notion de filtrage, tout le
> traffic des 256 devices se retrouve sur la même ligne.
>
Y'a rien de noté explicitement, mais dans les figures il y a bien des
repeaters.
> Et donc pour finir ? ben çà ne change pas grand chose, si ce n'est la
> manière de dessiner ton architecture.
>
Oui, comme tu le disais dans un autre message, tout depend du trafic que
tu as sur ta ligne.
Avec peu de trafic, un repeater peut suffire.
On 31 août, 10:27, Ferllings <ferlli...@gmail.com> wrote:
> Avec peu de trafic, un repeater peut suffire.
Tout à fait.
NB: la limite des 64 devices par segment, est une limite théorique
basée sur une consommation moyenne estimée par device de 10mA et une
alim de 640mA.
Cette limite n'est PAS physiquement implémentée dans l'architecture.
La pluspart des BCU modernes consomment entre 4-10mA, donc il y a un
peu de réserve (j'ai plus que 64 devices et çà marche toujours).
Il y a quand même un "hic", les EMO consomment +/-15mA, j'en ai 4. En
été, pas de chauffage, tout va bien. Mais en cas de coupure de courant
(ce qui arrive au moindre coup de tonerre, merci EDF) les EMO font un
recalibrate, et donc tournent tout les 4 en même temps :-(
Ceci dit, une programmation "maladroite" peut provoquer pas mal de
traffic.
Par exemple; quelques devices qui sont programmés pour envoyer leur
status plusieures fois par seconde...
Devinez qui a fait une erreur dans l'écriture d'une fonction logique
et de ce fait a fait une boucle :-( Bus saturé :-((
J'ai oublié de mentionner une contrainte bassement matérielle.
Suppose que tu n'as qu'un seul segment de câble qui fait tout le tour
de la maison et puis va dans le coffret.
Si tu veux installer plus de 64 devices, hé ben c'est rapé !
Soit tu installes un autre segment de câble (pas évident si les
travaux sont finis).
Soit tu "coupes" le câble quelque part vers le milieu et tu ajoutes un
coffret avec la 2ième alim et le coupleur/repeater. ûû
Perso, j'ai une vingtaine de segments, donc pas de problème de ce côté
là
On 31 août, 09:05, Ferllings <ferlli...@gmail.com> wrote:
> Ca fait donc 256 participants, avant d'avoir besoin de créer une
> nouvelle ligne (et donc d'utiliser un coupleur).
En cas de ré-organisation de l'architecture, il y a un avantage à
cette alternative:
il ne faut PAS changer les PA des devices, puisqu'il s'agit d'une
seule et même ligne.
Ce qui n'est pas le cas lors de la création d'une 2ième ligne avec
déménagement de devices de l'ancienne ligne.
|
