Neue Versionen und Support zum Modbus-Modul

Begonnen von StefanStrobel, 20 August 2017, 12:11:08

Vorheriges Thema - Nächstes Thema

oniT

Hallo Stefan,

hier der Log beim Lesen mit den FC3:

Error code 02 / illegal data address (in read after write for FCode 16)

2019.10.12 20:41:43 5: RTUWrite: set called with 261 (h261) setVal = 100
2019.10.12 20:41:43 5: RTUWrite: GetSetChecks with force
2019.10.12 20:41:43 5: RTUWrite: GetSetChecks returns success
2019.10.12 20:41:43 5: RTUWrite: set packed hex 313030 with n to hex 0064
2019.10.12 20:41:43 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 16, type h, adr 261, len 1, value 0064 for device RTUWrite reading 261 (set 261), read buffer empty
2019.10.12 20:41:43 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h261, qlen 0
2019.10.12 20:41:43 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 81349.043 secs ago, last read 81349.014 secs ago, last read on bus 3339.454 secs ago from id 99 (Quantum)
2019.10.12 20:41:43 5: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 22:05:54.907) for RTUWrite, delay 81348.915secs over
2019.10.12 20:41:43 5: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 22:05:54.878) for RTUWrite, delay 81348.944secs over
2019.10.12 20:41:43 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 631001050001020064064c request: id 99, fCode 16, type h, adr 261, len 1, value 0064 for device RTUWrite reading 261 (set 261), queued 0.00 secs ago, read buffer empty
2019.10.12 20:41:43 5: SW: 631001050001020064064c
2019.10.12 20:41:43 5: ModbusLine: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer called from Set
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer called and remaining timeout is 3.99478101730347
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 6310
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 631000
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 63100000
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 6310000000
2019.10.12 20:41:43 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 00
2019.10.12 20:41:43 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.12 20:41:43 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 631000000000
2019.10.12 20:41:43 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 0000
2019.10.12 20:41:43 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.12 20:41:43 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.12 20:41:43 5: ModbusLine: HandleResponse did not get a valid frame yet, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 631000000000c84b
2019.10.12 20:41:43 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 16 and data 00000000
2019.10.12 20:41:43 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.12 20:41:43 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.12 20:41:43 5: ModbusLine: CheckChecksum (called from HandleResponse): c84b is valid
2019.10.12 20:41:43 4: ModbusLine: ResponseDone request: id 99, fCode 16, type h, adr 261, len 1, value 0064 for device RTUWrite reading 261 (set 261), queued 0.04 secs ago, sent 0.04 secs ago, Current read buffer: 631000000000c84b, Id 99, fCode 16, response: id 99, fCode 16, type c, adr 261, len 1
2019.10.12 20:41:43 5: ModbusLine: DropFrame - drop 631000000000c84b
2019.10.12 20:41:43 5: RTUWrite: set is sending read after write
2019.10.12 20:41:43 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 3, type h, adr 261, len 1 for device RTUWrite reading 261 (set 261 Rd), read buffer empty
2019.10.12 20:41:43 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h261, qlen 0
2019.10.12 20:41:43 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 0.034 secs ago, last read 0.004 secs ago, last read on bus 0.005 secs ago from id 99 (RTUWrite)
2019.10.12 20:41:43 4: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 20:41:43.955) for RTUWrite, rest 0.095, sleep forced
2019.10.12 20:41:43 4: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 20:41:43.925) for RTUWrite, rest 0.065, sleep forced
2019.10.12 20:41:43 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 6303010500019db5 request: id 99, fCode 3, type h, adr 261, len 1 for device RTUWrite reading 261 (set 261 Rd), queued 0.00 secs ago, read buffer empty
2019.10.12 20:41:43 5: SW: 6303010500019db5
2019.10.12 20:41:43 5: ModbusLine: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer called from Set
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer called and remaining timeout is 3.99506902694702
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 63
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 6383
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 638302
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 63830261
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got: 638302612f
2019.10.12 20:41:43 4: ModbusLine: ParseFrameStart (RTU) extracted id 99, fCode 131 and data 02
2019.10.12 20:41:43 5: ModbusLine: HandleResponse called from ReadAnswer
2019.10.12 20:41:43 5: ModbusLine: ParseResponse called from HandleResponse
2019.10.12 20:41:43 5: ModbusLine: CheckChecksum (called from HandleResponse): 612f is valid
2019.10.12 20:41:43 4: ModbusLine: HandleResponse got response with error code 83 / 02, illegal data address
2019.10.12 20:41:43 4: ModbusLine: ResponseDone request: id 99, fCode 3, type h, adr 261, len 1 for device RTUWrite reading 261 (set 261 Rd), queued 0.03 secs ago, sent 0.03 secs ago, Current read buffer: 638302612f, Id 99, fCode 131, response: id 99, fCode 131, adr 261, len 1
2019.10.12 20:41:43 5: ModbusLine: DropFrame - drop 638302612f
2019.10.12 20:41:43 5: ModbusLine: ReadAnswer got Error code 02 / illegal data address


Nachfolgend ein Auszug der Befehle für Register 261 Leistungsstufe mit hterm:

100%
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 64 00 64 00 01 00 00 54 5A

66%
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 42 00 64 00 01 00 00 13 98

33%
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 21 00 64 00 01 00 00 40 9E

0%
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 00 00 64 00 01 00 00 71 9C


Damit schalten die Leistungsstufen.

Im Anhang habe ich noch ein Dokument gefunden, da sind noch etwas mehr Informationen enthalten, gerade bzgl. Rückmeldung.

Zitat
Kannst Du denn mit anderen Tools das Register 261 per Code 16 einzeln beschreiben?
Bisher nur mit dem CAS Modbus Scanner. Allerdings ebenfalls ohne Erfolg. Hast Du einen Vorschlag mit was ich es noch Testen kann um weitere Informationen zu erhalten?

