Neue Versionen und Support zum Modbus-Modul

[StefanStrobel]

Hallo sukram,

Probier doch mal die angehängte neue Version. Da gibt es ein neues Attribut mit Namen closeAfterResponse. Wenn das auf 1 steht, dann wird die TCP-Verbindung nach Erhalt der Response geschlossen und erst bei Bedarf wieder geöffnet.
Das muss allerdings noch getestet werden.

Du musst auch selbst dafür sorgen, dass verschiedene ModbusAttr-Instanzen sich nicht in die Quere kommen. Dazu musst Du die Update-Timer passend und nicht zu kurz setzen und am besten zusätzlich mit alignTime arbeiten.

Das Grundproblem bleibt dass Dein Relay nicht mehrere TCP-Verbindungen und keine überlappenden Anfragen bekommen darf. Mit einem Relay auf einem Pi-Zero mit Fhem wäre das sauber zu lösen und ich denke nicht dass der Strombedarf dadurch signifikant steigt.

Alternativ kann ich mal versuchen, das Modbus-Modul so zu erweitern, dass man auch ein Modbus-TCP-Device als IODev für andere Modbus-TCP-Devices eintragen kann, dann könnte Fhem auch als Master über TCP dafür sorgen, dass die Requests immer nur über eine Verbindung und sequentiell kommen.
Das könnte aber ein paar Tage dauern.

Gruß
    Stefan

[laserrichi]

Frage zum setzen von Registern, da es bei mir nicht so funktioniert wie es soll:

Setzen von Coil klappt. Bei den Holding leider nicht so richtig, ich will das h36870 von 1440 (14,40V) auf 1441 z.b. setzen, evtl. ein Thema mit pack ?

Code Auswählen Erweitern

2020.06.06 13:32:45 5: Solarlader: set called with EqualizingVoltage (h36870) setVal = 1441
2020.06.06 13:32:45 5: Solarlader: GetSetChecks with force
2020.06.06 13:32:45 5: Solarlader: GetSetChecks returns success
2020.06.06 13:32:45 5: Solarlader: set packed hex 31343431 with n to hex 05a1
2020.06.06 13:32:45 4: Solarlader: DoRequest called from Set created request: id 1, fCode 16, type h, adr 36870, len 1, value 05a1 for device Solarlader reading EqualizingVoltage (set EqualizingVoltage), read buffer empty
2020.06.06 13:32:45 5: Solarlader: QueueRequest called from DoRequest (Solarlader) with h36870, qlen 0
2020.06.06 13:32:45 4: Solarlader: ProcessRequestQueue called from QueueRequest, force, qlen 1, next entry to id 1 (Solarlader), last send to this device was 4.704 secs ago, last read 4.611 secs ago, last read on bus 4.611 secs ago from id 1 (Solarlader)
2020.06.06 13:32:45 5: Solarlader: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 13:32:41.064) for Solarlader, delay 4.511secs over
2020.06.06 13:32:45 5: Solarlader: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 13:32:40.971) for Solarlader, delay 4.605secs over
2020.06.06 13:32:45 4: Solarlader: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 1, sending 0110900600010205a1f4d7 request: id 1, fCode 16, type h, adr 36870, len 1, value 05a1 for device Solarlader reading EqualizingVoltage (set EqualizingVoltage), queued 0.00 secs ago, read buffer empty
2020.06.06 13:32:45 5: Solarlader: StartQueueTimer called from ProcessRequestQueue removes internal timer because it is not needed now
2020.06.06 13:32:45 5: Solarlader: ReadAnswer called from Set
2020.06.06 13:32:45 5: Solarlader: ReadAnswer called and remaining timeout is 1.99727821350098
2020.06.06 13:32:45 5: Solarlader: ReadAnswer got: 0190044dc3
2020.06.06 13:32:45 4: Solarlader: ParseFrameStart (RTU) extracted id 1, fCode 144 and data 04
2020.06.06 13:32:45 5: Solarlader: HandleResponse called from ReadAnswer
2020.06.06 13:32:45 5: Solarlader: ParseResponse called from HandleResponse
2020.06.06 13:32:45 5: Solarlader: CheckChecksum (called from HandleResponse): 4dc3 is valid
2020.06.06 13:32:45 4: Solarlader: HandleResponse got response with error code 90 / 04, slave device failure
2020.06.06 13:32:45 4: Solarlader: ResponseDone request: id 1, fCode 16, type h, adr 36870, len 1, value 05a1 for device Solarlader reading EqualizingVoltage (set EqualizingVoltage), queued 0.08 secs ago, sent 0.08 secs ago, Current read buffer: 0190044dc3, Id 1, fCode 144, response: id 1, fCode 144, adr 36870, len 1
2020.06.06 13:32:45 5: Solarlader: DropFrame - drop 0190044dc3
2020.06.06 13:32:45 5: Solarlader: ReadAnswer got Error code 04 / slave device failure
2020.06.06 13:32:56 5: Solarlader: attr change set updateGetSetList to 1


