KNX-IP Interface oder Router

[DiMa]

Wobei man natürlich darüber streiten kann, wie wichtig einem eine direkte Tasmota-Anbindung ist. Das wäre ja ein Anwendungsfall ohne HA, OpenHAB & Co., da ansonsten schlicht und einfach z.B. der HA als "Tasmota-KNX-Bridge" dienen kann - über die sowieso vorhandene Tunnelverbindung. Wäre für mich also kein Argument für einen KNX-IP-Router.

Nur mal so als Idee 😉

[ewfwd]

Es ist halt eine weitere Abgängigkeit

[gbglace]

Ich gehe davon aus wenn du den X1 neu parametrierst

Tja eines der letzten Bauteile die meine Hausanlage jemals sehen wird ist ein X1.

Aber ansonsten klar je mehr man in einen Logikserver auslagert umso mehr SPOF baut man sich in eine Anlage.
viele kleine nativ KNX-Module wäre da bestimmt besser aber die gibt es schlicht nicht um IoT Geräte anzubinden.

Wo man eine Logik implementiert, entweder viel verteilt in Aktoren/Tastern Logikmodule usw. vs einen zentralen Server muss jeder für Sich entscheiden.

Mein Server hat auch Schnittstellen, aber der muss nicht bei jeder Änderung von Logiken usw. neu bespielt werden. Nix externe Software wie GPA.
Bei ganz großen OS Updates da braucht der womöglich mal einen Reboot. aber das kommt weniger als einmal im Jahr vor, nicht weil es so wenige SW Updates gibt, eher weil die eben nur das einzelne Subsystem neu starten und nicht den ganzen Server.

Da kommt es häufiger vor das mal ein Container selbst (HA / NR) neu gestartet werden wollen wegen Updates.


Wenn der X1 natürlich immer als dicht macht beim Reboot und bei jedem überspielen des GPA sowas notwendig wird, dann kann das nervig werden wenn Papa immer was neues Baut und dann für paar Minuten nix so richtig läuft. Aber zum Glück ist ja niemand gezwungen sich nen X1 zu kaufen.

In Summe halte ich es daher eher für ein theoretisches Problem das so ein Server gleichzeitig Schnittstelle ist für andere IP-Services die sich per Tunneling mit dem Bus verbinden.

[mumpf]

Ich versuch mal die wichtigsten Punkte aufzuführen, die aus meiner Sicht die jeweiligen Geräte charakterisieren

Was macht einen Router aus:

• Er koppelt eine TP-Linie mit einer IP-Linie: Somit sind auf der IP-Linie "echte" KNX-Geräte mit eigener PA, eigenem Prog-Button und die Geräte können über die ETS programmiert werden.
• Der Router kann (sollte) filtern, da die Kapazität der IP-Linie viel höher ist als die der darunterliegenden TP-Linie. Insofern kann ein ungefilterter Betrieb schnell zur Überflutung der TP-Linie führen.
• Andere Geräte, z.B. Server wie der HA, können das KNX-IP-Protokoll implementieren und verhalten sich dann aus Sicht des Routers wie ein KNX-Gerät mit eigener PA. Da sie keine ETS-Applikation besitzen, können diese Geräte nicht über die ETS programmiert werden.
• Bei Routern verwendet man häufig Dummy-Applikationen in der ETS, bei denen all die GA verknüpft werden, die vom Server gebraucht werden. Aus diesen Daten kann die ETS die notwendigen Filtertabellen berechnen.
• Router können zwar den Gruppenmonitor der ETS unterstützen, aber nicht den Busmonitor bzw. nur die Busmonitor-Sicht der IP-Seite. Da es aber auf der Seite keine ACK/NACK gibt und damit auch keine Wiederholungen, ist das nicht der interessante Teil.
• Router müssen immer richtig in der Topologie eingeordnet sein und machen immer eine IP-Linie auf, bringen also neue Komplexität ins KNX-System.

Was macht einen Tunnel aus:

• Er sitzt auf einer bestimmten Linie und koppelt genau 1 IP-Gerät (dass kein KNX-Gerät ist) mit dem KNX-Bus.
• Das Gerät hat keine eigene PA, es bekommt die PA des Tunnels. Somit wird das Gerät durch den Tunnel repräsentiert.
• Das Gerät ist Teil der Linie und bekommt somit alle Telegramme dieser Linie mit.
• Alle Telegramme, die das Gerät versendet, kommen bei allen Geräten auf der Linie an.
• Auch für Geräte, die über Tunnel angebunden werden, braucht man Dummy-Applikationen, sofern diese mit Geräten kommunizieren sollen, die auf anderen Linien sitzen.
• Gerade in einfachen KNX-Systemen mit nur einer Linie bringen Tunnel keine neue Komplexität rein, es bleibt bei der einen Linie.
• Die ETS kann eine IP-Schnittstelle in einen Exclusiven Modus versetzen für den Busmonitor. Dann werden alle Telegramme empfangen, auch technische... in diesem Modus werden alle Tunnel geschlosen - außer dem, den die ETS verwendet.

Die Liste ist natürlich nicht vollständig und ich bin kein Experte, das mit dem Busmonitor sind Beobachtungen und Laienwissen, aber sind die Punkte, anhand deren ich entscheiden würde. Ich bin die ersten 8 Jahre gut ohne einen Router ausgekommen und sogar mit einer IP-Schnittstelle mit nur 4 Tunneln. Inzwischen habe ich den OpenKNX-Router, weil ich ein echtes KNX-IP-Gerät im System betreibe (das OpenKNX-Logikmodul-IP). So gesehen habe ich mir durch die Entwicklung eines IP-Logikmoduls selbst einen Router "aufgezwungen".

Vielleicht hilft das obige als Entscheidungskriterium. Aber wenn es nur das Geld ist... mit etwas löten kann man über OpenKNX ein REG1-Einbaugerät beziehen, das mit der entsprechenden Firmware (auch von OpenKNX) zu einem KNX-Bus-Versorgten Router wird. Mit 4 Tunneln, mit Potential auf 8 Tunnel, vielleicht sogar mehr. Ist eben noch Beta und im public Test. Und da wir non-profit arbeiten, ist der Selbstkostenpreis sicherlich günstiger als jegliche andere Schnittstelle, geschweige denn Router. Ich erwähne das nur, um den finanziellen Aspekt aus der Diskussion rauszuhalten.

Gruß, Waldemar

[tobiasr]

Der Router ist halt gleichzeitig auch Linienkoppler. Sobald man ein größeres Anwesen hat (z.B. das kleine Gartenhäuschen, Garage 20m weg vom Haus) kann es sinnvoll sein die dortige KNX Linie über sowieso vorhandenes Netzwerk - welches über Glas gleich potenzial getrennt ist - zu versorgen.

[scw2wi]

Ich versuch mal die wichtigsten Punkte aufzuführen, die aus meiner Sicht die jeweiligen Geräte charakterisieren

Vielen Dank Waldemar, ich hab mal wieder viel dazugelernt, wie so oft hier in diesem Forum.

Walter

[Beleuchtfix]

Super Beitrag, Waldemar!
Gruß Florian