Verbindungen zum Bus / Linienkoppler

[Pendragon]

Moin!

Seit einiger Zeit prügle ich mich mit diesem Problem herum und finde keinen Ansatzpunkt es zu lösen. Grundsätzlich habe ich teilweise Problem von IP auf den Bus zuzugreifen:

Aufbau:
3 Linien mit Merten TP-Linienkopplern
Rapsberry mit PIGATOR und knxd in Linie 1.1
PeaKNX in Linie 1.1
Edomi
IOBroker

Das beschreibt schon das erste Problem: Ich wollte die Router in 1.0 setzen, konnte von dort aber nicht immer alle Linien erreichen. In 1.1 klappt es öfter.
Die beiden Server sind jeweils über knxd über Multicast mit dem Bus verbunden. Wenn ich nun mit der ETS Geräte programmiere, hängt sich danach mindestens der Bus-Zugriff von Edomi auf. Teilweise auch von beiden Servern, welche ich danach neu starten muss. (Ist auch teilweise egal welches Interface ich in der ETS wähle)

Da auch die Koppler ab und zu Zicken machen (lassen sich erst im 5. Versuch programmieren(Schreiben in Speicherbereich...), lassen teilweise nichts mehr durch,...) überlege ich diese zu ersetzen.
Nun ist die Idee eventuell beide Probleme mit einem Streich zu erschlagen. Wenn ich die Koppler durch IP Router ersetze, kann ich für jeden Server einen eigenen Zugriffspunkt definieren. Auch preislich liegen die Router nicht so weit von den reinen LK entfernt.

Habe ich in meinen Gedanken ganz grobe Fehler? Kann der Versuch funktionieren? Was läuft da falsch?

Danke schon mal für Eure Anregungen.

Beste Grüße
Christian

[gbglace]

Beschreibe doch bitte noch deine Topo detaillierter. Und wo sind da Deine Router ich kann da keine erkennen. Und was sind für Parameter in den LK eingestellt bzgl..Durchlass von PA adressierten Telegrammen?

[Pendragon]

Ich habe versuche die Topologie aufzumalen .

Die koppler sind alle auf filtern gestellt. Adressiert Telegramme werden natürlich durchgelassen

[gbglace]

Also die beiden "Router" sind auf jeden Fall komisch. Der Rest passt ordentlich.

Wenn die beide wirklich Routing Funktionalität bereitstellen sollen, dann wären die beiden definitv besser auf der Hauptlinie aufgehoben und müssten eine PA mit x.x.0 erhalten und da es auf der Hauptlinie aber nur eine Position mit ..0 gibt müsste das andere Gerät eben auf eine fiktive andere TP Hauptlinie Routen oder einfach nur ein IP-Teilnehmer auf der IP-Bereichslinie sein, welches per IP Telegramme sendet und empfängt aber eben keine Routerfunktionalität für andere IP-Geräte darstellt.

Den knxd einfach nur als schnittstelle benutzne geht nicht für die ETS? Da könnte der auch auf der TP-Linie sitzen bleiben.

[mumpf]

Hi,

ich mag mich irren, aber ich habe irgendwo noch ein Bild im Hinterkopf: In einem TP-Teilbaum ist immer nur ein Router zugelassen! Wobei der Router dann die Wurzel des Teilbaums ist. Dieser koppelt dann über IP die anderen TP-Teilbäume.

Bei Dir passiert folgendes: Der knxd schickt jedes Paket per Multicast ins IP-Netz, der PEAKnx empfängt des und schickt es wieder ins TP-Netz (mit einem anderen Routing Zähler), das geht dann wieder über den knxd raus usw. Ein Router ist ja immer ein Koppler, Du koppelst die Linie quasi an sich selbst.

Mach die beiden einfach als Schnittstellen und gut ist - bzw. nur einen als 1.0.0, den anderen aber auf jeden Fall als Schnittstelle! Ich würde die Schuld erstmal nicht den LK geben.

Ferner: Wenn Du die LK rauswerfen willst und IP-Kopplung machen willst, bringst Du in Deinen Bus eine andere Technologie mit rein und damit potentiell neue Fehlerquellen. Bei mir darf der IP-Router/-Switch ausfallen, und der KNX-Bus läuft immer noch. Bei Dir wäre das dann anders. Ich würde, wenn ich schon alle LK habe, nicht auf IP wechseln.

Edit: Göran war schneller...

Gruß, Waldemar

[Pendragon]

Super, vielen Dank. Ich fange an zu verstehen

