Neue Versionen und Support zum Modbus-Modul

[StefanStrobel]

Hallo Cybers,

da habe ich mich wohl nicht klar ausgedrückt. Wenn Du im Device-Info hash ein "s" hinzufügst, hat das erst mal gar keine Auswirkungen. Gültige Objekt-Typen sind nur h für holding register, i für input register, c für coil und d für digital inputs. Andere Werte sind im Basis-Modul nicht vorgesehen und werden hoffentlich immer ignoriert.
Im Device-Info-Hash stehen meist nur die Defaults. Für jedes einzelne Objekt kann man das im Objekt überschreiben. Statt defUnpack im Device-Info-Hash einfach unpack im jeweiligen Objekt benutzen. Die Namen entsprechen übrigens den Attributen von ModbusAttr. In dessen Doku findest Du hoffentlich alle Details. Zum Testen kannst Du auch die Werte jederzeit mit den Attributen von ModbusAttr überschreiben. Du kannst ModbusSDM72DM als vorkonfigurierte Variante von ModbusAttr betrachten. Bitte schau Dir die Doku dazu mal an.
Wenn es dann immer noch nicht klappt, hilft es das verbose-Attribut für Dein Device und sein IO-Device auf 5 zu setzen. Dann steht sehr viel im Log und wenn man das Zeile für Zeile liest, kann man sehen, was intern passiert. Wenn Du den Auszug aus dem Log postest, kann ich auch drauf schauen.

Gruss
   Stefan

[StefanStrobel]

Hallo Anton,

die Doku von Waveshare ist gruselig. Vermutlich hat da jemand die Modbus-Specs schlecht auf chinesisch übersetzt, dann was kreatives programmiert und am Schluss die chinesische Doku wieder schlecht auf englisch übersetzt...
Aber ganz so schlimm ist es vermutlich doch nicht. Wenn man die echte Spezifikation daneben legt, gibt es durchaus Parallelitäten ;-)
(siehe https://modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf)

Wenn Du die Relais schon mal einzeln schalten kannst und nur  dev-c-brokenFC5 65535 dafür nötig ist, dann fehlt ja nur die Sonderfunktion zum Toggeln. Das könntest Du drum herum bauen (abhängig vom bisherigen Status schließen oder öffnen) oder ich müsste es im Basismodul als Sonderfall ergänzen.

Dann fehlt noch das Lesen aller Coils gleichzeitig.
Mit korrektem Modbus-Befehl kann man bei fc1 die Länge angeben. Das Modbus-Modul macht das implizit über die Kombination von Lesebefehlen in einem Update-Zyklus. Explizit per get mehrere Objekte gleichzeitig zu lesen ist so im Modul nicht vorgesehen, aber wenn Das Gerät eh nur 8 Relais hat, könnte man mit set reread auch alle Objekte auf einmal lesen lassen und per combine sollte daraus ein einziger Lese-Befehl mit Länge 8 werden.

Das Schreiben von 8 Coils auf einmal ist ein anderes Thema. Function code 15 (0f) ist dafür vorgesehen, aber bisher hat das noch niemand benötigt. Im Modul ist der Befehl bisher nicht implementiert. Das kann man auch nicht mit holding-Registern hinbiegen. Jeder function code hat ja seine eigene Definition.
Ich müsste auch erst mal überlegen, wie man das sinnvoll abbilden kann. Das Modbus-Modul sieht ja bisher eine einzelne Definition je Objekt vor. In diesem Fall müste man z.B. beim Set mehrere Werte übergeben, die dann auf aufeinander folgende Objekte geschrieben werden...
Ich werde mal drüber nachdenken.

Gruss
   Stefan

[Cybers]

Hallo Cybers,

da habe ich mich wohl nicht klar ausgedrückt. Wenn Du im Device-Info hash ein "s" hinzufügst, hat das erst mal gar keine Auswirkungen. Gültige Objekt-Typen sind nur h für holding register, i für input register, c für coil und d für digital inputs. Andere Werte sind im Basis-Modul nicht vorgesehen und werden hoffentlich immer ignoriert.
Im Device-Info-Hash stehen meist nur die Defaults. Für jedes einzelne Objekt kann man das im Objekt überschreiben. Statt defUnpack im Device-Info-Hash einfach unpack im jeweiligen Objekt benutzen. Die Namen entsprechen übrigens den Attributen von ModbusAttr. In dessen Doku findest Du hoffentlich alle Details. Zum Testen kannst Du auch die Werte jederzeit mit den Attributen von ModbusAttr überschreiben. Du kannst ModbusSDM72DM als vorkonfigurierte Variante von ModbusAttr betrachten. Bitte schau Dir die Doku dazu mal an.
Wenn es dann immer noch nicht klappt, hilft es das verbose-Attribut für Dein Device und sein IO-Device auf 5 zu setzen. Dann steht sehr viel im Log und wenn man das Zeile für Zeile liest, kann man sehen, was intern passiert. Wenn Du den Auszug aus dem Log postest, kann ich auch drauf schauen.

Gruss
   Stefan

Ich habe es mal wir folgt angelegt:

Code: [Auswählen]

defmod Testzaehler ModbusAttr 1 10
attr Testzaehler dev-h-combine 10
attr Testzaehler dev-h-defLen 2
attr Testzaehler dev-h-defUnpack n
attr Testzaehler dev-h-read 3
attr Testzaehler dev-h-write 16
attr Testzaehler obj-h61456-max 3
attr Testzaehler obj-h61456-min 3
attr Testzaehler obj-h61456-name Reset
attr Testzaehler obj-h61456-reading Reset
attr Testzaehler obj-h61456-set 1
attr Testzaehler obj-h61456-showGet 1
attr Testzaehler room Photovoltaik

setstate Testzaehler opened
setstate Testzaehler 2022-01-25 10:23:38 Reset 4096
setstate Testzaehler 2022-01-25 10:36:12 state opened
Log:

Code: [Auswählen]

request: id 1, write fc 16 h61456, len 2, value 0003, master device Testzaehler, reading Reset (set Reset)
2022.01.25 19:27:32 4: Testzaehler: DoRequest called from SetLDFn created new request, read buffer empty,
2022.01.25 19:27:32 5: Testzaehler: set packed hex 33 with n to hex 0003
2022.01.25 19:27:32 5: Testzaehler: checkRange for FormatSetVal checks 3 against max 3
2022.01.25 19:27:32 5: Testzaehler: checkRange for FormatSetVal checks 3 against min 3
2022.01.25 19:27:32 5: Testzaehler: GetSetChecks returns success
2022.01.25 19:27:32 5: Testzaehler: GetSetChecks with force
2022.01.25 19:27:32 4: Testzaehler: set called with Reset (h61456) setVal = 3
2022.01.25 19:27:29 4: Testzaehler: GetUpdate will now create requests for
2022.01.25 19:27:29 5: Testzaehler: CombineUpdateHash keys are now
2022.01.25 19:27:29 5: Testzaehler: CombineUpdateHash tries to combine read commands
2022.01.25 19:27:29 4: Testzaehler: CombineUpdateHash objHash keys before combine:
2022.01.25 19:27:29 5: Testzaehler: CreateUpdateList full object list: h61456
2022.01.25 19:27:29 4: Testzaehler: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 19:27:39.873, interval 10
2022.01.25 19:27:29 4: Testzaehler: GetUpdate (V4.4.02 - 31.3.2021) called from Fhem internal timer
2022.01.25 19:27:21 5: Testzaehler: UpdateSetList: getList=Reset:noArg
2022.01.25 19:27:21 5: Testzaehler: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects scanModbusId inactive active Reset
2022.01.25 19:27:19 4: Testzaehler: GetUpdate will now create requests for
2022.01.25 19:27:19 5: Testzaehler: CombineUpdateHash keys are now
2022.01.25 19:27:19 5: Testzaehler: CombineUpdateHash tries to combine read commands
2022.01.25 19:27:19 4: Testzaehler: CombineUpdateHash objHash keys before combine:
2022.01.25 19:27:19 5: Testzaehler: CreateUpdateList full object list: h61456
2022.01.25 19:27:19 4: Testzaehler: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 10.0 sec at 19:27:29.872, interval 10
2022.01.25 19:27:19 4: Testzaehler: GetUpdate (V4.4.02 - 31.3.2021) called from Fhem internal timer
Fehler: Timeout in Readanswer

[StefanStrobel]

Hallo Cybers,

ohne verbose 5 auch auf dem IO-Device fehlen leider die entscheidenden Details im Log :-)

