Neue Versionen und Support zum Modbus-Modul

[StefanStrobel]

Hallo Christian,

Als Mode wird dann im Device "master" angezeigt.
Daraus leite ich dann ab, dass der Wechselrichter ein Master ist.

Das ist das erste Missverständnis.
Mode "master" bedeutet dass Fhem als Master (= Modbus Client) arbeitet und somit aktiv einen Slave (=Modbus Server abfragen kann). Dein WR ist der Slave.

...
Ich beginne dann mal Punkt 1) - 4) umzusetzen...
...
Im Log finde ich dann diese Anfrage

Code Auswählen Erweitern


2022.11.17 12:28:04.722 4: WR_3_192.168.178.17_60726: HandleRequest, current frame / read buffer: 0001000000064703009a0014, id 71, fCode 3, tid 1,
request: id 71 fc 3 h154, len 20, tid 1

Allerdings weiß ich jetzt nicht, was ich mit dem  fc 3 h154, len 20 machen soll

Punkt 1 in der Liste haben wir damit:

1) den Slave in Fhem auf verbose 5 stellen und die eingehenden Requests vom Energiemanager mit Function code, Adresse und Länge notieren (z.B. fc4 auf i123 mit len 4, fc3 auf h234 mit len 1, ...)
2) Fhem als Master konfigurieren und genau solche Requests an den echten WR schicken. Ein input register muss dabei auch ein input register bleiben und darf kein holding register werden und wenn der Energiemanager 5 Register auf einmal - also Länge 5 - abfragt, dann musst Du das genauso mit len 5 machen. Dabei verbose auf 5
3) die Antworten des echten WR (Objekte mit Längen und Werten) im Fhem-Log suchen und notieren
4) daraus die Konfiguration des Fake WR Slaves in Fhem mit festen Werten (zum Testen) ableiten und Objekt für Objekt vergleichen, ob Fhem die gleichen Antworten schickt wie der der original WR.

Der Energiemanager liest 20 Register ab Register 154 in einem Request.

Jetzt würde ich mit Punkt 2 weiter machen, Fhem als Master konfigurieren und schauen, wie der WR auf so einen Request antwortet.
Die Register hast Du ja schon definiert. Wenn Du noch Combine auf 20 setzt, dann sollte Deine Master-Definition auch 20 Register auf einmal lesen und dann sehen wir bei verbose 5 wie der WR genau darauf antwortet.

Gruss
   Stefan




Gruss
   Stefan

[Mariomgn]

Hallo Stefan,

vielen Dank für die Antwort.

Ich habe das Ganze nun am laufen.

Wo kann ich das Projekt bereitstellen, falls noch jemand Fhem mit einer Micro 820 verbinden möchte?


MfG Mario

[ch.eick]

Ich habe das Ganze nun am laufen.

Wo kann ich das Projekt bereitstellen, falls noch jemand Fhem mit einer Micro 820 verbinden möchte?

Wie wäre es im Wiki? Du kannst Dir da einen Zugriff geben lassen und mithelfen, dass es immer besser wird.

[pejonp]

Hallo,

ich möchte einen TFU-2000M per Modbus auslesen.

Register h1529  2 Stellen  "Electronic serial number"          BCD   High byte first

Im Log wird es auch angezeigt, aber ich bekomme es nicht ordenlich in FHEM angezeigt.
die S/N-Nummer ist: 21217195

im Log wird : response: id 5, fc 3, h1528, len 2, values 21219571 angezeigt. Die Stellen müssen auch noch getauscht werden.

in FHEM (ich habe die beiden Regsiter aufgeteilt).Und das wird angezeigt.
SN1: 8481
SN2: 29077

attr TUF2000M5 obj-h1528-len 1
attr TUF2000M5 obj-h1528-reading SN1
attr TUF2000M5 obj-h1528-unpack s

