Frage bezüglich Modbus RTU/TCP bezüglich Anzahl der Verbindungen

[Gunner67]

Hallo, wie ist das eigentlich bei Modbus und mehreren Verbindungen? Angenommen ich habe hier mehrere ModBUS RTU Geräte und schließe diese an ein Modbus RTU/TCP Gateway an. Also ein Konverter der aus RTU TCP macht. zB

https://botland.store/uart-rs232-rs4...422385866.html

Oder irgendein anderes Modell.

Wie verhält es sich nun mit den Verbindungen? Kann man da auch weiterhin nur eine Verbindung aufbauen?

Hintergrund ist ich habe zB eine Wärmepumpe die Modbus RTU kann. Ich würde aber am liebsten über mehrere Geräte damit kommunizieren.
zB mir über ein KNX Gateway die Temperatur des Außenfühlers auf den Bus holen, gleichzeitig aber mit Telegraf mir sämtliche Daten in meine InfluxDB Datenbank holen.

Was ich ungern machen würde ist mir erst sämtliche Daten in ein System zu holen zB KNX um sie dann weiter woanders hin zu schicken.

Ist so etwas irgendwie möglich?
MIt Telegraf kann man zB direkt eine Verbindung über Modbus TCP aufbauen. Jetzt will ich aber die Außentemperatur mir nicht erst über InfluxDB wieder nach KNX holen müssen...
2 "Master" an Modbus RTU gehen afaik nicht. Ein Slave was zuhört zB ein Converter Modbus RTU nach KNX nützt mir nichts wenn dieser die Temperatur nicht abfragen kann weil er nur zuhören kann.

Irgendwie nen Modbus Proxy laufen zu haben in HomeAssistant ist auch keine Option.

Modbus ist für mich noch recht neu aber gibt es die möglichkeit zumindest über Modbus TCP Gateways es irgendwie hinzubekommen dass man mehrere Verbindungen gleichzeitig aufbauen kann und so ein Gateway das ganze dann koordiniert?

Im Grunde müsste man doch auch bei Modbus RTU nur einen Master haben der einfach "alles" abfragt und ich kann dann mehrere Clients dranhängen haben die einfach nur zuhören oder stehe ich da auf dem Schlauch?
Sprich solange mein Modbus Gateway einfach periodisch die Temperatur abfragen würde müsste ich doch einfach nur "zuhören" oder?


Da ein Gateway das aber offenbar nicht kann würde es bedeuten über ModBus TCP könnte ich mir schon die Temperatur holen über Telegraf und mit einem KNX Gateway über RTU würde ich das auch mithören können, aber nur solange Telegraf die Temperatur auch abfragt. Sprich wenn der Server offline wäre würde auch das KNX Gateway keine Temperatur mehr bekommen weil keine Leseanfragen mehr geschickt werden, richtig?

[Gunner67]

Kennt jemand ein Gerät was Modbus RTU auf TCP umsetzen kann und gleichzeitig noch einen KNX-TP anschluss besitzt?

[tsb2001]

Modbus ist grundsätzlich nicht Multimaster-fähig.
Es gibt dort nur einen Master, der jeweils die Slaves anspricht und die Daten abholt, bzw, dorthin sendet. Bei mehreren Mastern gäbe es dann Kollisionen auf dem Bus, was zu Datenverlusten führen würde, da diese Kommunikationsart per Design nicht dafür entwickelt worden ist.

Bei KNX wurde eine komplette Kollisionserkennung eingebaut, da jedes Gerät zu jeder Zeit „ungefragt“ senden darf.
Bei Modbus hingegen regelt das einzig und allein der Master. Sollte also deine Wärmepumpe der Master sein und sämtliche Daten seiner Sensoren abfragen (oder aber auch Sensoren darüber ansteuern), hat dieser dieses „Hoheit“ über den Bus und sorgt dafür, das alle Sendungen auf dem Bus nacheinander ablaufen. Hat die Wärmepumpe keinen zweiten Modbus, der als Slave einem übergeordneten Master Daten zur Verfügung stellen kann, wird das nichts werden.

