KNX IP Router; Quell-PA bei Multicast Routing in Spectrum KNX / Home Assistant

[TabSel]

Ich hab einen Enertex IP Secure Router in meine Anlage implementiert:
image.png
image.png

image.pngfür Home Assistant ist der Tunnel #1 vorgesehen.
Spectrum KNX in Home Assistant (NOT Companion) ist konfiguriert um keinen Tunnel, sondern Multicast Routing zu nutzen.

Wenn ich in Spectrum KNX ein Telegramm sende, dann sehe ich das Telegram mit der Quell-IP 15.15.250 im Gruppem-Monitor der ETS.

Warum? Wie sind denn da die Zusammenhänge? Ich hätte als Quell-Adresse die PA des Routers 1.0.0. erwartet....

[Klaus Gütter]

Nein, bei Routing wird das Telegramm vom HA generiert und vom IP Router nur weitergeleitet. Die Quelladresse muss daher irgendwo außerhalb deiner TP Linie sein.

[TabSel]

danke, ich verstehe, die Quell-Adresse steckt im gerouteten Telegramm und wird vom router nicht geändert.
die Anwendung "Spectrum KNX" innerhalb Home Assistant (NICHT companion, also unabhängig konfiguriert (multicast) von der Konfiguration der KNX-Integration (tunnel) in HA) vergibt also die Sende-PA.

Vermutlich kann ich in der Spectrum KNX Konfiguration mit dem Parameter "KNX_INDIVIDUAL_ADDRESS" die Sende-PA spezifizieren mit der Spectrum KNX multicast-routing-telegramme sendet...

Klaus Gütter : kann ich die Sende-Adresse von Anwendungen die KNX IP Routing verwenden bedenkenlos auf die PA des Routers einstellen, also 1.0.0? Ein Router kann ja keine KOs haben, es kann also keine Gruppen-Telegramme auf dem Bus mit Sendeadresse 1.0.0 geben, außer eben die gerouteten... oder handle ich mir damit Probleme ein bei an PA adressierten Telegrammen, Geräte-Info, Programmierung...? Wobei das ja nur durch die ETS geschieht, und die verwendet Ihren eigenen Tunnel 1.0.255 vom eibpc2 mit 1.0.253...
So wie ich es verstehe schicken Anwendungen ja keine physikalisch adressierten Telegramme, reagieren auch nicht auf physikalisch adressierte Telegramme, sollte also doch nix ausmachen, oder?

[Klaus Gütter]

Warum würdest du das machen wollen? Ich sehe darin keinen Sinn, stiftet IMHO nur Verwirrung.

Ich würde in der ETS an der Adresse, die diese Anwendung benutzt, einen Dummy platzieren und ihn "Spectrum KNX" nennen, dann siehst du diesen Namen als Quelladresse.

Im Übrigen: dass Router keine KOs haben können, ist zwar im Moment so, aber das muss nicht so bleiben.

[TabSel]

ich verstehe.
machen wollte ich das deswegen, um im ETS gruppenmonitor als Quell-PA den Router 1.0.0 zu sehen, dann weiß ich „kommt aus irgendnem Multicast nutzenden Programm…

ich hab jetzt bei Spectrum KNX (routing) innerhalb Home Assistant (mit KNX Integration per Tunnel 1.0.1) die KNX_INDIVIDUAL_ADDRESS 1.0.1 vergeben, das Telegramm kommt ja von ner Homeassistant-Anwrndung, ich sehe HomeAssistant als Quelle. und dann braucht’s auch keinen Dummy, das „Gerät“ 1.0.1 ist ja schon vorhanden.

[0per8or]

Ich habe heute Vormittag gerade das selbe gemacht, da ich alles von Tunneling auf Routing umgestellt habe. Ich habe mir einfach ein Segment 0.0 angelegt. Home Assistant hat jetzt die 0.0.1 und SpectrumKNX die 0.0.2. So ist die Zuordnung überall eindeutig.

[TabSel]

und dummys für die 0.0.x?
hab ich auch überlegt. Ich finde aber HA (und mit dem Bus dediziert interagierende Applikationen) macht sich besser per dediziertem Tunnel angebunden...
spectrum KNX ist für mich jetzt keine interagierende, sondern eher analytische App, da braucht’s keinen dedizierten Tunnel. Nur als Telegramm-Quelle will ich schon wissen wer oder was das Telegramm sendete, da genügt mir im ETS gruppenmonitor aber die Info „Home Assistant“, wenn ich per Spectrum KNX in Home Assistant sende weiß ich ja was ich grad tu…

