Neue Versionen und Support zum Modbus-Modul

stolus · 23 Mai 2020, 09:13:05

Hi Stefan,
vielen Dank für die Hilfe, hier meine Konfig: FHEM auf dem RaspberryZero hat die IP 192.168.1.33 und der FHEM Hauptserver die IP 192.168.1.35

Hier Die Konfig auf dem RaspberryZero:
1. Device ModbusRS485 Verbindung zur Wärmepumpe:

Code Auswählen

Internals:
   DEF        /dev/ttyS0@19200,8,E,1
   DeviceName /dev/ttyS0@19200,8,E,1
   EXPECT     idle
   FD         4
   FUUID      5eaec0a2-f33f-c83a-c2b3-f7cdf3852cd5fa82
   LASTOPEN   1590172778.53833
   MODE       master
   NAME       ModbusRS485
   NR         32
   NTFY_ORDER 50-ModbusRS485
   PARTIAL    
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2020-05-22 20:39:38   state           opened
   REMEMBER:
     lid        2
     lname      DHW300
     lrecv      1590216923.12295
     lsend      1590216923.09544
   defptr:
     DHW300     2
Attributes:
   room       Heizungsraum

2. Modbus Modul DHW300 zum Auslesen der Wärmepumpe Dimplex DHW300

Code Auswählen

Internals:
   CHANGED    
   DEF        2 60
   FUUID      5eb3e9b3-f33f-c83a-4c4d-0a1b18afa2d7fbd7
   INTERVAL   60
   IODev      ModbusRS485
   MODBUSID   2
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       DHW300
   NOTIFYDEV  global
   NR         33
   NTFY_ORDER 50-DHW300
   PROTOCOL   RTU
   STATE      opened
   TRIGGERTIME 1590217390.11278
   TRIGGERTIME_FMT 2020-05-23 09:03:10
   TYPE       ModbusDHW300
   lastUpdate 1590217330.11278
   FRAME:
   READ:
   READINGS:
     2020-05-23 09:02:11   Abtaufuehler_C  25
     2020-05-23 09:02:20   Betriebsart     Idle
     2020-05-23 09:02:12   Elektroheizung  AUS
     2020-05-23 09:01:12   Kollektrortemperatur_C 209
     2020-05-23 09:02:13   Laufzeit_Elektroheizung_h 70
     2020-05-23 09:02:18   Laufzeit_Geraet_h 1782
     2020-05-23 09:01:13   Laufzeit_Ventilator_h 237
     2020-05-23 09:02:26   Laufzeit_Verdichter_h 221
     2020-05-23 09:01:11   Leistung_W      0
     2020-05-23 09:02:28   Lufteintritt_C  20
     2020-05-23 09:02:15   Meldungen       Fuehlerfehler_R13
     2020-05-23 09:02:10   Solar-/Ladepumpe AUS
     2020-05-23 09:02:19   Sollwert_aktuell_C 15
     2020-05-23 09:02:14   Speichertemperatur_oben_C 46
     2020-05-23 09:02:23   Speichertemperatur_unten_C 46
     2020-05-23 09:02:27   Ventilator      AUS
     2020-05-23 09:01:10   Verdichter      AUS
     2020-05-23 09:02:17   WW_Absenktemperatur_C 15
     2020-05-23 09:02:29   WW_Boost_Dauer_h 4
     2020-05-23 09:02:22   WW_Boost_Solltemp_C 65
     2020-05-23 09:02:24   WW_Hysterese_K  5
     2020-05-23 09:02:25   WW_Modus        ECO
     2020-05-23 09:02:16   WW_Solltemperatur_C 55
     2020-05-23 09:02:21   WW_Verzoegerung_h 12
     2020-05-22 20:39:38   state           opened
   REMEMBER:
     lrecv      1590217349.98522
     lsend      1590217349.95613
   gotReadings:
     WW_Boost_Dauer_h 4
   lastRead:
     h14        1590217336.49537
     h15        1590217337.53371
     h16        1590217344.80143
     h17        1590217345.8406
     h18        1590217341.68684
     h19        1590217349.9927
     h20        1590217342.72483
     i10        1590217348.95442
     i11        1590217272.51521
     i12        1590217339.60988
     i13        1590217331.3041
     i14        1590217347.91674
     i15        1590217270.4393
     i16        1590217332.34306
     i17        1590217330.26112
     i18        1590217271.47673
     i19        1590217340.64979
     i20        1590217335.45801
     i21        1590217338.57179
     i22        1590217273.55346
     i23        1590217346.87779
     i24        1590217333.38071
     i8         1590217334.4187
     i9         1590217343.75937