Gruß
    Stefan

[Cybers]

Code: [Auswählen]

2022.01.25 22:31:54 3: Modbus: Timeout in Readanswer, read buffer empty,
2022.01.25 22:31:52 5: Modbus: ReadAnswer remaining timeout is 1.99214100837708
2022.01.25 22:31:52 5: Modbus: ReadAnswer called from SetLDFn
2022.01.25 22:31:52 5: Modbus: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.01.25 22:31:52 5: DevIo_SimpleWrite Modbus: 0110f0100002040003f48b
2022.01.25 22:31:52 5: Modbus: Send called from ProcessRequestQueue
request: id 1, write fc 16 h61456, len 2, value 0003, master device Testzaehler, reading Reset (set Reset), queued 0.00 secs ago
2022.01.25 22:31:52 4: Modbus: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 2, sending 0110f0100002040003f48b via /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@9600, read buffer empty,
2022.01.25 22:31:52 5: Modbus: checkDelays sendDelay, last send to same device was 10662.815 secs ago, required delay is 0.1
2022.01.25 22:31:52 5: Modbus: checkDelays clientSwitchDelay is not relevant
2022.01.25 22:31:52 5: Modbus: checkDelays commDelay, last communication with same device was never, required delay is 0.1
2022.01.25 22:31:52 5: Modbus: checkDelays busDelayRead, last activity on bus was 0.117 secs ago, required delay is 0
2022.01.25 22:31:52 5: Modbus: ProcessRequestQueue called from QueueRequest as direct:Modbus, qlen 2, force, request: request: id 1, write fc 16 h61456, len 2, value 0003, master device Testzaehler, reading Reset (set Reset), queued 0.00 secs ago
2022.01.25 22:31:52 5: Modbus: QueueRequest called from DoRequest with h61456, qlen 1 from master Testzaehler through io device Modbus
request: id 1, write fc 16 h61456, len 2, value 0003, master device Testzaehler, reading Reset (set Reset)
2022.01.25 22:31:52 4: Testzaehler: DoRequest called from SetLDFn created new request, read buffer empty,
2022.01.25 22:31:52 5: Testzaehler: set packed hex 33 with n to hex 0003
2022.01.25 22:31:52 5: Testzaehler: checkRange for FormatSetVal checks 3 against max 3
2022.01.25 22:31:52 5: Testzaehler: checkRange for FormatSetVal checks 3 against min 3
2022.01.25 22:31:52 5: Testzaehler: GetSetChecks returns success
2022.01.25 22:31:52 5: Testzaehler: GetSetChecks with force
2022.01.25 22:31:52 4: Testzaehler: set called with Reset (h61456) setVal = 3