Bestes Beispiel: hier hängt ein Fronius Wechselrichter mit 3 Modbus-Systemen. 2 davon sind RTU, einer TCP. Einer der RTU ist ein Master, der die Daten von dem Smartmeter abruft; der zweite ist der für den Akku, der je nach angeschlossenem BMS Master oder Slave ist (je nachdem, wer der Modbus-Master in dem Fall ist - Akku oder Wechselrichter) und den dritten nutze ich persönlich als Slave, womit ich über den Homeassistant die Daten vom Wechselrichter hole.

Solange deine Wärmepumpe keinen weiteren Bus bereitstellt, worauf du mit einem von Dir eingesetzten Master Daten abholen kannst, wird das leider nicht funktionieren, da Modbus dafür nicht ausgelegt ist.

Was absolut für mich nur in der Theorie denkbar wäre: du würdest beispielsweise den Temperaturfühler als Slave an den Modbus-RTU-KNX-Gateway von MDT anschließen und das Gerät als KNX-Master parametrieren. Dann hättest du diese Daten von dem Fühler in KNX.
Mit einem zweiten Gateway als Slave parametriert könntest du das anstelle des Temperaturfühlers in den Modbus der Wärmepumpe einbauen und die zuvor eingesammelte Außentemperatur der Wärmepumpe anbieten.
Folglich: AT-Fühler -> Modbus-KNX-Umsetzer1 (als Master zur Verwendung im KNX) -> weitere Verwendung der Daten im KNX -> Modbus-KNX-Umsetzer2 (als Slave im WP-Modbus zur Bereitstellung der AT) -> Wärmepumpe.
Somit würde die Wärmepumpe die Außentemperatur vom KNX bekommen.

Theoretisch schreibe ich deshalb, weil ich für solche wichtigen Systeme niemals diese Menge an Fehlerpunkten einbauen würde, welche mir im Winter mit viel Pech das Haus kalt lassen.

Zudem müssten die Modbus-Register des Aussenfühlers bekannt sein, welche die Wärmepumpe abfragt. Nur dann kann man die nachbilden. Falls die nicht bekannt sind, da der Hersteller sein eigenes „Ökosystem“ schützen möchte, wird es ab dem Punkt schon schwierig.

[Gunner67]

Könnte nicht folgendes Funktioneren: Wärmepumpe ist RTU Slave. ich nehme ein KNX Modbus Gateway als Master und lasse mir regelmäßig sämtliche Werte auslesen.
Parallel an den Modbus RTU Bus hänge ich dann ein ModbusRTU/TCP Konverter. Solange dieser dann im Slave Modus arbeitet also nur mithört könnte er gleichzeitig sämtliche Werte direkt nach IP senden zB in eine InfluxDB.

Nachteil wäre aber ich hätte die ganzen Werte dennoch auf dem KNX Bus und könnte sie mir im Grunde dann auch direkt über das KNX Interface holen...ergo der RTU/TCP Konverter wäre recht überflüssig dann...

Habe gelesen dass so ein Modbus TCP Konverter aber durchaus mehrere Verbindungen auf der IP Seite verarbeiten kann. Frage: Wie läuft es denn wenn ich ein bestimmtes Register auslese:

Also angenommen Client A fragt den TempSensor ab über das Gateway, das Gateway wandelt die Abfrage um nach RTU, fragt den Wert ab und liefert die Antwort dann an Client A wieder zurück. Wenn Client B aber das gleiche wissen will wird exakt das gleiche nochmal gemacht nehme ich an oder? Also es wird dann wieder der RTU Bus "gefragt", es gibt keinen Puffer der die Werte speichert und daraus bedient? Oder das Gateway sendet einfach an alle Clients A und B die Daten raus die es über RTU abfragt? Sprich Client B bekäme auch "ungefragt" den TempWert weil Client A danach gefragt hat?

[tsb2001]

Wärmepumpe ist RTU Slave

Ich glaube nicht, dass das geht. Die Wärmepumpe ist ja quasi das Prozessleitgerät als Master, welches die Daten der umgebenden Sensoren und Aktoren (also alle Slaves) passend ansteuert.
Wenn du also der Wärmepumpe die Rolle des Masters entziehen würdest, dann müsste der neu geschaffene Master alle Daten der Modbus-Slaves der Wärmepumpe abfragen und diese dem jetzigen WP-Master - der nun auch Slave sein würde - zur Verfügung stellen müsste. Wie sollte sonst der Wärmepumpen-Controller an seine Daten kommen, um diese überhaupt zu verarbeiten?