Beim setzen des Holding Registers von der Batteriekapazität die ich z.b. von 80 auf 81 ändere geht es und das Log sieht so aus:

Code Auswählen Erweitern

2020.06.06 14:37:14 5: Solarlader: set called with BattCapacityDefault (h36865) setVal = 81
2020.06.06 14:37:14 5: Solarlader: GetSetChecks with force
2020.06.06 14:37:14 5: Solarlader: GetSetChecks returns success
2020.06.06 14:37:14 5: Solarlader: set packed hex 3831 with n to hex 0051
2020.06.06 14:37:14 4: Solarlader: DoRequest called from Set created request: id 1, fCode 16, type h, adr 36865, len 1, value 0051 for device Solarlader reading BattCapacityDefault (set BattCapacityDefault), read buffer empty
2020.06.06 14:37:14 5: Solarlader: QueueRequest called from DoRequest (Solarlader) with h36865, qlen 8
2020.06.06 14:37:14 4: Solarlader: ProcessRequestQueue called from QueueRequest, force, qlen 9, next entry to id 1 (Solarlader), last send to this device was 0.163 secs ago, last read 0.075 secs ago, last read on bus 0.075 secs ago from id 1 (Solarlader)
2020.06.06 14:37:14 4: Solarlader: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 14:37:14.314) for Solarlader, rest 0.025, sleep forced
2020.06.06 14:37:14 5: Solarlader: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 14:37:14.227) for Solarlader, delay 0.063secs over
2020.06.06 14:37:14 4: Solarlader: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 9, sending 011090010001020051f674 request: id 1, fCode 16, type h, adr 36865, len 1, value 0051 for device Solarlader reading BattCapacityDefault (set BattCapacityDefault), queued 0.00 secs ago, read buffer empty
2020.06.06 14:37:14 5: SW: 011090010001020051f674
2020.06.06 14:37:14 5: Solarlader: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.06.06 14:37:14 5: Solarlader: ReadAnswer called from Set
2020.06.06 14:37:14 5: Solarlader: ReadAnswer called and remaining timeout is 1.99591517448425
2020.06.06 14:37:14 5: Solarlader: ReadAnswer got: 0110900100017d
2020.06.06 14:37:14 4: Solarlader: ParseFrameStart (RTU) extracted id 1, fCode 16 and data 900100
2020.06.06 14:37:14 5: Solarlader: HandleResponse called from ReadAnswer
2020.06.06 14:37:14 5: Solarlader: ParseResponse called from HandleResponse
2020.06.06 14:37:14 5: Solarlader: HandleResponse did not get a valid frame yet, wait for more data
2020.06.06 14:37:14 5: Solarlader: ReadAnswer got: 0110900100017d09
2020.06.06 14:37:14 4: Solarlader: ParseFrameStart (RTU) extracted id 1, fCode 16 and data 90010001
2020.06.06 14:37:14 5: Solarlader: HandleResponse called from ReadAnswer
2020.06.06 14:37:14 5: Solarlader: ParseResponse called from HandleResponse
2020.06.06 14:37:14 5: Solarlader: CheckChecksum (called from HandleResponse): 7d09 is valid
2020.06.06 14:37:14 4: Solarlader: ResponseDone request: id 1, fCode 16, type h, adr 36865, len 1, value 0051 for device Solarlader reading BattCapacityDefault (set BattCapacityDefault), queued 0.16 secs ago, sent 0.16 secs ago, Current read buffer: 0110900100017d09, Id 1, fCode 16, response: id 1, fCode 16, type c, adr 36865, len 1
2020.06.06 14:37:14 5: Solarlader: DropFrame - drop 0110900100017d09
2020.06.06 14:37:14 5: Solarlader: set is sending read after write
2020.06.06 14:37:14 4: Solarlader: DoRequest called from Set created request: id 1, fCode 3, type h, adr 36865, len 1 for device Solarlader reading BattCapacityDefault (set BattCapacityDefault Rd), read buffer empty
2020.06.06 14:37:14 5: Solarlader: QueueRequest called from DoRequest (Solarlader) with h36865, qlen 8
2020.06.06 14:37:14 4: Solarlader: ProcessRequestQueue called from QueueRequest, force, qlen 9, next entry to id 1 (Solarlader), last send to this device was 0.156 secs ago, last read 0.003 secs ago, last read on bus 0.003 secs ago from id 1 (Solarlader)
2020.06.06 14:37:14 4: Solarlader: CheckDelay called from ProcessRequestQueue commDelay (0.1s since 14:37:14.546) for Solarlader, rest 0.097, sleep forced
2020.06.06 14:37:14 5: Solarlader: CheckDelay called from ProcessRequestQueue sendDelay (0.1s since 14:37:14.392) for Solarlader, delay 0.057secs over
2020.06.06 14:37:14 4: Solarlader: ProcessRequestQueue (V4.1.5 - 17.9.2019) qlen 9, sending 010390010001f8ca request: id 1, fCode 3, type h, adr 36865, len 1 for device Solarlader reading BattCapacityDefault (set BattCapacityDefault Rd), queued 0.00 secs ago, read buffer empty
2020.06.06 14:37:14 5: SW: 010390010001f8ca
2020.06.06 14:37:14 5: Solarlader: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 seconds
2020.06.06 14:37:14 5: Solarlader: ReadAnswer called from Set
2020.06.06 14:37:14 5: Solarlader: ReadAnswer called and remaining timeout is 1.99602508544922
2020.06.06 14:37:14 5: Solarlader: ReadAnswer got: 01030200
2020.06.06 14:37:14 5: Solarlader: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2020.06.06 14:37:14 5: Solarlader: ReadAnswer got: 010302005179b8
2020.06.06 14:37:14 4: Solarlader: ParseFrameStart (RTU) extracted id 1, fCode 3 and data 020051
2020.06.06 14:37:14 5: Solarlader: HandleResponse called from ReadAnswer
2020.06.06 14:37:14 5: Solarlader: ParseResponse called from HandleResponse
2020.06.06 14:37:14 5: Solarlader: CheckChecksum (called from HandleResponse): 79b8 is valid
2020.06.06 14:37:14 5: Solarlader: HandleResponse now passing to logical device Solarlader for parsing data
2020.06.06 14:37:14 5: Solarlader: ParseObj called with data 0051, type h, adr 36865, valuesLen 1, op read
2020.06.06 14:37:14 5: Solarlader: ParseObj ObjInfo for h36865: reading=BattCapacityDefault, unpack=n, expr=$val=$val." Ah", format=, map=
2020.06.06 14:37:14 5: Solarlader: ParseObj unpacked 0051 with n to 81 hex 3831
2020.06.06 14:37:14 5: Solarlader: CheckEval for ParseObj evaluates expr for BattCapacityDefault, val=81, expr=$val=$val." Ah"
2020.06.06 14:37:14 5: Solarlader: CheckEval for ParseObj result is 81 Ah
2020.06.06 14:37:14 4: Solarlader: ParseObj assigns value 81 Ah to BattCapacityDefault

