Modbus TCP+RTU zu KNX Gateway mit Programmierung über ETS?

[StefanOberhaching]

Hallo Zusammen,
ich habe eine ganze Reihe Modbus Devices im Keller, manche machen Modbus TCP und manche Modbus RTU.

Die Modbus TCP Geräte kopple ich (teilweise) aktuell über Home Assistant und blende Daten in den KNX Bus ein, um sie auf MDT Glasstastern und Glasbedienzentralen zu visualisieren oder ansteuern zu können.
Das ist alles aber auch ganz schön ein Gebastel und gefällt mir nicht.

Für Modbus RTU fehlt mir im Moment der Adapter.

Meine Wunschvorstellung wäre ein Device (2-4 TE), das Modbus RTU und TCP an KNX anbindet und Brücke spielt. So dass ich die Werte von den Modbus Servern auf den Bus legen und in den Screens/Tastern anzeigen und auch rückwärts maniuplieren kann (Beispiel: Vorlauftemperatur Fernwärmeregler; Zieltemperatur Warmwassserboiler).

Ich habe einiges recherchiert, aber bisher keine Variante gefunden, wo ich nicht für 400-500 EUR am Ende einen separaten Modbus RTU - KNX und einen zweiten Modbus TCP - KNX Gateway kaufen müsste.

Die ganze Umrechenlogik ist aber in beiden Fällen die selbe, es sollte eigentlich nur ein zweite Eingang sein.

Bei den größeren Servern wie HomeLynk, SpaceLynk, LogicMachine, Timberwolff, usw. sieht man oft beides unterstützt, was mich da aber nervt ist, dass ich das dann nicht per ETS parametrieren kann, sondern das über irgendein oft mehr schlechtes als rechtes Interface geht und separat irgendwo abgelegt ist.

Kennt hier irgendwer eine gute Lösung, die meinem Wunsch vielleicht nahe kommt?

[skibbi]

Damit will ich sagen ich halte die KNX Gatways auch für gebastelt, da ,an dann vieles über KNX in die Visu schicken muss, was nicht sein müsste.

Dem würde ich mich anschließen. Modbus-Geräte stellen oft recht viele Messgrößen zur Verfügung. Wenn man die Visualisieren will oder in einer Timeseries-Datenbank für Diagramme aufzeichnen will, dann wäre es zu bevorzugen, die gar nicht erst über den TP-Bus schicken zu müssen.

Man könnte stattdessen die RTU-Geräte über Modbus TCP ansprechbar machen - es gibt da teilweise recht günstige Gateways. Dann kann man alle Werte ganz aktuell in der Visu darstellen und in Datenbanken speichern. Wenn man dann einzelne Werte davon auch auf dem Bus braucht, dann kann man das entweder mit der Modbus-TCP-Unterstützung des Visu/Logik/Integrations-Servers machen oder man macht das über ein separates KNX-Modbus-TCP-Gateway.

Die Lösung über ein RTU-TCP-Gateway hat auch den Vorteil, dass man dadurch die Nur-ein-Master-Beschränkung aushebelt. Bei Modbus-RTU kann es nur ein Gerät geben, das Informationen liest und Werte schreibt. Neben einem KNX-Modbus-RTU-Gateway kann man also kein anderes Gerät an den Modbus hängen, um damit z.B. häufiger Werte in eine Datenbank zu schreiben. Auf ein RTU-TCP-Gateway können aber mehrere Modbus-TCP-Master zugreifen.

[DerStandart]

Eine SymBox der Symcon GmbH ist 4 TE breit, kann mit einer MODBUS RTU Schnittstelle ausgestattet werden und sie kann die Werte auf den KNX Bus bringen (KNX IP-Schnittstelle erforderlich). MODBUS TCP wird natürlich auch unterstützt. Sollte preislich ungefähr hinkommen. Nachteil: Kann nicht über die ETS konfiguriert werden.

Falls Du diesbezüglich weitere Infos brauchst, melde dich per PN.

[ets3-user]

Wenn’s rein mit der ets passieren soll werden es zwei Geräte werden. Aber würee auch auf 2te passen.

[oezi]

Soweit ich informiert bin hat MDT jetzt auch einen Mod-Bus-RTU Koppler auf KNX-Basis
KNX Modbus Gateway RTU485 2TE

