Neue Versionen und Support zum Modbus-Modul

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

Vorheriges Thema - Nächstes Thema

ChristianA

Hallo,

meine Vermutung scheint sich zu bestätigen. Seit dem Tausch des USB-Seriell Adapters ist die Verbindung seit 16 Stunden stabil.

Zitat von: ChristianA am 09 Dezember 2022, 21:16:41
seit einigen Tagen läuft bei mir die Modbus Verbindung nicht mehr stabil. Nach einem Neustart funktioniert es für 1-2 Stunden, dann können keine Werte mehr gelesen werden. Im Logfile bekomme ich folgende Meldungen


2022.12.09 20:33:50 3: PMR09: Timeout waiting for a modbus response, read buffer empty,


Auf Grund der Logmeldung habe ich den USB Port mit Wireshark mitgeschnitten. Damit war dann klar, die fehlende Antwort kam dort schon nicht durch.

Vielen Dank und schöne Weihnachten
Christian

Kulli

#1066
Hallo Stefan

Gibt es im Modbus Modul eine Möglichkeit, das Timeouts als Events gemeldet werden?
Bei mir scheint durch Blitz ein Modbusmodul hops gegangen zu sein und ich habe es nicht mitbekommen.
Aktuell sehe ich nur die Möglichkeit, den Loglevel auf 3 zu setzen um die Meldungen im Log zu sehen, da kann ich aber nicht darauf reagieren :-)

LG
Uwe

Ergänzung:
Der MAX485 ist gestorben. Ich habe am gleichen Bus 3 andere Slaves hängen mit dem LTC485, die haben alle überlebt.
Also ich muss mir etwas bzgl. Schirmung und Erdung überlegen.
Nichtsdestotrotz: Wie kann ich notifies triggern wenn Timeouts auftreten?

mani

#1067
Hallo,

ich habe von Waveshare das 2-CH-Rs485-Can-HAT gekauft und lt. Anleitung aktiviert. Nun habe ich die zwei neuen Schnittstellen  /dev/ttySC0 und /dev/ttySC1 aber wenn ich auf sie zugreifen möchte mit Modbusmodul bekomme ich nur die Fehlermeldung =>


2023.01.03 18:59:14 3 : modbus: Timeout waiting for a modbus response, read buffer empty,
request: id 1, read fc 4 i0, len 17, master device WS, reading raw (getUpdate for raw len 17), queued 9.01 secs ago, sent 2.00 secs ago
[/s]

Läuft war doch noch ein rechte Problem..... ::)

Mfg Mani
RasPi B+,Onkyo_AVR,Luxtronik2,Logo7,Mpd,Arduino Uno mit Ethernet,KNX,Jablotron

Roger

Zitat von: Kulli am 03 Januar 2023, 14:58:44
Hallo Stefan
Gibt es im Modbus Modul eine Möglichkeit, das Timeouts als Events gemeldet werden?
Bei mir scheint durch Blitz ein Modbusmodul hops gegangen zu sein und ich habe es nicht mitbekommen.
Aktuell sehe ich nur die Möglichkeit, den Loglevel auf 3 zu setzen um die Meldungen im Log zu sehen, da kann ich aber nicht darauf reagieren :-)
LG Uwe

Hi Stefan,
daran hätte ich auch Interesse. Wenn bei meinem Modulen keine Spannung anliegt, so werden keine Daten gesendet (timeout). Wäre schön, wenn man für diesen Zustand eine Möglichkeit hätte einen speziellen Wert zu setzen (n/a, 0, ...).

//Roger
Zotac, BBB, RPIs mit 10*FHEM
2*HM-LAN, 2*JeeLink, 2*RS485, SignalESP
HomeMatic, PCA301 Komponenten, ModBus: Stromzähler, Fronius WR, Shelly

Roger