Also zunächst die Frage: lässt sich hardwareseitig der Modbus der Wärmepumpe von Master auf Slave umswitchen (Schalter, oder Softwareswitch)?

Oder das Gateway sendet einfach an alle Clients A und B die Daten raus die es über RTU abfragt? Sprich Client B bekäme auch "ungefragt" den TempWert weil Client A danach gefragt hat?

Nein.
Der Modbus-Master verbindet sich mit der Modbus-Adresse des ersten Slave, holt dort alle Register ab, beendet die Kommunikation, baut die Verbindung zum zweiten Slave auf, liest dort alle Register aus, macht das mit Slave 4…31 (falls vorhanden) und fängt dann wieder von vorne an. Beim Schreiben der Werte läuft es natürlich genauso.
Die anderen Slaves ignorieren die Werte, da diese ohne spezifische Adressierung des Masters (als explizites Telegramm) gar nichts tun.
Da hört auch nichts mit. Modbus RTU wurde 1979 ins Leben gerufen. Da ging es simpel um das einsammeln von Peripherie-Daten im Prozessleit-Umfeld. Und das gilt auch heute noch.
Da kann man auch nichts „umbiegen“ oder Slaves einfach senden lassen - und die anderen hören mit.

Also angenommen Client A fragt den TempSensor ab

Temperatursensor ist Client B. Da Client A niemals mit Client B direkt sprechen kann, wird das nix.
Ganz dummes Beispiel zum Modbus TCP:

• Master hat die IP 192.168.199.1 (SPS oder so)
• Client A hat die IP .2 und ist ein Sensor
• Client B hat die IP .3 und ist ein Aktor

Der Master stellt die Anfrage an die IP-Adresse 192.168.199.2 und liest sämtliche Register (wegen mir ein Temperaturwert). Am Aktor unter der 192.168.199.3 hängt eine Pumpe, die ab einer gewissen Temperatur eingeschaltet werden soll.
Nun erhält der Master den Temperaturwert des Sensors 192.168.199.2, übergibt ihn an die Logik (die SPS), diese vergleicht den mit dem Sollwert, entscheidet ob die Pumpe eingeschaltet werden soll und übergibt den Bitwert zurück an den Modbus-Master. Der baut nun die Verbindung zur 192.168.99.3 auf und sendet den Inhalt des Registers mit „1“ oder „0“, je nachdem ob die Pumpe laufen soll; oder halt nicht.

Da ist nichts mit mithören, da niemals Client 1 mit 2 direkt spricht. Alle Kommunikation geht ausschließlich über den Master. Denn dort sitzt die Logik, welche die Daten verarbeitet.

[Gunner67]

Ich glaube nicht, dass das geht. Die Wärmepumpe ist ja quasi das Prozessleitgerät als Master, welches die Daten der umgebenden Sensoren und Aktoren (also alle Slaves) passend ansteuert.

Ich glaube wir reden aneinander vorbei. Wärmepumpe mit Modbus RTU Anschluss heißt für mich ich kann das Gerät Wärmepumpe mit Modbus RTU an andere Dinge einbinden. Die die WP ihre eigenen Sensoren verarbeitet hat damit nix zu tun.
Ich rede von einer Modbus RTU Schnittstelle die dafür geschaffen wurde dass man die Wärmepumpe darüber steuert und Zustände und Temperaturwerte ausliest.
Die Wärmepumpe, also zumindest an dem besagten Ausgang ist ein Slave. Dauerhaft.

Temperatursensor ist Client B. Da Client A niemals mit Client B direkt sprechen kann, wird das nix.
Ganz dummes Beispiel zum Modbus TCP:

Glaube auch da reden wir aneinander vorbei.

Master sei ein TCP/RTU Konverter. Am RTU Teil hängt irgendein Gerät welches der Master abfragen kann.

Mit dem Konverter verbinden sich nur auf IP Seite mehrere Clients, die wollen die Temperatur wissen.
Der Master stellt also keine Anfragen an irgendwelche Clients zumindest nicht auf der IP Seite.

