openhabforum.de

Hallo zusammen und erstmal ein gesundes neues Jahr 2023!
Ich beschäftige mich seit einiger Zeit mit der Anbindung von Modbus-RTU-Energiezählern an Openhab 3. Jetzt gibt es ein Problem, zu dem ich im Forum bisher keinen Beitrag gefunden habe und auch nach längerem Probieren nicht weiter komme. Ich hoffen hier einen Lösungsnsatz zu finden
Folgende Geräte:
1. Modbus TCP/RTU-Gateway: dieses wird mit IP-Adresse auf Port 502 angesprochen. Dahinter befinden sich mehrere Zähler als Modbus RTU-Slave, mit entsprechender Modbus-RTU-ID.
2. Ich kann die Zähler über das Gateway anpollen (z.B. ModbusPoll) und Register auslesen/schreiben.
3. Mit Openhab 3 geht das alles auch, jedoch bei mir nur für einen Zähler!
4. In OH kann ich als "ThingType" einen "Modbus-TCP-Slave" mit einer entsprechenden ID einstellen.
5. Für weitere RTU-Zähler benötige ich noch weitere RTU-ID's. Daher wollte ich jetzt eine zweite TCP-Bridge, gleiche IP-Adresse (da ein Gateway) und weitere RTU-ID einstellen.
6. Jetzt meckert Openhab mit "ERROR:CONFIG" -> CONFIGURATION_ERROR ->
"Endpoint 'ModbusIPSlaveEndpoint [address=192.168.1.xxx, port=502]' has conflicting parameters: parameters of this thing (modbus:tcp:2fec610ec2 'ModbusTCPSlave_xxx') are different from some other thing's parameter. Ensure that all endpoints pointing to tcp slave '192.168.1.xxx:502' have same parameters."

Jetzt die Frage: wie kann ich über ein Gateway mehrer RTU-Teilnehmer erreichen (es sind ja theoretisch bis 250 möglich)?

Danke vorab für weiterführende Infos
VG wollebit

Stehe gerade vor demselben Problem.
Gibt es eine Funktionierende Lösung?

Könntest Du mal die Konfiguration der Modbus TCP Bridges zeigen? Bitte auf die Code-Ansicht wechseln, den Text kopieren und hier einfügen, kein Screenshot.

Hallo und Entschuldigung für die späte Antwort.
Ich war geschäftlich ein paar Tage im Ausland.

Ich habe 2 I/O Module die mithilfe eines TCP/RTU-Gateway angesteuert werden sollen.

Das erste Modul hat die ID 10 das zweite die ID 11.

Hier der Code der einzelnen Teile.
Ist für das erste ein Versuch somit sind die Namen noch etwas bescheiden.

Modbus TCP Slave:
UID: modbus:tcp:Modbus_4DI_2DO
label: Modbus_4DI_2DO
thingTypeUID: modbus:tcp
configuration:
rtuEncoded: true
timeBetweenTransactionsMillis: 10
connectMaxTries: 1
reconnectAfterMillis: 0
port: 502
timeBetweenReconnectMillis: 0
host: 22.22.22.16
connectTimeoutMillis: 10000
afterConnectionDelayMillis: 0
id: 10
enableDiscovery: false

Poll:
UID: modbus:poller:Modbus_2DI_2AI_2DO:Modbus_2DI_2AI_2DO_Poll
label: Modbus_2DI_2AI_2DO_Poll
thingTypeUID: modbus:poller
configuration:
length: 1
start: 0
refresh: 250
maxTries: 3
cacheMillis: 50
type: coil
bridgeUID: modbus:tcp:Modbus_2DI_2AI_2DO

Daten:
UID: modbus:data:Modbus_4DI_2DO:Modbus_4DI_2DO_DO0
label: Modbus_4DI_2DO_DO0
thingTypeUID: modbus:data
configuration:
readTransform: default
writeType: coil
writeTransform: default
updateUnchangedValuesEveryMillis: 1000
writeMultipleEvenWithSingleRegisterOrCoil: false
writeMaxTries: 3
writeStart: "0"
bridgeUID: modbus:poller:Modbus_4DI_2DO:Modbus_4DI_2DO_Poll

Das Problem ist nun das ich die ID umstellen muss um das 2te Modul (ID 11) zu erreichen.
Wenn ich es umstell funktioniert das Modul mit der ID 11 tadellos aber ich kann das Modul mit der 10ner ID nicht mehr erreichen.
Wenn ich 2 Modbus TCP Slaves erstelle bekomme ich einen Verbindungsfehler.

Vielen Dank schonmal im Voraus.

Grummel... Das mit der Markierung als Code war wörtlich zu nehmen, nicht interpretierbar. Farbe ist hübsch, wunderbar, hilft aber nicht. yaml (das ist das Format hier) gewichtet die Indentation, es besteht also ein Unterschied zwischen und Alles, was nicht als Code markiert ist, wird von der Forensoftware gnadenlos automatisch formatiert, z.B. werden führende Leerzeichen entfernt, ebenso Absatzmarken und vieles mehr. Code ist Code.

Ich fürchte, es wird darauf hinauslaufen, sich an die Entwickler zu wenden, offensichtlich ist es ein Designfehler, dass man über eine TCP Verbindung nur eine ID abfragen kann.
Ich nutze Modbus selbst nicht, aber es ist ja naheliegend, dass man auf einem Bus mit mehreren Geräten über eine Verbindung all diese Geräte ansprechen können sollte.
Und die "oberste Bridge" (ist ohnehin seltsam, dass hier mehrstufige Bridges verwendet werden, statt das Thing-Modell korrekt umzusetzen) ist sicherlich dazu gedacht, mit unterschiedlichen Bussen zu sprechen, nicht jeweils mit dem selben Bus, aber einem anderen Gerät.