dann wäre da noch eine Frage zu meinen erstellten Modul (Anhang).

Wie kann man in dem Modul z.b. stateformat webcmd webCmdLabel  fest mit einbauen?

[StefanStrobel]

Hallo laserrichi,

spontan sehe ich keinen Fehler.
Kann das Holding-Register 36870 denn korrekt gelesen werden?
Was steht denn in der Dokumentation des Geräts zum Datentyp?

Zu stateformat und WebCMD: das kannst Du nicht so einfach im Modul ablegen.
Die Attribute sollte der Anwender setzen oder ein Attr-Template verwenden.

Gruss
   Stefan

[StefanStrobel]

Hallo sukram,

habe gerade gesehen, dass das Modul im obigen Post nicht richtig hochgeladen wurde.
Jetzt ist die aktuelle Datei oben angehängt.

Gruss
   Stefan

[laserrichi]

Hallo Stefan,

ich habe mal mit Wireshark mitgeschnitten was denn die original Software so sendet. Leider kann ich da das einzelne nicht selektieren und die Software liest z.b. 16 aufeinanderfolgende Register aus oder schreibt die dann auch so.

Was mir aber jetzt aufgefallen ist, das der CRC in der Doku immer aus 2 Byte wohl besteht.

Aus meinen Beispiel oben wenn ich das Send Commando aufdrösel kommt folgendes dabei heraus:
sending 0110900600010205a1f4d7
01       device ID
10       function Code
90 06  start adresse
00 01  Anzahl adressen
02       CRC ... sollten eigentlich 2 sein  denn 02 05 als CRC wäre falsch
05 a1  das wäre  eigentlich mein gesetzter wert mit 1441 (14,41V)
f4 d7   ?  was das jetzt ist weis ich nicht

