Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[gaert]

Gibt's denn schon neue Erkenntnisse in Sachen Router/PA/etc.? Ist plötzlich so still geworden...

[apoc4lyps]

und dann gleich noch eine hoffentlich nicht zu blöde Frage (keine Ahnung was das technisch für einen Aufwand bedeuten würde...):

wäre es für EDOMI mit entsprechender Zielhardware (das heutige wiregate scheidet ja wohl leider als Plattform aus da kein 64Bit System...) per USB oder Seriellem Port auch eine Möglichkeit wie beim Wiregate über ein TPUART direkt ohne eine separate IP Schnittstelle auf den Bus zu gehen? Oder gibt es irgendwelche Gründe für eine separate KNX IP Schnittstelle? Ich habe bisher beim WG mit TPUART noch keine vermisst...

Naja du könntest einfach ein TPUART an den Server klemmen, eibd oder knxd konfigurieren und EDOMI als IP 127.0.0.1 geben.

gaert
Respekt was du da auf die Beine stellst!!

[coliflower]

Ich hoffe ich verwechsle hier nicht etwas aber hat nicht Christian geschrieben, dass er sein eigenes KNX-Stack entwickelt hat und somit TPUART via USB-Stick nicht notwendig ist ?

Hat er

EDOMI kommuniziert ausschließlich direkt mit einem IP-Router (ggf. auch mit einer IP-Schnittstelle). Alles andere wird zumindest aktuell nicht unterstützt. Den eibd habe ich ursprünglich tatsächlich eingebunden - aber dieses Gedanken dann wieder verworfen. Ob EDOMI auf irgendeinem Weg dennoch mit eibd "sprechen" kann, weiß ich nicht - es ist aber zumindest NICHT so vorgesehen!


EDIT: Huch?! Irgendwie habe ich jetzt DEINEN Beitrag editiert??? Bin ich jetzt Admin?!

[coliflower]

Nur so eine Frage, macht es Sinn um sich von Routerhardware unabhängig zu machen, EIBD (KNXD) in Edomi zu implementieren … so á la WG ?

[gaert]

Würde ich gerne versuchen - nur leider habe ich es noch nie geschafft mehr als eine Tunnelverbindung gleichzeitig zu etablieren. Auch lange vor EDOMI, mit der ETS, eibd, etc...

Wie gesagt: Meinem Verständnis nach hat man ohnehin keine Tunnelwahl, zumindest gibt die Spec nichts dergleichen her.

[SeatSLF]

Die PA scheint essentiell zu sein - ich habe gerade mal spaßeshalber die 0.0.0 angegeben und erhalte nun genau die erwähnten Fehlermeldungen (3 Versuche, dann Abbruch). Mit der PA 0.0.1 funktioniert es ohne Probleme bei mir.

Die aktuelle KNX-Spec enthält für mich keine neuen Informationen - der Verbindungsaufbau (CONNECTION_REQUEST) und das Tunneling (TUNNEL_REQUEST) ist korrekt implementiert - es funktioniert ja auch mit meinem Router... Vielleicht ist tatsächlich "nur" die PA das Problem?!

Das Hauptproblem bei einer Tunnelverbindung wird immer der Router sein, weil er die Tunnel frei vergibt.
Ist Tunnel 1 besetzt, macht er den zweiten auf usw.
Man müsste nun aufpassen das EDOMI immer den selben Tunnel bekommt,
da sonst wieder die Probleme anfangen.

Es sei den man könnte dem Router eine Art IP Binding beibringen, sodass nur EDOMI mit seiner IP
den Tunnel mit der passenden PA bekommt.

Christian du könntest spaßenshalber mal versuchen EDOMI auszuschalten, warten bis der Tunnel von deinem Router
geschlossen wurde. Dann verbindest du dich mit der ETS auf diesen Tunnel und startest dann EDOMI.
Sodass EDOMI bei dir mal auf einen anderen Tunnel "gezwungen" wird.

[gaert]

gaert
Hallo Christian, wenn du in der ETS schaust, welche PA siehst du im Monitor wenn du ein Befehl via EDOMI absetzt ?
DANKE.

0.0.1 (so wie in der edomi.ini konfiguriert)

Ich schätze mal, dass mein Router irgendwann auf die 0.0.1 konfiguriert wurde - ist schon lange her...

[coliflower]

gaert
Hallo Christian, wenn du in der ETS schaust, welche PA siehst du im Monitor wenn du ein Befehl via EDOMI absetzt ?
DANKE.

[GLT]

[USER="18706"]Der Homeserver braucht keinen Tunnel da er über Multicast mit dem Router "redet"

Und weswegen man auch keine IP-Schnittstelle verwenden kann

[gaert]

Soweit ich die Spec verstehe, ist die PA nicht frei wählbar (wie ich ursprünglich dachte) - vielmehr muss dies die PA des Router sein. EDOMI selbst hat ja in diesem Sinne keine PA - EDOMI kommuniziert ja nur per UDP mit dem Router (also auf Network-Ebene).

[gaert]

Die PA scheint essentiell zu sein - ich habe gerade mal spaßeshalber die 0.0.0 angegeben und erhalte nun genau die erwähnten Fehlermeldungen (3 Versuche, dann Abbruch). Mit der PA 0.0.1 funktioniert es ohne Probleme bei mir.

Die aktuelle KNX-Spec enthält für mich keine neuen Informationen - der Verbindungsaufbau (CONNECTION_REQUEST) und das Tunneling (TUNNEL_REQUEST) ist korrekt implementiert - es funktioniert ja auch mit meinem Router... Vielleicht ist tatsächlich "nur" die PA das Problem?!

[coliflower]

Bei mir meldet sich EDOMI in der ETS mit 1.1.201 obwohl in der edomi.ini die 1.0.2 eingetragen ist ...

Sooooo, wenn ich in der edomi.ini anstatt der EDOMI-HOST-PA 1.0.2 die in der ETS5 sichtbare TUNNEL-PA 1.1.201 einstelle, dann funktioniert es.
Mit 1 wird ein-, mit 0 ausgeschaltet …
Kein ERROR LOG mehr ...

Da ist die Frage offen, ist die edomi.ini PA eine HOST- oder TUNNEL-PA (Edomi tunnelt ja die Verbindung zum KNXnet/IP-Router …)

[coliflower]

Bei mir meldet sich EDOMI in der ETS mit 1.1.201 obwohl in der edomi.ini die 1.0.2 eingetragen ist ...

[SeatSLF]

Robby du musst ihn noch nichtmal ausschalten, die Tunnel werden nach 2 minuten automatisch geschlossen.
Der Homeserver braucht keinen Tunnel da er über Multicast mit dem Router "redet"

[basaltnischl]

Bei mir war es egal was ich für eine PA eingetragen habe. EDOMI hat immer mit 1.1.101 gesendet (zu sehen im Gruppenmonitor der ETS). Als ich die PA auf 1.1.101 gelegt habe ging es.
Ich habe aber keine Erklärung warum die Einstellungen nicht gezogen haben.