Zitat von: Roger am 18 Dezember 2022, 11:28:42
Hi Stefan,
in diese Richtung gingen auch meine Überlegungen.  :)
So ein sendRaw ist in Modbus als IO besser aufgehoben. Dann aber als wirkliches RAW (ohne Modbus-ID, aber schon mit CRC?).
Dort könnten dann ev. nicht zuordenbare Empfänge (z.B. C1, C2) in Readings abgelegt werden.
Das sendFC wie bisher in ModbusAttr mit den Empfangs-Readings ResponseFC-xx.
Was hältst Du davon? Soll ja für viele User nutzbar sein und Mehrwert bringen (z.B. zum testen/probieren).
//Roger

Hi Stefan,
ich wollte mal nachfragen wie Du zu der Änderung stehst? Ist die Idee zu aufwändig? Schafft es so eine Änderung ins offizielle Modul?

//Roger
Zotac, BBB, RPIs mit 10*FHEM
2*HM-LAN, 2*JeeLink, 2*RS485, SignalESP
HomeMatic, PCA301 Komponenten, ModBus: Stromzähler, Fronius WR, Shelly

StefanStrobel

Hallo Roger,

klingt durchaus sinnvoll. Ich bin nur leider noch nicht dazu gekommen an dem Thema weiter zu machen.
Auch die Events im Fall von Timeouts werde ich einbauen.
Könnte aber noch ein paar Tage oder sogar Wochen dauern.

Gruss
   Stefan

Tomk

#1071
Hallo,

unterstützt das Modul auch "Preset Single Register (FC=06)"?
Falls nein, kann man das irgendwie manuell schreiben?

In der Beschreibung ist nur die Rede von folgenden function codes:
holding registers (16 bit objects that can be read and written)
input registers (16 bit objects that can only be read)
coils (single bit objects that can be read and written)
discrete inputs (single bit objects that can only be read)


Danke vorab!

Hab's selbst kapiert: 06 sollte Holding Write sein, richtig?

StefanStrobel

Korrekt. FC6 schreibt ein Holding Register und wird ebenso wie FC16 zum Schreiben mehrerer Holding Register unterstützt.

Gruß
    Stefan

Tomk

Danke Stefan für die Bestätigung.

Ich habe noch 2 Fragen zu dem Modul auch wenn ich es schon längere Zeit nutze...

1. ich würde gerne einen Wert in ein Holding Register schreiben und benutze folgende Definition (Master Mode):
attr Qcells obj-h97-allowWrite 1
attr Qcells obj-h97-len 1
attr Qcells obj-h97-poll 0
attr Qcells obj-h97-reading QC_WriteSelfUseMinBatSoC


Für QC_WriteSelfUseMinBatSoC habe ich ein Dummy angelegt. Wie kann ich den Schreibvorgang triggern? Reicht ein ändern des Wertes im dummy, oder muss ich sonst noch was machen?

2. Für ein anderes Reading muss ich ein Byte des int Wertes ausmaskieren, wie kann ich das realisieren? Im unpack Attribute, oder gibt es hierfür noch eine andere Möglichkeit?

Besten Dank vorab!



StefanStrobel

Hallo Tomk,

zum Schreiben musst Du einen set-Befehl verwenden.

attr Qcells obj-h97-reading MeinWert
attr Qcells obj-h97-set 1


dann mit
set Qcells MeinWert 123
zum Manipulieren / Maskieren des Wertes würde ich eine setexpr verwenden.

Gruss
   Stefan

Tomk

So ganz klappt es mit dem Schreiben bei mir noch nicht... Bekomme scheinbar keine Antwort. Lesen von Werten funktioniert...