Vieleicht liegt hier der Hund begraben ? Oder Byte / Word Thema ?

Bei dem anderen setzen wo es funktioniert mit der Batterie kapazität steht der gesetzte Wert an der richtigen stelle aber nur mit einem Byte.
Im Anhang mal die Doku von epsolar
Auch wäre interessant wie ich meine Uhrzeit auch setzen kann die aus 3 Registern besteht, da war irgendwo im Forum schon ein anderer Beitrag, aber ist wohl tricky beim senden die Bytes wieder richtig zusammenzubauen...

[StefanStrobel]

Hallo laserrichi,

02 ist der Bytecount.
Die Prüfsumme kommt nach dem zu schreibenden Wert.

Gruß
    Stefan

[laserrichi]

Hallo Stefan,
ok ja jetzt hab ich es auch gesehen das es beim lesen und schreiben ja anders ist

Soweit ich sehe ist das ganze dann schon richtig, nur der Controler lehnt das ab oder er erwartet hier eine ganze reihe von Registern auf einmal.
Zumindest liest die Software von denen diese 16 Register auf einmal und schreibt sie auch so.
Andere Holding Register lassen sich ja schreiben.

Andere Frage, kann ich z.b. bei nur einem Reading den Function Code anpassen ?
So liest die Software wohl Gerätebezeichnung und Firmware Version aus:
01 2b 0e 01 00 70 77

das wäre ja Holding mit read 34

[StefanStrobel]

Hallo laserrichi,

Function code 43 (Hex 2b) steht für Encapsulated Interface Transport. Das ist nicht einfach ein Zugriff auf Holding-Register.
Ich setz den mal auf die Wunschliste. Sollte nicht zu aufwändig sein, den zu implemeritieren.  Bisher hatte ich aber noch kein Gerät, das diesen Code unterstützt ...

Gruß
   Stefan

[laserrichi]