[StefanStrobel]

Hallo Cybers,

Du versuchst gleich zwei Register auf einmal zu schreiben.
Laut der Anleitung Deines Geräts möchte das aber nur ein Objekt gleichzeitig.
Setz doch mal die Länge auf 1 statt auf 2.

Gruss
   Stefan

[Cybers]

Hallo Stefan,

das war es. Jetzt läuft es. Vielen Dank für deine Hilfe.

Gruß, Sascha

[ansgru]

Hallo Stefan,

besten Dank für deine Antwort!

die Doku von Waveshare ist gruselig. Vermutlich hat da jemand die Modbus-Specs schlecht auf chinesisch übersetzt, dann was kreatives programmiert und am Schluss die chinesische Doku wieder schlecht auf englisch übersetzt...

100% einverstanden :-)

Wenn Du die Relais schon mal einzeln schalten kannst und nur  dev-c-brokenFC5 65535 dafür nötig ist, dann fehlt ja nur die Sonderfunktion zum Toggeln. Das könntest Du drum herum bauen (abhängig vom bisherigen Status schließen oder öffnen) oder ich müsste es im Basismodul als Sonderfall ergänzen.

Das geht leider nicht weil einzelne Relais ein FF 00 erwarten als Befehl zum einschalten (resp. 55 00 für ein Toggle), das Schalten aller Relais aber ein FF FF. Mit dev-c-brokenFC5 kann ich ja nur global den zu senden Wert zum Aktivieren eines Coils festlegen wenn ich das richtig verstanden habe?

Dann fehlt noch das Lesen aller Coils gleichzeitig.
Mit korrektem Modbus-Befehl kann man bei fc1 die Länge angeben. Das Modbus-Modul macht das implizit über die Kombination von Lesebefehlen in einem Update-Zyklus. Explizit per get mehrere Objekte gleichzeitig zu lesen ist so im Modul nicht vorgesehen, aber wenn Das Gerät eh nur 8 Relais hat, könnte man mit set reread auch alle Objekte auf einmal lesen lassen und per combine sollte daraus ein einziger Lese-Befehl mit Länge 8 werden.

Das Schreiben von 8 Coils auf einmal ist ein anderes Thema. Function code 15 (0f) ist dafür vorgesehen, aber bisher hat das noch niemand benötigt. Im Modul ist der Befehl bisher nicht implementiert. Das kann man auch nicht mit holding-Registern hinbiegen. Jeder function code hat ja seine eigene Definition.
Ich müsste auch erst mal überlegen, wie man das sinnvoll abbilden kann. Das Modbus-Modul sieht ja bisher eine einzelne Definition je Objekt vor. In diesem Fall müste man z.B. beim Set mehrere Werte übergeben, die dann auf aufeinander folgende Objekte geschrieben werden...
Ich werde mal drüber nachdenken.

Hmmm, ich habe noch einen völlig anderen Ansatz: wie wäre es, wenn ich pro Register mit einem zusätzlichen Flag angeben kann, welcher Function Code verwendet werden soll? Also ein obj-[ih][1-9][0-9]*-overrideFC? Die Funktionsweise wäre dann wie folgt: ich würde für das Schalten der Relais "Holding Register Objekte" definieren (also obj-h255-reading statt obj-c255-reading) und zusätzlich ein obj-h255-overrideFC 5. Also ähnlich wie dev-([cdih]-)*write|read ABER pro Register UND intern würde Modbus.pm in diesem Beispiel h255 intern als Holding Register behandeln und nur in der Kommunikation den gewählten FC verwenden. Bei dev*write|read ist es ja so, dass - wenn ich z.B. dev-h-write 5 definiere - alle Holding Registers fortan als Coils betrachtet werden und ich damit wieder keine individuellen Werte wie FF FF, FF 00 individuell pro Register definieren kann.

Der Pseudocode für das Erstellen der Pakete könnte dann wie folgt aussehen:

Code: [Auswählen]

if ($fCode == 6) { // $fCode ist der Modbus.pm interne Function Code, hier also ein Holding Register
my $actualFC = $fCode;
if ($overrideFC) $actualFC = $overrideFC;
// Dann wird das Paket versandt mit $actualFC -> in unserem Beispiel also mit 05 statt 06
}