Kann man am Log was verdächtiges erkennen:
2023.01.28 06:16:22 4: Qcells: set called with QC_WriteSelfUseMinBatSoC (h97) setVal = 28
2023.01.28 06:16:22 5: Qcells: GetSetChecks with force
2023.01.28 06:16:22 5: Qcells: GetSetChecks returns success
2023.01.28 06:16:22 5: Qcells: set packed hex 3238 with n to hex 001c
2023.01.28 06:16:22 4: Qcells: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, write fc 6 h97, len 1, value 001c, master device Qcells, reading QC_WriteSelfUseMinBatSoC (set QC_WriteSelfUseMinBatSoC)
2023.01.28 06:16:22 5: Qcells: ParseDataString called from HandleResponse with data hex 001c, type h, adr 97, op write
2023.01.28 06:16:22 5: Qcells: SplitDataString called from ParseDataString with data hex 001c, type h, adr 97, valuesLen 1, op write
2023.01.28 06:16:22 5: Qcells: CreateDataObjects called from ParseDataString with objList h97
2023.01.28 06:16:22 5: Qcells: CreateDataObjects sortedList h97
2023.01.28 06:16:22 5: Qcells: CreateParseInfoCache called
2023.01.28 06:16:22 5: Qcells: CreateDataObjects unpacked 001c with n to 28
2023.01.28 06:16:22 4: Qcells: CreateDataObjects assigns value 28 to QC_WriteSelfUseMinBatSoC
2023-01-28 06:16:22 ModbusAttr Qcells QC_WriteSelfUseMinBatSoC: 28
2023.01.28 06:16:22 5: Qcells: ParseDataString created 1 readings
2023.01.28 06:16:22 4: Qcells: GetUpdate (V4.4.13 - 4.12.2022) called from Fhem internal timer
2023.01.28 06:16:22 4: Qcells: UpdateTimer called from GetUpdate with cmd next sets timer to call update function in 2.0 sec at 06:16:24.890, interval 2

StefanStrobel

Hallo Tomk,

leider fehlen im Log ein paar Details. Vermutlich geht dein Qcells-Device über ein serielles IO-Device. Das müsstest Du auch auf verbose 5 setzen.

Gruss
   Stefan

Tomk

Hallo Stefan,

danke für den Hinweis. Hätte ich auch drauf kommen können...

