KNX LAN Bridge

[csedl]

Hallo,

ich habe gerade eine KNX LAN Bridge programmiert um KNX Pakete über VPN in ein entferntes Netz zu übertragen, kann man sowas gebrauchen? Oder wie löst Ihr das? Geht auch mit mehreren Clients.

Gruß,
Christoph

[Gunner67]

Wofür brauch man das? In meinen Augen ist KNX jetzt nicht so das ideale Protokoll um es übers Internet zu schicken...

[csedl]

Ja, versteh ich, aber die Anforderung war zwei Standorte mit einer Visu zu bedienen.

[Gunner67]

Ich glaube da wäre die technisch saubere Lösung sicherlich mqtt und ähnliche Geschichten.Also die KNX Telegramme Lokal dann umsetzen auf etwas anderes.

[traxanos]

Sowas löst man normal mittels Multicast-Routing (PIM)

Ich glaube da wäre die technisch saubere Lösung sicherlich mqtt

das ist so die unsauberste methode. sorry.

Wenn man keine Ahnung von Mulicast-PIM hat bzw. nicht die technischen Möglichkeiten, dann gibt es auch noch Unicast KNX Router (z.B. Theben 9070770).

[DiMa]

Ich würd' dafür einfach ein site-2-site VPN aufsetzen und da zwei KNX-IP-Router reinpacken.

[DerStandart]

Ja, versteh ich, aber die Anforderung war zwei Standorte mit einer Visu zu bedienen.

Da reicht es doch, wenn die Visualisierung per VPN Zugriff auf die IP-Schnittstellen der Standorte hat.

[ewfwd]

Sowas löst man normal mittels Multicast-Routing (PIM)

Über eine VPN Verbindung? Was wenn der Tunnel mal zusammenbricht und sich reconnected im Hintergrund was geschieht dann mit Telegrammen die unterwegs waren?

das ist so die unsauberste methode. sorry.

Weiß nicht was daran unsauber sein soll. Bei einem Reconnect würde man bei Retained die letzten Nachrichten einfach vom Broker bekommen, bei KNX kriege ich sie entweder gar nicht oder es müssen lauter Leseanfragen verschickt werden.
Wenn ich ne unsaubere Verbindung habe die sich ständig neu aufbaut, wieso auch immer und jedesmal alles aktiv gelesen wird mülle ich mir da auf der anderen Seite ziemlich den Bus voll...

[traxanos]

Über eine VPN Verbindung? Was wenn der Tunnel mal zusammenbricht und sich reconnected im Hintergrund was geschieht dann mit Telegrammen die unterwegs waren?

Da passiert das, was spezifiziert ist. Die Telegramme gehen natürlich verloren, da es als Stateless-Verbindung implementiert ist.

Weiß nicht was daran unsauber sein soll. Bei einem Reconnect würde man bei Retained die letzten Nachrichten einfach vom Broker bekommen, bei KNX kriege ich sie entweder gar nicht oder es müssen lauter Leseanfragen verschickt werden.

Das gilt doch für den MQTT genauso. Wenn der stirb, sind deine Telegramme auch weg. Wenn der mqtt-broker auf der rechten Seite steht und der vpn weg ist, dann gehen dir auch die Telegramme auf der linken Seite verloren. Einfach einen höheres Protokoll in den Ring zu werfen, halt ich für keine gute Idee. Zumindest nicht als reguläre Empfehlung.

Selbst in einem Netzwerk könnte ein Switch ausfallen und somit die Verbindung zwischen mehreren Routern vor Ort ausfallen lassen. KNX ist nicht für Hochverfügbarkeit konzipiert. Jetzt Telegramme in irgend ein Fremdformat zu konvertieren um es auf der anderen Seite wieder zu konvertieren, ist meiner Meinung nach keine vernünftige Lösung.

Dazu holt man sich deutlich mehr Komplexität in die Kette, die alle noch mehr Probleme machen können. Da Löse ich ich das Problem doch lieber mit langen etablierten Standardlösungen - zumindest solange ich damit aus komme.


Und wenn man ehrlich ist will man auch nicht, dass Telegramme gebuffert werden, da dass wieder komplett neue Probleme und Fragen aufwirft. z.B.

• Bekommt du ggf. veraltete Telegramme
• Speicherst du dann auch komplette die Historie? oder nur die jeweilige GA
• Wenn du die auf der anderen Seite dann wieder auf einen Bus gibst, flutest du dann Bus oder verzögerst du?

und da fallen mir noch viel mehr ein.

[ewfwd]

Selbst in einem Netzwerk könnte ein Switch ausfallen und somit die Verbindung zwischen mehreren Routern vor Ort ausfallen lassen.

Das könnte alles passieren aber wenn die Verbindung wiederhergestellt wird werden einfach die letzten Zustände übertragen, sofern sie retained sind. Das halte ich für sinnvoller als auf der anderen Seite jedes Gerät einzelnt eine Leseanfrage zu schcken.

[traxanos]

Vielleicht haben wir gerade unterschiedliche Vorstellung. Hier war die Rede von LAN Bridge per VPN. Das bedeutet für mich ich habe Zweistandorte und will die KNX Busse koppeln. Sprich ich bekomme ein TP Frame als CeMI Frame und pack es ins MQTT und auf der anderen Seite packe ich das ganze wieder aus und gebe es auf den BUS.

wird werden einfach die letzten Zustände übertragen

Dann müsstest du ja einzelne GAs aufbereiten / filtern und dann auf den MQTT geben. Das wäre für mich keine LAN Bridge. Das ist ein normale Remotezugriff per Interface oder so mit "Buffer".

[ewfwd]

Nene. Ich rede davon einfach Statuswerte wie zB die Temperatur einfach in MQTT zu überführen, also nur den Zahlenwert. Natürlich dann nicht wieder zurück nach KNX zu verwandeln weil es ging ja um eine Visu, sofern die Visu MQTT auch versteht.
Also KNX-MQTT-KNX würde ich auch nicht machen...

Wenn der Wert auf der anderen Seite KNX sein muss dann wäre das natürlich quatsch, da gehe ich mit...

Mal angenommen ich habe auf Seite A ne KNX Anlage und will auf Seite B mir die Tempratur in meiner HA Visu anzeigen lassen. Da würde ich KNX=>MQTT machen auf Seite A und es dann so nach B schicken und von Seite B auf den Broker mich verbinden der dann entweder im Netz sitzt oder auf Seite A.

Wenn die Visu nur KNX kann dann geht das so natürlich nicht.

Da eine VPN Verbindung über Internet jetzt von der Stabilität nicht mit LAN zu vergleichen ist muss man sich natürlich überlegen was passieren soll bei Unterbrechung. Wenn jemand um 10Uhr das Tor auffährt und der Befehl kommt net an wäre es halt doof wenn um 19Uhr wenn die Verbindung wieder besteht dieser Befehl dann ggf nachgeholt wird womit keiner rechnet...