Keine Kommunikation zwischen KNX und Gira Homeserver 4

[TomasM]

1.1.x wäre völlig falsch, wie willst du denn das Gerät an die TP-Linie anschließen? Bitte die Grundlagen der KNX-Topologie mal im Auge behalten... Oder programmierst du auch TP-Geräte auf 1.1.x, obwohl du sie auf 0.0 (oder 1.0) anschließt?

Du hast hier ganz klar recht, aber ich bin mir mit der Sache doch recht unsicher. Da meine VISU Server immer TP auch haben hatte ich das halt noch nicht so gebraucht.
Ich habe 1.0.x HL und 1.1.x NL (IP Schnitstelle ist bei mir im 1.0.x)

Beispiel:

Wohin würde nun ggf. die Dummy APP für NodeRed / KNX-Ultimate-Plugin hingehören ? Ich meine die hat ja auch eine Phys Adresse gesetzt (bei mir 1.0.x) und der ETS Debug sieht auch soweit alles was das NodeRed macht unter der 1.0.x Adresse.

Die ETS ist doch eigentlich auch eine Art TCP IP Server der direkt auf die Schnitstelle geht z.B. fürs DEBUG, wenn ETS dann auch Befehle gibt (kann man Manuell auf den BUS Schicken) dann braucht die ja auch keine DUmmy APP als IP.

Ich bin davon ausgegangen, das Geräte die das IP Gateway Nutzen nicht unbedingt als IP Dummy APP Gerät rein müssen.

Son bissl bin ich gerade durcheinander, vielleicht kann mal einer Licht ins Dunkel bringen.

Mein IP Gateway ist von GIRA und da ist alles auf Standard gesetzt.
BUS->IP & IP -> BUS (Gleich)
Filtern (Hauptgruppe 0-13)
Ungefiltert (Hauptgruppe 14-31)
Filtern (Phys addr. Telegramme)


Tomas

[DirtyHarry]

Ich bin davon ausgegangen, das Geräte die das IP Gateway Nutzen nicht unbedingt als IP Dummy APP Gerät rein müssen.

Naja, grundsätzlich benötigst du für alles was die ETS nicht in der Datenbank hat einen Dummy, da sie sonst die Filtertabellen nicht automatisch erstellen kann. Unabhängig davon, ob per TP, IP oder RF angeschlossen...

Auch die ETS selbst bekommt keine Telegramme (oder kann sie schicken), wenn sie aus einer anderen Linie sind und nicht weitergeleitet werden.