Zunächst: Der Grund warum ich den knxd als Router und nicht als Schnittstelle laufen habe, ist, dass ich von mehreren Stellen darauf zurgeife (Edomi, iobroker,ETS). Das habe ich gedacht, ist mit einer Schnittstelle nicht möglich.
Der Router hat ja auch eine PA (1.1.180) und stellt 8 weitere Adressen von 1.1.181 bis 1.1.189 zur Verfügung. Somit weiß ich nicht, ob das zuordnen auf eine x.x.0 funktioniert.

Den knxd einfach nur als schnittstelle benutzne geht nicht für die ETS? Da könnte der auch auf der TP-Linie sitzen bleiben.

Das werde ich ausprobieren. Aber kann ich dann von 3 Stellen darauf zugreifen?

Wenn die beide wirklich Routing Funktionalität bereitstellen sollen

Das Routing/die Kopplung soll ja weiterhin über die TP-LK laufen.

Bei Dir passiert folgendes: Der knxd schickt jedes Paket per Multicast ins IP-Netz, der PEAKnx empfängt des und schickt es wieder ins TP-Netz (mit einem anderen Routing Zähler), das geht dann wieder über den knxd raus usw. Ein Router ist ja immer ein Koppler, Du koppelst die Linie quasi an sich selbst.

Das klingt auf jeden Fall sehr sinnvoll. Der PEAKKnx läuft auf meinem Windows Rechner. Dann müsste dieser Fall ja jedes Mal auftreten, wenn der Rechner an ist (was er sehr oft ist). Den "Fehlerfall" habe ich aber nur direkt nach dem programmieren über die ETS.

Ich würde, wenn ich schon alle LK habe, nicht auf IP wechseln.

Wäre ein sukszessiver Tausch, Koppler für Koppler, nicht möglich? (Werde den Tausch aber erstmal nach hinten schieben).

[gbglace]

Ich bin immer Fan von so wenig wie möglich IP in der KNX Anlage. IP ist zwar schnelllebiger im Bezug auf Innovation aber genauso im Bereich Unsicherheit.

Die zusätzlichen Andressen entstammen genau der Schnittstellenfunktionalität des knxd, und wenn der dann auf der Hauptlinie mit 1.0.0 sitzt werden die zusätzlichn Adressen dann wahrscheinlich 1.0.1 - 1.0.8 sein. Das sind dann auch normale TP-Adressen wie jetzt in der Linie 1.
Nutzen deine IP-Funktionen derzeit schon die PA-Adressen > 180 als Weg in deine KNX-Anlage, dann nutzen die quasi jetzt schon Tunneling und kein Routing.

Und ich vermute viele werden das Tunneling machen, weswegen ich es eh übertrieben finde in einem EFH sich nen Router zu verbauen, weil genutzt wird das von ganz wenigen Sachen, meist nur jene die echte zertifizierte KNX-IP-Geräte sind und eben nur KNX-IP sprechen. Die Geräte die Tunneling nutzen, sprechen halt eher KNX-TP haben aber nur nen LAN-Anschluss (so hab ich mir das als Laie mal einsortiert), trift technisch bestimmt nicht ganz am ende schauts aber so aus.

[mumpf]

Hi,

Zunächst: Der Grund warum ich den knxd als Router und nicht als Schnittstelle laufen habe, ist, dass ich von mehreren Stellen darauf zurgeife (Edomi, iobroker,ETS). Das habe ich gedacht, ist mit einer Schnittstelle nicht möglich.

in dieser Aussage erkenne ich mich direkt wieder! Eines der Forum-Mythen, auf die ich auch reingefallen bin: "Eine Schnittstelle kann nur ein Gerät" (war früher wohl auch so...). Darum habe ich auch den (damals noch) eibd genommen, da der ein Software-Router war so das Problem gelöst war... ohne dass ich wirklich wusste, was ich tat .

Aber eigentlich muss man von den Geräten (IP-Schnittstelle, KNX-Router) abstrahieren zu Tunnel-Verbindungen und Multicast. Beides ist für IP-Geräte gedacht, die mit KNX kommunizieren wollen.