Sagen wir ich habe 2 mal InfluxDB laufen und unabhängig voneinander will jedes InfluxDB jede Sekunde wissen welchen Wert ein Temperatursensor hat und baut dafür die Verbindung zu einem Modbus TCP/RTU Konverter auf.

Wenn der Modbus Konverter also nacheinander von beiden InfluxDB Instanzen den Befehl bekommt "lese mal die Temperatur aus" muss der Modbus Konverter 2mal auf RTU nachfragen?

Wenn InfluxDB Instanz #1 fragt nach Temperatur bekommt InfluxDB Instanz #2 also nicht ungefragt vom Modbus Konverter den Temperaturwert mitgeteilt? Also diese Inteligenz besitzt der Modbus Konverter nicht?

[tsb2001]

Die Wärmepumpe, also zumindest an dem besagten Ausgang ist ein Slave. Dauerhaft.

Jetzt verstehe ich es. Wenn es ein Slave ist, kannst du prinzipiell alles damit machen, wenn du die Register kennst.

Glaube auch da reden wir aneinander vorbei.

Stimmt!
Aber das hier geht trotzdem nicht:

Am RTU Teil hängt irgendein Gerät welches der Master abfragen kann.

Einen Master kannst du als Slave nicht abfragen. Weder über RTU, noch über IP, denn letzteres ist nichts anderes als eine Serialisierung des Datenstroms auf der IP-Seite. Der Grundsatz bei Modbus ist der, das immer der Master die Verbindung zum Slave aufbaut. Das wirst du auch nicht abändern können.

Wenn der Modbus Konverter also nacheinander von beiden InfluxDB Instanzen den Befehl bekommt "lese mal die Temperatur aus" muss der Modbus Konverter 2mal auf RTU nachfragen?

Du musst die Systeme gedanklich umdrehen. Mache den RTU/TCP-Umsetzer auf der TCP- und der RTU-Seite zum Master und die beiden Geräte mit der Influx-DB zum Slave. Dann sendest du vom Modbus-Master im Sekundentakt die Temperaturen an die Slaves der Influx-Datenbanken.

Gedankliche Abfolge: Der RTU/TCP-Umsetzer macht den Master, pollt auf der RTU-Seite als Master sekündlich die Außentemperatur und andere Werte der Wärmepumpe, setzt diese auf TCP um und sendet unmittelbar diese Daten an die Geräte der Influx-DB. Wenn du dann noch die Daten im KNX verwenden möchtest, hängst du auf der TCP-Seite einen weiteren Slave dran; und zwar den: https://weinzierl.de/images/products...tasheet-de.pdf . Dort sendest du von dem Master die Daten hin, welche du im KNX haben möchtest.

Welches Hersteller ein Gerät produziert, was auf der RTU-Seite als Master und auf der TCP-Seite gleichzeitig der Server sein kann; dass weiß ich nicht. Die Gateways setzen eigentlich nur um, wenn ein TCP-Server die Anfrage stellt, fungieren dort als Client und routen das dann auf die Modbus-Seite, der dann als Master fungiert.

Ich setze dafür seit Ewigkeiten den Homeassistant ein.
Der pollt die Daten als Modbus-TCP-Server vom Wechselrichter, holt via API die Daten von der Heizung und packt genau das alles in die InfluxDB (wegen Grafana) und nimmt die aktuellen Werte des Ladezustands im Akku der PV sowie die Außentemperatur von der Heizung und schreibe die noch Richtung KNX. Ein Gateway für alles. Und die Influx-DB ist auch schon drin…

[Gunner67]

Du musst die Systeme gedanklich umdrehen. Mache den RTU/TCP-Umsetzer auf der TCP- und der RTU-Seite zum Master und die beiden Geräte mit der Influx-DB zum Slave. Dann sendest du vom Modbus-Master im Sekundentakt die Temperaturen an die Slaves der Influx-Datenbanken.

Ich weiß nicht ob das so funktioniert. Bis du dir da sicher??

https://github.com/influxdata/telegr...dbus/README.md

In meinen Augen funktioniert es so dass auf IP Seite InfluxDB sich mit dem Modbus Converter verbindet. Der Modbus Converter ist Master auf der RTU Seite. Ich gehe davon aus dass die Leseanforderungen gezielt von InfluxDB aus kommen, diese zum Converter geschickt werden, und der Converter diese Befehle einfach 1:1 durchreicht, die Antwort dann entgegen nimmt und über IP zurück sendet.