Wenn du weder Linienkoppler, noch KNX/IP-Router hast (also für die ETS eine USB- oder IP-Schnittstelle nutzt), stellt sich die Frage nicht. Sobald du aber einen KNX/IP-Router hast, hast du schon 2 Linien und es kommt drauf an, wie du die ETS verbindest (wie ich es in #11 schon erklärt habe).

Mein IP Gateway ist von GIRA

IP-Gateway ist so ne WischiWaschi-Bezeichnung, bei der man dann gar nichts weiß. Ist das Schnittstelle, ist das Router? (Ich kann dir z.B. sagen, die alten ABB IP-Gateways waren zwar sowas wie Router, basierten aber nicht auf dem heutigen KNX/IP und sind dementsprechend auch nicht kompatibel dazu.)
Zudem wechselst du die Bezeichnungen für das Gerät innerhalb eines Posts. Mal Schnittstelle, mal Gateway, zudem dann Einstellungen eines Routers/Linienkopplers...

Gehen wir mal davon aus, du hast einen KNX/IP-Router, der die Adresse 1.0.0 hat. Dann ist die Linie 0.0 deine IP-Linie und alle KNX/IP-Geräte bekommen eine Adresse von dieser Linie. Dann hast du eine Linie 1.0, die muss dann natürlich TP sein. Außerdem hast du laut deiner Aussage noch eine Linie 1.1.
Du hast also 2 Spannungsversorgungen, eine Linienkoppler und den KNX/IP-Router (ansonsten ist deine Topologie falsch und wir brauchen gar nicht weiter darüber zu reden).
Zum Testen könntest du nun eine GA anlegen, mit einem Gerät in der Linie 1.1 verbinden und programmieren. Dann gehen wir mal davon aus, auch dein Linienkoppler steht auf Filtern. Probiere dann mal

1. die ETS per Routing oder Tunneling mit dem KNX zu verbinden und mit der frisch angelegten GA das Gerät in der 1.1 zu schalten.
2. Als nächstes legst du eine Dummy in die Linie 1.0, verknüpfst die GA und programmierst deinen Linienkoppler. Anschließende wieder die beiden Tests mit der ETS.
3. Und als letztes schiebst den Dummy mit der GA in die Linie 0.0 programmierst den KNX/IP-Router und machst nochmal den Test mit der ETS.

Hinweis: Tu dir eine Gefallen und programmiere die Koppler/Router vollständig. Ich hab jetzt schon mehrfach den Fehler gehabt, dass die ETS die Änderung der Filtertabelle nicht angezeigt hat und partielles Programmieren dann gar nichts gemacht hat. Zudem habe ich oben nur den wirklich betroffenen Router/Koppler aufgelistet, du kannst auch immer beide programmieren.

Ich nehme mal das Ergebnis vorweg:
Im ersten Fall geht gar nichts. Im zweiten Fall funktioniert es mit Tunneling, bei Routing nicht. Im dritten Fall ist es egal, funktioniert es immer.



Auch wenn das jetzt nicht ganz auf das Problem des TE gemünzt ist, hoffe ich doch dass es auch ihm die Topologie und das Verhalten der Filtertabellen näher bringt und er dadurch vielleicht sein Problem beheben kann.

[TomasM]

Du hast also 2 Spannungsversorgungen, eine Linienkoppler und den KNX/IP-Router (ansonsten ist deine Topologie falsch und wir brauchen gar nicht weiter darüber zu reden).

Zum Testen könntest du nun eine GA anlegen, mit einem Gerät in der Linie 1.1 verbinden und programmieren. Dann gehen wir mal davon aus, auch dein Linienkoppler steht auf Filtern. Probiere dann mal[LIST=1][*]die ETS per Routing oder Tunneling mit dem KNX zu verbinden und mit der frisch angelegten GA das Gerät in der 1.1 zu schalten.[*]Als nächstes legst du eine Dummy in die Linie 1.0, verknüpfst die GA und programmierst deinen Linienkoppler. Anschließende wieder die beiden Tests mit der ETS.[*]Und als letztes schiebst den Dummy mit der GA in die Linie 0.0 programmierst den KNX/IP-Router und machst nochmal den Test mit der ETS.

Hallo Andreas,
lieben Dank für deine Ausführliche Info und Lernkurs.. Ich nenn das mal so :-) Natürlich sollte man in einem Post bei einem "wording" bleiben, sorry, glücklicherweise hast Du alles korrekt übersetzt :-) Daraus können sicher auch andere Einsteiger lernen.


Ich hab folgende Konfig:
1.0.xHauptlinie TP (IP-Router / Netzteil / Taster Aktoren etc...)
1.1.x Linie Aussenbereich TP (Koppler / Netzteil / Wetterstation etc.)
0.0.x wäre dann der Backbone IP hier hab ich aktuell (noch) keine Geräte.

Damit die 1.0.x Geräte mit 1.1.x reden können,bzw umgekehrt hab ich bestehende Filter die durch die GA´s ja automatisch erstellt werden. Testweise hat die Kommunikation ohne Filter nicht funktioniert :-))

Soweit erstmal zum Setting. Nun was ich nun verstanden habe:

1 ) Ein HS4 (HomeServe4) würde dann als Dumy korrekterweise als IP Gerät in die Linie 0.0.x kommen. Alle GA´s die man halt benötigt, müssten dann mit dem Dummy verbunden werden.

2) Alternativ würde der HS4 aber auch der HL 1.0.x funktionieren wenn er denn mit dem IP Router direkt über Tunneling reden könnte. (Das geht ja anscheinend nicht).

3a) Mein Node-Red mit dem KNX Ultimate hat aktuell eine Dummy in der 1.0.x Linie, und spricht direkt mit dem Gateway über seine IP/Port mit Tunnel UDP. (so ist zumindest die Konfig im NodeRed/KNXU)

3b) Ein Routing würde nur dann funktionieren wenn er eine Adrese im 0.0.x bekommt und die Filter wären korrekt.

-->
Doku aus dem KNX Ultimate (NodeRed)
Tunnel UDP is for KNX/IP interfaces, Multicast UDP is for KNX/IP Routers.
-->

So gesehen kann ich meine Dummy APP für den "NodeRed KNX Teil" in der HL 1.0.x lassen, wenn ich mein GIRA IP Router als KNX/IP Interface nutze). Bei Multicast UDP müsste ich in die 0.0.x.


Ich dachte das der HS4 eine ähnliche Kommunikation aufbauen könnte wie mein KNX Ultimate, und dann eben halt nicht eine Dummy APP in IP Linie braucht.

Ich hab nun hoffentlich keinen Denkfehler :-))

Grüße
Tomas

[DirtyHarry]

Ich hab nun hoffentlich keinen Denkfehler :

Wenn ich dich nirgendwo missverstanden hab, würde ich sagen passt.