ok Super.
Ich habe jetzt doch tatsächlich in der Doku die auch oben angehängt ist, den Satz hier gefunden:
Only when the battery type is User, the customer can set the other parameters(the parameters need to be set at the same time)
Ok Typ hab ich ja auf User, aber das entscheidende ist das man die Parameter alle zur selben Zeit setzen muss, also genau die 16 Aufeinanderfolgenden Registern.
k.a. wie ich das im Modul umsetzen kann. Aber das wäre dann mit Kanonen auf Spatzen geschossen. Denn man setzt das ja nur einmal und dann nimmt man halt die Original Software und in Fhem reicht es wenn man die Werte liest und weis was eingestellt ist.
Ich hab heute viel an dem Modul gebastelt und auch Doku mit eingebaut zu den Readings. Ich sollte wenn es soweit ist, vieleicht für den Hersteller (gibt davon ja auch andere Brands) einen eigenen Thread eröffnen und da das Modul anhängen, ist sicher auch anderen Nützlich zumal ich danach schon gefragt wurde.

[sukram]

Hallo Stefan,

danke fürs nochmal hochladen. Bin arbeitsbedingt noch nicht weitergekommen, habe das gerade erst eingerichtet. Es werden jetzt im 5 Sekundentakt die 3 Zähler abgefragt, sehr schön. Es springt zwar bei jedem Reconnect die State-Anzeige von meiner Zusammenfassung auf "disconnected, opened" und wieder zurück, aber das ist eher kosmetisch. SilentReconnect scheint ja eher für das Systemlog gedacht zu sein, richtig?

Ich bin mit der Lösung erst mal ganz zufrieden, du musst dir nicht die zusätzliche Arbeit machen. In meinem Fundus hat sich noch ein älterer Advantech ADAM 4570 Adapter aufgetan (2x Seriell RS232/485/422 auf Ethernet), der dann für FHEM als serieller Port erscheint. Den werde ich erstmal auf Tauglichkeit prüfen.

MfG

EDIT: Nach etwas basteln habe ich den Takt auf 10 Sekunden zwischen den Modulen und 60 Sekunden Intervall pro Modul eingerichtet. Das reicht erstmal 

[Wolfshund]

Hallo zusammen,

habe inzwischen mein modbus am laufen, jedoch noch ein Problem.
Es soll ein Modbus device in Fhem angelegt werden, das mit einer vorhandenen Erfassungssoftware ( closed Source) zusammenarbeitet.
Software arbeitet NUR mit Wattnode Metern zusammen und genau das möchten wird umgehen.
Die Software sendet zur Identifizierung der angeschlossenen Nodes den Function Code 17(0x11) nennt sich "Report Slave ID"
Laut der Doku von Wattnode antwortet das Meter mit einem vorgegebenen Textstring

Address                             1 byte           1-247                          Modbus address of meter
Function Code                   1 byte            0x11                           Report Slave ID Function Code
Byte Count                        1 byte            1-x                             Number of bytes in Slave ID, Run Indicator Status, and Additional Data
Slave ID                             1 byte            0x02                         WattNode meter Slave ID byte
Run Indicator Status         1 byte             0xFF                         Always returns 0xFF
Additional Data                  Variable         ASCII string              Example: "Continental Control Systems LLC, WattNode MODBUS, WNC-3Y-208-MB"
                                                                null terminated
CRC                                   2 byte   

Ich habe probeweise mal an zweistellen im 98_Modbus.pw den Function Code 17(0x11)  hinzugefügt und bekomme auch schon eine Reaktion auf die Anfrage ,
die natürlich falsch formatiert ist.

2020.06.22 11:48:04 4: Weidmueller_192.168.74.86_1081: ParseFrameStart (TCP) extracted id 7, fCode 17, tid 1, dlen 2 and data
2020.06.22 11:48:04 5: Weidmueller_192.168.74.86_1081: HandleRequest called from Read
2020.06.22 11:48:04 5: Weidmueller_192.168.74.86_1081: ParseRequest called from HandleRequest
2020.06.22 11:48:04 5: Weidmueller_192.168.74.86_1081: HandleRequest could not parse request frame yet, wait for more data