Danke
Tino
BBB - debian weezy - FHEM 5.7
HMLAN - HM-LC-Bl1-FM, HM-ES-PMSw1-PI, HM-LC-Sw1-FM, HM-TC-IT-WM-W-EU, HM-WDS40-TH-I, HM-Sen-Wa-Od, HM-Sec-RHS
Dimplex Wärmepumpe / Dimplex ZL 300 - Modbus TCP
SDM630M - Modbus TCP
SolarLog 200 / SMA SonnyBoy 1.5/2.5 - Modbus TCP

StefanStrobel

Hallo Tino,

Die Befehle, die Du mit hterm übertragen hast, schreiben immer 8 Register auf einmal, beginnend bei 0x100 also 256.
Offenbar reagiert das Gerät nur auf diese Anfangsadresse korrekt. Bei einem direkten Schreibzugriff auf 261 hat es keine Fehlermeldung zurückgeschickt, aber in der Antwort stand dass 0 Bytes geschrieben wurden.
Beim Versuch das Register 261 zu lesen kommt dann sogar die Fehlermeldung dass die Adresse illegal ist.
Das sieht für mich nach einer etwas "reduzierten" Modbus-Implementation aus.

Wenn Du nur die Leistungsstufen schalten möchtest, dann kannst Du das auch in so einem Fall von Fhem aus machen.
Du musst eben auch 8 Register bzw. 16 Bytes ab Register 256 gleichzeitig schreiben.
Dazu könntest Du ein Objekt als h256 mit Länge 8 definieren und einen Hex-String übergeben.
Unpack-Code dann so etwas wie H*

Im Log siehst Du ja was gesendet wird:
Zitat
2019.10.12 20:41:43 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 631001050001020064064c request: id 99, fCode 16, type h, adr 261, len 1, value 0064 for device RTUWrite reading 261 (set 261), queued 0.00 secs ago, read buffer empty
2019.10.12 20:41:43 5: SW: 631001050001020064064c

Da müsste statt dessen der String stehen, den Du auch per hterm geschickt hast:
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 64 00 64 00 01 00 00 54 5A
Natürlich ohne die Spaces.

Das Bedeutet:
Adresse 0x63 bzw. 99
Fcode 0x10 (schreibe mehrere Holding-Register)
0100 ab Adresse 0x100 bzw. 256
0008 Länge 8 Register
10 als Bytes 16 Bytes
0000 0000 0000 0000 0000 das sind jeweils 0-Werte für die Register 256 bis 260
0064 das ist dann der Wert für Register 261
0001 Wert für Register 262
0000 Wert für Regsiter 263
545A das ist die Prüfsumme. Die erzeugt das Modul automatisch.

Damit Du beim set den Wert als 0-100 übergeben kannst, könntest Du eine setexpr verwenden, die aus dem Wert den passenden Hex-String erzeugt.

Ebenso musst Du vermutlich beim Lesen immer ab Register 256 lesen. Das macht die Sache recht unschön. Ich würde deshalb erstmal nur das mit dem Schreiben umsetzen. Wenn das soweit klappt, kann ich mit dem Lesen und zerlegen der einzelnen Werte helfen.

Gruss
    Stefan

oniT

Hallo Stefan,

Zitat
Die Befehle, die Du mit hterm übertragen hast, schreiben immer 8 Register auf einmal, beginnend bei 0x100 also 256.
Offenbar reagiert das Gerät nur auf diese Anfangsadresse korrekt. Bei einem direkten Schreibzugriff auf 261 hat es keine Fehlermeldung zurückgeschickt, aber in der Antwort stand dass 0 Bytes geschrieben wurden. Beim Versuch das Register 261 zu lesen kommt dann sogar die Fehlermeldung dass die Adresse illegal ist.
Das sieht für mich nach einer etwas "reduzierten" Modbus-Implementation aus.
Ja das ist auch meine Vermutung.

Zitat
Wenn Du nur die Leistungsstufen schalten möchtest, dann kannst Du das auch in so einem Fall von Fhem aus machen.
Du musst eben auch 8 Register bzw. 16 Bytes ab Register 256 gleichzeitig schreiben.
Dazu könntest Du ein Objekt als h256 mit Länge 8 definieren
Ja verstanden. Ist soweit klar. Ich habe h256 mit der Länge 8 (obj-h256-len 8) angelegt.

Zitat
und einen Hex-String übergeben. Unpack-Code dann so etwas wie H*
Das ist mir beides nicht klar.

Zitat
Da müsste statt dessen der String stehen, den Du auch per hterm geschickt hast:
63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 64 00 64 00 01 00 00 54 5A
Natürlich ohne die Spaces.

Das Bedeutet:
Adresse 0x63 bzw. 99
Fcode 0x10 (schreibe mehrere Holding-Register)
0100 ab Adresse 0x100 bzw. 256
0008 Länge 8 Register
10 als Bytes 16 Bytes
0000 0000 0000 0000 0000 das sind jeweils 0-Werte für die Register 256 bis 260
0064 das ist dann der Wert für Register 261
0001 Wert für Register 262
0000 Wert für Regsiter 263
545A das ist die Prüfsumme. Die erzeugt das Modul automatisch.
Ja das ist mir wieder klar.

ZitatDamit Du beim set den Wert als 0-100 übergeben kannst, könntest Du eine setexpr verwenden, die aus dem Wert den passenden Hex-String erzeugt.
Ist mir nicht ganz klar. Wie mach ich das? Setzte ich auf das Register h256 den Wert 100, dann steht im Log auch 0064. Soweit richtig. Aber, trotz Länge 8 hätte ich jetzt den kompletten String 63 10 01 00 00 08 10 00 00 00 00 00 00 00 00 00 00 00 64 00 00 00 00 00 00 erwartet. Kommt aber nicht. Der ist trotzdem noch immer kurz und es fehlen die 0000 für die Register 256 bis 260 bzw. 262 bis 263.