attr TUF2000M5 obj-h1529-len 1
attr TUF2000M5 obj-h1529-reading SN2
attr TUF2000M5 obj-h1529-unpack s

Vielleicht kann mir einer einmal einen Hinweis geben was bei unpack eingetragen werden muss und wie die Stellen getauscht werden können.
Vielen Dank.

log

Code Auswählen Erweitern


2022.11.18 11:42:26 5: ioUltra: ResetExpect for HandleResponse from response to idle
2022.11.18 11:42:26 5: ioUltra: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2022.11.18 11:42:26 5: ioUltra: DropFrame called from ReadFn - drop 050304000300044e30
2022.11.18 11:42:26 5: ioUltra: ProcessRequestQueue called from Fhem internal timer as queue:ioUltra, qlen 1, request: request: id 5, read fc 3 h1528, len 2, master device TUF2000M5, reading SN1 (getUpdate for combined h1528 len 1 SN1 with h1529 len 1 SN2), queued 1.09 secs ago
2022.11.18 11:42:26 5: ioUltra: checkDelays clientSwitchDelay is not relevant
2022.11.18 11:42:26 5: ioUltra: checkDelays sendDelay, last send to same device was 0.046 secs ago, required delay is 0.1
2022.11.18 11:42:26 5: ioUltra: checkDelays busDelayRead, last activity on bus was 0.015 secs ago, required delay is 0
2022.11.18 11:42:26 5: ioUltra: checkDelays commDelay, last communication with same device was 0.013 secs ago, required delay is 0.1
2022.11.18 11:42:26 4: ioUltra: checkDelays found commDelay not over, set timer to try again in 0.087
2022.11.18 11:42:27 5: ioUltra: ProcessRequestQueue called from Fhem internal timer as queue:ioUltra, qlen 1, request: request: id 5, read fc 3 h1528, len 2, master device TUF2000M5, reading SN1 (getUpdate for combined h1528 len 1 SN1 with h1529 len 1 SN2), queued 1.18 secs ago
2022.11.18 11:42:27 5: ioUltra: checkDelays commDelay, last communication with same device was 0.104 secs ago, required delay is 0.1
2022.11.18 11:42:27 5: ioUltra: checkDelays busDelayRead, last activity on bus was 0.106 secs ago, required delay is 0
2022.11.18 11:42:27 5: ioUltra: checkDelays clientSwitchDelay is not relevant
2022.11.18 11:42:27 5: ioUltra: checkDelays sendDelay, last send to same device was 0.137 secs ago, required delay is 0.1
2022.11.18 11:42:27 4: ioUltra: ProcessRequestQueue (V4.4.11 - 5.10.2022) qlen 1, sending 050305f8000244b2 via /dev/rs485@9600,8,N,1, read buffer empty,
request: id 5, read fc 3 h1528, len 2, master device TUF2000M5, reading SN1 (getUpdate for combined h1528 len 1 SN1 with h1529 len 1 SN2), queued 1.18 secs ago
2022.11.18 11:42:27 5: ioUltra: Send called from ProcessRequestQueue
2022.11.18 11:42:27 5: DevIo_SimpleWrite ioUltra: 050305f8000244b2
2022.11.18 11:42:27 5: ioUltra: readFn buffer: 05
2022.11.18 11:42:27 5: ioUltra: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2022.11.18 11:42:27 5: ioUltra: readFn did not see a valid RTU frame start yet, wait for more data
2022.11.18 11:42:27 5: ioUltra: readFn buffer: 050304
2022.11.18 11:42:27 5: ioUltra: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2022.11.18 11:42:27 5: ioUltra: readFn did not see a valid RTU frame start yet, wait for more data
2022.11.18 11:42:27 5: ioUltra: readFn buffer: 0503042121
2022.11.18 11:42:27 5: ioUltra: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2022.11.18 11:42:27 4: ioUltra: ParseFrameStart (RTU, master) extracted id 5, fCode 3 and potential data 04
2022.11.18 11:42:27 5: ioUltra: HandleResponse called from ReadFn
2022.11.18 11:42:27 5: ioUltra: ParseResponse called from HandleResponse
2022.11.18 11:42:27 5: ioUltra: ParseResponse got incomplete frame. Got 5 but expecting 9 bytes
2022.11.18 11:42:27 5: ioUltra: readFn buffer: 050304212195714ab1
2022.11.18 11:42:27 5: ioUltra: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2022.11.18 11:42:27 4: ioUltra: ParseFrameStart (RTU, master) extracted id 5, fCode 3 and potential data 0421219571
2022.11.18 11:42:27 5: ioUltra: HandleResponse called from ReadFn
2022.11.18 11:42:27 5: ioUltra: ParseResponse called from HandleResponse
2022.11.18 11:42:27 5: ioUltra: CheckChecksum (called from ParseResponse): 4ab1 is valid
2022.11.18 11:42:27 5: ioUltra: now parsing response data objects, master is TUF2000M5 relay is undefined
2022.11.18 11:42:27 4: ioUltra: HandleResponse done, current frame / read buffer: 050304212195714ab1, id 5, fCode 3,
request: id 5, read fc 3 h1528, len 2, master device TUF2000M5, reading SN1 (getUpdate for combined h1528 len 1 SN1 with h1529 len 1 SN2), queued 1.23 secs ago, sent 0.05 secs ago,
response: id 5, fc 3, h1528, len 2, values 21219571
2022.11.18 11:42:27 5: ioUltra: ResetExpect for HandleResponse from response to idle
2022.11.18 11:42:27 5: ioUltra: DropFrame called from ReadFn - drop 050304212195714ab1


