Neue Versionen und Support zum Modbus-Modul

kurt6908 · 25 Juni 2021, 11:23:50

Hallo,

ich brächte mal Unterstützung, bin am Verzweifeln ...

Ich will meinen EPEver UP3000-M6322 Inverter/Charger per Modbus/RS485 abfragen.

Als Modul verwende ich hier 98_ModbusEPEVER und natürlich diese Modbus-Modul hier.

Als ModBus-Device ist ein DSD Tech USB FTDI FT232RL Konverter im Einsatz.

Aktuell habe ich das Problem, dass keinerlei Werte ausgelesen werden, ich habe zwei Fehlerzustände vom Modbus-Modul:

* RS485 A/B auf USB-Adapter A/B:
Timeout waiting for a modbus response, read buffer empty

* RS485 A/B auf umgedreht auf USB-Adapter B/A:
Timeout waiting for a modbus response, current frame / read buffer: 00

Die Anfragen vom MasterDevice (98_ModbusEPEVER) kommen im Modbus-Modul an.

Adapter ist mit /dev/ttyUSB1@115200 definiert; 98_ModbusEPEVER mit 1 300 und Protokoll RTU

Ich vermute mal es liegt nicht am 98_ModBusEPEVER, sondern eher an einem Timeming-Problem (eventuell Baudrate?) meiner Konfiguration, so dass das Modbus-Modul nichts zurückliefert. Auch da ich im Netz unterschiedlich A/B-Belegungen gefunden habe, bringt mich bei der Lösungsfindung nicht weiter....

Kann mir jemand noch einen Tipp geben, wo der Fehler liegen könnte....

Vielen Dank.

Kurt

antonwinden · 25 Juni 2021, 12:34:58

Widerstand am Ende des Kabels zwischen A und B vorhanden?

kurt6908 · 25 Juni 2021, 20:23:13

Hallo antonwinden,

ZitatWiderstand am Ende des Kabels zwischen A und B vorhanden?

Nein, bei meinem Adapter gibt es nur Schraubanschlüsse für A/B. Ich habe mir nun noch einen Adapter gekauft, bei dem man einen Widerstand zwischen A und B bei Bedarf schalten kann.

Ich glaube ich habe nun alle A/B-Variationen durch. Der RJ45-Anschluss der RS485-Buchse hat

3+4 B
5+6 A
7+8 GND

Im Netz finde ich mindestens 4 verschiedene Variationen welchen Pin ich auf die A/B/GND-Anschlüsse am Adapter legen muss. Egal was ich belege, es kommt immer der TimeOut....

Kurt

beejayf · 26 Juni 2021, 21:25:21

Hallo zusammen,

ich bekomme nachdem ich nach Ewigkeiten mein FHEM mal neu gestartet habe folgende Fehlermeldung in meine Logfile:

Code Auswählen

Undefined subroutine &Modbus::InitializeLD called at ./FHEM/98_ModbusAttr.pm line 46.
Undefined subroutine &Modbus::InitializeLD called at ./FHEM/98_SolarEdge.pm line 779.

Da ich nicht weiß ob der Fehler von Modbus oder einem der beiden Module kommt habe ich das Problem hier und in ähnlicher Form in SorlarEdge Thread gepostet - hoffe das ist okay.

Danke im Voraus für Eure Hinweise!

BeeJayF

beejayf · 28 Juni 2021, 17:39:50

So - hab FHEM neu installiert und die fhem.conf wieder hergestellt, alle Module neu installiert - jetzt klappts

kurt6908 · 29 Juni 2021, 21:30:29

Hallo antonwinden,

vielen Dank für Deinen Hinweis.

Nach dem dritten Adapter (dem billigesten von allen) und der richtigen Kabelbelegung klappt nun die Kommunikation unter Windows und über Raspbian.

Gruß

Kurt

kurt6908 · 01 Juli 2021, 07:21:24

Hallo Stefan,

ich verwende Dein low level Modul mit dem Modul 98_ModbusEPEVER.

