Neue Versionen und Support zum Modbus-Modul

[Bjoernar]

Hallo,

ich nutze schon seit ca. 5 Jahren ohne Probleme das Modbus Modul (dafür schon mal Danke!) nun bekomme ich aber immer wieder folgende Meldung in mein log:

Code Auswählen Erweitern

Undefined subroutine &Modbus::DevIo_Disconnected called at ./FHEM/98_Modbus.pm line 3916.

Das ist an für sich ja nicht schlimm, jedoch hängt sich danach meine FHEM komplett weg.

Vielleicht kann mir ja jemand bei der Lösung helfen.

Danke und Gruß
Björnar

[abc2006]

Ich muss mich hier leider auch nochmal dranhängen.
Heute hat mein Modbus leider nicht funktioniert, der Wechselrichter speist nicht ein.
Mit verbose 5 erhalte ich folgende Meldungen im Log:

Code Auswählen Erweitern

2021.01.20 13:29:36.564 5: infini_modbus_physical: read buffer: 050104
2021.01.20 13:29:36.564 5: infini_modbus_physical: ParseFrameStart called from Modbus::ReadFn
2021.01.20 13:29:36.565 5: infini_modbus_physical: readFn did not see a valid RTU frame start yet, wait for more data
2021.01.20 13:29:36.580 5: infini_modbus_physical: read buffer: 050104003400023005
2021.01.20 13:29:36.581 5: infini_modbus_physical: ParseFrameStart called from Modbus::ReadFn
2021.01.20 13:29:36.581 4: infini_modbus_physical: ParseFrameStart (RTU) extracted id 5, fCode 1 and data 0400340002
2021.01.20 13:29:36.582 5: infini_modbus_physical: HandleRequest called from Modbus::ReadFn
2021.01.20 13:29:36.582 5: infini_modbus_physical: ParseRequest called from Modbus::HandleRequest
2021.01.20 13:29:36.583 4: infini_modbus_physical: RequestDone, Frame with checksum error, error: Invalid checksum 0230 received. Calculated 2a7e, current frame / read buffer: 050104003400023005, id 5, fCode 1, error: Invalid checksum 0230 received. Calculated 2a7e
2021.01.20 13:29:36.584 5: infini_modbus_physical: DropFrame - drop 0501040034000230 rest 05
2021.01.20 13:29:36.584 5: infini_modbus_physical: ParseFrameStart called from Modbus::ReadFn
2021.01.20 13:29:36.584 5: infini_modbus_physical: readFn did not see a valid RTU frame start yet, wait for more data


diese wiederholten sich sekündlich.
Mit einem Klick auf DEF und modify (ohne was an der DEF zu ändern), wechselten die Meldungen zu

Code Auswählen Erweitern


2021.01.20 13:29:41.870 5: infini_modbus_physical: read buffer: 0104003400023005
2021.01.20 13:29:41.871 5: infini_modbus_physical: ParseFrameStart called from Modbus::ReadFn
2021.01.20 13:29:41.871 4: infini_modbus_physical: ParseFrameStart (RTU) extracted id 1, fCode 4 and data 00340002
2021.01.20 13:29:41.871 5: infini_modbus_physical: HandleRequest called from Modbus::ReadFn
2021.01.20 13:29:41.871 5: infini_modbus_physical: ParseRequest called from Modbus::HandleRequest
2021.01.20 13:29:41.872 5: infini_modbus_physical: CheckChecksum (called from Modbus::HandleRequest): 3005 is valid
2021.01.20 13:29:41.872 4: infini_modbus_physical: HandleRequest, current frame / read buffer: 0104003400023005, id 1, fCode 4,
request: id 1 fc 4 i52, len 2
2021.01.20 13:29:41.872 5: infini_modbus_physical: GetLogHash returns hash for device infini_modbus_logical
2021.01.20 13:29:41.874 5: infini_modbus_physical: PackResponse called from Modbus::CreateResponse
2021.01.20 13:29:41.874 5: infini_modbus_physical: Send called from Modbus::CreateResponse
2021.01.20 13:29:41.875 5: SW: 010404442fc0008ebd
2021.01.20 13:29:41.876 4: infini_modbus_physical: RequestDone, current frame / read buffer: 0104003400023005, id 1, fCode 4,
request: id 1 fc 4 i52, len 2,
response: id 1, fc 4 i52, len 2, value 442fc000
2021.01.20 13:29:41.876 5: infini_modbus_physical: DropFrame - drop 0104003400023005


und schon nimmt mein Wechselrichter die Arbeit auf.

Erinnerst du dich, dass ich sowas schonmal reportet hatte? Wenn nicht, such ich gleich mal nach der Stelle...
Bitteschön: hier ist der Link:
https://forum.fhem.de/index.php/topic,75638.msg1072886.html#msg1072886

Grüße,
Stephan

edit: Ich mach jetzt auch noch ein update - da ich die Situation aber leider nicht provozieren kann, wollte ich es trotzdem mal melden.
edit2: ich habe noch die "# $Id: 98_Modbus.pm unreleased development version StefanStrobel $" laufen. Soll ich besser die letzte Version aus dem Thread oder die aus dem update nehmen?

[StefanStrobel]

Hallo,

anbei eine neue Version zum Testen, in der das Problem von Bjoernar gelöst sein sollte. Das war ein Bug / fehlender Eintrag in der Import-Liste.

Gruss
   Stefan

[StefanStrobel]

Hallo Stephan,

ich glaube ich erkenne die Ursache des Problems.
Um das vernünftig nachstellen zu können, würde es mir sehr helfen, wenn Du Deine komplette Konfiguration und einen größeren Ausschnitt aus dem Log mit verbose 5 für sowohl das logische, als auch das physische io-Device posten könntest.

Gruss
   Stefan

[abc2006]

das logical device:

Code Auswählen Erweitern

Internals:
   DEF        1 slave
   FUUID      5f9065ae-f33f-c595-0470-6439b4611fc27d0a
   IODev      infini_modbus_physical
   MODBUSID   1
   MODE       slave
   MODULEVERSION Modbus 4.3.12 - 11.1.2021
   NAME       infini_modbus_logical
   NOTIFYDEV  global
   NR         25
   NTFY_ORDER 50-infini_modbus_logical
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   READINGS:
     2021-01-20 13:58:48   state           opened
   REMEMBER:
     lsend      1611178999.68184
Attributes:
   obj-i52-len 2
   obj-i52-reading Stromzaehler:4_modbus
   obj-i52-unpack f>1
   room       Solar_PV
   verbose    5
   webCmd     active:inactive
das physical device:

Code Auswählen Erweitern


Internals:
   DEF        /dev/fspmodbus@19200,8,N,1
   DeviceName /dev/fspmodbus@19200,8,N,1
   EXPECT     request
   FD         4
   FUUID      5f0aea1b-f33f-c595-6afd-f82bc0e7fc2ead7b
   LASTOPEN   1611147525.10464
   MODE       slave
   NAME       infini_modbus_physical
   NOTIFYDEV  global
   NR         22
   NTFY_ORDER 50-infini_modbus_physical
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   READ:
     BUFFER     
   READINGS:
     2021-01-20 13:58:45   state           opened
   REMEMBER:
     lid        1
     lname      infini_modbus_physical
     lrecv      1611179053.66588
     lsend      1611179053.68261
   REQUEST:
     ADR        52
     FCODE      4
     LEN        2
     MODBUSID   1
     PDU        4
     TYPE       i
   defptr:
     infini_modbus_logical 1
Attributes:
   verbose    5


das Logfile häng ich dir an. Reicht das?
Wenn du noch was anderes brauchst, meld dich.

Grüße,
Stephan

[StefanStrobel]

Hallo Stephan,

In Deinem Fall hat der Slave offenbar den Beginn eines Frames verpasst und aufgrund der häufigen Abfragen den Beginn nicht mehr gefunden.
Bitte teste doch mal die angehängte neue Version. Ich habe zwei Stellen erweitert, die in solchen Fällen jetzt dafür sorgen sollten, dass es sich schnell wieder synchronisiert.
Am besten mit dem Attribut skipGarbage 1 für das physische IO-Device.

Gruss
   Stefan

[Hollo]

Wenn ich das gerade richtig im Kopf habe, schreibt die Modbus RTU Spec eigentlich eine der folgenden Varianten vor:
1 Startbit, 8 Datenbits, Parität gerade oder ungerade, 1 Stoppbit
1 Startbit, 8 Datenbits, keine Parität, 2 Stoppbits

8N1 entspricht dementsprechend nicht der Spec; kann funktionieren, muss aber nicht.

[holle75]

Hallo Stefan,
Kannst du bitte ein Beispiel nennen.

Danke
Dirk

sag mal ein Beispiel, was du auslesen möchtest. Bin ja gerade "drin" im Thema.

[dobiwan]

Hallo dobiwan,

Du musst nur die Objekte, die Du auslesen oder schreiben möchtest, per Attribut in ModbusAttr angeben. Dazu die Länge, den Namen des gewünschten Readings und einen unpack-Code für die richtige Kodierung.
Sollte kein größeres Problem sein.

Gruss
   Stefan

Hallo Stefan,
ich habe jetzt die Beispiele und das Wiki angesehen. Leider bekomme ich keine Werte. Siehe Bild.
Die ID 211 verwende ich, weil ein Modbus Scan mit dem Handy das als offset/ID ergeben hat. Bin mir aber nicht sicher, dass das stimmt.

Gruß

Dirk

[Hollo]

...Die ID 211 verwende ich, weil ein Modbus Scan mit dem Handy das als offset/ID ergeben hat. Bin mir aber nicht sicher, dass das stimmt...

Wenn du nur Modbus/TCP hast, gibt es keine ID; dafür hat das Device (der Modbus/TCP Server) ja eine IP und den Port.
Hast du es mal ohne diese 211 probiert?

[dobiwan]

Wenn du nur Modbus/TCP hast, gibt es keine ID; dafür hat das Device (der Modbus/TCP Server) ja eine IP und den Port.
Hast du es mal ohne diese 211 probiert?

Das Modul verlangt eine ID beim anlegen. da habe ich schon mehrere ausprobiert.
ID ist aber in der CommandRef nicht näher beschrieben.

[holle75]

Vielleicht verstehe ich dich auch falsch, aber die ID (bei meinem Solarlader beschreibt der Hersteller das auch als "slave address") von deinem Solarregler ist die Basis von allem was danach kommt. Gibts da nicht ein Manual oä. wo das beschrieben ist?

edit: oops, TCP, nicht seriell. TCP habe ich keine Ahnung.

[abc2006]

8N1 entspricht dementsprechend nicht der Spec; kann funktionieren, muss aber nicht.

Hat funktioniert, habs trotzdem geändert, bisher funktionierts immer noch. Danke für den Hinweis.

Bitte teste doch mal die angehängte neue Version.

Hab die neue Version eingespielt, danke dafür.
Leider treten die Fehler nur sehr selten auf, ich werde es aber reporten, wenn es wieder passiert.


Grüße,
Stephan

[StefanStrobel]

Hallo dobiwan,

wie fragst Du die Readings denn ab?
Hast Du einen get-Befehl verwendet?
Oder möchtest Du dass die Readings automatisch zyklisch abgefragt werden, dann muss beim Define ein Intervall angegeben sein und das poll-Attribut entsprechend bei den Objekten.
In jedem Fall hilft es wenn Du verbose auf 5 setzt und dann einen Auszug aus dem Log postest. Dann sieht man was wirklich passiert und muss weniger raten

Gruss
    Stefan

[holle75]

Hallo @StefanStrobel

ich habe jetzt noch ab und zu diese PERL WARNINGS

Code Auswählen Erweitern

2021.01.22 16:09:50 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3747.
2021.01.22 16:18:52 3: Eastron: Timeout waiting for a modbus response, read buffer empty,
request: id 43, read fc 4 i62, len 2, master device Studer485_XTM, reading AUX1_Transfer (getUpdate), queued 5.28 secs ago, sent 1.30 secs ago
2021.01.22 16:18:52 1: PERL WARNING: Use of uninitialized value $startByte in index at ./FHEM/98_Modbus.pm line 2102.
2021.01.22 16:18:52 3: Eastron: readfn got data while EXPECT was set to idle: 2b0404000000007046

Das Erste hatten wir ja schon. Meintest du, solle man ignorieren. Das Zweite bekomme ich nachdem ich das Attr skipGarbage 1 im Modbus Device gesetzt habe wenn mal ein Timeout kommt.

Ich bin ja einer dieser Log-Fanatiker die Warnings unästhetisch finden

Kannst man/du da was machen?