2019.10.13 21:36:03 5: RTUWrite: set called with 256 (h256) setVal = 100
2019.10.13 21:36:03 5: RTUWrite: GetSetChecks with force
2019.10.13 21:36:03 5: RTUWrite: GetSetChecks returns success
2019.10.13 21:36:03 5: RTUWrite: set packed hex 313030 with n to hex 0064
2019.10.13 21:36:03 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 16, type h, adr 256, len 8, value 0064 for device RTUWrite reading 256 (set 256), read buffer empty
2019.10.13 21:36:03 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h256, qlen 0
2019.10.13 21:36:03 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 17.548 secs ago, last read 17.525 secs ago, last read on bus 12.055 secs ago from id 99 (Quantum)
2019.10.13 21:36:03 5: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 21:35:46.051) for RTUWrite, delay 17.426secs over
2019.10.13 21:36:03 5: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 21:35:46.028) for RTUWrite, delay 17.449secs over
2019.10.13 21:36:03 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 631001000008100064a580 request: id 99, fCode 16, type h, adr 256, len 8, value 0064 for device RTUWrite reading 256 (set 256), queued 0.00 secs ago, read buffer empty
2019.10.13 21:36:03 5: SW: 631001000008100064a580


Irgendwie stehe ich da auf dem Schlauch. Ich benötige hier bitte noch weitere Unterstützung.

Danke
Gruß
Tino
BBB - debian weezy - FHEM 5.7
HMLAN - HM-LC-Bl1-FM, HM-ES-PMSw1-PI, HM-LC-Sw1-FM, HM-TC-IT-WM-W-EU, HM-WDS40-TH-I, HM-Sen-Wa-Od, HM-Sec-RHS
Dimplex Wärmepumpe / Dimplex ZL 300 - Modbus TCP
SDM630M - Modbus TCP
SolarLog 200 / SMA SonnyBoy 1.5/2.5 - Modbus TCP

StefanStrobel

Hallo Tino,

Das Modul kann nicht wissen, in welcher Form die Benutzereingabe kodiert werden soll. Manche Geräte speichern Zahlen als 16Bit signed integer, manche als 32Bit float etc.
Deshalb konfiguriert man einen unpack-Code, mit dem das Modul beim Lesen den Wert aus der Modbus-Response in ein Reading umwandelt und andersherum mit dem eine Benutzereingabe beim Set-Befehl in das Format für das Gerät umgewandelt wird. Der Default ist dabei ein n (unsigned short (16-bit) in "network" (big-endian) order).

In Deinem Fall muss aber aus dem Perl String/Wert 100 nicht einfach nur der Code 0064 in ein Register geschrieben werden, sondern Du musst noch viel mehr Bytes schreiben und 0064 kommt erst nach ein paar Nullen.

Jetzt könntest Du mit dem Unpack-Code H*, der bei einem Set-Befehl zum Packen verwendet wird, und einem Set-Befehl mit 000000000000000000000064 statt 100 den Hex-Strong an das Modul übergeben.
Das wäre aber nicht so elegant wie einfach nur set Device 100.

Deshalb gibt es auch noch eine setexpr. Da kann man per Attribut eine Perl-Expression festlegen, die den bei Set übergebenen Wert als $val weiterverarbeiten kann, z.B. Mit '00000000000000000000'.unpack('H4',pack('n',$val))
Ich kann das gerade nicht testen, aber so sollte aus einer eingegebenen 100 der String "000000000000000000000064" werden.

Dann kommt der per Attribut definierte Unpack-Code H* und macht daraus den Binärstring für den Schreib-Request.

Wenn ich in den nächsten Tagen mal dazu komme, kann ich die konkrete Konfiguration mal testen und posten..

Gruß
    Stefan

oniT

Hallo Stefan,

ok, so ein wenig habe ich es verstanden. Ich habe dies mal so zusammengesetzt


0000000000000000000000'.unpack("H4", pack("n", $val)).'006400010000

oder auch mal so

000000000000000000'.unpack("H8", pack("N", $val)).'006400010000

Das Resultat ist gleich. Dabei ist im Log nun folgender Eintrag


2019.10.14 22:14:49 5: RTUWrite: set called with 256 (h256) setVal = 100
2019.10.14 22:14:49 5: RTUWrite: GetSetChecks with force
2019.10.14 22:14:49 5: RTUWrite: GetSetChecks returns success
2019.10.14 22:14:49 5: RTUWrite: CheckEval for Set evaluates setexpr for 256, val=100, expr='0000000000000000000000'.unpack("H4", pack("n", $val)).'006400010000'
2019.10.14 22:14:49 5: RTUWrite: CheckEval for Set result is 00000000000000000000000064006400010000
2019.10.14 22:14:49 5: RTUWrite: set packed hex 3030303030303030303030303030303030303030303030303634303036343030303130303030 with n to hex 6710
2019.10.14 22:14:49 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 16, type h, adr 256, len 8, value 6710 for device RTUWrite reading 256 (set 256), read buffer empty
2019.10.14 22:14:49 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h256, qlen 0
2019.10.14 22:14:49 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 271.094 secs ago, last read 271.072 secs ago, last read on bus 271.073 secs ago from id 99 (RTUWrite)
2019.10.14 22:14:49 5: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 22:10:17.999) for RTUWrite, delay 270.973secs over
2019.10.14 22:14:49 5: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 22:10:17.977) for RTUWrite, delay 270.995secs over
2019.10.14 22:14:49 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 6310010000081067108f97 request: id 99, fCode 16, type h, adr 256, len 8, value 6710 for device RTUWrite reading 256 (set 256), queued 0.00 secs ago, read buffer empty