Ich sehe da keine Client ID auf der TCP Seite die es in InfluxDB zu konfigurieren gäbe. In meinen Augen würden beide InfluxDB Instanzen als Master arbeiten und das Gateway bzw Converter arbeitet dann mehr wie eine Art Router. Gibt also die Befehle die es von InfluxDB Instanz #1 und #2 bekommt als seine eigenen aus auf der RTU Seite.

Zumindest sehe ich bei InfluxDB an keiner Stelle eine konfigurationsmöglichkeit zwischen Master und Slave. In meinen Augen arbeitet das als Master..

Mehrere IP Verbindungen zu einem RTU/TCP Modbus Gateway sind ja durchaus möglich... nur auf RTU Seite ist es so dass es nur einen Master geben darf.

Ich setze dafür seit Ewigkeiten den Homeassistant ein.

Ich nutze auch HA möchte es aber nicht zur Zentrale für alles machen...

Ich will dass sich mein InfluxDB direkt mit dem Modbus Gateway verbindet... InfluxDB nutze ich auch nicht in HA sondern läuft unabhängig davon..

und zwar den: https://weinzierl.de/images/products...tasheet-de.pdf . Dort sendest du von dem Master die Daten hin, welche du im KNX haben möchtest.

Also die Modbus Gateways/Konverter die ich so gesehen habe bieten keine Möglichkeit dort irgendwelche IPs einzustellen nach denen die sich verbinden sollen. Die Teile erlauben afaik nur eingehende Verbindungen... Also Modbus Master TCP die sich auf diese Gateways verbinden...

So wie du es beschreibst müsste ich irgendwo in so einem Modbus Gateway meine IPs eintragen zB von InfluxDB und diesem weinzierl Teil. Mir ist kein Gerät bekannt wo das geht... sprich ich glaube man kann sich nur auf diese Gateways verbinden aber nicht andersherum.
Die reichen Modbus Abfragen einfach 1:1 quasi Transparent an den RTU Teil dann weiter...

Auf TCP Seite kann es ja durchaus mehrere Master gleichzeitig geben...Das Teil muss halt mit mehreren Verbindungen gleichzeitig klarkommen können...

Technisch ein Problem sehe ich da erstmal nicht wieso es mit mehreren Master auf TCP Seite nicht klappen sollte..Die Anfragen können einfach nacheinander bedient werden..."Kollisionen" gibt es so gesehen bei TCP nicht. Die würden nur auf RTU Seite stattfinden wenn man dort mehrere Master parallel betreibt...

Der RTU/TCP-Umsetzer macht den Master, pollt auf der RTU-Seite als Master sekündlich die Außentemperatur und andere Werte der Wärmepumpe, setzt diese auf TCP um und sendet unmittelbar diese Daten an die Geräte der Influx-DB.

Wird nicht funktionieren...weil der RTU/TCP Umsetzer nichtmal die Register kennt die er abfragen muss. Auch dazu gibt es im Webinterface an keiner Stelle eine Möglichkeit sowas einzutragen. Ein RTU/TCP Umsetzer leitet einfach nur weiter...Wenn keiner über TCP irgendetwas anfragt, wird der Umsetzer auch keine Abfragen auf RTU Seite rausschicken...

Handbuch eines TCP/RTU Umsetzers:


https://hmsnetworks.blob.core.window...ser-manual.pdf

Es ist nicht Möglich dort die notwendigen Einstellungen vorzunehmen. Ich müsste im Webinterface viel mehr Einstellmöglichkeiten haben. zB müsste ich alle meine Client IDs die ich auf RTU Seite haben definieren können damit das Gateway weiß was es abfragen muss. Die Register ebenso. Das ist nicht möglich. Die Client ID, also welches Gerät abgefragt werden soll, und auch welches Register geschieht von außen also von der TCP Seite, sprich von InfluxDB. Dort muss das alles konfiguriert werden.

Das Gateway kann so gesehen keine Nachrichten nach InfluxDB schreiben oder pushen, InfluxDB muss sich das alles abholen.