Ich verwende hierzu einen seriellen USB-Adapter und das RTU_Protokoll. Der Adapter funktioniert mit der herstellereigenen Sofware ohne Probleme.

Nun habe ich das Problem das im ModBusEPEVER nur drei Readings ausgelesen und angelegt werden.

Ein Verbose 5 auf Deinem Modul und auf ModbusEPEVER schaut bei einem get so aus:

Code Auswählen


2021.06.30 21:42:06 4: OffGridLoader: get called with BattVoltage (i13082)
2021.06.30 21:42:06 5: OffGridLoader: GetSetChecks with force
2021.06.30 21:42:06 5: OffGridLoader: GetSetChecks returns success
2021.06.30 21:42:06 4: OffGridLoader: DoRequest called from GetLDFn created new request, read buffer empty, 
request: id 1, read fc 4 i13082, len 1, master device OffGridLoader, reading BattVoltage (get BattVoltage)
2021.06.30 21:42:06 5: ModBusLine: QueueRequest called from DoRequest with i13082, qlen 0 from master OffGridLoader through io device ModBusLine
2021.06.30 21:42:06 5: ModBusLine: ProcessRequestQueue called from QueueRequest as direct:ModBusLine, qlen 1, force, request: request: id 1, read fc 4 i13082, len 1, master device OffGridLoader, reading BattVoltage (get BattVoltage), queued 0.00 secs ago
2021.06.30 21:42:06 5: ModBusLine: checkDelays clientSwitchDelay is not relevant
2021.06.30 21:42:06 5: ModBusLine: checkDelays commDelay, last communication with same device was 200.575 secs ago, required delay is 0.1
2021.06.30 21:42:06 5: ModBusLine: checkDelays sendDelay, last send to same device was 200.771 secs ago, required delay is 0.1
2021.06.30 21:42:06 5: ModBusLine: checkDelays busDelayRead, last activity on bus was 200.576 secs ago, required delay is 0
2021.06.30 21:42:06 4: ModBusLine: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 0104331a00011f49 via /dev/ttyUSB1@115200, read buffer empty, 
request: id 1, read fc 4 i13082, len 1, master device OffGridLoader, reading BattVoltage (get BattVoltage), queued 0.00 secs ago
2021.06.30 21:42:06 5: ModBusLine: Send called from ProcessRequestQueue
2021.06.30 21:42:06 5: SW: 0104331a00011f49
2021.06.30 21:42:06 5: ModBusLine: ReadAnswer called from GetLDFn
2021.06.30 21:42:06 5: ModBusLine: ReadAnswer remaining timeout is 1.99355697631836
2021.06.30 21:42:06 5: ModBusLine: ReadAnswer got: 018402c2c1
2021.06.30 21:42:06 5: ModBusLine: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2021.06.30 21:42:06 4: ModBusLine: ParseFrameStart (RTU, master) extracted id 1, fCode 132 and potential data 02
2021.06.30 21:42:06 5: ModBusLine: HandleResponse called from ReadAnswer
2021.06.30 21:42:06 5: ModBusLine: ParseResponse called from HandleResponse
2021.06.30 21:42:06 5: ModBusLine: CheckChecksum (called from ParseResponse): c2c1 is valid
2021.06.30 21:42:06 4: ModBusLine: HandleResponse got response with error code 84 / 02, illegal data address
2021.06.30 21:42:06 4: ModBusLine: HandleResponse done, current frame / read buffer: 018402c2c1, id 1, fCode 132, 
request: id 1, read fc 4 i13082, len 1, master device OffGridLoader, reading BattVoltage (get BattVoltage), queued 0.11 secs ago, sent 0.11 secs ago, 
response: id 1, fc 132, error code 02, len 1
2021.06.30 21:42:06 5: ModBusLine: ResetExpect for HandleResponse from response to idle
2021.06.30 21:42:06 5: ModBusLine: DropFrame called from ReadAnswer - drop 018402c2c1

Laut laserrichi liegt es wohl am RTU-Protokoll bzw. an Deinem Modul:

Zitat
Code:

2021.06.30 21:42:06 5: ModBusLine: ReadAnswer got: 018402c2c1
2021.06.30 21:42:06 5: ModBusLine: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2021.06.30 21:42:06 4: ModBusLine: ParseFrameStart (RTU, master) extracted id 1, fCode 132 and potential data 02
2021.06.30 21:42:06 5: ModBusLine: HandleResponse called from ReadAnswer
2021.06.30 21:42:06 5: ModBusLine: ParseResponse called from HandleResponse
2021.06.30 21:42:06 5: ModBusLine: CheckChecksum (called from ParseResponse): c2c1 is valid
2021.06.30 21:42:06 4: ModBusLine: HandleResponse got response with error code 84 / 02, illegal data address

also hier kommt etwas falsches zurück: 018402c2c1

01 = device ID ist Richtig
84 = function Code... das ist Falsch.... hier müsste eigentlich 04 stehen
02 = zwei bytes ist wohl auch Richtig
c2c1 ist auch nicht plausibel, das wären ja 498,57V bissl viel...

das ist eigentlich ein Fall für StefanStrobel... der kann dazu vieleicht mehr sagen.

Edit: habe gerade bei Modbus Spezifikationen gefunden das es wohl Function Code in Exception Response ist.

Kannst Du Dir dieses bitte mal anschauen, ich stehe für Tests und andere Log-Auszüge natürlich bereit...

Viele Grüße

Kurt

StefanStrobel · 01 Juli 2021, 18:59:21

Hallo Kurt,

die Kommunikation scheint sauber zu funktionieren, aber Dein Gerät antwortet auf die Anfrage für das Input-Register 13082 mit der Fehlermeldung dass diese Adresse nicht erlaubt ist. Hast Du denn eine Doku für das Gerät und steht da drin, dass diese Register-Nummer korrekt sein sollte?

Gruss
Stefan

kurt6908 · 01 Juli 2021, 20:14:19

Hallo Stefan,

es handelt sich um einen EPEver UPower Inverter.

Das Modul von laserrichi 98_ModbusEPEVER sollte diesen eigentlich unterstützen. Eine Modbus-Doku habe ich leider nicht, vielleicht laserrichi. Eventuell hat es bei den neuen UPower-Modellen eine Änderung geben, im Netz habe ich z.B. das gefunden:

https://stackoverflow.com/questions/63055446/issue-reading-modbus-registers-from-epever-upower-charger-inverter-using-pymod]https://stackoverflow.com/questions/63055446/issue-reading-modbus-registers-from-epever-upower-charger-inverter-using-pymod]https://stackoverflow.com/questions/63055446/issue-reading-modbus-registers-from-epever-upower-charger-inverter-using-pymod

Zitat
You need to change your Address from 0x3100 to 0x3500.

I decompiled the SolarStationSoftware and found out that they changed the Realtime Address to 13568.

Aber wenn ich Dich richtig verstehe, ist es doch eher ein Problem vom 98_ModbusEPEVER?

Ansonsten habe ich nur Dokus über die B-Serie gefunden:

https://www.developpez.net/forums/attachments/p196506d1451307310/systemes/autres-systemes/automation/probleme-com-modbus-pl7-pro/controllerprotocolv2.3.pdf

https://www.aggsoft.com/serial-data-logger/tutorials/modbus-data-logging/epever-b-series.htm]https://www.aggsoft.com/serial-data-logger/tutorials/modbus-data-logging/epever-b-series.htm]https://www.aggsoft.com/serial-data-logger/tutorials/modbus-data-logging/epever-b-series.htm

http%3A%2F%2Fwww.solar-elektro.cz%2Fdata%2Fdokumenty%2F1733_modbus_protocol.pdf&usg=AOvVaw2l5P3iHoscUNM1t4jzkCSc]http://http%3A%2F%2Fwww.solar-elektro.cz%2Fdata%2Fdokumenty%2F1733_modbus_protocol.pdf&usg=AOvVaw2l5P3iHoscUNM1t4jzkCSc]http%3A%2F%2Fwww.solar-elektro.cz%2Fdata%2Fdokumenty%2F1733_modbus_protocol.pdf&usg=AOvVaw2l5P3iHoscUNM1t4jzkCSc