Diese Zeile sieht dabei ja schon einmal vielversprechend aus

2019.10.14 22:14:49 5: RTUWrite: CheckEval for Set result is 00000000000000000000000064006400010000


Was bedeutet eigentlich dies hier

RTUWrite: set packed hex 3030303030303030303030303030303030303030303030303634303036343030303130303030 with n to hex 6710


Grundsätzlich komme ich vermutlich mit den unpack und pack nicht ganz klar.

Danke schon einmal für Deine Geduld.

Gruß
Tino
BBB - debian weezy - FHEM 5.7
HMLAN - HM-LC-Bl1-FM, HM-ES-PMSw1-PI, HM-LC-Sw1-FM, HM-TC-IT-WM-W-EU, HM-WDS40-TH-I, HM-Sen-Wa-Od, HM-Sec-RHS
Dimplex Wärmepumpe / Dimplex ZL 300 - Modbus TCP
SDM630M - Modbus TCP
SolarLog 200 / SMA SonnyBoy 1.5/2.5 - Modbus TCP

StefanStrobel

Hallo Tino,

Du kommst der Sache schon näher :-)
Die setexpr hat noch den Fehler, dass nach dem umgewandelten Wert nochmal 0064 angehängt wird. Damit hast Du 0064 doppelt.
Das Hauptproblem ist aber, dass das Attribut für den unpack-Code noch fehlt. Daher wird per Default "n" genommen. Wenn das Modul nun den mühsam zusammengesetzten Hex-String mit "n" an die pack-Funktion übergibt, bleibt nur 6710 übrig. So macht das ja keine Sinn.
Wenn Du jetzt aber obj-h256-unpack H* angibst, sollte sich etwas ändern. Dann wird der Hex-String nicht als Integer sondern tatsächlich als Hex-String interpretiert.

Gruß
    Stefan

oniT

Hallo Stefan,

ja fein, das ist die Lösung. Ich hatte noch ein paar 00 zu viel, aber jetzt konnten die Werte 0, 33, 66 und 100% für die Leistungsstufe geschrieben werden. Hier wieder ein Auszug aus dem Log:


2019.10.15 20:28:47 5: RTUWrite: set called with 256 (h256) setVal = 100
2019.10.15 20:28:47 5: RTUWrite: GetSetChecks with force
2019.10.15 20:28:47 5: RTUWrite: GetSetChecks returns success
2019.10.15 20:28:47 5: RTUWrite: CheckEval for Set evaluates setexpr for 256, val=100, expr='00000000000000000000'.unpack("H4", pack("n", $val)).'006400010000'
2019.10.15 20:28:47 5: RTUWrite: CheckEval for Set result is 000000000000000000000064006400010000
2019.10.15 20:28:47 5: RTUWrite: set packed hex 303030303030303030303030303030303030303030303634303036343030303130303030 with H* to hex 000000000000000000000064006400010000
2019.10.15 20:28:47 4: RTUWrite: DoRequest called from Set created request: id 99, fCode 16, type h, adr 256, len 8, value 000000000000000000000064006400010000 for device RTUWrite reading 256 (set 256), read buffer empty
2019.10.15 20:28:47 5: ModbusLine: QueueRequest called from DoRequest (RTUWrite) with h256, qlen 0
2019.10.15 20:28:47 4: ModbusLine: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 99 (RTUWrite), last send to this device was 51.455 secs ago, last read 51.432 secs ago, last read on bus 21.616 secs ago from id 99 (Quantum)
2019.10.15 20:28:47 5: ModbusLine: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 20:27:56.018) for RTUWrite, delay 51.333secs over
2019.10.15 20:28:47 5: ModbusLine: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 20:27:55.995) for RTUWrite, delay 51.356secs over
2019.10.15 20:28:47 4: ModbusLine: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 63100100000810000000000000000000000064006400010000545a request: id 99, fCode 16, type h, adr 256, len 8, value 000000000000000000000064006400010000 for device RTUWrite reading 256 (set 256), queued 0.00 secs ago, read buffer empty
2019.10.15 20:28:47 5: SW: 63100100000810000000000000000000000064006400010000545a


Und hier die Definition, für alle die auch einmal solch eine Lösung benötigen.


defmod RTUWrite ModbusAttr 99 3600
attr RTUWrite userattr dev-h-write dev-timing-timeout obj-h256-len obj-h256-reading obj-h256-set obj-h256-setexpr obj-h256-unpack
attr RTUWrite dev-h-write 16
attr RTUWrite dev-timing-timeout 4
attr RTUWrite obj-h256-len 8
attr RTUWrite obj-h256-reading 256
attr RTUWrite obj-h256-set 1
attr RTUWrite obj-h256-setexpr '00000000000000000000'.unpack("H4", pack("n", $val)).'006400010000'
attr RTUWrite obj-h256-unpack H*


Ist noch nicht dringend, gibt es aber auch irgendwie die Möglichkeit diesen String mit den anderen Registern zusammenzusetzen? Bei dieser Lösung ist dieser ja bis auf h261 fest. Im setexpr wird ja der eingegebene Wert durch $val mit übergeben. Könnte man zum Beispiel in einem DOIF oder notify, ist ja egal, die Setexpr mit anderen Werten zum Beispiel aus einem Dummy zusammenbauen und dann in das "attr RTUWrite obj-h256-setexpr ' ....'" schreiben. Anschließend wird noch der Befehl ausgeführt, fertig. Das ist meiner Meinung nach doch möglich und sollte unktionieren. Ist vielleicht nicht die eleganteste Lösung, aber vermutlich die einfachste. Oder was meinst Du? Gibt es noch eine andere Lösung.