Attributes:
   event-on-change-reading .*
   room       Heizungsraum

3. Modbus Relay DHW300RELAY zum weiterleiten der Anfrage aus dem FHEM Hauptserver

Code Auswählen

Internals:
   CFGFN      
   DEF        3 relay 192.168.1.35:502 TCP to DHW300
   DeviceName 192.168.1.35:502
   EXPECT     request
   FUUID      5ec82669-f33f-c83a-7f42-ef064944d7189bc8
   IODev      DHW300RELAY
   MODBUSID   3
   MODE       relay
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       DHW300RELAY
   NOTIFYDEV  global
   NR         63
   NTFY_ORDER 50-DHW300RELAY
   PROTOCOL   TCP
   RELAY      DHW300
   RELID      2
   SERVERSOCKET 
   STATE      Initialized
   TCPConn    1
   TCPServer  1
   TYPE       ModbusAttr
   READ:
     BUFFER     
   READINGS:
     2020-05-22 22:02:34   state           Initialized
   defptr:
     DHW300RELAY 3
Attributes:
   room       Heizungsraum

Hier die Konfig auf dem FHEM Hauptserver:
1. Modbus Modul DHW300MASTER

Code Auswählen


Internals:
   DEF        4 60 192.168.1.33:502 TCP
   DeviceName 192.168.1.33:502
   EXPECT     idle
   FUUID      5ec82930-f33f-8703-0938-336013e718f2d6e8
   INTERVAL   60
   IODev      DHW300MASTER
   LASTOPEN   1590217817.93141
   MODBUSID   4
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       DHW300MASTER
   NEXT_OPEN  1590217851.85001
   NOTIFYDEV  global
   NR         362
   NTFY_ORDER 50-DHW300MASTER
   PARTIAL    
   PROTOCOL   TCP
   STATE      disconnected
   TCPConn    1
   TRIGGERTIME 1590217837.78341
   TRIGGERTIME_FMT 2020-05-23 09:10:37
   TYPE       ModbusDHW300
   devioLoglevel 3
   lastUpdate 1590217777.78341
   nextOpenDelay 60
   FRAME:
   QUEUE:
     HASH(0xa374e20)
     HASH(0xa076558)
     HASH(0xa2fd818)
     HASH(0xa2d05c8)
     HASH(0x9fc7b08)
     HASH(0xa2e58a8)
     HASH(0xa31e248)
     HASH(0xa0ac6f0)
     HASH(0xa2f34c8)
     HASH(0x9fc2d08)
     HASH(0xa2cb220)
     HASH(0x9fac470)
     HASH(0xa303440)
     HASH(0xa2ee2c0)
     HASH(0xa0a3158)
     HASH(0xa2bc340)
     HASH(0xa096598)
     HASH(0xa2c7e90)
     HASH(0xa315290)
     HASH(0xa2c7b00)
     HASH(0x9751550)
     HASH(0xa2f1670)
     HASH(0x9f93fc8)
     HASH(0xa314c30)
   READ:
     BUFFER     
   READINGS:
     2020-05-23 09:09:51   state           disconnected
   defptr:
     DHW300MASTER 4
   lastRead:
Attributes:
   DbLogExclude .*
   room       Heizungsraum

stolus · 23 Mai 2020, 09:30:37

Ich habe es alternativ auch mit dem Modbusattr auf dem RaspberryZero probiert

1. Modbus Master DHW300 mit Modbusattr

Code Auswählen

Internals:
   CFGFN      
   DEF        2 60
   FUUID      5ec8cf90-f33f-c83a-bd15-41403676820e59d7
   INTERVAL   60
   IODev      ModbusRS485
   MODBUSID   2
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       DHW300
   NOTIFYDEV  global
   NR         136
   NTFY_ORDER 50-DHW300
   PROTOCOL   RTU
   STATE      opened
   TRIGGERTIME 1590218942.69795
   TRIGGERTIME_FMT 2020-05-23 09:29:02
   TYPE       ModbusAttr
   lastUpdate 1590218882.69795
   READINGS:
     2020-05-23 09:24:00   state           opened