Gruß

Kurt

laserrichi · 01 Juli 2021, 21:08:06

ah ok jetzt habe ich es auch verstanden, Stefan hat recht, die Exception kommt wenn die Anfrage falsch ist.
Scheinbar hat die Upower Serie andere Abfragen....
Ich habe mal die Doku angefordert, mal sehen was da dann kommt dann wissen wir wohl mehr.

kurt6908 · 01 Juli 2021, 21:25:01

WOW .... Super, danke Euch !!!

Gruß

Kurt

RaKoHe · 07 Juli 2021, 09:14:50

Moin aus dem sonnigen Norden,

Ich möchte meinen Dupline Kanalgenerator DKG20 von der Firma Doepke per Modbus RTU auszulesen.

Ausgelesen wird mit ModbusAttr und einem USB to Serial.

Es werden auch die aktuellen Zustände(0000/0001) gelesen, nur wird dann immer mit unpack "a" aus dem 0001=
ParseObj unpacked 30 with a to 0 hex 30
gemacht.
Wo kommt diese 30 her?

Es ist egal was ich als unpack definiere,hier versuchsweise C
Ich habe auch schon map ohne Erfolg probiert, was aber letzlich das Ziel ist.
0000=Aus 0001=Ein

Anbei die Modbus Beschreibung von Doepke. siehe 3.3.2 auf Seite 15

https://www.doepke.de/uploads/tx_doepkeproducts/bedienungsanleitung/web/doepke_dupline_modbus_man_de.pdf

Vielen Dank für eure Hilfe

P.S.: Das Dupline System entspricht vermutlich dem Carlo Gavazzi Fieldbus.

Code Auswählen

defmod DUPATTR ModbusAttr 5 15 /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0@57600,8,N,1
attr DUPATTR userattr dev-d-defPoll dev-d-defUnpack dev-d-read obj-d1584-reading
attr DUPATTR dev-d-defPoll 1
attr DUPATTR dev-d-defUnpack C
attr DUPATTR dev-d-read 02
attr DUPATTR obj-d1584-reading Schreibtischlampeneu
attr DUPATTR room Heizung
attr DUPATTR verbose 5

setstate DUPATTR opened
setstate DUPATTR 2021-06-30 12:18:48 Schreibtischlampe 0
setstate DUPATTR 2021-06-30 14:02:31 Schreibtischlampeneu 0
setstate DUPATTR 2021-06-30 14:02:48 state opened

Code Auswählen

2021.06.30 14:17:40 4: DUPATTR: ResponseDone request: id 5, fCode 02, type d, adr 1584, len 1 for device DUPATTR reading Schreibtischlampeneu (getUpdate), queued 0.02 secs ago, sent 0.02 secs ago, Current read buffer: 050202000189b8, Id 5, fCode 2, response: id 5, fCode 2, type d, adr 1584, len 1, value 0001
2021.06.30 14:17:40 5: DUPATTR: HandleResponse got 1 readings from ParseObj for DUPATTR
2021.06.30 14:17:40 4: DUPATTR: ParseObj assigns value 0 to Schreibtischlampeneu
2021.06.30 14:17:40 5: DUPATTR: ParseObj unpacked 30 with a to 0 hex 30
2021.06.30 14:17:40 5: DUPATTR: ParseObj ObjInfo for d1584: reading=Schreibtischlampeneu, unpack=a, expr=, format=, map=
2021.06.30 14:17:40 5: DUPATTR: ParseObj shortened coil / input bit string: 0, start adr 1584, valuesLen 1
2021.06.30 14:17:40 5: DUPATTR: ParseObj called with data 0001, type d, adr 1584, valuesLen 1, op read
2021.06.30 14:17:40 5: DUPATTR: HandleResponse now passing to logical device DUPATTR for parsing data
2021.06.30 14:17:40 5: DUPATTR: CheckChecksum (called from HandleResponse): 89b8 is valid
2021.06.30 14:17:40 5: DUPATTR: ParseResponse called from HandleResponse
2021.06.30 14:17:40 5: DUPATTR: HandleResponse called from Read
2021.06.30 14:17:40 4: DUPATTR: ParseFrameStart (RTU) extracted id 5, fCode 2 and data 020001
2021.06.30 14:17:40 5: DUPATTR: read buffer: 050202000189b8
2021.06.30 14:17:40 5: DUPATTR: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2021.06.30 14:17:40 5: SW: 050206300001b8c9
2021.06.30 14:17:40 4: DUPATTR: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 050206300001b8c9 request: id 5, fCode 02, type d, adr 1584, len 1 for device DUPATTR reading Schreibtischlampeneu (getUpdate)