Danke für die Unterstützung, hat mich wieder ein Stück weitergebracht.

Gruß
Tino
BBB - debian weezy - FHEM 5.7
HMLAN - HM-LC-Bl1-FM, HM-ES-PMSw1-PI, HM-LC-Sw1-FM, HM-TC-IT-WM-W-EU, HM-WDS40-TH-I, HM-Sen-Wa-Od, HM-Sec-RHS
Dimplex Wärmepumpe / Dimplex ZL 300 - Modbus TCP
SDM630M - Modbus TCP
SolarLog 200 / SMA SonnyBoy 1.5/2.5 - Modbus TCP

StefanStrobel

Hallo Tino,

Du kannst in der setexpr durchaus Werte von Readings oder Attributen verwenden.
Siehe https://wiki.fhem.de/wiki/DevelopmentModuleAPI#ReadingsVal
Oder https://wiki.fhem.de/wiki/DevelopmentModuleAPI#AttrVal
Die Variable $hash steht in der Expression ebenso wie $val zur Verfügung.

Gruß
    Stefan

oniT

Hallo Stefan,

alles klar. ReadingsVal steht im Attribut setexpr zur Verfügung. Ist ja noch besser.  :)

Hier mal das Beispiel, funktioniert und kann beliebig um die restlichen Register ja erweitert werden.

obj-h256-setexpr '00000000000000000000'.unpack("H4", pack("n", $val)).unpack("H4",pack("n",ReadingsVal("dummy_h262_quantum","state","0000"))).unpack("H4",pack("n",ReadingsVal("dummy_h263_quantum","state","0000"))).'0000'


Eine weitere Frage oder auch Anmerkung, wenn ich hieraus über saveAsModule dies als Modul speichere und später über Edit Files bearbeite, kommt dann beim Speichern eine Fehlermeldung bzgl. der Zeichensetzung. Ich wollte es nur erwähnen, ich weiß nicht ob es schon jemand aufgefallen ist. Eventuell kannst du dies ja sogar im ModbusAttr Modul mit beheben. Also falls das geht und die Zeichensetzung berücksichtigt werden kann.

syntax error at ./FHEM/98_ModbusRTUDimplexQuantum.pm line 44, near "''00000000000000000000"

Danke
Gruß
Tino
BBB - debian weezy - FHEM 5.7
HMLAN - HM-LC-Bl1-FM, HM-ES-PMSw1-PI, HM-LC-Sw1-FM, HM-TC-IT-WM-W-EU, HM-WDS40-TH-I, HM-Sen-Wa-Od, HM-Sec-RHS
Dimplex Wärmepumpe / Dimplex ZL 300 - Modbus TCP
SDM630M - Modbus TCP
SolarLog 200 / SMA SonnyBoy 1.5/2.5 - Modbus TCP

StefanStrobel

Hallo Tino,

Danke für den Hinweis.
Ist bisher nicht aufgefallen.

Gruß
    Stefan

ch.eick

Hallo zusammen.

Ich denke ich bin hier richtig um einen Kostal plenticore Wechselrichter über modbus TCP auszulesen. Ich habe einfach mal folgendes in FHEM definiert:


Internals:
   CFGFN     
   DEF        5 60 192.168.178.18:1502 TCP
   DeviceName 192.168.178.18:1502
   EXPECT     idle
   FD         28
   FUUID      5db5b8b3-f33f-81e9-4e6c-e6ea81fa8ef6414b
   INTERVAL   30
   IODev      PV_Anlage_1
   LASTOPEN   1572190873.57548
   MODBUSID   5
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       PV_Anlage_1
   NOTIFYDEV  global
   NR         13633
   NTFY_ORDER 50-PV_Anlage_1
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TRIGGERTIME 1572191536.36499
   TRIGGERTIME_FMT 2019-10-27 16:52:16
   TYPE       ModbusAttr
   devioLoglevel 3
   lastUpdate 1572191476.36499
   nextOpenDelay 60
   READ:
     BUFFER     
   READINGS:
     2019-10-27 16:41:13   state           opened
   defptr:
     PV_Anlage_1 5
Attributes:
   verbose    5


Und bekomme schon dies im Log zu sehen

2019.10.27 16:39:06 3: PV_Anlage_1: defined with id 5, interval 30, protocol TCP, mode master, connection to 192.168.178.18:1502
2019.10.27 16:39:07 4: PV_Anlage_1: Notify / Init: opening connection
2019.10.27 16:39:07 5: PV_Anlage_1: open called from Notify
2019.10.27 16:39:07 4: PV_Anlage_1: open trying to open connection to 192.168.178.18:1502
2019.10.27 16:39:07 3: Opening PV_Anlage_1 device 192.168.178.18:1502
2019.10.27 16:39:07 5: HttpUtils url=http://192.168.178.18:1502/
2019.10.27 16:39:07 4: IP: 192.168.178.18 -> 192.168.178.18
2019.10.27 16:39:07 5: PV_Anlage_1: SetartUpdateTimer called from Notify kept existing timer, will call GetUpdate in 6.8 sec at 2019-10-27 16:39:13, interval 30
2019.10.27 16:39:07 5: PV_Anlage_1: UpdateSetList: setList=interval reread:noArg reconnect:noArg stop:noArg start:noArg close:noArg saveAsModule scanStop:noArg scanModbusObjects
2019.10.27 16:39:07 5: PV_Anlage_1: UpdateSetList: getList=
2019.10.27 16:39:07 3: PV_Anlage_1 device opened
2019.10.27 16:39:07 5: PV_Anlage_1: SetartUpdateTimer called from OpenCB kept existing timer, will call GetUpdate in 6.6 sec at 2019-10-27 16:39:13, interval 30