• Tunnel: Ein bestimmtes IP-Gerät bekommt auf der KNX-Seite eine PA und ist somit auf der KNX-Seite wie ein "normales" KNX-Gerät zu sehen. Im Bus- bzw. Gruppenmonitor sieht man dieses IP-Gerät mit genau dieser PA, wobei das IP-Gerät selbst die PA nicht unbedingt kennen muss. Auf der IP-Seite ist es eine Point-to-Point-Verbindung von dem Gerät, dass den Tunnel erzeugt zu der IP, die das IP-Gerät hat.
• Multicast: Jedes KNX-Telegramm wird vom KNX-Netz ins IP-Netz gesendet, ohne auf der IP-Seite ein bestimmtes Gerät zu adressieren. Alle IP-Geräte können diese Nachrichten empfangen und entscheiden, ob sie darauf reagieren, genau so wie es jedes KNX-Gerät macht. Anders gesagt, der KNX-Bus wird "einfach" ins IP-Netz gespiegelt.

Heutzutage ist es üblich, dass ein KNX-Gerät "IP-Schnittstelle" Dir bis zu 4 Tunnel liefert. Damit kannst Du 4 Geräte mit Deiner KNX-TP-Linie kommunizieren lassen. Diese IP-Schnittstellen haben dann eine PA, die das Gerät selbst hat (damit man die Applikation in die Schnittstelle spielen kann) und bis zu 4 Tunnel-PA. Diese Tunnel-PA bekommen die einzelnen IP-Geräte, die über diesen Tunnel zugreifen.

Ein KNX-Gerät "Router" bietet Dir heutzutage üblicherweise beides: Bis zu 5 Tunnel UND Multicast. Tunnel werden wie bei der Schnittstelle angelegt (also weitere PA), die Router-PA wird für den Multicast genutzt. Ein Router hat normalerweise auch noch die Funktion eines LK implementiert, also die Filterung von Protokollen, aber nicht zwischen 2 TP-Linien, sondern zwischen dem IP- und dem TP-Netz. Damit kann man verhindern, dass alle Telegramme von der TP-Linie auf die IP-Linie kommen und umgekehrt.

Der knxd ist ein Software-Router, der dir einstellbar viele Tunnel liefert und natürlich Multicast, aber ohne Filter. Wenn man also Routing eingestellt hat, gehen alle Telegramme ins IP-Netz. Die von Dir erwähnten Adressen 1.1.181 - 1.1.189 sind die Tunnel-Adressen, die per Default angelegt werden (bei einer knxd-PA von 1.1.180). Damit kannst Du 8 IP-Geräte auf KNX zugreifen lassen.

Also ja, über den knxd kannst Du ohne Routing Edomi, iobroker und ETS laufen lassen. Ich lasse darüber ETS, callidomus und smarthomeNG.py laufen.

Der PEAKKnx läuft auf meinem Windows Rechner. Dann müsste dieser Fall ja jedes Mal auftreten, wenn der Rechner an ist (was er sehr oft ist). Den "Fehlerfall" habe ich aber nur direkt nach dem programmieren über die ETS.

Den PEAKnx kenne ich nicht und weiß nicht, was er als Router macht. Ich vermute, dass er GA-basierte Telegramme filtert, wenn sie von der selben Linie kommen (dann kommen die nicht als Wiederholungen zurück), PA-basierte aber nicht.

Da Dein Bus sowieso nicht sehr ausgelastet sein wird, klappt es selbst mit Wiederholungen im Normalbetrieb recht gut, beim Programmieren kommen aber viel mehr Telegramme und da wird nicht gefiltert, ergo es gibt mehr/häufiger Probleme. Ist aber nur eine Amateur-Vermutung. Bin hier eben kein Profi.

Ich würde folgendes machen: Den knxd in die 1.0 mit der PA 1.0.0, aber ohne Routing. Edomi, iobroker und ETS auf die generierten Tunnel-PA (default: 1.0.1, 1.0.2 und 1.0.3) gehen lassen. Der PEAKnx macht auch kein Routing und geht wie auch immer an den Bus. Damit sollte es erstmal stabil laufen.

Gruß, Waldemar

[Pendragon]

Hallo Waldemar,

vielen Dank für die Beschreibung. Solangsam macht es "klick". Habe den knx grade umgesteckt und das -R entfernt. Dummys wurden neu plaziert und die Koppler neu programmiert. Die Server haben neue PAs (wobei ich bei Edomi keine feste einstellen kann, er nimmt sich eine freie).

Werde mal drauf achten wie stabil das ganze bleibt. Es scheint sehr vielversprechend.

Danke!

Christian

[gbglace]

Ich denke das wird werden.

[mumpf]

Ja, ich hoffe auch, dass es sich jetzt bessert. Und falls es Probleme gibt, beschreibst Du den konkreten Fall und dann kann man die lösen.

Gruß, Waldemar