Der empfangende Code wüsste dann anhand der Registeradresse analog dazu, ob z.B. ein obj-h255-overrideFC 5 definiert ist und welcher FC entsprechend erwartet wird. Würde das so Sinn machen? Ich habe das Gefühl, das würde einige Flexibilität bieten für nicht normgerechte Implementationen?

Beste Grüsse, Anton

[Cybers]

Hallo Stefan,
ich habe doch noch ein kleines Problem. Ich habe die Werte aus dem Testdevice mit denen es dann lief in meine 98_ModbusSDM72DM.pm übernommen. Damit geht es dann nicht mehr. Irgendetwas habe ich noch falsch übertragen.
Hier mein funktionierender Testdevice:

Code: [Auswählen]

defmod Testzaehler ModbusAttr 1 10
attr Testzaehler dev-h-combine 10
attr Testzaehler dev-h-defLen 1
attr Testzaehler dev-h-defUnpack n
attr Testzaehler dev-h-read 3
attr Testzaehler dev-h-write 16
attr Testzaehler obj-h61456-max 3
attr Testzaehler obj-h61456-min 3
attr Testzaehler obj-h61456-name Reset
attr Testzaehler obj-h61456-reading Reset
attr Testzaehler obj-h61456-set 1
attr Testzaehler obj-h61456-showGet 1
attr Testzaehler room Photovoltaik
Hier die Zeilen in meiner 98_ModbusSDM72DM.pm:

Code: [Auswählen]

"h61456" => { # holding register 0x0014
# Write the network port node address: 1 to 247 for MODBUS Protocol, default 1.
# Requires a restart to become effective.
# https://data.stromzähler.eu/eastron/SDM72DM-manual.pdf
name => "Reset", # internal name of this register in the hardware doc
reading => "Reset", # name of the reading for this value
min => 3, # input validation for set: min value
max => 3, # input validation for set: max value
# format => '%u', # format string for sprintf
# poll => "once", # only poll once after define (or after a set)
defLen => 1, # default length (number of registers) per value (e.g. 2 for a float of 4 bytes that spans 2 registers)
set => 1, # this value can be set
# map => "3:Reset",
defUnpack => "n",
},
Im Anhang noch meine komplette 98_ModbusSDM72DM.pm

Edit: Fehler gefunden und Problem gelöst. Aus "defLen" und "defUnpack" muss "len" und "unpack" werden.

[abc2006]

Moin Stefan,
ich muss mich auch mal wieder mit einer Frage anschließen:

Kannst du mir helfen, diese Logmeldungen zu deuten und einen Fehler zu finden?
Ich bin der Meinung, dass es anfangs einwandfrei lief - jetzt hab ich immer größere Aussetzer in Fhem - und habe die Updaterate schon verringert...

Grüße,
Stephan

Code: [Auswählen]

2022.01.28 12:46:19.486 5: alfen_Socket_aussen: ProcessRequestQueue called from Fhem internal timer as queue:alfen_Socket_aussen, qlen 2, request: request: id
1, read fc 3 h1208, len 2, tid 87, master device alfen_Socket_aussen, reading MaxCurrentValidTimeRemaining (getUpdate for MaxCurrentValidTimeRemaining len 2),
queued 6.17 secs ago
2022.01.28 12:46:19.486 5: alfen_Socket_aussen: checkDelays sendDelay, last send to same device was 0.265 secs ago, required delay is 0.1
2022.01.28 12:46:19.486 5: alfen_Socket_aussen: checkDelays commDelay, last communication with same device was 0.115 secs ago, required delay is 0.1
2022.01.28 12:46:19.486 5: alfen_Socket_aussen: checkDelays clientSwitchDelay is not relevant
2022.01.28 12:46:19.486 5: alfen_Socket_aussen: checkDelays busDelayRead, last activity on bus was 0.115 secs ago, required delay is 0
2022.01.28 12:46:19.486 4: alfen_Socket_aussen: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 2, sending 005700000006010304b80002 via 192.168.0.49:502, read b
uffer empty,
request: id 1, read fc 3 h1208, len 2, tid 87, master device alfen_Socket_aussen, reading MaxCurrentValidTimeRemaining (getUpdate for MaxCurrentValidTimeRemain
ing len 2), queued 6.17 secs ago
2022.01.28 12:46:19.486 5: alfen_Socket_aussen: Send called from ProcessRequestQueue
2022.01.28 12:46:19.486 5: DevIo_SimpleWrite alfen_Socket_aussen: 005700000006010304b80002
2022.01.28 12:46:19.488 5: alfen_Socket_aussen: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.01.28 12:46:19.618 5: alfen_Socket_aussen: readFn buffer: 0057000000070103040000012b
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: ParseFrameStart called from ReadFn protocol TCP expecting id 1
2022.01.28 12:46:19.619 4: alfen_Socket_aussen: ParseFrameStart (TCP, master) extracted id 1, fCode 3, tid 87, dlen 7 and potential data 040000012b
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: HandleResponse called from ReadFn
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: ParseResponse called from HandleResponse
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: now parsing response data objects, master is alfen_Socket_aussen relay is undefined
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: ParseDataString called from HandleResponse with data hex 0000012b, type h, adr 1208, op read
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: SplitDataString called from ParseDataString with data hex 0000012b, type h, adr 1208, valuesLen 2, op read
2022.01.28 12:46:19.619 5: alfen_Socket_aussen: CreateDataObjects called from ParseDataString with objList h1208
2022.01.28 12:46:19.620 5: alfen_Socket_aussen: CreateDataObjects sortedList h1208
2022.01.28 12:46:19.620 5: alfen_Socket_aussen: CreateDataObjects unpacked 0000012b with L> to 299
2022.01.28 12:46:19.620 4: alfen_Socket_aussen: CreateDataObjects assigns value 299 to MaxCurrentValidTimeRemaining
2022.01.28 12:46:19.636 4: alfen_Socket_aussen: set called with Charge_Current (h1210) setVal = 0
2022.01.28 12:46:19.636 5: alfen_Socket_aussen: GetSetChecks with force
2022.01.28 12:46:19.636 4: alfen_Socket_aussen: GetSetChecks calls ReadAnswer to take over async read, still waiting for response, current frame / read buffer:
 0057000000070103040000012b, id 1, fCode 3, tid 87,