2019.10.27 16:39:13 5: PV_Anlage_1: GetUpdate called from HandleTimeout
2019.10.27 16:39:13 5: PV_Anlage_1: SetartUpdateTimer called from GetUpdate updated timer, will call GetUpdate in 30.0 sec at 2019-10-27 16:39:43, interval 30
2019.10.27 16:39:13 5: PV_Anlage_1: GetUpdate objects from attributes:
2019.10.27 16:39:13 5: PV_Anlage_1: GetUpdate full object list:
2019.10.27 16:39:13 5: PV_Anlage_1: GetUpdate tries to combine read commands
2019.10.27 16:39:13 5: PV_Anlage_1: GetUpdate doesn't sort objList before sending requests


Gibt es nun eine Möglichkeit eine Liste aller Datenfelder von dem Kostal Plenticor (Master) zu bekommen?


Mit dem Python Skript kostal_modbusquery_V003.py bekomme ich bereits diese Liste, jedoch wäre mir das Modbus Modul eleganter.

Desweiteren habe ich dann noch den EM410 und einen BYD Speicher. Der EM410 spricht ebenfalls modbus TCP, womit ich meine Hilfeersuchen direkt erweitern möchte.

Viele Grüße
     Christian


fhem@raspberrypi:~/python/kostal$ python kostal_modbusquery_V003.py
Starting QUERY ..........
Inverter article number b'10335959'
Software-Version IO-Controller (IOC) b'01.34\x00\x00\x00'
Total DC power 13.52
State of energy manager 0.0
Home own consumption from battery 0.0
Home own consumption from grid 0.0
Total home consumption Battery 0.0
Total home consumption Grid 0.0
Total home consumption PV 0.0
Home own consumption from PV 0.0
Total home consumption 0.0
Isolation resistance 65535000.0
Power limit from EVU 100.0
Total home consumption rate 0.0
Worktime 38235.0
Actual cos phi 1.0
Grid frequency 49.98
Current Phase 1 0.04
Active power Phase 1 -2.75
Voltage Phase 1 228.66
Current Phase 2 0.05
Active power Phase 2 -2.94
Voltage Phase 2 229.93
Current Phase 3 0.04
Active power Phase 3 -2.65
Voltage Phase 3 229.54
Total AC active power -8.35
Total AC reactive power 28.08
Total AC apparent power 29.29
Battery charge current 20.0
Number of battery cycles 0.0
Actual battery charge -minus or discharge -plus current 0.0
PSSB fuse state 0.0
Battery ready flag 1.0
Act. state of charge 17.0
Battery temperature 16.6
Battery voltage 14.31
Cos phi (powermeter) nan
Frequency (powermeter) nan
Current phase 1 (powermeter) nan
Active power phase 1 (powermeter) nan
Reactive power phase 1 (powermeter) nan
Apparent power phase 1 (powermeter) nan
Voltage phase 1 (powermeter) nan
Current phase 2 (powermeter) nan
Active power phase 2 (powermeter) nan
Reactive power phase 2 (powermeter) nan
Apparent power phase 2 (powermeter) nan
Voltage phase 2 (powermeter) nan
Current phase 3 (powermeter) nan
Active power phase 3 (powermeter) nan
Reactive power phase 3 (powermeter) nan
Apparent power phase 3 (powermeter) nan
Voltage phase 3 (powermeter) nan
Total active power (powermeter) nan
Total reactive power (powermeter) nan
Total apparent power (powermeter) nan
Current DC1 0.02
Power DC1 8.36
Voltage DC1 443.86
Current DC2 0.05
Power DC2 5.73
Voltage DC2 118.62
Current DC3 0.0
Power DC3 0.0
Voltage DC3 0.0
Total yield 10850.03
Daily yield 2690.12
Yearly yield 10850.03
Monthly yield 10850.03
Battery actual SOC 17
Battery Manufacturer b'        '
Battery Model ID 0
Battery Serial Number 0
Work Capacity 0
Inverter Max Power 10000
Inverter Generation Power (actual) 65528
Generation Energy 711065600
Actual battery charge-discharge power 0
Battery Firmware 0
Battery Type 4
Done...
[[6, 'Inverter article number', 'Strg8', b'10335959'],
[46, 'Software-Version IO-Controller (IOC)', 'Strg8', b'01.34\x00\x00\x00'],
[100, 'Total DC power', 'Float', 13.52],
[104, 'State of energy manager', 'Float', 0.0],
[106, 'Home own consumption from battery', 'Float', 0.0],
[108, 'Home own consumption from grid', 'Float', 0.0],
[110, 'Total home consumption Battery', 'Float', 0.0],
[112, 'Total home consumption Grid', 'Float', 0.0],
[114, 'Total home consumption PV', 'Float', 0.0],
[116, 'Home own consumption from PV', 'Float', 0.0],
[118, 'Total home consumption', 'Float', 0.0],
[120, 'Isolation resistance', 'Float', 65535000.0],
[122, 'Power limit from EVU', 'Float', 100.0],
[124, 'Total home consumption rate', 'Float', 0.0],
[144, 'Worktime', 'Float', 38235.0],
[150, 'Actual cos phi', 'Float', 1.0],
[152, 'Grid frequency', 'Float', 49.98],
[154, 'Current Phase 1', 'Float', 0.04],
[156, 'Active power Phase 1', 'Float', -2.75],
[158, 'Voltage Phase 1', 'Float', 228.66],
[160, 'Current Phase 2', 'Float', 0.05],
[162, 'Active power Phase 2', 'Float', -2.94],
[164, 'Voltage Phase 2', 'Float', 229.93],
[166, 'Current Phase 3', 'Float', 0.04],
[168, 'Active power Phase 3', 'Float', -2.65],
[170, 'Voltage Phase 3', 'Float', 229.54],
[172, 'Total AC active power', 'Float', -8.35],
[174, 'Total AC reactive power', 'Float', 28.08],
[178, 'Total AC apparent power', 'Float', 29.29],
[190, 'Battery charge current', 'Float', 20.0],
[194, 'Number of battery cycles', 'Float', 0.0],
[200, 'Actual battery charge -minus or discharge -plus current', 'Float', 0.0],
[202, 'PSSB fuse state', 'Float', 0.0],
[208, 'Battery ready flag', 'Float', 1.0],
[210, 'Act. state of charge', 'Float', 17.0],
[214, 'Battery temperature', 'Float', 16.6],
[216, 'Battery voltage', 'Float', 14.31],
[218, 'Cos phi (powermeter)', 'Float', nan],
[220, 'Frequency (powermeter)', 'Float', nan],
[222, 'Current phase 1 (powermeter)', 'Float', nan],
[224, 'Active power phase 1 (powermeter)', 'Float', nan],
[226, 'Reactive power phase 1 (powermeter)', 'Float', nan],
[228, 'Apparent power phase 1 (powermeter)', 'Float', nan],
[230, 'Voltage phase 1 (powermeter)', 'Float', nan],
[232, 'Current phase 2 (powermeter)', 'Float', nan],
[234, 'Active power phase 2 (powermeter)', 'Float', nan],
[236, 'Reactive power phase 2 (powermeter)', 'Float', nan],
[238, 'Apparent power phase 2 (powermeter)', 'Float', nan],
[240, 'Voltage phase 2 (powermeter)', 'Float', nan],
[242, 'Current phase 3 (powermeter)', 'Float', nan],
[244, 'Active power phase 3 (powermeter)', 'Float', nan],
[246, 'Reactive power phase 3 (powermeter)', 'Float', nan],
[248, 'Apparent power phase 3 (powermeter)', 'Float', nan],
[250, 'Voltage phase 3 (powermeter)', 'Float', nan],
[252, 'Total active power (powermeter)', 'Float', nan],
[254, 'Total reactive power (powermeter)', 'Float', nan],
[256, 'Total apparent power (powermeter)', 'Float', nan],
[258, 'Current DC1', 'Float', 0.02],
[260, 'Power DC1', 'Float', 8.36],
[266, 'Voltage DC1', 'Float', 443.86],
[268, 'Current DC2', 'Float', 0.05],
[270, 'Power DC2', 'Float', 5.73],
[276, 'Voltage DC2', 'Float', 118.62],
[278, 'Current DC3', 'Float', 0.0],
[280, 'Power DC3', 'Float', 0.0],
[286, 'Voltage DC3', 'Float', 0.0],
[320, 'Total yield', 'Float', 10850.03],
[322, 'Daily yield', 'Float', 2690.12],
[324, 'Yearly yield', 'Float', 10850.03],
[326, 'Monthly yield', 'Float', 10850.03],
[514, 'Battery actual SOC', 'U16', 17],
[517, 'Battery Manufacturer', 'Strg8', b'        '],
[525, 'Battery Model ID', 'U32', 0],
[527, 'Battery Serial Number', 'U32', 0],
[529, 'Work Capacity', 'U32', 0],
[531, 'Inverter Max Power', 'Float', 10000],
[575, 'Inverter Generation Power (actual)', 'S16', 65528],
[577, 'Generation Energy', 'U32', 711065600],
[582, 'Actual battery charge-discharge power', 'S16', 0],
[586, 'Battery Firmware', 'U32', 0],
[588, 'Battery Type', 'U16', 4]]
----------------------------------
Doing some Calculations of the received information:
Left Side Raw Power Generation of Panles : 14.1
BatteryCharge (-) / Discharge(+) is      : 0.0
Powerfromgrid (-) /To Grid (+) is        : 65528.0
Total current Home consumption is        : 0.0
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