Attributes:
   room       Heizungsraum

Leider auch keine Verbindung

StefanStrobel · 23 Mai 2020, 14:10:43

Hallo Stolus,

mir fallen zwei Dinge auf:
Bei der Definition des Relays musst Du eine lokale IP-Adresse und einen lokalen TCP-Port angeben, auf dem das Relay auf eingehende Verbindungen wartet. Du hast aber die Adresse des Haupt-Fhem-Servers beim Relay angegeben. Das kann nicht funktionieren.

Als Port für das Relay hast Du 502 angegeben. Wenn Fhem aber nicht als root läuft oder anderweitig dafür gesorgt wird, kann es diesen Port nicht öffnen. Ich würde eher 1502 nehmen.

Ich muss das wohl in der Doku etwas deutlicher beschreiben.

Am besten nimmst Du auch die neue Version, die ich hier vor ein paar Tagen gepostet habe. Gerade beim Betrieb als Relay sollte die besser funktionieren, muss aber noch getestet werden

Gruß
Stefan

stolus · 24 Mai 2020, 17:09:59

Hallo Stefan,
danke für den Tip, ich habe die Def jetzt angepasst
RaspberryZero:

Code Auswählen

defmod DHW300RELAY ModbusAttr 3 relay 192.168.1.33:1502 TCP to DHW300
FHEM Hauptserver:

Code Auswählen

defmod DHW300MASTER ModbusDHW300 4 60 192.168.1.33:1502
Jetzt kommt beim Hautpserver ein opened.

Leider bekomme ich beim auslesen der Register nur Fehlermeldung (Timeout).
Hier ein paar Beispiele:

Code Auswählen

2020.05.24 17:04:16 3: DHW300MASTER: ResponseTimeout called, master was DHW300MASTER
2020.05.24 17:04:16 3: DHW300MASTER: Timeout waiting for a modbus response, read buffer empty, request: id 4, fCode 3, type h, adr 19, len 1, master device DHW300MASTER, reading WW_Boost_Dauer_h (getUpdate), queued 12.00 secs ago, sent 3.00 secs ago
2020.05.24 17:04:19 3: DHW300MASTER: ResponseTimeout called, master was DHW300MASTER
2020.05.24 17:04:19 3: DHW300MASTER: Timeout waiting for a modbus response, read buffer empty, request: id 4, fCode 4, type i, adr 14, len 1, master device DHW300MASTER, reading Ventilator (getUpdate), queued 15.01 secs ago, sent 3.00 secs ago
2020.05.24 17:04:22 3: DHW300MASTER: ResponseTimeout called, master was DHW300MASTER
2020.05.24 17:04:22 3: DHW300MASTER: Timeout waiting for a modbus response, read buffer empty, request: id 4, fCode 4, type i, adr 17, len 1, master device DHW300MASTER, reading Solar-/Ladepumpe (getUpdate), queued 18.01 secs ago, sent 3.00 secs ago
2020.05.24 17:04:25 3: DHW300MASTER: ResponseTimeout called, master was DHW300MASTER
2020.05.24 17:04:25 3: DHW300MASTER: Timeout waiting for a modbus response, read buffer empty, request: id 4, fCode 4, type i, adr 10, len 1, master device DHW300MASTER, reading Lufteintritt_C (getUpdate), queued 21.01 secs ago, sent 3.00 secs ago

Das Modul habe ich auf beiden Instanzen gegen das aktuelle von Dir getauscht.

StefanStrobel · 24 Mai 2020, 21:09:51

Hallo stolus,

Dein Relay hört auf Modbus ID 3, Dein Master versucht aber Modbus ID 4 abzufragen.
Stell mal den DHW300Master so ein, dass er die ID des Relays abfragt, also 3.

Wenn es dann noch nicht klappt, wäre ein Auszug aus den Logs hilfreich, wobei sowohl für ModbusRS485, DHW300, DHW300RELAY als auch DHW300Master das verbose-Attribut auf 5 stehen sollte.