235,--

mit bis zu 200 frei konfigurierbaren Kanälen. Als Modbus-Master oder -Slave einsetzbar. Slave ID für jeden Kanal separat auswählbar. Einfache Skalierungseinstellungen mittels mathematischer Funktionen. Wertebereichsumrechnungen für jeden Kanal einstellbar. Multi Read Funktionalität Modbus-seitig. Read/Write Funktion mit 2 Objekten pro Kanal. Wertevergleicher Blöcke mit je 4 Vergleichswerten und Operationen. Meldetexte zur Darstellung des Geräte-Status. Universell einsetzbar, unterstützt eine Vielzahl von Modbus- und KNX-Datentypen. Keine zusätzliche Modbus Versorgungsspannung notwendig. Die Stromversorgung erfolgt über den KNX-Anschluss. Modbus / KNX galvanisch getrennt.

[ets3-user]

Der kann aber auch nur ein Protokoll

[Ralf988]

Was ist so schlimm wenn Du zwei Geräte nimmst.
bzw. eines je Protokoll?

Ich persönlich denke das Du damit auch besser fährst.
Für den unwahrscheinlichen Fall das so ein Gerät mal kaputt geht, geht Nur ein Teil und nicht alles nicht mehr.
Und vor allem glaube ich das Du solch ein Gerät in der Zukunft eher wieder bekommst.
Ein Gerät mit beiden Schnittstellen ist offensichtlich ein Sonderling.
Preislich kommt es auch aufs gleiche raus.


Wobei wenn schon HA im Spiel ist.
Die Integration dort kenne ich nicht.
Aber in Node Red und dort fand ich es recht einfach.
Modbus Register angeben und mit KNX Adresse verbinden fertig.
Gibt es ein paar tolle Videoanleitungen von Torben auf YouTube.

Wobei ich auch nicht alle Werte auf dem KNX habe, da es einfach zu viel ist.
Aber auf der Visu bzw. Handy finde ich es schon gut.
Damit will ich sagen ich halte die KNX Gatways auch für gebastelt, da man dann vieles über KNX in die Visu schicken muss, was nicht sein müsste.

[skibbi]

Damit will ich sagen ich halte die KNX Gatways auch für gebastelt, da ,an dann vieles über KNX in die Visu schicken muss, was nicht sein müsste.

Dem würde ich mich anschließen. Modbus-Geräte stellen oft recht viele Messgrößen zur Verfügung. Wenn man die Visualisieren will oder in einer Timeseries-Datenbank für Diagramme aufzeichnen will, dann wäre es zu bevorzugen, die gar nicht erst über den TP-Bus schicken zu müssen.

Man könnte stattdessen die RTU-Geräte über Modbus TCP ansprechbar machen - es gibt da teilweise recht günstige Gateways. Dann kann man alle Werte ganz aktuell in der Visu darstellen und in Datenbanken speichern. Wenn man dann einzelne Werte davon auch auf dem Bus braucht, dann kann man das entweder mit der Modbus-TCP-Unterstützung des Visu/Logik/Integrations-Servers machen oder man macht das über ein separates KNX-Modbus-TCP-Gateway.

Die Lösung über ein RTU-TCP-Gateway hat auch den Vorteil, dass man dadurch die Nur-ein-Master-Beschränkung aushebelt. Bei Modbus-RTU kann es nur ein Gerät geben, das Informationen liest und Werte schreibt. Neben einem KNX-Modbus-RTU-Gateway kann man also kein anderes Gerät an den Modbus hängen, um damit z.B. häufiger Werte in eine Datenbank zu schreiben. Auf ein RTU-TCP-Gateway können aber mehrere Modbus-TCP-Master zugreifen.

[StefanOberhaching]

Hey Zusammen,
nachdem ich nochmal einige Stunden in Recherche verblasen habe, komme ich zum selben Schluss wie skibbi .

Danke für eure Gedanken, das hat dem Reifen meiner Lösung auch geholfen.