wie auch immer, topologisch finde ich 1.0.1 für homeassistant über Tunnel und routing eines Routers 1.0.0 stimmiger als 0.0.x….

[gbglace]

als Quell-PA den Router 1.0.0 zu sehen, dann weiß ich „kommt aus irgendnem Multicast nutzenden Programm…

Also wenn ein Software-Service natives KNX-IP beherrscht, dann sollte dieser Software-Service auch in der Lage sein sich eine spezifische PA verpassen zu lassen. So wie Du es oben auch mit der INDIVIDUAL_ADRESS gefunden hast.

Warum also für diesen und weitere solcher Art-Services alles auf die Router-PA Mappen und wieder Übersicht verlieren wer es denn nun wirklich war der gesendet hat?

Dann baust Dir halt eine IP-Linie und packst das Dummies rein für jeden dieser Softwareservices einen mit der exacten PA und schon hast auch im Buslog volle Transparenz wer da gesendet hat.

Oder willst da erst noch parallel das Netzwerk mit allen KNX Paketen loggen?

Ich habe mir einfach ein Segment 0.0 angelegt.

Im KNX nennt sich eine Linie 0.0 Backbone/Bereichslinie.
Segmentkoppler sind da glaube nicht drauf zulässig, sofern als Medium IP angelegt.

Ich würde eher eine Hauptlinie oder gar eigene Linie dafür verwenden.
Je nach Menge an verwendeter KNX-IP Geräte kann das natürlich auch eine TopologieStruktur ergeben und PAs nach IP Geräte je Etage / Gebäudeteil usw. aufteilen.

Innerhalb des Medium IP gibt/benötigt es ja keine Linienkoppler um 2.3.45 mit 8.6.138 via 25/7/202 reden zu lassen.

[0per8or]

Ja, beide haben Dummy Objekte. Ich wollte für mich auch eine optische Trennung von IP- und TP-Geräten haben. Alles was Routing ist, landet in 0.0. Alle TP-Geräte landen in 1.x.

Im KNX nennt sich eine Linie 0.0 Backbone/Bereichslinie.

Der Backbone ist als IP-Medium angelegt. Um dann aber eine Linie 0.0 zu bekommen, muss ich in der ETS "Hinzufügen > Segmente" sagen.

[gbglace]

Naja die ETS war schon immer komisch in Ihren Bezeichnungen im UI.

Der Backbone ist einfach die engliche Bezeichnung der Bereichslinie. Ist halt in der Hierarchie die oberste Linie 0.0 mit Ihren Teilnehmern 0.0.x.

[Klaus Gütter]

Du kannst Geräte (und Dummies) auch direkt auf den Backbone ziehen, ein extra Segment ist nicht nötig.

[Noschvie]

alles von Tunneling auf Routing umgestellt

Routing=Multicast hat doch den Nachteil, dass IP-Telegramme verloren gehen können, ohne dass man es merkt. Eine Tunnel Connection gewährleistet eine zuverlässige Übertragung, da Telegramme quittiert werden und Übertragungsfehler erkannt werden können.

[mumpf]

Ich würde für solche generischen Applikationen wie HA oder SpectrumKNX auch eher Tunneling nutzen - vorausgesetzt, alles interessante ist unterhalb 1.0. So vermeidet man, dass man den Router auf Durchzug stellen muss. Und ich gehe davon aus, dass SpectrumKNX ja alle Telegramme aufzeichnen können soll und auf jede GA schreiben können soll.

Gruß, Waldemar

[TabSel]

ich habe einen linienkoppler der die außenlinie mit der hauptlinie verbindet, da wird gefiltert.
für die ETS und dessen Programm stellt der eibPC2 zwei udp-Tunnel auf die hauptlinie bereit.
der knxip router ist für "alles andere" ip-gezeugs. der steht auf Durchzug. für dedizierte Anwendungen wie HomeAssistant nutze ich einen tcp-tunnel. Für mainly read-only/Analyse-Zeugs wie Spectrum KNX Routing

[mumpf]

Klar, jeder darf das machen, was er will. Nur manche wissen eben nicht, was sie tun . Router auf Durchzug kann bedeuten, dass man die IP-Linie flutet. Deswegen versuche ich, so was zu vermeiden. Aber wenn Du das im Griff hast, spricht nichts dagegen, es so zu machen, wie Du es machst.

Gruß, Waldemar