request: id 1, read fc 3 h1208, len 2, tid 87, master device alfen_Socket_aussen, reading MaxCurrentValidTimeRemaining (getUpdate for MaxCurrentValidTimeRemain
ing len 2), queued 6.32 secs ago, sent 0.15 secs ago,
response: id 1, fc 3, h1208, len 2, values 0000012b
2022.01.28 12:46:19.636 5: alfen_Socket_aussen: ReadAnswer called from GetSetChecks
2022.01.28 12:46:19.636 5: alfen_Socket_aussen: ReadAnswer remaining timeout is 1.84963798522949
2022.01.28 12:46:21.488 3: alfen_Socket_aussen: Timeout in Readanswer, current frame / read buffer: 0057000000070103040000012b, id 1, fCode 3, tid 87,
request: id 1, read fc 3 h1208, len 2, tid 87, master device alfen_Socket_aussen, reading MaxCurrentValidTimeRemaining (getUpdate for MaxCurrentValidTimeRemain
ing len 2), queued 8.17 secs ago, sent 2.00 secs ago,
response: id 1, fc 3, h1208, len 2, values 0000012b
2022.01.28 12:46:21.488 5: alfen_Socket_aussen: DropFrame called from ReadAnswer - drop 0057000000070103040000012b
2022.01.28 12:46:21.489 5: alfen_Socket_aussen: GetSetChecks returns success
2022.01.28 12:46:21.489 5: alfen_Socket_aussen: set packed hex 30 with f> to hex 00000000
2022.01.28 12:46:21.490 4: alfen_Socket_aussen: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, write fc 16 h1210, len 2, value 00000000, tid 98, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current),
response: id 1, fc 3, h1208, len 2, values 0000012b
2022.01.28 12:46:21.490 5: alfen_Socket_aussen: QueueRequest called from DoRequest with h1210, qlen 1 from master alfen_Socket_aussen through io device alfen_Socket_aussen
2022.01.28 12:46:21.490 5: alfen_Socket_aussen: ProcessRequestQueue called from QueueRequest as direct:alfen_Socket_aussen, qlen 2, force, request: request: id 1, write fc 16 h1210, len 2, value 00000000, tid 98, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current), queued 0.00 secs ago
2022.01.28 12:46:21.490 5: alfen_Socket_aussen: checkDelays clientSwitchDelay is not relevant
2022.01.28 12:46:21.490 5: alfen_Socket_aussen: checkDelays busDelayRead, last activity on bus was 1.871 secs ago, required delay is 0
2022.01.28 12:46:21.490 5: alfen_Socket_aussen: checkDelays commDelay, last communication with same device was 1.871 secs ago, required delay is 0.1
2022.01.28 12:46:21.491 5: alfen_Socket_aussen: checkDelays sendDelay, last send to same device was 2.003 secs ago, required delay is 0.1
2022.01.28 12:46:21.491 4: alfen_Socket_aussen: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 2, sending 00620000000b011004ba00020400000000 via 192.168.0.49:502, read buffer empty,
request: id 1, write fc 16 h1210, len 2, value 00000000, tid 98, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current), queued 0.00 secs ago,
response: id 1, fc 3, h1208, len 2, values 0000012b
2022.01.28 12:46:21.491 5: alfen_Socket_aussen: Send called from ProcessRequestQueue
2022.01.28 12:46:21.491 5: DevIo_SimpleWrite alfen_Socket_aussen: 00620000000b011004ba00020400000000
2022.01.28 12:46:21.493 5: alfen_Socket_aussen: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.01.28 12:46:21.493 5: alfen_Socket_aussen: StartQueueTimer called from SetLDFn sets internal timer to process queue in 0.000 seconds
2022.01.28 12:46:21.493 5: alfen_Socket_aussen: ReadAnswer called from SetLDFn
2022.01.28 12:46:21.494 5: alfen_Socket_aussen: ReadAnswer remaining timeout is 1.99603891372681
2022.01.28 12:46:21.593 5: alfen_Socket_aussen: ReadAnswer got: 006200000006011004ba0002
2022.01.28 12:46:21.593 5: alfen_Socket_aussen: ParseFrameStart called from ReadAnswer protocol TCP expecting id 1
2022.01.28 12:46:21.593 4: alfen_Socket_aussen: ParseFrameStart (TCP, master) extracted id 1, fCode 16, tid 98, dlen 6 and potential data 04ba0002
2022.01.28 12:46:21.593 5: alfen_Socket_aussen: HandleResponse called from ReadAnswer
2022.01.28 12:46:21.594 5: alfen_Socket_aussen: ParseResponse called from HandleResponse
2022.01.28 12:46:21.594 4: alfen_Socket_aussen: HandleResponse done, current frame / read buffer: 006200000006011004ba0002, id 1, fCode 16, tid 98,
request: id 1, write fc 16 h1210, len 2, value 00000000, tid 98, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current), queued 0.10 secs ago, sent 0.10 secs ago,
response: id 1, fc 16, c1210, len 2
2022.01.28 12:46:21.594 5: alfen_Socket_aussen: ResetExpect for HandleResponse from response to idle
2022.01.28 12:46:21.594 5: alfen_Socket_aussen: DropFrame called from ReadAnswer - drop 006200000006011004ba0002
2022.01.28 12:46:21.594 5: alfen_Socket_aussen: set is sending read after write
2022.01.28 12:46:21.595 4: alfen_Socket_aussen: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, read fc 3 h1210, len 2, tid 199, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current Rd),
response: no id, no fcode
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: QueueRequest called from DoRequest with h1210, qlen 1 from master alfen_Socket_aussen through io device alfen_Socket_aussen
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: ProcessRequestQueue called from QueueRequest as direct:alfen_Socket_aussen, qlen 2, force, request: request: id 1, read fc 3 h1210, len 2, tid 199, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current Rd), queued 0.00 secs ago
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: checkDelays sendDelay, last send to same device was 0.103 secs ago, required delay is 0.1
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: checkDelays clientSwitchDelay is not relevant
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: checkDelays busDelayRead, last activity on bus was 0.002 secs ago, required delay is 0
2022.01.28 12:46:21.595 5: alfen_Socket_aussen: checkDelays commDelay, last communication with same device was 0.002 secs ago, required delay is 0.1
2022.01.28 12:46:21.596 4: alfen_Socket_aussen: checkDelays found commDelay not over, sleep for 0.098 forced
2022.01.28 12:46:21.694 4: alfen_Socket_aussen: checkDelays sleep done, go on with sending
2022.01.28 12:46:21.694 4: alfen_Socket_aussen: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 2, sending 00c700000006010304ba0002 via 192.168.0.49:502, read buffer empty,
request: id 1, read fc 3 h1210, len 2, tid 199, master device alfen_Socket_aussen, reading Charge_Current (set Charge_Current Rd), queued 0.10 secs ago,
response: no id, no fcode
2022.01.28 12:46:21.694 5: alfen_Socket_aussen: Send called from ProcessRequestQueue
2022.01.28 12:46:21.694 5: DevIo_SimpleWrite alfen_Socket_aussen: 00c700000006010304ba0002
2022.01.28 12:46:21.696 5: alfen_Socket_aussen: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2022.01.28 12:46:21.697 5: alfen_Socket_aussen: ReadAnswer called from SetLDFn
2022.01.28 12:46:21.697 5: alfen_Socket_aussen: ReadAnswer remaining timeout is 1.89792394638062
2022.01.28 12:46:21.818 5: alfen_Socket_aussen: ReadAnswer got: 00c70000000701030400000000
2022.01.28 12:46:21.818 5: alfen_Socket_aussen: ParseFrameStart called from ReadAnswer protocol TCP expecting id 1
2022.01.28 12:46:21.818 4: alfen_Socket_aussen: ParseFrameStart (TCP, master) extracted id 1, fCode 3, tid 199, dlen 7 and potential data 0400000000
2022.01.28 12:46:21.818 5: alfen_Socket_aussen: HandleResponse called from ReadAnswer
2022.01.28 12:46:21.818 5: alfen_Socket_aussen: ParseResponse called from HandleResponse
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: now parsing response data objects, master is alfen_Socket_aussen relay is undefined
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: ParseDataString called from HandleResponse with data hex 00000000, type h, adr 1210, op read
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: SplitDataString called from ParseDataString with data hex 00000000, type h, adr 1210, valuesLen 2, op read
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: CreateDataObjects called from ParseDataString with objList h1210
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: CreateDataObjects sortedList h1210
2022.01.28 12:46:21.819 5: alfen_Socket_aussen: CreateDataObjects unpacked 00000000 with f> to 0
2022.01.28 12:46:21.820 4: alfen_Socket_aussen: CreateDataObjects assigns value 0 to Charge_Current
2022.01.28 12:46:21.822 5: alfen_Socket_aussen: ParseDataString created 1 readings





