Modbus mit TCP/IP Gateway / Verständnissfrage

Begonnen von cberl, 22 Februar 2020, 09:38:28

Vorheriges Thema - Nächstes Thema

cberl

Hallo, ich habe mir ein EAP Modul2020 B02 Modbus-TCP/IP (Modbus Gateway) zugelegt, welches ich per:

defmod ModbusEAPline1 Modbus 192.168.48.129:502
attr ModbusEAPline1 room 82.Modbus

setstate ModbusEAPline1 opened
setstate ModbusEAPline1 2020-02-21 22:18:03 state opened

eingebunden habe.
Wenn ich nun beispielsweise ein einzelnes Device am Bus anlege:

defmod MB_SDM630M_1 ModbusSDM630M 2 10
attr MB_SDM630M_1 alias EnergyMeter_PV3Phases
attr MB_SDM630M_1 room 52.Energie,82.Modbus

setstate MB_SDM630M_1 opened

Oder den SDM über ModbusAttr:

defmod ModbusEAPDev3 ModbusAttr 2 10
attr ModbusEAPDev3 userattr obj-i00004-poll obj-i00004-reading obj-i00005-poll obj-i00005-reading obj-i00006-poll obj-i00006-reading
attr ModbusEAPDev3 disable 0
attr ModbusEAPDev3 obj-i00004-poll 1
attr ModbusEAPDev3 obj-i00004-reading i4
attr ModbusEAPDev3 obj-i00005-poll 1
attr ModbusEAPDev3 obj-i00005-reading i5
attr ModbusEAPDev3 obj-i00006-poll 1
attr ModbusEAPDev3 obj-i00006-reading i6
attr ModbusEAPDev3 room 82.Modbus

setstate ModbusEAPDev3 opened
setstate ModbusEAPDev3 2020-02-21 23:58:28 state opened

Bekomme ich keine Readings. Das Gateway hat unter der ID 230 acht Eingänge, wo ich auch keine Readings bekomme.
Als IODEV wird in der GUI ModbusEAPline1 angezeigt, im List aber nicht.

Ein Abfragen der Geräte/Register mit QModMaster über TCP/IP funktioniert.
Das Abfragen der einzelnen Geräte mit ModbusAttr TCP funktioniert auch:

defmod ModbusEAPDev1 ModbusAttr 230 10 192.168.48.129:502 TCP
attr ModbusEAPDev1 userattr obj-d00032-poll obj-d00032-reading obj-d00033-poll obj-d00033-reading
attr ModbusEAPDev1 disable 0
attr ModbusEAPDev1 obj-d00032-poll 1
attr ModbusEAPDev1 obj-d00032-reading Pin1
attr ModbusEAPDev1 obj-d00033-poll 1
attr ModbusEAPDev1 obj-d00033-reading Pin2
attr ModbusEAPDev1 room 82.Modbus

setstate ModbusEAPDev1 opened
setstate ModbusEAPDev1 2020-02-21 22:43:04 Pin1 0
setstate ModbusEAPDev1 2020-02-21 22:43:04 Pin2 1
setstate ModbusEAPDev1 2020-02-21 22:18:05 state opened


Zusammengefasst: Nutze ich das angelegte Modbus Device als IODEV, funktionieren die Abfragen nicht.
Lege ich für jedes Gerät am RS485 Bus ein ModbusAttr an und frage es per TCP ab, bekomme ich Readings.

Wie verhält sich das bei Modbus TCP/IP? Ich finde da nur Beispiele mit serieller Anbindung.
Müssen alle Geräte am Bus über ModbusAttr mit [ID] 10 192.168.48.129:502 TCP angelegt werden oder sollte es auch funktionieren,
wenn ich das IODEV im ......ModbusAttr [ID] .. nutze?
..hoffe, dass ich mich verständlich ausgedrückt habe :-)