Gruss
Stefan

stolus · 29 Mai 2020, 09:55:42

Hi Stefan,
alleine komme ich da anscheinend nicht weiter.

FHEM DHW300MASTER jetzt auf ID 3

Code Auswählen

Internals:
   DEF        3 60 192.168.1.33:1502
   DeviceName 192.168.1.33:1502
   EXPECT     idle
   FD         5
   FUUID      5ec82930-f33f-8703-0938-336013e718f2d6e8
   INTERVAL   60
   IODev      DHW300MASTER
   LASTOPEN   1590736838.56948
   MODBUSID   3
   MODE       master
   MODULEVERSION Modbus 4.1.8 - 12.11.2019
   NAME       DHW300MASTER
   NOTIFYDEV  global
   NR         362
   NTFY_ORDER 50-DHW300MASTER
   PARTIAL    
   PROTOCOL   RTU
   STATE      opened
   TCPConn    1
   TIMEOUTS   221
   TRIGGERTIME 1590738766.13994
   TRIGGERTIME_FMT 2020-05-29 09:52:46
   TYPE       ModbusDHW300
   devioLoglevel 3
   lastUpdate 1590738706.13994
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2020-05-29 09:20:39   state           opened
   REMEMBER:
     lid        3
     lname      DHW300MASTER
     lsend      1590738724.15785
   defptr:
     DHW300MASTER 3
   lastRead:
Attributes:
   DbLogExclude .*
   room       Heizungsraum
   verbose    5

Hier ein Auszug der Logfiles:
FHEM Server:
https://pastebin.com/RXbCjZu8

FHEM Raspberry Zero
https://pastebin.com/QrVL6jfd

98_ModbusDHW300
https://pastebin.com/MyjaiNmh

StefanStrobel · 29 Mai 2020, 20:44:12

Hallo stolus,

kein Problem, das bekommender schon noch hin

Aktuell scheitert es daran, dass Du bei DHW300MASTER im Define das Schlüsselwort TCP vergessen hast.
Dann verwendet der das Protokoll Modbus-RTU über TCP und nicht Modbus-TCP.
Beim Relay hattest Du aber TCP angegeben, so dass das Relay eben Modbus-TCP erwartet.
Modbus-RTU über TCP und Modbus-TCP verwenden unterschiedliche Frame-Formate.

Gruß
Stefan

stolus · 29 Mai 2020, 22:01:32

Hi Stefan,
TCP habe ich ergänzt.
Leider noch immer kein Erfolg.
Hier mal die Logs der letzten Minuten

FHEM RaspberryZero
https://pastebin.com/xSwwAbyK

FHEM Server
https://pastebin.com/0Rh6HcSp

Code Auswählen

Internals:
   DEF        3 60 192.168.1.33:1502 TCP
   DeviceName 192.168.1.33:1502
   EXPECT     idle
   FD         42
   FUUID      5ec82930-f33f-8703-0938-336013e718f2d6e8
   INTERVAL   60
   IODev      DHW300MASTER
   LASTOPEN   1590780191.00167
   MODBUSID   3
   MODE       master
   MODULEVERSION Modbus 4.1.8 - 12.11.2019
   NAME       DHW300MASTER
   NOTIFYDEV  global
   NR         362
   NTFY_ORDER 50-DHW300MASTER
   PARTIAL    
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TIMEOUTS   21
   TRIGGERTIME 1590782442.32565
   TRIGGERTIME_FMT 2020-05-29 22:00:42
   TRIGGERTIME_SAVED 
   TYPE       ModbusDHW300
   devioLoglevel 3
   lastUpdate 1590782382.32565
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2020-05-29 21:23:11   state           opened
   REMEMBER:
     lid        3
     lname      DHW300MASTER
     lrecv      1590782221.44373
     lsend      1590782400.34241
   defptr:
     DHW300MASTER 3
   lastRead:
Attributes:
   DbLogExclude .*
   room       Heizungsraum
   verbose    5

Es kommen immer noch timeouts.

StefanStrobel · 30 Mai 2020, 11:06:32

Hallo stolus,