edit: Verbose level set to 5

[tomix]

Keine Ahnung ob hier am richtigen Ort.

Ich habe einen DS3484, siehe auch:
https://forum.fhem.de/index.php?topic=109904.0

Aktuell nutze ich nur die 4 fest verbauten Relais, welche via FHEM geschaltet werden.
Funktioniert aber das Ding müllt mir das Logfile.voll, da die Vertbindung immer wieder umterbrochem wird (in der Praxis bemerke ich nichts davon):

Code: [Auswählen]

2022.01.28 22:43:00 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:43:00 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 22:46:16 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:46:16 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 22:49:32 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:49:32 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 22:52:48 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:52:48 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 22:56:05 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:56:05 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 22:59:21 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 22:59:21 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 23:02:37 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 23:02:37 3: 192.168.178.15:502 reappeared (ds3484)
2022.01.28 23:05:53 3: 192.168.178.15:502 disconnected, waiting to reappear (ds3484)
2022.01.28 23:05:53 3: 192.168.178.15:502 reappeared (ds3484)

RAW-Listing

Code: [Auswählen]

defmod ds3484 ModbusAttr 1 60 192.168.178.15:502 TCP
attr ds3484 icon lan_rs485
attr ds3484 obj-c0-hint 0,1
attr ds3484 obj-c0-reading LichtTreppe
attr ds3484 obj-c0-set 1
attr ds3484 obj-c1-hint 0,1
attr ds3484 obj-c1-reading LichtGarten
attr ds3484 obj-c1-set 1
attr ds3484 obj-c10-hint 0,1
attr ds3484 obj-c10-reading Relais11
attr ds3484 obj-c10-set 1
attr ds3484 obj-c11-hint 0,1
attr ds3484 obj-c11-reading Relais12
attr ds3484 obj-c11-set 1
attr ds3484 obj-c12-hint 0,1
attr ds3484 obj-c12-reading Relais13
attr ds3484 obj-c12-set 1
attr ds3484 obj-c13-hint 0,1
attr ds3484 obj-c13-reading Relais14
attr ds3484 obj-c13-set 1
attr ds3484 obj-c14-hint 0,1
attr ds3484 obj-c14-reading Relais15
attr ds3484 obj-c14-set 1
attr ds3484 obj-c15-hint 0,1
attr ds3484 obj-c15-reading Relais16
attr ds3484 obj-c15-set 1
attr ds3484 obj-c16-hint 0,1
attr ds3484 obj-c16-reading Relais17
attr ds3484 obj-c16-set 1
attr ds3484 obj-c17-hint 0,1
attr ds3484 obj-c17-reading Relais18
attr ds3484 obj-c17-set 1
attr ds3484 obj-c18-hint 0,1
attr ds3484 obj-c18-reading Relais19
attr ds3484 obj-c18-set 1
attr ds3484 obj-c19-hint 0,1
attr ds3484 obj-c19-reading Relais20
attr ds3484 obj-c19-set 1
attr ds3484 obj-c2-hint 0,1
attr ds3484 obj-c2-reading InvDoseEingang
attr ds3484 obj-c2-set 1
attr ds3484 obj-c20-hint 0,1
attr ds3484 obj-c20-reading Relais21
attr ds3484 obj-c20-set 1
attr ds3484 obj-c21-hint 0,1
attr ds3484 obj-c21-reading Relais22
attr ds3484 obj-c21-set 1
attr ds3484 obj-c22-hint 0,1
attr ds3484 obj-c22-reading Relais23
attr ds3484 obj-c22-set 1
attr ds3484 obj-c23-hint 0,1
attr ds3484 obj-c23-reading Relais24
attr ds3484 obj-c23-set 1
attr ds3484 obj-c24-hint 0,1
attr ds3484 obj-c24-reading Relais25
attr ds3484 obj-c24-set 1
attr ds3484 obj-c25-hint 0,1
attr ds3484 obj-c25-reading Relais26
attr ds3484 obj-c25-set 1
attr ds3484 obj-c26-hint 0,1
attr ds3484 obj-c26-reading Relais27
attr ds3484 obj-c26-set 1
attr ds3484 obj-c27-hint 0,1
attr ds3484 obj-c27-reading Relais28
attr ds3484 obj-c27-set 1
attr ds3484 obj-c28-hint 0,1
attr ds3484 obj-c28-reading Relais29
attr ds3484 obj-c28-set 1
attr ds3484 obj-c29-hint 0,1
attr ds3484 obj-c29-reading Relais30
attr ds3484 obj-c29-set 1
attr ds3484 obj-c3-hint 0,1
attr ds3484 obj-c3-reading InvSitzplatz
attr ds3484 obj-c3-set 1
attr ds3484 obj-c30-hint 0,1
attr ds3484 obj-c30-reading Relais31
attr ds3484 obj-c30-set 1
attr ds3484 obj-c31-hint 0,1
attr ds3484 obj-c31-reading Relais32
attr ds3484 obj-c31-set 1
attr ds3484 obj-c4-hint 0,1
attr ds3484 obj-c4-reading Relais5
attr ds3484 obj-c4-set 1
attr ds3484 obj-c5-hint 0,1
attr ds3484 obj-c5-reading Relais6
attr ds3484 obj-c5-set 1
attr ds3484 obj-c6-hint 0,1
attr ds3484 obj-c6-reading Relais7
attr ds3484 obj-c6-set 1
attr ds3484 obj-c7-hint 0,1
attr ds3484 obj-c7-reading Relais8
attr ds3484 obj-c7-set 1
attr ds3484 obj-c8-hint 0,1
attr ds3484 obj-c8-reading Relais9
attr ds3484 obj-c8-set 1
attr ds3484 obj-c9-hint 0,1
attr ds3484 obj-c9-reading Relais10
attr ds3484 obj-c9-set 1
attr ds3484 obj-d0-reading 1
attr ds3484 obj-d1-reading 1
attr ds3484 obj-d11-reading 1
attr ds3484 obj-d2-reading 1
attr ds3484 obj-d27-reading 1
attr ds3484 obj-d3-reading 1
attr ds3484 obj-d31-reading 1
attr ds3484 obj-d7-reading 1