[ch.eick]

Hallo Christian,
Das ist das erste Missverständnis.
Mode "master" bedeutet dass Fhem als Master (= Modbus Client) arbeitet und somit aktiv einen Slave (=Modbus Server abfragen kann). Dein WR ist der Slave.

Punkt 1 in der Liste haben wir damit:
Der Energiemanager liest 20 Register ab Register 154 in einem Request.

Jetzt würde ich mit Punkt 2 weiter machen, Fhem als Master konfigurieren und schauen, wie der WR auf so einen Request antwortet.
Die Register hast Du ja schon definiert. Wenn Du noch Combine auf 20 setzt, dann sollte Deine Master-Definition auch 20 Register auf einmal lesen und dann sehen wir bei verbose 5 wie der WR genau darauf antwortet.

Hallo Stefan,
ich habe empirisch mal eben Schritt 2-4 übersprungen und melde Erfolg

Es war somit sehr wohl möglich, die ModBus Definition aus dem lesenden Device zu übernehmen.

Im verbose 5 Log habe ich noch einige fehlene Register gefunden, die ich mit der Definition aus dem orinal Wechselrichter Device und Wert 0 zusätzlich übernommen habe.
Auch das "attr WR_3 dev-h-combine 20" habe ich eingetragen.

Wie im Anhang zu sehen, wird der Leistungswert aus dem FHEM WR_3 Device nun angezeigt und auch der Status ist nun ein grünes Häckchen.
Wie immer vielen Dank für die unermüdliche unterstützung.

Mit dem Device geht es dann jetzt im Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV) Thread weiter.

VG
    Christian

[ch.eick]

Hallo zusammen,
obwohl in meinem Device verbose 0 gesetzt ist, wird folgende Meldung im log angezeigt.

Code Auswählen Erweitern


2022.11.18 14:56:52.402 5: WR_3_192.168.178.17_57082: ResetExpect for HandleServerConnection from undefined to request
2022.11.18 14:56:52.999 5: WR_3_192.168.178.17_57088: ResetExpect for HandleServerConnection from undefined to request

VG   Christian

[StefanStrobel]

Hallo Christian,