Ich werde meine Modbus RTU Geräte auf Modbus TCP umsetzen mit einer einfachen billigen Bridge wie der von Waveshare. Bei Waveshare "RS485 to RJ45 Ethernet Converter Module" (https://www.amazon.de/gp/product/B0B...ZIAONBLW&psc=1) genannt, kostet gerade mal um die 40 EUR, kann per PoE mit Strom versorgt werden (kein Extra Netzteil auf der Hutschiene) und ist klein. Damit krieg ich meine Smart Meter auf TCP umgesetzt und kann von dort dann einfach weitermachen.

Entweder mit Home Assistant und von dort in den KNX Bus einspeisen soweit ich das brauche (auch der Vorschlag ist gut, das sehr selektiv zu machen) oder ggf. noch ein MDT oder Weinzierl Modbus TCP <-> KNX Gateway, wobei ich das fast eher nicht sehe.


Meine Motivation das in ein Gerät zu kriegen war recht einfach: Platz sparen im Schaltschrank, Strom sparen (wozu zwei kleine Rechner, die fast das selbe machen und eh keine riesige Anzahl Datenpunkte transportieren), Kosten sparen durch bessere Auslastung einer Hardware und an einer Stelle zentral programmieren, daher auch ETS und nicht irgendwas anderes proprietäres.

Es in einem Gerät zu sehen war dem Gedanken geschuldet, dass die Interface TechnikRichtung Modbus (Ethernet+TCP vs. RS485+RTU) ja nur etwa ein Viertel oder so ausmacht, der Rest ist KNX Interface und dem Rechner drin für die Konvertierung, usw. identisch wäre. Bauen können sollte man sowas also eigentlich easy und wenn ich mir meinen Keller so ansehe, glaube ich auch, dass da ein klarer Use Case da ist, da man schnell beides hat.
Ist aber egal, scheint so nicht zu existieren bzw. nur in wesentlich größerer Form als HomeLynk/SpaceLynk, Logic Machine, Timberwolff, Symcon oder ähnliches.

[StefanOberhaching]

Was ist so schlimm wenn Du zwei Geräte nimmst.
bzw. eines je Protokoll?

Grundsätzlich nichts, aber der freie Platz im Schaltschrank ist nicht mehr üppig und:

Es in einem Gerät zu sehen war dem Gedanken geschuldet, dass in der Komponente die Interface Technik in Richtung Modbus (Ethernet+TCP vs. RS485+RTU) ja nur etwa ein Viertel ausmacht, der Rest ist KNX Interface und dem Rechner drin für die Konvertierung, Konfiguration, Programmierung, usw. identisch wäre. Man bräuchte also nicht zweimal 75% das gleiche einbauen. Sollte Geld und Ressourcen sparen.

"Redundanz" bzw. mehr Ausfallsicherheit durch Verteilung auf zwei Geräte hätte ich hier als unwichtig gesehen und ich verspreche mir hier auch nichts viel davon. Am Ende geht eh immer das kaputt wo es am meisten weh tut, also wahrscheinlich nicht dieses Gateway, sondern z.B. der Fernwärme Regler selbst ;-)

Wobei wenn schon HA im Spiel ist.
Die Integration dort kenne ich nicht.
Aber in Node Red und dort fand ich es recht einfach.
Modbus Register angeben und mit KNX Adresse verbinden fertig.

Bei Home Assistant (HA) ist es auch nicht kompliziert. Du konfigurierst per YAML deine Modbus Datenpunkte. Wenn Du dann z.B. den Modbus Register als Sensor (Datenpunkt) in Home Assistant hast, kannst Du ihn einfach wieder per YAML Konfiguration auf den Bus exponieren. In der ETS musst Du vorher noch eine Gruppenadresse anlegen und irgendwen drauf lauschen lassen (sonst ist das exponieren natürlich für die Katz und ggf. kommst Du nicht durch deine Linienkoppler).

In Summe aber sind es mindestens 2 Stellen in der HA YAML Konfig und passend dazu was in der ETS. Genau das wollte ich gerne vermeiden, indem ich alles was für Basisfunktionen im Haus relevant ist, in der ETS zusammen habe. Ich baue bisher alles so, dass der KNX Bus sozusagen das Nervensystem ist für alles "lebenswichtige". Über Home Assistant läuft nur Komfort- und Nice-To-Have. Das ist in der Regel eine Mischung aus zusätzlicher Automatisierung und Dingen, die ich auf typischen KNX Komponenten mit einfacher boolscher Logik nicht mehr abbilden kann.