setstate ds3484 opened
setstate ds3484 2022-01-28 22:00:00 InvDoseEingang 1
setstate ds3484 2022-01-28 22:26:39 InvSitzplatz 1
setstate ds3484 2021-12-05 18:24:34 LichtGarten 0
setstate ds3484 2022-01-28 17:15:24 LichtTreppe 1
setstate ds3484 2022-01-28 22:43:00 state opened
:

Irgendwelche Ideen was das Problem sein könnte?

Gruss
tomix

[ansgru]

Keine Ahnung ob hier am richtigen Ort.

Ich habe einen DS3484, siehe auch:
https://forum.fhem.de/index.php?topic=109904.0

Aktuell nutze ich nur die 4 fest verbauten Relais, welche via FHEM geschaltet werden.
Funktioniert aber das Ding müllt mir das Logfile.voll, da die Vertbindung immer wieder umterbrochem wird (in der Praxis bemerke ich nichts davon):

Hast du versucht, Verbose hochzusetzen auf 5? Ich würde die Definition auf "defmod ds3484 ModbusAttr 1 1 192.168.178.15:502 TCP" ändern und dann via "at" oder telnet und einem Script o.ä. die Relais im Sekundentakt ändern. Das ist das ein rechter Stresstest und du siehst wohl relativ schnell, wann es zu einem Disconnect kommt und was vorher das Problem war. So habe ich bei meinen Stromzählern (ABB B23) herausgefunden, dass sie ca. 200ms für eine Antwort benötigen und während dieser Zeit keine weiteren Modbusabfragen stattfinden dürfen, sonst gehen Antworten verloren.