Vielen Dank

Ralf

laserrichi · 07 Juli 2021, 19:45:53

also a wäre ja hier falsch, das ist : A string with arbitrary binary data, will be null padded

deine Antwort mal zerlegt die du bekommst:

050202000189b8
05 Device ID
02 Function Code
02 zwei Bytes bingo....
00 01 das ist dein wert
Mit C machst du daraus: An unsigned char (octet) value

ich würde Vorschlagen nimm mal defunpack S
dann sollte es richtig sein

StefanStrobel · 07 Juli 2021, 22:01:41

Hallo Ralf,

Zunächst solltest Du Fhem aktualisieren. Du scheinst ein sehr altes Modul zu verwenden. In der aktuellen Version kommen andere Meldungen und einige Bugs sind behoben.

Für coils und digital inputs verwendet das Modbus-Modul eine spezielle Behandlung, da die Daten immer 0/1 sind und als Folge einzelner Bits gelesen werden. Die werden intern als String von 0/1-Zeichen verarbeitet.

Insbesondere solltest Du gar keinen unpack-Code vorgeben. Der würde bei digital inputs und coils eh ignoriert.
Ebenso kannst Du das Attribut für den function code 2 weglassen. Das ist der Default.

Probier es doch nochmal mit der aktuelle Version und einer vereinfachten Konfiguration und poste dann einen Ausschnitt aus dem Log.

Gruss
Stefan

RaKoHe · 08 Juli 2021, 11:32:26

Moin,

danke Laserrichi und Stefan.

Da das Update und weniger Attr kein Erfolg gebracht hat habe ich FHEM auf dem just eingetroffenen pi4 mit einer neuen Karte installiert.
Dann nur DUPATTR definiert.
Leider ohne Erfolg.

Code Auswählen

defmod DUPATTR ModbusAttr 5 15 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0@57600,8,N,1
attr DUPATTR dev-d-defPoll 1
attr DUPATTR obj-d1584-reading Schreibtischlampeneu
attr DUPATTR room Heizung
attr DUPATTR verbose 2

setstate DUPATTR opened
setstate DUPATTR 2021-07-08 11:26:25 Schreibtischlampeneu 0
setstate DUPATTR 2021-07-08 11:19:48 state opened

Code Auswählen