Wenn ein TCP-Server-Device eine Verbindung annimmt, dann wird daraus ein neues Verbindungs-Device.
Leider bedeutet das auch dass Attribute, die Du im WR_3 setzt, nicht automatisch auf WR_3_192.168.178.17_57082 übernommen werden. Dort steht verbose vermutlich immer noch auf 5, bis diese Verbindung geschlossen wurde.
Da ich das auch lästig fand, es aber niemandem aufzwingen wollte, habe ich ein Attribut mit Namen propagateVerbose eingebaut. Dann wird verbose weitergegeben ...

Gruss
   Stefan

[StefanStrobel]

Hallo pejonp,

kannst Du es mit revRegs oder bswapRegs lösen?

Gruss
   Stefan

[pejonp]

Hallo Stefan,

vielen Dank für den Hinweis.
Habe es jetzt so gelöst:

Code Auswählen Erweitern


attr TUF2000M5 obj-h1528-bswapRegs 1
attr TUF2000M5 obj-h1528-len 2
attr TUF2000M5 obj-h1528-reading SN
attr TUF2000M5 obj-h1528-unpack H*


pejonp

[ch.eick]

Wenn ein TCP-Server-Device eine Verbindung annimmt, dann wird daraus ein neues Verbindungs-Device.
Leider bedeutet das auch dass Attribute, die Du im WR_3 setzt, nicht automatisch auf WR_3_192.168.178.17_57082 übernommen werden. Dort steht verbose vermutlich immer noch auf 5, bis diese Verbindung geschlossen wurde.
Da ich das auch lästig fand, es aber niemandem aufzwingen wollte, habe ich ein Attribut mit Namen propagateVerbose eingebaut. Dann wird verbose weitergegeben ...

Moin,
die nachfolgenden Meldungen sind dann jetzt verschwunden.
Vielen Dank
   Christian

Code Auswählen Erweitern


2022.11.18 14:56:52.402 5: WR_3_192.168.178.17_57082: ResetExpect for HandleServerConnection from undefined to request
2022.11.18 14:56:52.999 5: WR_3_192.168.178.17_57088: ResetExpect for HandleServerConnection from undefined to request


[Mariomgn]

Hallo Stefan,

ich habe nun einen Auszug aus dem Log, warum Fhem sich aufhängt.

Code Auswählen Erweitern

2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53888: read from TCP server connection got null -> closing
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53888: _UnDef is closing Data4PLC_192.168.0.250_53888
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53889: read from TCP server connection got null -> closing
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53889: _UnDef is closing Data4PLC_192.168.0.250_53889
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53890: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53890: _UnDef is closing Data4PLC_192.168.0.250_53890
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53892: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53892: _UnDef is closing Data4PLC_192.168.0.250_53892
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53893: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53893: _UnDef is closing Data4PLC_192.168.0.250_53893
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53894: read from TCP server connection got null -> closing
2022.11.21 01:17:48 3: Data4PLC_192.168.0.250_53894: _UnDef is closing Data4PLC_192.168.0.250_53894
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53896: read from TCP server connection got null -> closing
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53896: _UnDef is closing Data4PLC_192.168.0.250_53896
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53898: read from TCP server connection got null -> closing
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53898: _UnDef is closing Data4PLC_192.168.0.250_53898
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53899: read from TCP server connection got null -> closing
2022.11.21 01:19:29 3: Data4PLC_192.168.0.250_53899: _UnDef is closing Data4PLC_192.168.0.250_53899
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:

die Log datei ist 2,1 GB groß

Woran könnte das liegen?

MfG Mario

[ch.eick]

ich habe nun einen Auszug aus dem Log, warum Fhem sich aufhängt.

Code Auswählen Erweitern

2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53888: read from TCP server connection got null -> closing
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53888: _UnDef is closing Data4PLC_192.168.0.250_53888
2022.11.21 01:16:27 3: Data4PLC_192.168.0.250_53889: read from TCP server connection got null -> closing

