OpenKNX IP-Router

[stonie2oo4]

Besten Dank

[mobil750]

Hallo zusammen,

ich bin gerade auf ein komisches Problem gestoßen. Ich habe nun seit fast einer Woche den IP-Router ohne Probleme in Betrieb. Ich programmiere damit erfolgreich meine Geräte - bis auf mein MDT KNX Netzteil. Wenn ich da den Upload oder auch "Gerät neu starten" in der ETS starte, kommt sofort

Netzteil.png

Alle anderen Geräte lassen sich mit dem IP-Router programmieren ...

Was könnte das sein?


Nachtrag: ich habe ein 2. KNX Netzteil hinter einem Linien-Verstärker (Koppler auf transparent geschaltet) und das kann ich problemlos programmieren.

Netzteil-2.png


Gruß
Helmut

[traxanos]

dein netzteil läuft aber nicht im secure mode?

[Ing-Dom]

Eine Aufzeichnung (ETS Gruppenmonitor oder Wireshark) mit dem Verbindungsaufbau und Abbruch wäre nicht schlecht. Dann kann man ggf mehr sagen.

[mobil750]

Nein kein Secure Mode ...

Habe heute meinen Rechner neu hochgefahren und siehe da, ich kann das Gerät wieder ansprechen. Der erste Programmierlauf ist zwar schief gegangen aber beim 2. klappte es dann. Dieses Verhalten hatte ich bislang nicht. Wie gesagt gestern hat das NT sofort abgelehnt. Ich habe beide Programmiervorgänge mit der ETS aufgezeichnet. Falls jemand draufschauen will, kann ich sie gerne hochladen.

Falls mal wieder so ein Fall (sofortige Ablehnung) auftritt, mache ich gleich einen Trace.

Danke und Gruß
Helmut

[Ing-Dom]

Falls jemand draufschauen will, kann ich sie gerne hochladen.

würde ich mir gerne ansehen !


Genau darum geht es ja in der Beta-Phase. Solche seltenen Spezialfälle irgendwie herauszufinden und ggf. zu beheben.
Dass unsere OpenKNX FW keine aufwändigem Zertifizierungs- und ComplianceTests durchlaufen ist ja klar, da kommt die Qualität dann durch das Feedback aus dem Feld.

[mobil750]

Gerne, ich hoffe das hilft ...

[Ing-Dom]

2024-04-06 10_26_10-Window.png Das proggen scheitert, weil dein NT (1.1.1) nicht auf den Memory_Write mit einem Memory_Response antwortet.
Wo das Antworttelegram verloren geht, ob das NT es nicht schickt oder der Router es nicht weiterleitet, kann man hier nicht erkennen.
Ich würde aber stark vermuten, dass es NICHT am Router liegt, denn alle anderen Telegramme mit der gleichen Verbindungsart imd Quell- und Zieladresse gehen ja durch.

Das war über Tunneling, oder?

Sollte das nochmal auftreten wäre es gut wenn du dann alternativ probierst über Routing zu proggen oder noch besser, über ein alternatives Interface.

[stonie2oo4]

Ich weiß jetzt nicht ob ich ein Problem mit dem Router hab oder es allgemein an meinem Verständnis liegt, aber ich würde trotzdem gerne verstehen wie es funktioniert.
Folgendes Szenario hab ich hier:
Edomi ist per Tunnel mit dem Router verbunden und sendet mir in gewissen Intervallen Werte meiner Wärmepumpe und Lüftung auf den Bus.
Telegraf / influx auf einem anderen Gerät ist per Routing mit dem KNX-Router verbunden und lauscht auf die Telegramme und schreibt diese dann in die Datenbank.

Nun hab ich gedacht die komplette Kommunikation läuft im IP-Backbone ab und ich muss nichts weiteres machen.
Aber telegraf erkennt die Werte erst wenn ich in der Hauptlinie (in welcher der Router sitzt) ein Dummy mit den GAs befülle.

Zum Test hab ich auch mal versucht die Werte von Edomi in nodeRed (per tunnel und multicast) abzufragen, aber auch hier geht es wieder nur wenn ich einen Dummy in der Hauptlinie mit den GAs die ich abfragen möchte anlege.

Hier mal meine Topologie: (1.0.- ist der alte Router und geparkt)
Screenshot 2024-04-07 201344.png

Die Hauptlinie ist ja TP und wenn ich hier eine Dummy anlege mit den GAs die mir Edomi über IP sendet, dann sind doch die ganzen Telegramme auch auf der (TP) Hauptlinie, oder seh ich das falsch?
Gibt es eine Möglichkeit die gesamte Kommunikation nur über IP laufen zu lassen?

[mumpf]

Hi Ben,

es ist wirklich so, dass Du da einiges verweschselst...