[tomix]

Hast du versucht, Verbose hochzusetzen auf 5? Ich würde die Definition auf "defmod ds3484 ModbusAttr 1 1 192.168.178.15:502 TCP" ändern und dann via "at" oder telnet und einem Script o.ä. die Relais im Sekundentakt ändern. Das ist das ein rechter Stresstest und du siehst wohl relativ schnell, wann es zu einem Disconnect kommt und was vorher das Problem war. So habe ich bei meinen Stromzählern (ABB B23) herausgefunden, dass sie ca. 200ms für eine Antwort benötigen und während dieser Zeit keine weiteren Modbusabfragen stattfinden dürfen, sonst gehen Antworten verloren.

Ich schalte drei der Relais nur vier mal am Tag. Die Einträge treten aber dauern auf (jeweils unter 5 Minuten bis zum nächsten disconnected).

Gibt es eine Möglichkeit ein Device mal auf inaktiv zu stellen oder geht nur löschen und neu anzulegen (aktuell hängt FHEM regelmässig, was vorher nicht der Fall war, dies kann aber eigentlich nicht mit dem zusammenhängen, da dieses Problem schon länger besteht).

Gruss
tomix

[ansgru]

Ich schalte drei der Relais nur vier mal am Tag. Die Einträge treten aber dauern auf (jeweils unter 5 Minuten bis zum nächsten disconnected).

Hast du mal

Code: [Auswählen]

silentReconnect
if set to 1, then it will set the loglevel for "disconnected" and "reappeared" messages to 4 instead of 3
ausprobiert?

Gibt es eine Möglichkeit ein Device mal auf inaktiv zu stellen oder geht nur löschen und neu anzulegen (aktuell hängt FHEM regelmässig, was vorher nicht der Fall war, dies kann aber eigentlich nicht mit dem zusammenhängen, da dieses Problem schon länger besteht).

disable?

Code: [Auswählen]

disable
stop communication with the device while this attribute is set to 1. For Modbus over TCP this also closes the TCP connection.

[tomix]

Hast du mal

Code: [Auswählen]

silentReconnect
if set to 1, then it will set the loglevel for "disconnected" and "reappeared" messages to 4 instead of 3
ausprobiert?
disable?

Code: [Auswählen]

disable
stop communication with the device while this attribute is set to 1. For Modbus over TCP this also closes the TCP connection.

Nein, habe ich nicht. Ich ging davon aus, dass sich die Verbindung nicht verabschieden sollte. Nach dem hier, passiert dies aber offenbar öfters:
https://forum.fhem.de/index.php?topic=97441.195

Nun mal folgendes gesetzt:

Code: [Auswählen]

attr ds3484 silentReconnect 1

Werde mal gucken ob sich was ändert.

Gruss
tomix