Die Requests vom Master kommen jetzt korrekt beim Relay an, werden zum Slave weitergeleitet und die Antwort wird auch vom Relay wieder empfangen. Dann schlägt aber scheinbar ein Bug im Relay zu und das Relay hat vergessen, an wen die Antwort weiter geleitet werden soll. Dass muss ich mir genauer ansehen. Es kann sein, dass der Bug nur in der aktuellen Entwicklungsversion steckt oder dass er schon immer da war und aus irgendwelchen Gründen bisher nicht aufgefallen ist.
Ich melde mich sobald ich ein Update habe.

Gruß
Stefan

StefanStrobel · 30 Mai 2020, 22:08:53

Hallo,

Anbei ein neuer Zwischenstand des Modbus-Moduls, bei dem der Fehler im Relay-Modus der letzen Version behoben sein sollte.

Gruß
Stefan

sukram · 31 Mai 2020, 14:39:11

Hallo alle beisammen,

ich hätte da gern mal ein Problem

Ist Zustand:
FHEM auf Ubuntu Server
DIY Modbus TCP-RTU Gateway (ethersex auf mod. AVR-Net-IO)
3x Saia ALE3 Modbus Stromzähler
Eine Instanz ModbusAttr für einen Zähler funktioniert problemlos, alle 30sek neue Daten (10 von 52 Registern)

Soll Zustand:
mind. 3-10 Instanzen ModbusAttr für Stromzähler, Thermostate, Aktoren.

Problem:
konkurrierender TCP Zugriff auf das Gateway schlägt fehl. Die erste Instanz bekommt kurz Zugriff, danach gehen alle Instanzen auf Timeout. Dabei wird von einer anderen Instanz der Fehler gemeldet, dass unaufgefordete Daten eingegangen sind. Anscheinend gibt es Probleme bei der Koordination der Datenströme.

Logauszug:

Code Auswählen

2020.05.30 15:07:14 3: nioZaehler1: read got new data while idle, drop buffer 000a00000007040304000652dc
2020.05.30 15:07:16 3: nioZaehler3: Timeout waiting for a modbus response request: id 4, fCode 3, tid 10, type h, adr 27, len 2 for device nioZaehler3 reading Total1 (getUpdate), queued 2.37 secs ago, sent 2.37 secs ago, read buffer empty

"nioZaehlerx" ist der Name der jeweiligen ModbusAttr Instanz.

Raw definition der Instanz:

Code Auswählen