2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:19:29 1: Accept failed (Data4PLC: Too many open files)
2022.11.21 01:

Woran könnte das liegen?

Hallo Mario,
bei mir kamen diese Meldungen bei einem anderen Gerät auch und es fehlten noch reading definitionen, die dann nicht beantwortet wurden.
Geh mal auf verbose 5 und such nach errors.
Wärend des suchens habe ich das Device dann immer auf inactive gesetzt, damit mir das Log nicht voll lief.
VG
   Christian

[Mariomgn]

Ich habe ein paar Fehler gefunden, kann damit aber nichts anfangen
das Log File hat auch schon wieder 2 GB

Code Auswählen Erweitern

2022.11.21 09:53:41 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 43452 for h 40, len 2, device Data4PLC (TCP), pdu 0304002f0000, V 4.1.5 - 17.9.2019
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: Send a9bc00000007060304002f0000
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: RequestDone request: id 6, fCode 3, tid 43452, type h, adr 40, len 2 for device Data4PLC_192.168.0.250_46123, Current read buffer: a9bc00000006060300280002, Id 6, fCode 3, tid 43452, response: id 6, fCode 3, tid 43452, type h, adr 40, len 2, value 002f0000
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: DropFrame - drop a9bc00000006060300280002
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: read buffer: a9bd00000006060300180002
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: ParseFrameStart (TCP) extracted id 6, fCode 3, tid 43453, dlen 6 and data 00180002
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: HandleRequest called from Read
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: ParseRequest called from HandleRequest
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: HandleRequest request: id 6, fCode 3, tid 43453, type h, adr 24, len 2, Current read buffer: a9bd00000006060300180002, Id 6, fCode 3, tid 43453
2022.11.21 09:53:41 5: Data4PLC: CreateResponse called from HandleRequest
2022.11.21 09:53:41 5: Data4PLC: PackObj called from CreateResponse with h 24 and valuesLen 2
2022.11.21 09:53:41 5: Data4PLC: PackObj ObjInfo for h24: reading=Temperatur_Heizung:DS18B20-2_Temperature, expr=, format=, len=2, map=, unpack=n
2022.11.21 09:53:41 4: Data4PLC: PackObj for h24 is using reading DS18B20-2_Temperature of device Temperatur_Heizung with value 47.4
2022.11.21 09:53:41 5: Data4PLC: PackObj packed 47.4 with pack code n to 002f
2022.11.21 09:53:41 5: Data4PLC: PackObj padded / cut object to 002f0000
2022.11.21 09:53:41 5: Data4PLC: PackObj counter reached 2
2022.11.21 09:53:41 5: Data4PLC: PackObj full data string is 002f0000
2022.11.21 09:53:41 5: Data4PLC: PackObj padded / cut data string to 002f0000
2022.11.21 09:53:41 5: Data4PLC: prepare response pdu
2022.11.21 09:53:41 4: Data4PLC: CreateResponse sends fc 3 to id 6, tid 43453 for h 24, len 2, device Data4PLC (TCP), pdu 0304002f0000, V 4.1.5 - 17.9.2019
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: Send a9bd00000007060304002f0000
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: RequestDone request: id 6, fCode 3, tid 43453, type h, adr 24, len 2 for device Data4PLC_192.168.0.250_46123, Current read buffer: a9bd00000006060300180002, Id 6, fCode 3, tid 43453, response: id 6, fCode 3, tid 43453, type h, adr 24, len 2, value 002f0000
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: DropFrame - drop a9bd00000006060300180002
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: read buffer: a9be000000110610010400050a00000000000000000000
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: ParseFrameStart (TCP) extracted id 6, fCode 16, tid 43454, dlen 17 and data 010400050a00000000000000000000
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: HandleRequest called from Read
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: ParseRequest called from HandleRequest
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: HandleRequest request: id 6, fCode 16, tid 43454, type h, adr 260, len 5, value 00000000000000000000, Current read buffer: a9be000000110610010400050a00000000000000000000, Id 6, fCode 16, tid 43454
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: passing value string of write request to ParseObj to set readings
2022.11.21 09:53:41 5: Data4PLC: ParseObj called with data 00000000000000000000, type h, adr 260, valuesLen 5
2022.11.21 09:53:41 5: Data4PLC: ParseObj ObjInfo for h260: reading=Ventil_Atmos:state, unpack=n, expr=, format=, map=
2022.11.21 09:53:41 5: Data4PLC: ParseObj unpacked 00000000000000000000 with n to 0 hex 30
2022.11.21 09:53:41 4: Data4PLC: ParseObj assigns value 0 to reading state of device Ventil_Atmos
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h261
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h261
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h262
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h262
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h263
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h263
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h264
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h264
2022.11.21 09:53:41 5: Data4PLC: HandleRequest got 1 readings from ParseObj
2022.11.21 09:53:41 5: Data4PLC: CreateResponse called from HandleRequest
2022.11.21 09:53:41 5: Data4PLC: prepare response pdu
2022.11.21 09:53:41 4: Data4PLC: CreateResponse sends fc 144 error code 2 to id 6, tid 43454 for h 260, len 5, device Data4PLC (TCP), pdu 9002, V 4.1.5 - 17.9.2019
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: Send a9be00000003069002
2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: RequestDone request: id 6, fCode 16, tid 43454, type h, adr 260, len 5, value 00000000000000000000 for device Data4PLC_192.168.0.250_46123, Current read buffer: a9be000000110610010400050a00000000000000000000, Id 6, fCode 16, tid 43454, response: id 6, fCode 16, tid 43454, type h, adr 260, len 5
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: DropFrame - drop a9be000000110610010400050a00000000000000000000
2022.11.21 09:55:41 4: Data4PLC: closing connection after inactivity
2022.11.21 09:55:41 5: Data4PLC_192.168.0.250_46123: Close called from ServerTimeout
2022.11.21 09:55:41 4: Data4PLC_192.168.0.250_46123: Close TCP server connection and delete hash
2022.11.21 09:55:41 3: Data4PLC_192.168.0.250_46123: _UnDef is closing Data4PLC_192.168.0.250_46123