Fhem immer aktuell @win2016 und @ubuntu VM|7xFRM/ArduinoEthernet|Homematic|HMLan|CUNO|HarmonyHub|Modbus|Z-Wave|Milight-Hub|MQTT|OWX an ETH-UART|GoogleAssist,Alexa,Sonos|2nHelios IP Vario|Amad-Odroid|Telegram|Enigma2

Hollo

Ich verstehe es mal so, dass Du Deine (vorhandenen) Devices mit Modbus RTU nun hinter dem neuen Gerät betrieben willst!?

Ich würde an Deiner Stelle Stück für Stück vorgehen, und dabei zunächst bekannte Rahmenbedingungen schaffen.
Unbekanntes oder Besonderheiten gibt es meist genug, da hilft evtl. die Anleitung weiter.

1.
Da Dein Modul2020 ein integriertes Modbus RTU zu TCP Gateway besitzt, musst Du über dessen (Web)Interface diesen Bus parametrieren.
Also die üblichen Einstellungen wie Baudrate, Bits etc. .
Deine "seriellen" Devices müssen entsprechend auch auf die selbe Baudrate etc. und unterschiedliche Slave IDs eingestellt werden.

2.
Denk an die korrekte Terminierung (Busabschluss) des seriellen Busses; jeweils 120 Ohm am ANfang und Ende der Leitung.
Evtl. ist das am Modul und dem letzten Device auch zuschaltbar.

3.
Nimm Deinen Energiezähler, weil der ein funktionierendes definiertes Modul hat.
Dann brauchst Du Dich nicht um Registeradressen etc. kümmern.

Beispiel:
define SDM220_1 ModbusSDM220M 2 120 192.168.0.53:1000 RTU

Slave ID des Zählers: 2   (das vermeidet Ärger, wenn Du irgendwo die Default 1 hast oder brauchst)
Abfrageintervall: 120 sekunden (mach das am Anfang nicht zu klein!)
IP-Adresse des Gateways = Dein Modul2020
Port des Gateways: bei Dir vermutlich 502 !
Angabe RTU als Hinweis für das FHEM-Modul, dass Du ein serielles Device über TCP ansprechen willst.

4.
Lass dieses Gelumpe mit setstate open weg; wozu soll das sein!?

5.
Testen.
Da sollten nach etwas Zeit Werte/Readings kommen.
Wenn nicht, kontrolliere Stück für Stück die Einstellungen.

6.
Wenn das läuft, klemm das nächste Device in den Bus und konfiguriere weiter.

7.
Wenn Du das Gateway selbst über ModbusAttr definieren willst, musst es wahrscheinlich mit der ID 230 definieren/ansprechen.
"Nur" als Gateway brauchst Du es gar nicht definieren, dazu haben die RTU Slaves dann schon die IP.
Da musst Du etwas experimentieren.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

StefanStrobel

Hallo cberl,

Zitat von: cberl am 22 Februar 2020, 09:38:28

defmod ModbusEAPline1 Modbus 192.168.48.129:502


So ein define ist nicht nötig und wird auch nicht funktionieren.
Verbindungen über TCP macht ModbusAttr ohne zusätzliches IODev.
Ein IO Device vom Typ Modbus ist nur für serielle Verbindungen nötig, da sich dann ja mehrere ModbusAttr-Geräte ein gemeinsames serielles Interface teilen müssen.
TCP-Verbindungen enden aber direkt bei ModbusAttr.

Gruß
   Stefan



cberl

#3
@Stefan - Ich bin durch OWX, FRM, MQTT und HM IODEV geprägt und genau das wollte ich wissen - ModbusAttr benötigt bei TCP/IP kein definiertes IODEV!
Deswegen findet ich wohl auch nichts im Forum :-) & THX für die Module!
@Hollo - Ja, Anfangs tun sich da viele Fragen auf. Ich habe jetzt mehrere Geräte mit Modbus und Step by Step gehts vorwärts: Solax Wechselrichter, GTIL Wechselrichter, Energiemessung, China IO-Board. Interessantes Thema.