in Modbus_ParseResponse  und  Modbus_ParseRequest habe ich hinzugefügt :

} elsif ($fCode == 17) {
        # Read id as acii                     pdu: fCode, adr, len
        return if ($dataLength) < 2;
        my ($adr, $values)  = unpack ('na*', $data);
        $response->{ADR}    = $adr;                         # adr of register
        $response->{VALUES} = "Continental Control Systems LLC, WattNode MODBUS, WNC-3Y-400-MB";
        $response->{TYPE}   = 'h';                          # holding registers
        $frame->{PDULEXP}   = 5;                            # 1 Byte fCode + 2 Bytes adr + 2 Bytes register

Das war nur ein Versuch der jedoch schon mal den Logeintag von oben erzeugt hat.
Meine vermutung ist das  $frame->{PDULEXP}   = 5;    geänert werden muss bzw. noch ananderen Stellen was fehlt.
Kann mir jemand einen Fingerzeig geben, oder kann ich das unter keinen Umstänen selber lösen?

LG

Andreas

[StefanStrobel]

Hallo Andreas,

$hash->{FRAME}{PDULEXP} bzw. $frame->{PDULEXP} ist die zu erwartende Länge der PDU.
Das wird in ParseRequest und ParseResponse gesetzt beziehungsweise bei Modbus-TCP schon in ParseFrameStart.
In HandleRequest wir daraus die erwartete Frame-Länge berechnet um dann zu erkennen, ob schon alle Daten gelesen wurden.
Eigentlich sollte es nicht zu kompliziert sein, den function code zu ergänzen. Am sinnvollsten wäre es natürlich, wenn der String dann nicht im Code steht, sondern aus einem Attribut geholt wird.

Gruss
   Stefan

[Wolfshund]

Hallo Stefan,

Danke für die Antwort, jedoch habe ich das inzwischen mit einen Arduino gelöst,
Da es nur darum geht den Function Code 0x11 zu beantworten, und es läuft auch so wie es soll,
Ich bin kein Perl Programmierer, kann es zwar bedingtlesen, aber NICHT programmieren.

Mein momentanes Problem ist einfach in meiner Unwissenheit in Perl begründet.

Ich bekomme folgendes Reading in mein Modbus Device eingelesen

   

Code Auswählen Erweitern

Energy_Sum_LRA   hex=3233332e333337313733343631393134, string=233.337173461914, s=13106, s>=12851, S=13106, S>=12851, i=13106, i>=12851, I=13106, I>=12851, f=4.07453584760908e-11, f>=1.04308082171656e-08

ich möchte den Wert

Code Auswählen Erweitern

string=233.337173461914
als 233,33 angezeigt bekommen

Das reading habe ich so definiert

attr mega_id10 obj-h19000-allowWrite 0
attr mega_id10 obj-h19000-len 2
attr mega_id10 obj-h19000-reading Energy_Sum_LRA
attr mega_id10 obj-h19000-revRegs 0
attr mega_id10 obj-h19000-set 1
attr mega_id10 obj-h19000-unpack f>

Ich glaube es ist nur eine Formatierung
wie z.B.

Code Auswählen Erweitern

attr mega_id10 obj-h19000-format %.2f
das geht aber nicht. sondern liefert immer nur 0.00

Dank nochmals für das Modul Modbus und Deine Antwort

LG

Andreas

2020-06-26 15:04:56

[StefanStrobel]

Hallo Andreas,

Das sieht nach einem ASCII-String aus, nicht nach einer Float-Zahl.
Gib doch mal als unpack-Code a* an.

Gruss
   Stefan

[max333]

Hallo,

ich habe mir mit ModbusAttr ein Modul erstellen lassen für meinen Sensor. Dieser Sensor gibt zusätzlich zu den Werten einen Fehlerstatus aus. Falls dieser größer als 0 ist, dann sind alle Messwerte zu verwerfen. Wie kann ich das erreichen, das im Fehlerfall keine readings aktualisiert werden außer dieser Fehlerstatus? Der Fehlerstatus hat nichts mit der Prüfsumme vom Modbusprotokoll zu tun.