Das von dir genannte Weinzierl KNX Gateway müsste also ebenfalls als Master fungieren und dann wie InfluxDB auch seine Abfragen an das Modbus RTU/TCP Gateway senden...wenn ich zB die Außentemperatur wissen will von der Wärmepumpe.

Was dumm ist: Wollen mehrere IP Geräte die Außentemperatur wissen muss jedes Gerät selbst die Information anfragen explizit...
Also InfluxDB #1 muss über Modbus TCP ans Gateway dann die Anfrage schicken, InfluxDB #2 muss aber exakt das gleiche tun weil ich glaube nicht dass das Gateway eigenständig diese Info an eine andere IP Adresse schicken wird als die Adresse von der die Anfrage kam...
Wenn InfluxDB #1 also anfragt, bekommt auch nur InfuxDB #1 die Anwort.
Ausnahme: Ich würde mich gleichzeitig auf RTU Eben mit nem Client reinhängen. Der müsste dann einfach mithören können...
Dieser wäre aber, da er nur Client ist, angewiesen darauf dass jemand anders Anfragen stellt weil der Client ja nur mithören kann.
Sprich sobald InfluxDB nicht mehr nach Temperatur fragt, würde auch auf RTU Seite kein Client die Nachrichten mehr mitlauschen können...

Besser wäre also dieses Weinzierl KNX Modbus Teil. Nur dann hat man noch einmal Ethernet dazwischen zwischen Modbus RTU und KNX TP. Aber anders geht es afaik nicht..außer eben nur einen KNX Modbus RTU Master zu betreiben der dann alles an Infos ausliest und auf den KNX Bus sendet und InfluxDB holt sich die Infos dann über den KNX Bus...

Kurzum ich vermute mit einem TCP/RTU Modbus Umsetzer wird man flexibler sein als RTU=>KNX TP. Wobei RTU=>KNX TP zuverlässiger wäre weil ein Medium (Ethernet) weniger...

Wobei am Ende beim KNX Interface bzw Router wird dann eh auf Ethernet umgesetzt...

[Noschvie]

Eine InfluxDB kann keine Anfragen an ein Modbus Gateway senden. Du benötigst ein Service dazwischen, das periodisch das Modbus Gateway abfragt und den Response aufbereitet und ein insert in die InfluxDB macht. Dieses Service kann nun Node-Red, Python usw sein.
Ähnlich macht es ja das Weinzierl mit KNX auf der anderen Seite.
Und wenn du ein Service hast, auf Basis zb Node-Red oder Python oder … kannst du damit die InfluxDB und den KNX Bus bedienen, versorgen.

[gbglace]

Also die Influx DB ist alles nur kein Master und auch kein Client, das ist eine ganz einfache Datenbank. Wenn dann macht der Telegraf da etwas.

Wenn Du eine Multiprotokoll Umsetzer suchst, ich nutze da dann eher die ausgewachsene Variante in Form des Timberwolfservers.

Das Modbusprofil der WP hinterlegen und schon hast die Datenpunkte der Register im Server und kannst dann entscheiden was davon willst in einer Timesieries in einer Influx haben, was auf dem KNX, was im MQTT, was auf der Visu, was als Modbus-TCP in anderen Modbusgeräten. Der Server hat eine Mdbus-TPU Schnittstelle kann aber auch Modbus-TCP. Es gibt auch weitere Modbus-RTU Module falls weitere Busse mit anderen Basisparametern anzubinden sind.

Kostet mehr kann aber das was Du willst und noch viel mehr.

[Gunner67]

Vielen Dank für bisschen Werbung für den TB Server, aber hier soll es anders umgesetzt werden

Wenn dann macht der Telegraf da etwas.

Wie im ersten Beitrag ganz oben von mir erwähnt.

In den weiteren Beiträgen ist immer wenn ich von InfluxDB rede InfluxDB und der darauf laufendes Telegraf Dienst gemeint.

Eine InfluxDB kann keine Anfragen an ein Modbus Gateway senden. Du benötigst ein Service dazwischen, das periodisch das Modbus Gateway abfragt und den Response aufbereitet und ein insert in die InfluxDB macht. Dieses Service kann nun Node-Red, Python usw sein.
Ähnlich macht es ja das Weinzierl mit KNX auf der anderen Seite.

Nun das ist ja ein Master auf der TCP Seite somit...