Hier sollte alles drin sein:
2023.01.29 21:23:45 4: Qcells: set called with QC_WriteSelfUseMinBatSoC (h97) setVal = 28
2023.01.29 21:23:45 5: Qcells: GetSetChecks with force
2023.01.29 21:23:45 4: Qcells: GetSetChecks calls ReadAnswer to take over async read, still waiting for response, read buffer empty,
request: id 1, read fc 3 h139, len 1, master device Qcells, reading QC_Mode (getUpdate for QC_Mode len 1), queued 6.54 secs ago, sent 0.01 secs ago
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer called from GetSetChecks
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer remaining timeout is 1.98934698104858
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer got: 0103020000b844
2023.01.29 21:23:45 5: QCellsModbus: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.01.29 21:23:45 4: QCellsModbus: ParseFrameStart (RTU, master) extracted id 1, fCode 3 and potential data 020000
2023.01.29 21:23:45 5: QCellsModbus: HandleResponse called from ReadAnswer
2023.01.29 21:23:45 5: QCellsModbus: ParseResponse called from HandleResponse
2023.01.29 21:23:45 5: QCellsModbus: CheckChecksum (called from ParseResponse): b844 is valid
2023.01.29 21:23:45 5: QCellsModbus: now parsing response data objects, master is Qcells relay is undefined
2023.01.29 21:23:45 5: Qcells: ParseDataString called from HandleResponse with data hex 0000, type h, adr 139, op read
2023.01.29 21:23:45 5: Qcells: SplitDataString called from ParseDataString with data hex 0000, type h, adr 139, valuesLen 1, op read
2023.01.29 21:23:45 5: Qcells: CreateDataObjects called from ParseDataString with objList h139
2023.01.29 21:23:45 5: Qcells: CreateDataObjects sortedList h139
2023.01.29 21:23:45 5: Qcells: CreateParseInfoCache called
2023.01.29 21:23:45 5: Qcells: CreateDataObjects unpacked 0000 with n to 0
2023.01.29 21:23:45 4: Qcells: CreateDataObjects assigns value 0 to QC_Mode
2023.01.29 21:23:45 5: Qcells: ParseDataString created 1 readings
2023.01.29 21:23:45 4: QCellsModbus: HandleResponse done, current frame / read buffer: 0103020000b844, id 1, fCode 3,
request: id 1, read fc 3 h139, len 1, master device Qcells, reading QC_Mode (getUpdate for QC_Mode len 1), queued 6.56 secs ago, sent 0.02 secs ago,
response: id 1, fc 3, h139, len 1, values 0000
2023.01.29 21:23:45 5: QCellsModbus: ResetExpect for HandleResponse from response to idle
2023.01.29 21:23:45 5: QCellsModbus: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2023.01.29 21:23:45 5: QCellsModbus: DropFrame called from ReadAnswer - drop 0103020000b844
2023.01.29 21:23:45 5: Qcells: GetSetChecks returns success
2023.01.29 21:23:45 5: Qcells: set packed hex 3238 with n to hex 001c
2023.01.29 21:23:45 4: Qcells: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, write fc 6 h97, len 1, value 001c, master device Qcells, reading QC_WriteSelfUseMinBatSoC (set QC_WriteSelfUseMinBatSoC)
2023.01.29 21:23:45 5: QCellsModbus: QueueRequest called from DoRequest with h97, qlen 30 from master Qcells through io device QCellsModbus
2023.01.29 21:23:45 5: QCellsModbus: ProcessRequestQueue called from QueueRequest as direct:QCellsModbus, qlen 31, force, request: request: id 1, write fc 6 h97, len 1, value 001c, master device Qcells, reading QC_WriteSelfUseMinBatSoC (set QC_WriteSelfUseMinBatSoC), queued 0.00 secs ago
2023.01.29 21:23:45 5: QCellsModbus: checkDelays clientSwitchDelay is not relevant
2023.01.29 21:23:45 5: QCellsModbus: checkDelays commDelay, last communication with same device was 0.026 secs ago, required delay is 0.1
2023.01.29 21:23:45 5: QCellsModbus: checkDelays sendDelay, last send to same device was 0.037 secs ago, required delay is 0.1
2023.01.29 21:23:45 5: QCellsModbus: checkDelays busDelayRead, last activity on bus was 0.027 secs ago, required delay is 0
2023.01.29 21:23:45 4: QCellsModbus: checkDelays found commDelay not over, sleep for 0.074 forced
2023.01.29 21:23:45 4: QCellsModbus: checkDelays sleep done, go on with sending
2023.01.29 21:23:45 4: QCellsModbus: ProcessRequestQueue (V4.4.13 - 4.12.2022) qlen 31, sending 01060061001cd9dd via /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@19200,8,E,1, read buffer empty,
request: id 1, write fc 6 h97, len 1, value 001c, master device Qcells, reading QC_WriteSelfUseMinBatSoC (set QC_WriteSelfUseMinBatSoC), queued 0.08 secs ago,
response: no id, no fcode
2023.01.29 21:23:45 5: QCellsModbus: Send called from ProcessRequestQueue
2023.01.29 21:23:45 5: DevIo_SimpleWrite QCellsModbus: 01060061001cd9dd
2023.01.29 21:23:45 5: QCellsModbus: StartQueueTimer called from ProcessRequestQueue sets internal timer to process queue in 1.000 seconds
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer called from SetLDFn
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer remaining timeout is 1.90582013130188
2023.01.29 21:23:45 5: QCellsModbus: ReadAnswer got: 01060061001cd9dd
2023.01.29 21:23:45 5: QCellsModbus: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.01.29 21:23:45 4: QCellsModbus: ParseFrameStart (RTU, master) extracted id 1, fCode 6 and potential data 0061001c
2023.01.29 21:23:45 5: QCellsModbus: HandleResponse called from ReadAnswer
2023.01.29 21:23:45 5: QCellsModbus: ParseResponse called from HandleResponse
2023.01.29 21:23:45 5: QCellsModbus: CheckChecksum (called from ParseResponse): d9dd is valid
2023.01.29 21:23:45 5: QCellsModbus: now parsing response data objects, master is Qcells relay is undefined
2023.01.29 21:23:45 5: Qcells: ParseDataString called from HandleResponse with data hex 001c, type h, adr 97, op write
2023.01.29 21:23:45 5: Qcells: SplitDataString called from ParseDataString with data hex 001c, type h, adr 97, valuesLen 1, op write
2023.01.29 21:23:45 5: Qcells: CreateDataObjects called from ParseDataString with objList h97
2023.01.29 21:23:45 5: Qcells: CreateDataObjects sortedList h97
2023.01.29 21:23:45 5: Qcells: CreateParseInfoCache called
2023.01.29 21:23:45 5: Qcells: CreateDataObjects unpacked 001c with n to 28
2023.01.29 21:23:45 4: Qcells: CreateDataObjects assigns value 28 to QC_WriteSelfUseMinBatSoC
2023-01-29 21:23:45 ModbusAttr Qcells QC_WriteSelfUseMinBatSoC: 28
2023.01.29 21:23:45 5: Qcells: ParseDataString created 1 readings
2023.01.29 21:23:45 4: QCellsModbus: HandleResponse done, current frame / read buffer: 01060061001cd9dd, id 1, fCode 6,
request: id 1, write fc 6 h97, len 1, value 001c, master device Qcells, reading QC_WriteSelfUseMinBatSoC (set QC_WriteSelfUseMinBatSoC), queued 0.13 secs ago, sent 0.13 secs ago,
response: id 1, fc 6, h97, len 1, values 001c
2023.01.29 21:23:45 5: QCellsModbus: ResetExpect for HandleResponse from response to idle
2023.01.29 21:23:45 5: QCellsModbus: StartQueueTimer called from HandleResponse sets internal timer to process queue in 0.000 seconds
2023.01.29 21:23:45 5: QCellsModbus: DropFrame called from ReadAnswer - drop 01060061001cd9dd


Ich habe noch einige andere zyklische Abfragen welche hier in die Quere gekommen sind, glaube ich.

Moment... es geht... konnte gerade in der App des Wechselrichter sehen das die 28% angenommen wurden... keine Ahnung warum das gestern nicht geklappt hat.

Super, danke dir trotzdem!

yoda_gh

Hallo zusammen!

Ich habe FHEM am 23.01. seit längerem (genauer: seit 02.10.22) wieder mal aktualisiert und jetzt werden einige Werte von meinem Fronius Gen24 nicht mehr gelesen. Ulkigerweise betrifft es nur einen Teil der Werte und mir fehlt komplett die Idee, woran es liegen kann.

Beispiel 1:


attr gen24 obj-h40267-format %d
attr gen24 obj-h40267-group 1-1
attr gen24 obj-h40267-len 1
attr gen24 obj-h40267-reading DCPowerScale
attr gen24 obj-h40267-unpack s>
attr gen24 obj-h40284-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr gen24 obj-h40284-group 1-2
attr gen24 obj-h40284-len 1
attr gen24 obj-h40284-reading DCPowerMPPT1
attr gen24 obj-h40284-unpack n
attr gen24 obj-h40304-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr gen24 obj-h40304-group 1-3
attr gen24 obj-h40304-len 1
attr gen24 obj-h40304-reading DCPowerMPPT2
attr gen24 obj-h40304-unpack n
attr gen24 obj-h40324-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr gen24 obj-h40324-group 1-4
attr gen24 obj-h40324-len 1
attr gen24 obj-h40324-reading BatteryChargeWatt
attr gen24 obj-h40324-unpack n
attr gen24 obj-h40344-expr $val * 10 ** ReadingsVal($name, 'DCPowerScale', 1)
attr gen24 obj-h40344-group 1-5
attr gen24 obj-h40344-len 1
attr gen24 obj-h40344-reading BatteryDischargeWatt
attr gen24 obj-h40344-unpack n


Hier funktionieren DCPowerScale und DCPowerMPPT1 einwandfrei, während die folgenden Werte DCPowerMPPT2, BatteryChargeWatt und BatteryDischargeWatt bei einem "set gen24 reread" nicht mehr aktualisiert werden.

Im Log sieht das dann so aus:


2023.01.29 20:42:14 4 : gen24: ProcessRequestQueue (V4.4.13 - 4.12.2022) qlen 1, sending 00db0000000601039d4b0064 via 192.168.YY.XX:502, read buffer empty,
request: id 1, read fc 3 h40267, len 100, tid 219, master device gen24, reading DCPowerScale (getUpdate for combined g1 len 78 (h40267 len 1 DCPowerScale and h40284 len 1 DCPowerMPPT1 and h40304 len 1 DCPowerMPPT2 and h40324 len 1 BatteryChargeWatt and h40344 len 1 BatteryDischargeWatt) with h40355 len 1 BatConfigMaxReferenceWatt and h40358 len 1 BatConfigMaxEnabled and h40360 len 1 BatConfigReserve and h40361 len 1 BatteryChargePercent and h40364 len 1 BatteryState and h40365 len 1 BatConfigMaxDischargeWatt and h40366 len 1 BatConfigMaxChargeWatt), queued 0.36 secs ago
2023.01.29 20:42:14 4 : gen24: ParseFrameStart (TCP, master) extracted id 1, fCode 3, tid 219, dlen 203 and potential data c8fffefffeffffffff0004ffff00014d50505420310000000000000000000000000bf80000294b52722b6988958000ffffffffffff00024d505054203200000000000000000000000014f9000025898b4a2b6988958000ffffffffffff000353744368612033000000000000000000000000000000000000002b6988958000ffffffffffff00045374446973436861203400000000000026744d994c5908acfc7e2b6988958000ffffffffffff007c00181400006400640003ffff05dc064affffffff00030b710f42
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value 5120.0 to BatConfigMaxReferenceWatt
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value bothMax to BatConfigMaxEnabled
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value 16.1 to BatteryChargePercent
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value discharging to BatteryState
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value 1499.6 to BatConfigMaxDischargeWatt
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value 1999.9 to BatConfigMaxChargeWatt
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value -2 to DCPowerScale
2023.01.29 20:42:14 4 : gen24: CreateDataObjects assigns value 0.0 to DCPowerMPPT1
2023.01.29 20:42:14 4 : gen24: HandleResponse done, current frame / read buffer: 00db000000cb0103c8fffefffeffffffff0004ffff00014d50505420310000000000000000000000000bf80000294b52722b6988958000ffffffffffff00024d505054203200000000000000000000000014f9000025898b4a2b6988958000ffffffffffff000353744368612033000000000000000000000000000000000000002b6988958000ffffffffffff00045374446973436861203400000000000026744d994c5908acfc7e2b6988958000ffffffffffff007c00181400006400640003ffff05dc064affffffff00030b710f42, id 1, fCode 3, tid 219,


Bei den "assigns value"-Zeilen taucht also nur noch DCPowerMPPT1 auf, dann ist Schluss, die folgenden Werte fehlen.

Es betrifft auch noch andere Werte, die nicht in einer Group sind:

attr gen24 obj-h40360-expr $val / 100
attr gen24 obj-h40360-len 1
attr gen24 obj-h40360-reading BatConfigReserve
attr gen24 obj-h40360-unpack n
attr gen24 obj-h40361-expr $val / 100
attr gen24 obj-h40361-len 1
attr gen24 obj-h40361-reading BatteryChargePercent
attr gen24 obj-h40361-unpack n


Hier funktioniert BatteryChargePercent, während BatConfigReserve nicht aktualisiert wird.

Seit meinem letzten Update am 2.10. gab es zwei Änderungen in 98_Modbus.pm, aber ich habe ein bisschen probiert und bin mir ziemlich sicher, dass das Problem durch die letzte Änderung reingekommen ist: https://svn.fhem.de/trac/changeset/26789/trunk/fhem/FHEM/98_Modbus.pm. Leider ist die Änderung halbwegs umfangreich und ich habe keine rechte Idee, was mein Problem auslösen könnte...

Ersetze ich bei mir die Datei durch die letzte Version https://svn.fhem.de/trac/export/26497/trunk/fhem/FHEM/98_Modbus.pm ("Modbus 4.4.11 - 5.10.2022"), gefolgt von einem "shutdown restart", dann funktioniert wieder alles einwandfrei:


2023.01.29 21:15:39 4 : gen24: ProcessRequestQueue (V4.4.11 - 5.10.2022) qlen 1, sending 00680000000601039d4b0064 via 192.168.YY.XX:502, read buffer empty,
request: id 1, read fc 3 h40267, len 100, tid 104, master device gen24, reading DCPowerScale (getUpdate for combined g1 len 78 (h40267 len 1 DCPowerScale and h40284 len 1 DCPowerMPPT1 and h40304 len 1 DCPowerMPPT2 and h40324 len 1 BatteryChargeWatt and h40344 len 1 BatteryDischargeWatt) with h40355 len 1 BatConfigMaxReferenceWatt and h40358 len 1 BatConfigMaxEnabled and h40360 len 1 BatConfigReserve and h40361 len 1 BatteryChargePercent and h40364 len 1 BatteryState and h40365 len 1 BatConfigMaxDischargeWatt and h40366 len 1 BatConfigMaxChargeWatt), queued 0.32 secs ago
2023.01.29 21:15:39 4 : gen24: ParseFrameStart (TCP, master) extracted id 1, fCode 3, tid 104, dlen 203 and potential data c80000fffeffffffff0004ffff00014d5050542031000000000000000000000000188a0000294b52722b69906b8000ffffffffffff00024d5050542032000000000000000000000000171a000025898b4a2b69906b8000ffffffffffff000353744368612033000000000000000000000000000000000000002b69906b8000ffffffffffff00045374446973436861203400000000000000004d3b000008ad12fb2b69906b8000ffffffffffff007c00181400006400640003ffff05dc05dcffffffff00060b710f42
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 5120.0 to BatConfigMaxReferenceWatt
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value bothMax to BatConfigMaxEnabled
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 15.0 to BatConfigReserve
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 15.0 to BatteryChargePercent
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value holding to BatteryState
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 1499.6 to BatConfigMaxDischargeWatt
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 1999.9 to BatConfigMaxChargeWatt
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 0 to DCPowerScale
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 0.0 to DCPowerMPPT1
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 0.0 to DCPowerMPPT2
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 0.0 to BatteryChargeWatt
2023.01.29 21:15:39 4 : gen24: CreateDataObjects assigns value 0.0 to BatteryDischargeWatt
2023.01.29 21:15:39 4 : gen24: HandleResponse done, current frame / read buffer: 0068000000cb0103c80000fffeffffffff0004ffff00014d5050542031000000000000000000000000188a0000294b52722b69906b8000ffffffffffff00024d5050542032000000000000000000000000171a000025898b4a2b69906b8000ffffffffffff000353744368612033000000000000000000000000000000000000002b69906b8000ffffffffffff00045374446973436861203400000000000000004d3b000008ad12fb2b69906b8000ffffffffffff007c00181400006400640003ffff05dc05dcffffffff00060b710f42, id 1, fCode 3, tid 104,


Im Anhang erstmal die vollständige Definition und komplette Log-Auszüge im Gutfall und Fehlerfall. Ich bin für alle Hinweise und Ideen dankbar und kann auch gerne selbst Code-Änderungen ausprobieren, wenn jemand eine Idee hat, was es sein könnte!

StefanStrobel

Hallo yoda_gh,

das sieht nach einem Bug aus.
Wenn Du auch für den funktionierenden Fall einen Auszug aus dem Log bei verbose 5 posten könntest, finde ich die Stelle sicher schneller (so ist es einmal mit verbose 4 und dann mit verbose 5).

Gruß
     Stefan