2021.07.08 11:16:51 4: DUPATTR: GetUpdate (V4.4.02 - 31.3.2021) called from Fhem internal timer
2021.07.08 11:16:51 4: DUPATTR: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 15.0 sec at 11:17:06.333, interval 15
2021.07.08 11:16:51 5: DUPATTR: CreateUpdateList full object list: d1584
2021.07.08 11:16:51 5: DUPATTR: CreateUpdateList will request d1584 len 1 Schreibtischlampeneu
2021.07.08 11:16:51 4: DUPATTR: CombineUpdateHash objHash keys before combine: d1584
2021.07.08 11:16:51 5: DUPATTR: CombineUpdateHash tries to combine read commands
2021.07.08 11:16:51 5: DUPATTR: CombineUpdateHash keys are now d1584
2021.07.08 11:16:51 4: DUPATTR: GetUpdate will now create requests for d1584 len 1 (Schreibtischlampeneu)
2021.07.08 11:16:51 4: DUPATTR: DoRequest called from GetUpdate created new request, read buffer empty, 
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1)
2021.07.08 11:16:51 5: DUPATTR: QueueRequest called from DoRequest with d1584, qlen 0 from master DUPATTR through io device DUPATTR
2021.07.08 11:16:51 5: DUPATTR: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2021.07.08 11:16:51 5: DUPATTR: ProcessRequestQueue called from Fhem internal timer as queue:DUPATTR, qlen 1, request: request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.00 secs ago
2021.07.08 11:16:51 5: DUPATTR: checkDelays commDelay, last communication with same device was 14.992 secs ago, required delay is 0.1
2021.07.08 11:16:51 5: DUPATTR: checkDelays busDelayRead, last activity on bus was 14.992 secs ago, required delay is 0
2021.07.08 11:16:51 5: DUPATTR: checkDelays sendDelay, last send to same device was 14.999 secs ago, required delay is 0.1
2021.07.08 11:16:51 5: DUPATTR: checkDelays clientSwitchDelay is not relevant
2021.07.08 11:16:51 4: DUPATTR: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 050206300001b8c9 via /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0@57600,8,N,1, read buffer empty, 
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.00 secs ago
2021.07.08 11:16:51 5: DUPATTR: Send called from ProcessRequestQueue
2021.07.08 11:16:51 5: SW: 050206300001b8c9
2021.07.08 11:16:51 5: DUPATTR: readFn buffer: 050202000189b8
2021.07.08 11:16:51 5: DUPATTR: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2021.07.08 11:16:51 4: DUPATTR: ParseFrameStart (RTU, master) extracted id 5, fCode 2 and potential data 020001
2021.07.08 11:16:51 5: DUPATTR: HandleResponse called from ReadFn
2021.07.08 11:16:51 5: DUPATTR: ParseResponse called from HandleResponse
2021.07.08 11:16:51 5: DUPATTR: CheckChecksum (called from ParseResponse): 89b8 is valid
2021.07.08 11:16:51 5: DUPATTR: now parsing response data objects, master is DUPATTR relay is undefined
2021.07.08 11:16:51 5: DUPATTR: ParseDataString called from HandleResponse with data hex 0001, type d, adr 1584, op read
2021.07.08 11:16:51 5: DUPATTR: SplitDataString called from ParseDataString with data hex 0001, type d, adr 1584, valuesLen 1, op read
2021.07.08 11:16:51 5: DUPATTR: SplitDataString shortened coil / input bit string to 0, start adr 1584, valuesLen 1
2021.07.08 11:16:51 5: DUPATTR: CreateDataObjects called from ParseDataString with objList d1584
2021.07.08 11:16:51 5: DUPATTR: CreateDataObjects sortedList d1584
2021.07.08 11:16:51 5: DUPATTR: CreateDataObjects unpacked 30 with a to 0
2021.07.08 11:16:51 4: DUPATTR: CreateDataObjects assigns value 0 to Schreibtischlampeneu
2021.07.08 11:16:51 5: DUPATTR: ParseDataString created 1 readings
2021.07.08 11:16:51 4: DUPATTR: HandleResponse done, current frame / read buffer: 050202000189b8, id 5, fCode 2, 
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.02 secs ago, sent 0.02 secs ago, 
response: id 5, fc 2, d1584, len 1, values 0001
2021.07.08 11:16:51 5: DUPATTR: ResetExpect for HandleResponse from response to idle
2021.07.08 11:16:51 5: DUPATTR: DropFrame called from ReadFn - drop 050202000189b8
2021.07.08 11:17:06 4: DUPATTR: GetUpdate (V4.4.02 - 31.3.2021) called from Fhem internal timer
2021.07.08 11:17:06 4: DUPATTR: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 15.0 sec at 11:17:21.336, interval 15
2021.07.08 11:17:06 5: DUPATTR: CreateUpdateList full object list: d1584
2021.07.08 11:17:06 5: DUPATTR: CreateUpdateList will request d1584 len 1 Schreibtischlampeneu
2021.07.08 11:17:06 4: DUPATTR: CombineUpdateHash objHash keys before combine: d1584
2021.07.08 11:17:06 5: DUPATTR: CombineUpdateHash tries to combine read commands
2021.07.08 11:17:06 5: DUPATTR: CombineUpdateHash keys are now d1584
2021.07.08 11:17:06 4: DUPATTR: GetUpdate will now create requests for d1584 len 1 (Schreibtischlampeneu)
2021.07.08 11:17:06 4: DUPATTR: DoRequest called from GetUpdate created new request, read buffer empty, 
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1)
2021.07.08 11:17:06 5: DUPATTR: QueueRequest called from DoRequest with d1584, qlen 0 from master DUPATTR through io device DUPATTR
2021.07.08 11:17:06 5: DUPATTR: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2021.07.08 11:17:06 5: DUPATTR: ProcessRequestQueue called from Fhem internal timer as queue:DUPATTR, qlen 1, request: request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.00 secs ago
2021.07.08 11:17:06 5: DUPATTR: checkDelays sendDelay, last send to same device was 15.003 secs ago, required delay is 0.1
2021.07.08 11:17:06 5: DUPATTR: checkDelays clientSwitchDelay is not relevant
2021.07.08 11:17:06 5: DUPATTR: checkDelays commDelay, last communication with same device was 14.997 secs ago, required delay is 0.1
2021.07.08 11:17:06 5: DUPATTR: checkDelays busDelayRead, last activity on bus was 14.997 secs ago, required delay is 0
2021.07.08 11:17:06 4: DUPATTR: ProcessRequestQueue (V4.4.02 - 31.3.2021) qlen 1, sending 050206300001b8c9 via /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0@57600,8,N,1, read buffer empty, 
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.00 secs ago
2021.07.08 11:17:06 5: DUPATTR: Send called from ProcessRequestQueue
2021.07.08 11:17:06 5: SW: 050206300001b8c9
2021.07.08 11:17:06 5: DUPATTR: readFn buffer: 050202000189b8
2021.07.08 11:17:06 5: DUPATTR: ParseFrameStart called from ReadFn protocol RTU expecting id 5
2021.07.08 11:17:06 4: DUPATTR: ParseFrameStart (RTU, master) extracted id 5, fCode 2 and potential data 020001
2021.07.08 11:17:06 5: DUPATTR: HandleResponse called from ReadFn
2021.07.08 11:17:06 5: DUPATTR: ParseResponse called from HandleResponse
2021.07.08 11:17:06 5: DUPATTR: CheckChecksum (called from ParseResponse): 89b8 is valid
2021.07.08 11:17:06 5: DUPATTR: now parsing response data objects, master is DUPATTR relay is undefined
2021.07.08 11:17:06 5: DUPATTR: ParseDataString called from HandleResponse with data hex 0001, type d, adr 1584, op read
2021.07.08 11:17:06 5: DUPATTR: SplitDataString called from ParseDataString with data hex 0001, type d, adr 1584, valuesLen 1, op read
2021.07.08 11:17:06 5: DUPATTR: SplitDataString shortened coil / input bit string to 0, start adr 1584, valuesLen 1
2021.07.08 11:17:06 5: DUPATTR: CreateDataObjects called from ParseDataString with objList d1584
2021.07.08 11:17:06 5: DUPATTR: CreateDataObjects sortedList d1584
2021.07.08 11:17:06 5: DUPATTR: CreateDataObjects unpacked 30 with a to 0
2021.07.08 11:17:06 4: DUPATTR: CreateDataObjects assigns value 0 to Schreibtischlampeneu
2021.07.08 11:17:06 5: DUPATTR: ParseDataString created 1 readings
2021.07.08 11:17:06 4: DUPATTR: HandleResponse done, current frame / read buffer: 050202000189b8, id 5, fCode 2, 
request: id 5, read fc 2 d1584, len 1, master device DUPATTR, reading Schreibtischlampeneu (getUpdate for Schreibtischlampeneu len 1), queued 0.02 secs ago, sent 0.02 secs ago, 
response: id 5, fc 2, d1584, len 1, values 0001
2021.07.08 11:17:06 5: DUPATTR: ResetExpect for HandleResponse from response to idle

Noch eine Idee??

Vielen Dank

Mit sonnigen Grüßen

Ralf