define nioZaehler1 ModbusAttr 2 30 10.102.1.240 TCP
attr nioZaehler1 dev-h-combine 20
attr nioZaehler1 dev-type-dint-expr $val/100
attr nioZaehler1 dev-type-dint-len 2
attr nioZaehler1 dev-type-dint-revRegs 0
attr nioZaehler1 dev-type-dint-unpack N
attr nioZaehler1 obj-h0-reading Firmwareversion
attr nioZaehler1 obj-h1-reading Registercount
attr nioZaehler1 obj-h14-reading Hardwareversion
attr nioZaehler1 obj-h15-reading Serialnumber
attr nioZaehler1 obj-h15-type dint
attr nioZaehler1 obj-h2-reading Flagcount
attr nioZaehler1 obj-h21-reading Status
attr nioZaehler1 obj-h22-reading Modbustimeout
attr nioZaehler1 obj-h23-reading ModbusAddress
attr nioZaehler1 obj-h24-reading Error
attr nioZaehler1 obj-h26-reading Tarif
attr nioZaehler1 obj-h27-poll 1
attr nioZaehler1 obj-h27-reading Total1
attr nioZaehler1 obj-h27-type dint
attr nioZaehler1 obj-h29-poll 1
attr nioZaehler1 obj-h29-reading Subtotal1
attr nioZaehler1 obj-h29-type dint
attr nioZaehler1 obj-h3-reading Baudrate
attr nioZaehler1 obj-h3-type dint
attr nioZaehler1 obj-h31-reading Total2
attr nioZaehler1 obj-h31-type dint
attr nioZaehler1 obj-h33-reading Subtotal2
attr nioZaehler1 obj-h33-type dint
attr nioZaehler1 obj-h35-poll 1
attr nioZaehler1 obj-h35-reading Urms_L1
attr nioZaehler1 obj-h36-expr $val/10
attr nioZaehler1 obj-h36-poll 1
attr nioZaehler1 obj-h36-reading Irms_L1
attr nioZaehler1 obj-h37-expr $val/100
attr nioZaehler1 obj-h37-poll 1
attr nioZaehler1 obj-h37-reading Prms_L1
attr nioZaehler1 obj-h38-expr $val/100
attr nioZaehler1 obj-h38-poll 1
attr nioZaehler1 obj-h38-reading Qrms_L1
attr nioZaehler1 obj-h39-expr $val/100
attr nioZaehler1 obj-h39-poll 1
attr nioZaehler1 obj-h39-reading CosPhi_L1
attr nioZaehler1 obj-h40-poll 0
attr nioZaehler1 obj-h40-reading Urms_L2
attr nioZaehler1 obj-h41-expr $val/10
attr nioZaehler1 obj-h41-poll 0
attr nioZaehler1 obj-h41-reading Irms_L2
attr nioZaehler1 obj-h42-expr $val/100
attr nioZaehler1 obj-h42-poll 0
attr nioZaehler1 obj-h42-reading Prms_L2
attr nioZaehler1 obj-h43-expr $val/100
attr nioZaehler1 obj-h43-poll 0
attr nioZaehler1 obj-h43-reading Qrms_L2
attr nioZaehler1 obj-h44-expr $val/100
attr nioZaehler1 obj-h44-poll 0
attr nioZaehler1 obj-h44-reading CosPhi_L2
attr nioZaehler1 obj-h45-poll 0
attr nioZaehler1 obj-h45-reading Urms_L3
attr nioZaehler1 obj-h46-expr $val/10
attr nioZaehler1 obj-h46-poll 0
attr nioZaehler1 obj-h46-reading Irms_L3
attr nioZaehler1 obj-h47-expr $val/100
attr nioZaehler1 obj-h47-poll 0
attr nioZaehler1 obj-h47-reading Prms_L3
attr nioZaehler1 obj-h48-expr $val/100
attr nioZaehler1 obj-h48-poll 0
attr nioZaehler1 obj-h48-reading Qrms_L3
attr nioZaehler1 obj-h49-expr $val/100
attr nioZaehler1 obj-h49-poll 0
attr nioZaehler1 obj-h49-reading CosPhi_L3
attr nioZaehler1 obj-h50-expr $val/100
attr nioZaehler1 obj-h50-poll 1
attr nioZaehler1 obj-h50-reading Prms_total
attr nioZaehler1 obj-h51-expr $val
attr nioZaehler1 obj-h51-poll 1
attr nioZaehler1 obj-h51-reading Qrms_total
attr nioZaehler1 obj-h6-len 8
attr nioZaehler1 obj-h6-reading Type
attr nioZaehler1 obj-h6-unpack a*
attr nioZaehler1 stateFormat Summe: Total1 kWh Aktuell: Prms_total W Qrms_total VA<br />L1 Urms_L1 V Irms_L1 A Prms_L1 W Qrms_L1 VA Cos Phi CosPhi_L1

Wie gesagt, eine Instanz läuft ganz brav, mehrere schlagen sich. Ein alternativer Ansatz ist jetzt am Start, dabei habe ich einen ModbusTCPServer definiert, der auf das NetIO Gateway zeigt, und dann muss ich jedes Register einzeln anlegen. Nicht so schön, aber funktioniert stabil:

Code Auswählen


define netiomb ModbusTCPServer 10.102.1.240
attr netiomb combineReads 10:20
attr netiomb pollInterval 30
attr netiomb queueDelay 20

define Zaehler02PRMS ModbusRegister 2 50
attr Zaehler02PRMS IODev netiomb

define Zaehler04PRMS ModbusRegister 4 50
attr Zaehler04PRMS IODev netiomb

define Zaehler02Stand ModbusRegister 2 27
attr Zaehler02Stand IODev netiomb
attr Zaehler02Stand plcDataType DINT_BE

define Zaehler04Stand ModbusRegister 4 27
attr Zaehler04Stand IODev netiomb
attr Zaehler04Stand plcDataType DINT_BE

Da jetzt am Relay Teil wegen der Adresszuordnung gebaut wurde, kann das hier auch zum Erfolg führen?