StefanStrobel

Hallo Christian,

Eine Liste der definierten Datenpunkte und vor allem der zugehörigen Datentypen kann man leider nicht von einem Modbus-Gerät abfragen. Aber in dem von Dir erwähnten Skript wird das wohl alles drinstehen.
Schau das doch mal genauer an.
Alternativ sollte der Hersteller solche Infos bereitstellen.
Eventuell hat das aber auch schon jemand mit Fhem gemacht und kann Dir die fertige Konfiguration zur Verfügung stellen.
Hast Du schon mal im Forum gesucht?

Gruß
    Stefan

ch.eick

Hallo Stefan,

danke für Deine unermüdlichen Hilfen.

Ja, gesucht habe ich bereits, denn so bin ich hier gelandet ;-) Eine Dokumentation zum Modbus TCP habe ich auch bereits und halt das Python Skript.
Mir fehlt momentan das Verständnis, wie ich das bereits definierte Modbus Device in FHEM so modifizieren kann, dass es die readings vom Modbus ausliest.

An diese Stelle natürlich auch noch mal Dank an den Pythen Skript Ersteller.

Hier einige Ausschnitte, um einen Einstieg für die Definitionen in FHEM zu haben


Das habe ich ja bereits bei der definition des FHEM devices eingetragen
        #Change the IP address and port to suite your environment:
        self.inverter_ip="192.168.178.18"
        self.inverter_port="1502"
        #No more changes required beyond this point