In der Config sieht das Ganze so aus :

Code Auswählen Erweitern

define Data4PLC ModbusAttr 6 slave 192.168.0.150:1502 TCP
setuuid Data4PLC 63713fba-f33f-3045-2110-88b318e9d470e9d9
attr Data4PLC userattr obj-h22-len obj-h22-reading obj-h22-unpack obj-h24-len obj-h24-reading obj-h24-unpack obj-h26-len obj-h26-reading obj-h26-unpack obj-h260-allowWrite obj-h260-len obj-h260-reading obj-h260-unpack obj-h28-len obj-h28-reading obj-h28-unpack obj-h30-len obj-h30-reading obj-h30-unpack obj-h32-len obj-h32-reading obj-h32-unpack obj-h34-len obj-h34-reading obj-h34-unpack obj-h36-len obj-h36-reading obj-h36-unpack obj-h38-len obj-h38-reading obj-h38-unpack obj-h40-len obj-h40-reading obj-h40-unpack obj-h60-len obj-h60-reading obj-h60-unpack
attr Data4PLC obj-h22-len 2
attr Data4PLC obj-h22-reading Temperatur_Heizung:DS18B20-7_Temperature
attr Data4PLC obj-h22-unpack n
attr Data4PLC obj-h24-len 2
attr Data4PLC obj-h24-reading Temperatur_Heizung:DS18B20-2_Temperature
attr Data4PLC obj-h24-unpack n
attr Data4PLC obj-h26-len 2
attr Data4PLC obj-h26-reading Temperatur_Heizung:DS18B20-6_Temperature
attr Data4PLC obj-h26-unpack n
attr Data4PLC obj-h260-allowWrite 1
attr Data4PLC obj-h260-len 1
attr Data4PLC obj-h260-reading Ventil_Atmos:state
attr Data4PLC obj-h260-unpack n
attr Data4PLC obj-h28-len 2
attr Data4PLC obj-h28-reading Temperatur_Heizung:DS18B20-3_Temperature
attr Data4PLC obj-h28-unpack n
attr Data4PLC obj-h30-len 2
attr Data4PLC obj-h30-reading Temperatur_Heizung:DS18B20-1_Temperature
attr Data4PLC obj-h30-unpack n
attr Data4PLC obj-h32-len 2
attr Data4PLC obj-h32-reading Temperatur_Heizung_2:DS18B20-1_Temperature
attr Data4PLC obj-h32-unpack n
attr Data4PLC obj-h34-len 2
attr Data4PLC obj-h34-reading Temperatur_Heizung_2:DS18B20-2_Temperature
attr Data4PLC obj-h34-unpack n
attr Data4PLC obj-h36-len 2
attr Data4PLC obj-h36-reading Temperatur_Heizung_2:DS18B20-3_Temperature
attr Data4PLC obj-h36-unpack n
attr Data4PLC obj-h38-len 2
attr Data4PLC obj-h38-reading Temperatur_Heizung:DS18B20-4_Temperature
attr Data4PLC obj-h38-unpack n
attr Data4PLC obj-h40-len 3
attr Data4PLC obj-h40-reading Temperatur_Heizung:DS18B20-5_Temperature
attr Data4PLC obj-h40-unpack n
attr Data4PLC obj-h60-len 2
attr Data4PLC obj-h60-reading WW_Zirkulation:cmd
attr Data4PLC obj-h60-unpack n
attr Data4PLC room Modbus
attr Data4PLC verbose 5