Erstmal zur Theorie: Nur weil verschiedene Geräte IP reden, müssen sie sich nicht verstehen. IP ist das Übertragungsmedium, nicht mehr. Wenn Menschen sprechen, nutzen sie Schall als Übertragungsmedium, einen Portugiesen wirst Du aller wahrscheinlichkeit nach hören können, aber nicht verstehen.
Eine Tunnelverbindung ist eine andere Verbindungsart als eine Routerverbindung, die bekommen nichts voneinander mit und verstehen sich auch nicht. Somit ist der Gedanke falsch:

Nun hab ich gedacht die komplette Kommunikation läuft im IP-Backbone ab und ich muss nichts weiteres machen.

Jetzt zum Rest der Beschreibung:
Eine Tunnelverbindung vergibt genau einem Gerät, der auf der IP-Seite des Tunnels ist, im KNX eine PA, die dann exakt auf der Linie liegt, die die PA repräsentiert. Bei Deiner Topologie müsste die PA irgendwas mit 1.0.x sein.
Wenn Edomi also über einen Tunnel verbunden ist, dann sendet Edomi mit einer PA 1.0.x und alle Pakete sind sowieso auf der Linie 1.0. Da ist kein Dummy nötig.
Das kannst Du im Gruppenmonitor für die Linie 1.0 sehen.

Da Du sagst, Telegram/Influx sind per Routing verbunden, sitzen sie aus Sicht des Routers auf der Linie 0 (IP-Backbone). Jetzt ist die Frage, wie der Filter im Router eingestellt ist, ich vermute mal, der filtert. Dann bräuchtest Du aber einen Dummy auf der Linie 0 und nicht auf der Linie 1.

Es gibt bei dem, wie Du es beschreibst, keinen Grund für den Dummy auf 1.0.2. Ich vermute mal ein Topologieproblem, sonst kann ich mir das nicht erklären.
Funktioniert es denn mit dem anderen Router ohne Dummy? Es kann ja sein, dass auch bei unserem Router noch irgendwas nicht stimmt.

Gruß, Waldemar

[Ing-Dom]

ist telegraf/influx tatsächlich per Routing angebunden?
ALs ich das vor 1-2 Jahren mal ausprobiert habe, war damit nur tunneling möglich.

Das würde auch das Verhalten erklären - den Tunnel-Endpoints gehören logisch zur Sublinie, also in dem Fall der TP-Linie 1.0.x.
Jedes (Gruppen) Telegram, das per Tunnel => IP gesendet wird, wird auch auf der Linie gesendet.
Insofern sind Tunnelverbindungen ungeeignet, um eine Entlastung der TP-Linie zu erreichen.

[mobil750]

2024-04-06 10_26_10-Window.png Das proggen scheitert, weil dein NT (1.1.1) nicht auf den Memory_Write mit einem Memory_Response antwortet.
Wo das Antworttelegram verloren geht, ob das NT es nicht schickt oder der Router es nicht weiterleitet, kann man hier nicht erkennen.
Ich würde aber stark vermuten, dass es NICHT am Router liegt, denn alle anderen Telegramme mit der gleichen Verbindungsart imd Quell- und Zieladresse gehen ja durch.

Das war über Tunneling, oder?

Sollte das nochmal auftreten wäre es gut wenn du dann alternativ probierst über Routing zu proggen oder noch besser, über ein alternatives Interface.

Ja das war Tunneling. Ich werde das weiter beobachten und entsprechend berichten - sofern es Probleme gibt.

Gruß
Helmut

[mumpf]

Das würde auch das Verhalten erklären

Das Verhalten ließe sich nur erklären, wenn Edomi über die Routerverbindung angeschlossen wäre und Telegraf/Influx über einen Tunnel 1.0.x. Dann wäre nämlich der Dummy 1.0.2 auch erforderlich, damit die Edomi-Werte durch den Router auf die 1.0-Linie kommen, um dann per Tunnel an Telegraf/Influx weitergeleitet zu werden.

stonie2oo4: Wenn alles auf der IP-Seite "abgefrühstückt" werden soll, müssten beide (Edomi und telegraf/influx) KNXnet/IP, also das KNX-IP-Protokoll reden.

Gruß, Waldemar

[stonie2oo4]

Jetzt zum Rest der Beschreibung:
Eine Tunnelverbindung vergibt genau einem Gerät, der auf der IP-Seite des Tunnels ist, im KNX eine PA, die dann exakt auf der Linie liegt, die die PA repräsentiert. Bei Deiner Topologie müsste die PA irgendwas mit 1.0.x sein.
Wenn Edomi also über einen Tunnel verbunden ist, dann sendet Edomi mit einer PA 1.0.x und alle Pakete sind sowieso auf der Linie 1.0. Da ist kein Dummy nötig.
Das kannst Du im Gruppenmonitor für die Linie 1.0 sehen.