.....
Und so sind in Python die Kostal Register definiert

        self.KostalRegister = []
        self.Adr6=[]
        self.Adr6=[6]
        self.Adr6.append("Inverter article number")
        self.Adr6.append("Strg8")
        self.Adr6.append(0)
       
        self.Adr46=[]
        self.Adr46 =[46]
        self.Adr46.append("Software-Version IO-Controller (IOC)")
        self.Adr46.append("Strg8")
        self.Adr46.append(0)
       
        self.Adr100=[]
        self.Adr100 =[100]
        self.Adr100.append("Total DC power")
        self.Adr100.append("Float")
        self.Adr100.append(0)
               
        self.Adr104=[]
        self.Adr104 =[104]
        self.Adr104.append("State of energy manager")
        self.Adr104.append("Float")
        self.Adr104.append(0)


Ich könnte jetzt natürlich das Python Skript aufrufen und aus Python die readings mit set sezten, jedoch fände ich scharmanter, wenn ich es direkt in FHEM durchführen würde.

Für ein Muster der änderungen wäre ich schon dankbar und würde dann die Fleißarbeit übernehmen.

Viele Grüße
    Christian

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Wzut

fang mal ganz klein an :
attr PV_Anlage_1 dev-h-defLen 2
attr PV_Anlage_1 dev-h-defPoll 1
attr PV_Anlage_1 dev-h-defUnpack N

(das erspart dir später eventuell Tipparbeit )
und dann holst du deinen ersten Wert , laut deinem Listing liegt in Register 100 der Wert "Total DC power"
also noch :
attr PV_Anlage_1 obj-h1000-reading Total_DC_Power
danach sollte dein erstes Reading da sein, wenn der Wert unsinnig ist mit Unpack spielen und/oder ggf die Länge von 2 auf 1 ändern.
Steht aber alles in der Kostal Modubus pdf Doku, d.h. Register Nr. , Name, Länge & Typ


Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

ch.eick

Okay, einfach ist immer gut...


Wäre der MODE master in der fhem definition denn richtig? Der Kostal Plenticore ist auch als Master definiert.

Internals:
   CFGFN     
   DEF        5 60 192.168.178.18:1502 TCP
   DeviceName 192.168.178.18:1502
   EXPECT     idle
   FD         23
   FUUID      5db5b8b3-f33f-81e9-4e6c-e6ea81fa8ef6414b
   INTERVAL   60
   IODev      PV_Anlage_1
   LASTOPEN   1572284858.33409
   MODBUSID   5
   MODE       master
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       PV_Anlage_1
   NOTIFYDEV  global
   NR         13633
   NTFY_ORDER 50-PV_Anlage_1
   PARTIAL   
   PROTOCOL   TCP
   STATE      opened
   TCPConn    1
   TIMEOUTS   5
   TRIGGERTIME 1572350716.61945
   TRIGGERTIME_FMT 2019-10-29 13:05:16
   TYPE       ModbusAttr
   devioLoglevel 3
   lastUpdate 1572350656.61945
   nextOpenDelay 60
   QUEUE:
   READ:
     BUFFER     
   READINGS:
     2019-10-28 18:47:38   state           opened
   REMEMBER:
     lid        5
     lname      PV_Anlage_1
     lsend      1572350658.68951
   defptr:
     PV_Anlage_1 5
   lastRead:
Attributes:
   dev-h-defLen 2
   dev-h-defPoll 1
   dev-h-defUnpack N
   obj-h100-reading Total_DC_Power
   room       Strom->Photovoltaik
   userattr   dev-h-defLen dev-h-defPoll dev-h-defUnpack obj-h100-reading
   verbose    5



2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate called from HandleTimeout
2019.10.29 13:09:17 5: PV_Anlage_1: SetartUpdateTimer called from GetUpdate updated timer, will call GetUpdate in 60.0 sec at 2019-10-29 13:10:17, interval 60
2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate objects from attributes: h100
2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate full object list: h100
2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate check h100 => Total_DC_Power, poll = 1, last = 0
2019.10.29 13:09:17 4: PV_Anlage_1: GetUpdate will request Total_DC_Power
2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate tries to combine read commands
2019.10.29 13:09:17 5: PV_Anlage_1: GetUpdate doesn't sort objList before sending requests
2019.10.29 13:09:17 4: PV_Anlage_1: DoRequest called from GetUpdate created request: id 5, fCode 3, tid 77, type h, adr 100, len 2 for device PV_Anlage_1 reading Total_DC_Power (getUpdate), read buffer empty
2019.10.29 13:09:17 5: PV_Anlage_1: QueueRequest called from DoRequest (PV_Anlage_1) with h100, qlen 0
2019.10.29 13:09:17 4: PV_Anlage_1: ProcessRequestQueue called from QueueRequest, qlen 1, next entry to id 5 (PV_Anlage_1), last send to this device was 60.015 secs ago, last read never, last read on bus never from id 5 (PV_Anlage_1)
2019.10.29 13:09:17 5: PV_Anlage_1: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 13:08:17.028) for PV_Anlage_1, delay 59.919secs over
2019.10.29 13:09:17 4: PV_Anlage_1: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 004d00000006050300640002 request: id 5, fCode 3, tid 77, type h, adr 100, len 2 for device PV_Anlage_1 reading Total_DC_Power (getUpdate), queued 0.01 secs ago, read buffer empty
2019.10.29 13:09:17 5: SW: 004d00000006050300640002
2019.10.29 13:09:17 5: PV_Anlage_1: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2019.10.29 13:09:19 3: PV_Anlage_1: Timeout waiting for a modbus response request: id 5, fCode 3, tid 77, type h, adr 100, len 2 for device PV_Anlage_1 reading Total_DC_Power (getUpdate), queued 2.00 secs ago, sent 2.00 secs ago, read buffer empty
2019.10.29 13:09:19 5: PV_Anlage_1: DropFrame - drop
2019.10.29 13:09:19 5: PV_Anlage_1: StartQueueTimer called from ResponseTimeout removes internal timer because it is not needed now
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick