[gelöst] ModbusAttr - read got new data while idle, drop buffer

[abc2006]

Hallo,
ich habe versucht, ein Modbus-Device zu erstellen.
Informationsteil:
Ich habe einen Wechselrichter (den 10k von FSP) und möchte mit diesem via Modbus kommunizieren (bzw. ihm Antworten geben).

Dazu habe ich folgende Devices definiert:

das physikalische Device, welches auf einen lokalen USB->Seriell-Adapter zugreift:

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
   IODev      infini_modbus
   LASTOPEN   1594728125.09245
   MODE       slave
   NAME       infini_modbus
   NR         29
   NTFY_ORDER 50-infini_modbus
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   READ:
     BUFFER     
   READINGS:
     2020-07-14 14:02:05   state           opened
   REMEMBER:
     lid        1
     lname      infini_modbus
     lrecv      1594730997.20221
     lsend      1594730997.20894
   REQUEST:
     ADR        52
     FCODE      4
     LEN        2
     MODBUSID   1
     PDU        4
     TYPE       i
     DEVHASH:
       DEF        1 slave
       FUUID      5f0aea39-f33f-c595-edac-f72ea29a8f63c0b8
       IODev      infini_modbus
       MODBUSID   1
       MODE       slave
       MODULEVERSION Modbus 4.1.5 - 17.9.2019
       NAME       modbus
       NOTIFYDEV  global
       NR         30
       NTFY_ORDER 50-modbus
       PROTOCOL   RTU
       STATE      opened
       TYPE       ModbusAttr
       READINGS:
         2020-07-14 14:01:08   state           opened
         2020-07-14 13:48:22   zeropadding     0
       REMEMBER:
         lsend      1594730997.20894
   defptr:
     modbus     1
Attributes:


sowie ein logisches Device:

Code Auswählen Erweitern

Internals:
   DEF        1 slave
   FUUID      5f0aea39-f33f-c595-edac-f72ea29a8f63c0b8
   IODev      infini_modbus
   MODBUSID   1
   MODE       slave
   MODULEVERSION Modbus 4.1.5 - 17.9.2019
   NAME       modbus
   NOTIFYDEV  global
   NR         30
   NTFY_ORDER 50-modbus
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   READINGS:
     2020-07-14 14:01:08   state           opened
     2020-07-14 13:48:22   zeropadding     0
   REMEMBER:
     lsend      1594731064.99809
Attributes:
   obj-h52-len 2
   obj-i52-reading Stromzaehler:modbus
   obj-i52-unpack f>1
   obj-i53-reading zeropadding
   userattr   obj-h52-len obj-i52-reading obj-i52-unpack obj-i53-reading


Die Anfrage des Wechselrichters lautet

Code Auswählen Erweitern


0104003400023005

und bedeutet:

• Adresse 01h
• Funktion 04h (Auslesen)
• Register 34h (=52dez)
• Länge 0002h Register (= 4 Byte)
• Prüfsumme 3005h

erstes Problem:
Der Wechselrichter möchte gerne einen IEEE754-floating-Wert über 4 Byte erhalten.
Mit unpack f>1 wird der Wert richtig codiert:

Code Auswählen Erweitern

2020.07.14 14:57:27.321 5: modbus: PackObj  packed -232 with pack code f>1 to c3680000
Leider wird er dann auf 2 Byte gekürzt:

Code Auswählen Erweitern

2020.07.14 14:57:27.321 5: modbus: PackObj padded / cut object to c368

um dann mit dem Wert aus Register 53 befüllt zu werden:

Code Auswählen Erweitern

2020.07.14 14:57:27.322 5: modbus: PackObj moves to next object, skip 1 to i53, counter=1
2020.07.14 14:57:27.323 5: modbus: PackObj ObjInfo for i53: reading=zeropadding, expr=, format=, len=1, map=, unpack=n
2020.07.14 14:57:27.324 4: modbus: PackObj for i53 is using reading zeropadding of device modbus with value 0
2020.07.14 14:57:27.324 5: modbus: PackObj packed 0 with pack code n to 0000
2020.07.14 14:57:27.324 5: modbus: PackObj padded / cut object to 0000


Und dann zu einem String zusammengesetzt zu werden

Code Auswählen Erweitern

2020.07.14 14:57:27.325 5: modbus: PackObj full data string is c3680000
2020.07.14 14:57:27.325 5: modbus: PackObj padded / cut data string to c3680000
2020.07.14 14:57:27.325 5: modbus: prepare response pdu
2020.07.14 14:57:27.326 4: modbus: CreateResponse sends fc 4 to id 1, for i 52, len 2, device modbus (RTU), pdu 0404c3680000, V 4.1.5 - 17.9.2019



Kann mir jemand einen Tipp geben, wie ich konfiguriere, dass der Wert aus Register 52 komplett gesendet wird (und auf Register 53 verzichtet)?



Zweites Problem:

Nach einem "shutdown restart" erhalte ich regelmäßig die Log-Meldung

Code Auswählen Erweitern

2020.07.14 14:02:01.741 3: infini_modbus: read got new data while idle, drop buffer 0104003400023005

und mein Wechselrichter erhält keine Antworten mehr. Durch mehrfachen Neustart kann dieses "Problem" "behoben" werden. Ist aber doof, wenn mein Raspi neu startet und dann mein WR nicht mehr einspeist (=teuer:)

Ich habe die Hardware-Devices über udev-Regeln an die namen gebunden, so dass sichergestellt ist, dass /dev/fspmodbus immer mit der Modbus-Karte redet (ist mir symphatischer als /by-id, da man direkt sieht, welches device man benutzt ..). Wie man sieht, sind die eingehenden Anfragen auch korrekt, werden aber nicht ausgewertet/bearbeitet.

Hat hierzu auch jemand einen Tipp für mich?
Grade der zweite Punkt wäre mir extrem wichtig, der erste ist ja eher eine Unschönheit, aber funktioniert.

Danke und Grüße,
Stephan

[abc2006]

Durch bearbeiten der DEF von infini_modbus (das physikalische Device) kann das Problem reproduzierbar "behoben" werden.

Vorgehensweise:
klicken auf DEF
klicken auf modify infini_modbus
fertig

[StefanStrobel]

Hallo Stephan,

Dein erstes Problem scheint an den Attributen zu liegen:

obj-h52-len 2
obj-i52-reading Stromzaehler:modbus
obj-i52-unpack f>1
obj-i53-reading zeropadding

Du setzt die Länge für das Objekt an holding register 52 auf 2. Holding register werden mit function code 3 gelesen.
Dann definierst Du aber ein Objekt für ein input register 52. Das sind zwei verschiedene Dinge. Input register werden mit function code 4 gelesen.
Da das Modul so bei Anfragen auf input register 52 von einer Länge 1 ausgeht, wird der korrekt gepackte Wert abgeschnitten.

Um Dein zweites Problem tatsächlich zu lösen wäre es sehr hilfreich, einen Auszug aus dem Log mit verbose 5 (für das physische und das logische Gerät) zu sehen. Am besten vom Starten bis zur "Behebung".

Gruss
   Stefan

[abc2006]

Hallo Stefan,
danke für deine Antwort.

Dein erstes Problem scheint an den Attributen zu liegen:

Ja, da hast du natürlich völlig recht. Hatte das mit den h-Registern aus der commandref nachgebaut, und dann ist mir aufgefallen, dass aber die i-Register abgefragt werden.Beim Umbau hab ich das dann wohl übersehen... Werde das testen, wenn ich Anfang August wieder zuhause bin. Von Unterwegs ist mir das Risiko zu hoch, dass da was ungewolltes passiert und ich Zeit reinstecken muss

Um Dein zweites Problem tatsächlich zu lösen wäre es sehr hilfreich, einen Auszug aus dem Log mit verbose 5 (für das physische und das logische Gerät) zu sehen. Am besten vom Starten bis zur "Behebung".

Ich habe dir ein Log angehängt.
Zeile 1: "shutdown restart". So lässt sich das Problem reproduzieren.
Zeile 59: Startup-Definition des physischen Modbus-Gerätes
Zeile 96: Auftreten der ersten Meldung
Zeile 230: defmod <gleiche DEF> durch ein DOIF, welches 5 Sekunden verzögert auf global:INITIALIZED triggert. So lässt sich das Problem lösen.


Die ganzen Pylontech-Meldungen habe ich der Vollständigkeit halber dringelassen, die tauchen auf, weil ich von den 8 Batterien, die abgefragt werden, zwei für meinen Urlaub geklaut habe. Leider ist es etwas unsauber programmiert (Anzahl hardcoded), so dass er jetzt zwei Stück vermisst... Wenn die dich stören, sag Bescheid, dann lösch ich die noch raus. Sollte nix mit dem Modbus-Problem zu tun haben, das trat vorher schon auf (allerdings nicht mit Loglevel 5 geloggt)

Viele Grüße,
Stephan

[StefanStrobel]

Hallo Stephan,

das Problem nach restart ist ein Bug. Bitte probier doch mal die neue Version, die ich hier gepostet habe: https://forum.fhem.de/index.php/topic,75638.480.html
Derzeit bin ich noch dabei einiges zu überarbeiten, deshalb ist noch keine neue Version eingecheckt.

Gruss
   Stefan

[abc2006]

Hat das Zeit bis zum 3.8.? dann gerne.

Grüße,
Stephan

[Hollo]

...Der Wechselrichter möchte gerne einen IEEE754-floating-Wert über 4 Byte erhalten...

Ich interpretiere das mal so, dass Du den Wert an den Umrichter "senden" willst!?
Dazu wird Dir weder FC3 noch FC4 helfen, da Du dafür FC16 (write multiple register) nutzen musst.
Das wäre das Gegenstück zu FC3 Holding Register(s).

[abc2006]

Ich weiss nicht, ob es ein Unterschied ist, aber ich möcht nicht senden, sondern auf Abfragen antworten. Das funktioniert soweit,  auch wenn ich die hinteren 2Byte fake.

Grüße,
Stephan

[abc2006]

Hi Stefan, sorry, hat leider etwas länger gedauert.
Mit der neuen Version https://forum.fhem.de/index.php/topic,75638.msg1055159.html#msg1055159 aus #460 und der Änderung des Attributes von h auf i scheint erstmal alles perfekt zu funktionieren.

Vielen Dank!

Falls mir noch was auffällt, melde ich mich.
Grüße,
Stephan