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 ist, 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 das Telegramme, da das wieder komplett neue Probleme und Fragen aufwirft. z.B.

• Du bekommt ggf. veraltete Telegramme
• Speicherst du dann auch die Historie? oder nur jeweils je 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.