Danke für die Hinweise. 
Fhem immer aktuell @win2016 und @ubuntu VM|7xFRM/ArduinoEthernet|Homematic|HMLan|CUNO|HarmonyHub|Modbus|Z-Wave|Milight-Hub|MQTT|OWX an ETH-UART|GoogleAssist,Alexa,Sonos|2nHelios IP Vario|Amad-Odroid|Telegram|Enigma2

jw2013

#4
Hallo @cberl, @Stefan,

entschuldigt bitte vorab, dass ich dieses alte Thema nochmals aufgreife, aber ich bin leider aktuell auf ein großes Problem mit Stefan's Modbus Modul gestoßen.

Aber das soll kein Rant werden, allerbesten Dank für die tollen Module, Stefan!!!

Ich wollte für ein größeres Mehrfamilienhaus FHEM als Backend einsetzen, u.a. zur Heizungsoptimierung. Dort kommen viele BAC6000ALN Modbus-Thermostate für Klima-Anlagen zum Einsatz, da die Wärmepumpen im Sommer auch kühlen werden, aber das ist ein anderes Thema.

Jedenfalls gab es beim Test-Aufbau keinerlei Probleme, Raspberry war über USB-RS485 Dongles mit den Thermostat-Bus-Leitungen verbunden, alles funktionierte wie gewünscht (ca. 30 Module pro Bus).

Im fertigen Gebäude kommen statt USB Dongles Netzwerk-fähige Medien-Konverter zum Einsatz (Protoss-PE11), und auf jedem Bus können nur noch 5 Thermostate angesteuert werden :-/

Ursache ist, dass ModbusAttr für jedes TCP Modul eine eigene Verbindung öffnet, und die RS485-Netzwerk-Adapter die Anzahl gleichzeitiger Client-Verbindungen limitieren, per Default auf 5. Das lies sich in den Settings noch auf 20 hochsetzen, lief dann allerdings nicht mehr stabil, und auch noch nicht ausreichend.

Ich dachte zuerst, da könne ich doch nicht der erste sein, der in dieses Problem rennt, aber scheinbar...

Jedenfalls gibt es eine Lösung, OHNE Änderungen am Code. Danke dafür, @Stefan ;-)


define MB_GW_1 Modbus 10.100.200.101:8899

define Thermostat_1_1 BAC6000ALN 11 60 TCP
attr Thermostat_1_1 IODev MB_GW_1
define Thermostat_1_2 BAC6000ALN 12 60 TCP
attr Thermostat_1_2 IODev MB_GW_1
define Thermostat_1_3 BAC6000ALN 13 60 TCP
attr Thermostat_1_3 IODev MB_GW_1

define MB_GW_2 Modbus 10.100.200.102:8899

define Thermostat_2_1 BAC6000ALN 21 60 TCP
attr Thermostat_2_1 IODev MB_GW_2
define Thermostat_2_2 BAC6000ALN 22 60 TCP
attr Thermostat_2_2 IODev MB_GW_2
define Thermostat_2_3 BAC6000ALN 23 60 TCP
attr Thermostat_2_3 IODev MB_GW_2


Funktioniert tatsächlich wie gewünscht, jetzt öffnet FHEM je nur noch eine TCP Verbindung zu jedem Gateway, und alle Thermostate sind wieder ansteuerbar!

@cberl, in Deinem Fall hätte folgendes funktioniert:


defmod ModbusEAPline1 Modbus 192.168.48.129:502
attr ModbusEAPline1 room 82.Modbus

defmod MB_SDM630M_1 ModbusSDM630M 2 10 TCP
attr MB_SDM630M_1 IODev ModbusEAPline1
attr MB_SDM630M_1 alias EnergyMeter_PV3Phases
attr MB_SDM630M_1 room 52.Energie,82.Modbus


Mit dem 'TCP' in der Definition spricht Stefans Modul Modbus-TCP (statt RTU), und das IODev bindet den richtigen Adapter.

Hoffe, das hilft auch anderen!

Beste Grüße
- jens