Habe ich etwas vergessen?

MfG Mario

[ch.eick]

Ich habe ein paar Fehler gefunden, kann damit aber nichts anfangen

Code Auswählen Erweitern


2022.11.21 09:53:41 4: Data4PLC_192.168.0.250_46123: HandleRequest request: id 6, fCode 16, tid 43454, type h, adr 260, len 5, value 00000000000000000000, Current read buffer: a9be000000110610010400050a00000000000000000000, Id 6, fCode 16, tid 43454
2022.11.21 09:53:41 5: Data4PLC_192.168.0.250_46123: passing value string of write request to ParseObj to set readings
2022.11.21 09:53:41 5: Data4PLC: ParseObj called with data 00000000000000000000, type h, adr 260, valuesLen 5
2022.11.21 09:53:41 5: Data4PLC: ParseObj ObjInfo for h260: reading=Ventil_Atmos:state, unpack=n, expr=, format=, map=
2022.11.21 09:53:41 5: Data4PLC: ParseObj unpacked 00000000000000000000 with n to 0 hex 30
2022.11.21 09:53:41 4: Data4PLC: ParseObj assigns value 0 to reading state of device Ventil_Atmos


Du hast z.B. für h260 eine Len von 1 angegeben. Im Log steht aber len 5 .

Auch werden h261 - h264 angeboten, sind aber bei Dir nicht definiert.

Code Auswählen Erweitern


2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h261
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h261
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h262
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h262
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h263
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h263
2022.11.21 09:53:41 5: Data4PLC: ParseObj moves to next object, skip 1 to h264
2022.11.21 09:53:41 5: Data4PLC: ParseObj has no information about parsing h264


[StefanStrobel]

Hallo Mario,

das sieht so aus als ob die TCP-Verbindungen nicht richtig geschlossen werden.
Ich versuche das mal bei mir nachzustellen.
In der Zwischenzeit könntest Du mal versuchen den Servertimeout so hoch zu stellen, dass Fhem die Verbindung nicht schließt (höher als das Abfrageintervall das Masters)

Gruss
   Stefan