Danke schon mal!

MfG sukram

PS: gibt es irgendwo eine Sammlung von Registerdefinitionen für verschiedene Geräte?

StefanStrobel · 31 Mai 2020, 15:46:24

Hallo Sukram,

Auf den ersten Blick sieht es so aus, als ob Dein Gateway nicht in der Lage wäre mehrere TCP-Verbindungen zu bedienen bzw. Replies korrekt einem Request und dessen TCP-Verbindung zuzuordnen. Es scheint so als ob Das Gateway die Modbus-Replies einfach an die zuletzt geöffnete TCP-Verbindung schickt, unabhängig davon, ob darüber auch der Request reinkam.
Genau kann ich das aber erst sagen, wenn Du Logs mit Verbose 5 postest.

Die einfachste Lösung wäre vermutlich das Gateway durch ein Relay auf einem Pi/Pi-Zero und Fhem-Basis auszutauschen. Dann kümmert sich das Relay darum.

Poste doch mal ein ausführliches Log mit Verbose 5, dann sehen wir, was genau passiert und welche Optionen es gibt.

Gruß
Stefan

stolus · 31 Mai 2020, 15:50:02

Hallo Stefan,
ich habe gerade Deinen aktuellen Stand des Moduls eingepflegt.
Läuft jetzt wie erwartet.
Vielen Dank für Deine Hilfe und super schnelle Reaktion !!

sukram · 31 Mai 2020, 17:01:00

Zitat von: StefanStrobel am 31 Mai 2020, 15:46:24
Hallo Sukram,

Auf den ersten Blick sieht es so aus, als ob Dein Gateway nicht in der Lage wäre mehrere TCP-Verbindungen zu bedienen bzw. Replies korrekt einem Request und dessen TCP-Verbindung zuzuordnen. Es scheint so als ob Das Gateway die Modbus-Replies einfach an die zuletzt geöffnete TCP-Verbindung schickt, unabhängig davon, ob darüber auch der Request reinkam.
Genau kann ich das aber erst sagen, wenn Du Logs mit Verbose 5 postest.

Mit der 1x TCP Verbindung bin ich mir ziemlich sicher, dass dem so ist. So leistungsfähig ist die Kombination ATMega und Ethersex nicht.

Zitat
Die einfachste Lösung wäre vermutlich das Gateway durch ein Relay auf einem Pi/Pi-Zero und Fhem-Basis auszutauschen. Dann kümmert sich das Relay darum.

Poste doch mal ein ausführliches Log mit Verbose 5, dann sehen wir, was genau passiert und welche Optionen es gibt.

Gruß
Stefan

Den Stromverbrauch/Pflegeaufwand eines Raspi wollte ich mir gerne sparen. Deshalb die Lightversion mit AVR. Ausserdem passt das auch in ein kleines Hutschienengehäuse.

Ich liefere gern noch Logdaten, das dauert aber bis morgen. Was mir vorschweben würde, dass die Daten wie bei dem Modbusmodul für lokale Schnittstellen zusammengefasst wird, bevor es auf die Reise geht. Ich hätte ansonsten noch mit Kommandozeilentricks wie netcat, socat und co probiert...

sukram · 01 Juni 2020, 23:48:06

Hallo nochmal, ich habe hier ein kurzes Logfile, mit 2 aktiven ModbusAttr Instanzen - nioZaehler1 und nioZaehler3 - im verbose 5. Die Definitionen dazu stehen ein paar Post weiter oben.

Das Gateway kann definitiv nur 1 TCP Stream gleichzeitig bearbeiten. Gibt es eine Möglichkeit, dass die ModbusAttr Instanz sofort die TCP Verbindung wieder schließt oder statt direkt eine Verbindung aufzubauen an eine ModbusTCPServer Instanz bindet?

Ich möchte verschiedene einfache Geräte wie z.B. Relais-I/O-Module, kleine Feldbuskoppler und eben komplexe Geräte wie diese Zähler an einem Bus bündeln, und das auch ohne Kopfstände in FHEM einbinden. Gibt es eine Variante, die nicht auf externe Rechenleistung im Interface/Gateway angewiesen ist?

MfG sukraM