1. Korrekt
2. Richtig. Grundsätzlich kann der HS mittlerweile Tunneling. Dem offiziellen nach aber nur mit Secure, während bei mir mittlerweile 2 Anlagen laufen bei dem die Tunnel des S1 Unsecure sind (1x Secure in Betrieb genommen, 1x komplett Unsecure).
3. Wenn das Node-Red auch Routing spricht... Ansonsten korrekt.

Nochmal in Kurz, die Dummys gehören immer dahin, wo auch das Gerät ist.
Beim Routing ist es topologisch oberhalb des Routers, beim Tunneling unterhalb (der Tunnel geht ja am eigentlichen "Router" vorbei in die Linie, erkennt man auch an den PAs der Tunnel).
Ob man die GA, die auch an Geräten in dieser Linie verknüpft sind, auch mit dem Dummy verknüpft, ist der Filtertabelle egal, jedoch ist es sinnvoll das zu tun (nach mehrern Jahren entfernt man das Gerät und wundert sich nach der nächsten Programmierung der Koppler, dass nichts mehr geht).

[gbglace]

Son bissl bin ich gerade durcheinander, vielleicht kann mal einer Licht ins Dunkel bringen.

Jedes Stück Software welches KNX-Spricht sieht genau jene Telegramme wo sein Schnittstellenrüssel auf die Topologie des KNX-Busses trifft.

Hast eine KNX-IP-Schnittstelle dann sieht eine Software die einen solchen Tunnel verwendet alle Telegramme die auf dieser Linie zirkulieren wo die Schnittstelle eben endet.

Wenn die Segmentierung in Linien des Busses derart gut gemacht ist das Telegramme einer Linie keinen Bedarf haben in einer anderen Linien unterwegs sein zu müssen, dann ist da auch jede Software blind für diese Telegramme, wenn die Schnittstellen-Endpunkte auf eine andere Linien zeigen.

Dabei ist es vollkommen egal ob das Stück Software ein Gira-HomeServer, eine ETS, ein RPI mit NodeRed oder was auch immer ist.

Und es ist auch egal ob es ein KNX-IP-Interface oder eben ein KNX-IP Router ist. Das ändert nur ein wenig die Art wie die Software dann KNX-Spricht.

Also solange durch Linienkoppler eine effektive Segmentierung eingerichtet ist, sieht man nix was auf den anderen Linien so los ist.

Was die ETS mehr kann ist, das sie eben nicht nur normale Gruppentelegramme beherrscht, sondern auch physikalischadressierte Telegramme und da gelten in den Kopplern per Default andere Regeln was durchgelassen bzw. gefiltert wird. Daher kann die ETS hinter einem Interface oder einem KNX-IP-Router meist auch ohne Probleme in allen Linien im Bus Geräte programmieren. Aber auch die ETS wird an einem Schnittstelle-Tunnel 2.1.x keine GA senden können auf die dann ein Aktor an der Linien 1.3.x reagiert, sofern nicht an den zwei notwendigen LK#s auf dem Weg dazwischen diese GA in den Filtertabellen steckt.

Filtertabellen füllt die ETS sowie sie sieht das GA's auf beiden Seiten benötigt werden.

Und wenn man neue GA generiert, muss man dann auch immer den Aktor und Taster und eben die notwendigen LK's programmieren, sonst funktioniert zwar das Schalten am Taster aber nicht an der Software / Server.

Wenn Du mehrere solcher Software-Elemente hast genügt auch ein Dummy auf der einen Linie wo die IP-Seite landet. Denn ob Dein NR nun die PA 1.0.4 oder 1.0.5 hat kannst nur bei ganz ganz wenigen Schnittstellen definieren (fixe Zuordnung IP-Adresse zu KNX-Tunnel). Nur beim Routing kannst das klar definieren, aber da würde auch ein Dummy genügen für alle IP-Geräte die eine PA auf der 0.0.x haben.

Andere Alternative, man benutzt Server für Visu/Logik die selbst eine ETS Applikation haben und entsprechend sichtbar eine effektive Verbindung GA zu KO haben an denen man dann auch passenden mit Flags und Mehrfachzuordnungen von GA's die Kommunikation mit dem Bus gestaltet.

[DirtyHarry]

Aber auch die ETS wird an einem Schnittstelle-Tunnel 2.1.x keine GA senden können auf die dann ein Aktor an der Linien 1.3.x reagiert, sofern nicht an den zwei notwendigen LK#s auf dem Weg dazwischen diese GA in den Filtertabellen steckt.

2 Router würde ja noch passen, aber bei LK sind es 4.

[gbglace]

Jep die beiden HL müssen ja auch noch zur Bereichslinie gekoppelt werden.