Autsch, ergibt so ja auch total Sinn, wenn ich ein Read-Request über die ETS von einer der GAs von Edomi anfordere, bekomme ich ja auch im Gruppen-Monitor die beiden Tunnel 1.0.4 (ETS) und 1.0.6 (Edomi) angezeigt.
Screenshot 2024-04-08 212738.png
Hab jetzt ein bisschen rumgetestet. Wenn ich von Edomi zu ETS Telegramme sende brauch ich kein Dummy-Gerät, da beides über Tunnel kommuniziert und somit auf der Hauptlinie 1.0.x sind.

Wenn ich jetzt aber die Werte in z.B. nodeRed (Routing, wie telegraf, nur einfacher zu testen für mich) angezeigt haben möchte, muss ich ich 2 Dummys verwenden, einen in 0.0.x und einen in 1.0.x. Ist nach ein bisschen probieren auch logisch. Wenn ich nur jeweils einen anlege, legt der Router die GAs nicht in der Filtertabelle zum weiterleiten an. Einfach weil edomi kein echtes Gerät ist und telegraf/nodeRed auch nicht, also müssen die Geräte auf den jeweiligen Linien abgebildet werden.

Jetzt ist die Frage, wie der Filter im Router eingestellt ist, ich vermute mal, der filtert. Dann bräuchtest Du aber einen Dummy auf der Linie 0 und nicht auf der Linie 1.

Ja, filtern. Bisher habe ich auch alle Dummys in Linie 0.0.x angelegt. Da die GAs ja alle von echten Geräten der Gruppen 1.0.x, 1.1.x, 1.2.x und 1.3.x kommen hat das so auch immer funktioniert. Da die GAs somit immer auf 2 Seiten des Routers vorhanden waren und er somit einen Filtereintrag anlegen musste. Da aber edomi kein echtes Gerät ist hat das nun in diesem Fall nicht funktioniert.
Eigentlich waren die Dummys auf Linie 0 immer dazu gedacht die GAs der anderen Linien an edomi weiterzuleiten, aber wenn ich mir das so anschaue hab ich das eigentlich nie ganz korrekt gemacht und sie hätten in 1.0.x gehört. Auf der anderen Seite hätte ich dann aber für alle GAs die ich per telegraf in influx schreibe zusätzlich ein Dummy in 0.0.x anlegen müssen. Mhh muss ich mir mal noch mal genau überlegen ob es Sinn macht das umzumodeln das es der Realität entspricht.

Funktioniert es denn mit dem anderen Router ohne Dummy? Es kann ja sein, dass auch bei unserem Router noch irgendwas nicht stimmt.

Ich könnte es auf Wunsch gerne testen, aber nach den versuchen von oben glaub ich das euere Router hier alles korrekt interpretiert.

ist telegraf/influx tatsächlich per Routing angebunden?
ALs ich das vor 1-2 Jahren mal ausprobiert habe, war damit nur tunneling möglich.

Ja ist es, hatte auch erst per Tunnel angebunden, aber immer das Problem das bei Verbindungsabbruch keine neue Verbindung aufgebaut wurde. Seit ich es auf Routing umgestellt habe läuft es Problemlos.

Wenn alles auf der IP-Seite "abgefrühstückt" werden soll, müssten beide (Edomi und telegraf/influx) KNXnet/IP, also das KNX-IP-Protokoll reden.

Danke hab ich jetzt verstanden, aber geht leider nicht, edomi kann nur tunnel und telegraf funktioniert bei mir per routing reibungslos.

Vielen Dank an alle das ihr mir geholfen habt das besser zu verstehen. Also kann man abschließend sagen dass das Verhalten so eigentlich absolut korrekt ist und das was ich erreichen wollte nicht umzusetzen ist.

[mumpf]

muss ich ich 2 Dummys verwenden, einen in 0.0.x und einen in 1.0.x. Ist nach ein bisschen probieren auch logisch.

Genau richtig erkannt. Ich hatte aus der ersten Beschreibung vermutet, dass Du nur auf der 1.0-Seite einen Dummy brauchst, das hätte ich mir nicht erklären können, aber wenn Du sowieso auf der 0.0-Seite einen hast, ist es klar.

Mhh muss ich mir mal noch mal genau überlegen ob es Sinn macht das umzumodeln das es der Realität entspricht.

Wenn man das macht, vermeidet man Überraschungen wie die oben, hat aber für Edomi bzw. Telegraf immer Doppelpflege. Der vorteil ist, dass man in der ETS sieht, wer welche GA konsumiert, man verbessert somit die Dokumentation.

Falls es Dich interessiert, ich arbeite gerade an einem großen OpenKNX-Dummy (mit bis zu 99 bzw. 999 Kanälen, also KO), der es nicht nur erlaubt, die DPT der KO zu bestimmen, sondern auch jedes KO vernünftig zu benennen und die Flags so zu setzen, dass sie dem Verhalten des Virtuellen Gerätes entsprechen. Damit kann man schon recht gut ein "echtes" Gerät nachbilden. Hat aber alles nur dokumenarischen Charakter, ist ohne Funktion, wie jeder Dummy. Ich könnte das am kommenden Wochenende freigeben.

Gruß, Waldemar