Neue Versionen und Support zum Modbus-Modul

[yoda_gh]

Hallo Stefan!

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).

Oh, sorry. Ich habe zu spät gesehen, dass das nur verbose 4 war und dachte, es wäre nicht so wichtig im Gutfall. Hier ist es natürlich.

Wenn ich sonst irgendwie helfen kann, das einzugrenzen oder Du einen Verdacht hast, was ich testen könnte, sag Bescheid! Oder wenn es hilft und Du mir sagst, wo ich sie finde, probiere ich auch gerne Zwischenversionen, im SVN gibt es nur 4.4.11 und 4.4.13.

[StefanStrobel]

Hallo yoda_gh,

bitte probier doch mal das angehängte Modul. Ich hoffe dass es das Problem schon behebt, mir fehlt aber gerade die Zeit das vollständig nachzustellen.

Gruss / Thanx
    Stefan

[yoda_gh]

Super, danke! Schaut schon mal besser aus - ob wirklich sinnvolle Werte kommen, kann ich morgen sagen, wenn die Sonne wieder scheint.

[yoda_gh]

Hallo Stefan!

bitte probier doch mal das angehängte Modul. Ich hoffe dass es das Problem schon behebt, mir fehlt aber gerade die Zeit das vollständig nachzustellen.

Sorry für die späte Antwort. Aber ich kann jetzt bestätigen, dass alles wieder rund läuft, danke!! Wenn ich noch irgendwie helfen kann, da was nachzustellen oder eine Code-Änderung zu verifzieren, sag gerne Bescheid! Ich verstehe leider noch nicht wirklich, wo Dein Patch das fixt, sonst hätte ich schon mehr Details geliefert.

VG,
Gernot

[laserrichi]

nach einen totalausfall von meinem Raspberry findet man dann wieder Fehler die scheinbar schon länger im System sind

ich kann es Zeitlich schon etwas eingrenzen, vermutlich als ich modbusproxy eingerichtet habe bzw. meine PV Anlage mit angebunden habe. Kann aber auch sein das es ein anderes Modbus Modul ist.

Diese Meldungen treten immer nur einmalig auf wenn fhem startet:

Code Auswählen Erweitern

2023.02.09 22:22:42 1: PERL WARNING: Subroutine Initialize redefined at ./FHEM/98_Modbus.pm line 492, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine InitializeLD redefined at ./FHEM/98_Modbus.pm line 514, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine DefineFn redefined at ./FHEM/98_Modbus.pm line 542, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine DefineLDFn redefined at ./FHEM/98_Modbus.pm line 574, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine UndefFn redefined at ./FHEM/98_Modbus.pm line 695, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine UndefLDFn redefined at ./FHEM/98_Modbus.pm line 721, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine AttrFn redefined at ./FHEM/98_Modbus.pm line 746, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine AttrLDFn redefined at ./FHEM/98_Modbus.pm line 771, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine UpdateGetSetList redefined at ./FHEM/98_Modbus.pm line 905, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine GetLDFn redefined at ./FHEM/98_Modbus.pm line 958, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine FormatSetVal redefined at ./FHEM/98_Modbus.pm line 994, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine SetLDFn redefined at ./FHEM/98_Modbus.pm line 1045, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine ControlSet redefined at ./FHEM/98_Modbus.pm line 1111, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine createAttrsFromParseInfo redefined at ./FHEM/98_Modbus.pm line 1264, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine SaveAsModule redefined at ./FHEM/98_Modbus.pm line 1311, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine ScanObjects redefined at ./FHEM/98_Modbus.pm line 1383, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine ScanIds redefined at ./FHEM/98_Modbus.pm line 1429, <$fh> line 4747.
2023.02.09 22:22:42 1: PERL WARNING: Subroutine NotifyFn redefined at ./FHEM/98_Modbus.pm line 1496, <$fh> line 4747.

hab ich natürlich gekürzt, es ist vermutlich jede sub die hier erwähnt wird

Jemand eine Idee wie ich dem ganzen auf die pelle rücken kann ?

[StefanStrobel]

Hallo laserrichi,

Du könntest mal schauen, welche Module, die Modbus verwenden, bei Dir eingebunden sind und wie die jeweils das Modbus-Modul in ihrer Initialize-Funktion laden.

In ModbusAttr sieht das z.B. so aus:

Code Auswählen Erweitern


sub Initialize {
    my ($modHash) = @_;

    LoadModule "Modbus";
    Modbus::InitializeLD($modHash);                         # Generic function of the Modbus module does the rest


Gruß
   Stefan

[laserrichi]

hm, im prinzip sehen alle meine so aus:

Code Auswählen Erweitern

sub ModbusEPEVER_Initialize($)
{
    my ($modHash) = @_;
    require "$attr{global}{modpath}/FHEM/98_Modbus.pm";
    $modHash->{parseInfo}  = \%ModbusEPEVERparseInfo;  # defines registers, inputs, coils etc. for this Modbus Defive
    $modHash->{deviceInfo} = \%ModbusEPEVERdeviceInfo; # defines properties of the device like defaults and supported function codes

    ModbusLD_Initialize($modHash);              # Generic function of the Modbus module does the rest
   
    $modHash->{AttrList} = $modHash->{AttrList} . " " .     # Standard Attributes like IODEv etc
        $modHash->{ObjAttrList} . " " .                     # Attributes to add or overwrite parseInfo definitions
        $modHash->{DevAttrList} . " " .                     # Attributes to add or overwrite devInfo definitions
        "poll-.* " .                                        # overwrite poll with poll-ReadingName
        "polldelay-.* ";                                    # overwrite polldelay with polldelay-ReadingName
}

entsprechend die Namen immer anders.
Liegt das evtl an dem require ? würde da ein LoadModul reichen ?

[StefanStrobel]

Hallo laserrichi,

beim require werden die Module mehrfach geladen. Daher die Warnungen.

Gruß
    Stefan

[Roger]

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

Hi Stefan,
ich wollte mich mal in Erinnerung bringen. Schaffen es die Änderungen ins offizielle Modul?

//Roger

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

[StefanStrobel]

Hallo Roger,

ich bin gerade am Testen eines neuen Features für custom function codes, die mit wenigen Attributen definiert werden können. Scheint zu funktionieren. Neues Modul zum Testen poste ich demnächst

Gruß
    Stefan

[Roger]

Hi Stefan,
Klasse. Freue mich schon. 
//Roger

[laserrichi]

Hallo laserrichi,

beim require werden die Module mehrfach geladen. Daher die Warnungen.

Gruß
    Stefan

Hallo Stefan, danke... das war es !!  Da wäre ich nie drauf gekommen.

[StefanStrobel]

Hallo Roger,

hier ein erster Entwurf zum Testen.

Als Beispiel habe ich einen fiktiven function code 93 (dezimal) definiert, der das gleiche macht wie function code 3:

Code Auswählen Erweitern


attr Master dev-fc93Request-unpack nn
attr Master dev-fc93Request-fieldList ADR, LEN

attr Master dev-fc93Response-unpack Ca*
attr Master dev-fc93Response-fieldList LEN, VALUES
attr Master dev-fc93Response-fieldExpr-PDULEXP $response->{LEN} + 2
attr Master dev-fc93Response-fieldExpr-TYPE 'h'
attr Master dev-fc93Response-fieldExpr-ADR $val + 0


das bedeutet:
Der Request besteht aus zwei 16-Bit-Wörtern (unpack nn)
Die werden mit der Adresse und der Länge aus dem Request-Hash gefüllt

Die Antwort besteht aus einem Byte und folgenden Werten, die 1:1 durchgereicht werden (unpack Ca*)
Das Ergebnis des unpacks geht in die Response-Felder LEN und VALUES
Die erwartete Länge der Response in Bytes berechnet sich aus der übermittelten Länge *2
Die Response wird als Felder vom Typ h (holding register) interpretiert und mit den definierten Objekten vom Typ h und Adresse des Requests + 0 geparsed. So könnte man auch auf virtuelle Objekte verweisen, die als obj-h10000 o.ä. definiert sind.

Um das selbst definieren zu können, sollte man den Aufbau des request- bzw. response-Hashes kennen. Darin gibt es die Felder TYPE, ADR, LEN, VALUES, FCODE etc.

Für Deinen einfachen function code x42 bzw. 66, bei dem es gar keine Felder gibt, würde das so aussehen:

Code Auswählen Erweitern


attr Master dev-fc66Request-unpack none
attr Master dev-fc66Response-unpack none
attr Master dev-fc66Response-fieldExpr-PDULEXP 1


none steht für keine Felder.
Man kann das ganze auch für Slaves verwenden. Zum Testen kann das hilfreich sein.
Das ganze ist noch nicht final getestet und noch nicht weiter dokumentiert. Ich werde es vermutlich auch noch ein wenig umbauen, so dass man damit auch bestehende function codes umdefinieren kann. Damit könnte man in Zukunft fest reinkodierte "broken-fcxy" vermeiden und einfach den function code passend verbiegen.

Um den function code dann zu verwenden kann man ein virtuelles Objekt festlegen, z.B. obj-h9000-Reading reset und dafür dann overrideFCwrite setzen.
Bei einem set auf dieses Objekt wird dann der neue function code verwendet. Ob der sich für die Adresse und den Typ des Objekts überhaupt interessiert, ist Definitionssache.

Gruss
   Stefan

[Roger]

Hi Stefan,
besten Dank vorab. Ich komme aber erst morgen/übermorgen zum Testen.

//Roger

[Roger]

Hi Stefan,
so habe getestet. Hier die Ergebnisse:

Definition:

Code Auswählen Erweitern


# Definition send FC 0x42=66(decimal) zum Zuruecksetzen der Energie
attr HA_PZEM_B1 dev-fc66Request-unpack none
# Definition Empfang FC 0x42=66(decimal): Energie erfolgreich zurueckgesetzt
attr HA_PZEM_B1 dev-fc66Response-unpack none
attr HA_PZEM_B1 dev-fc66Response-fieldExpr-PDULEXP 1
# virtuelles Holding Register zum erfolgreichen Zuruecksetzen der Energie
attr HA_PZEM_B1 obj-h9042-reading Reset
attr HA_PZEM_B1 obj-h9042-set 1
attr HA_PZEM_B1 obj-h9042-overrideFCwrite 66


Dann Befehl: set   HA_PZEM_B1 Reset 1  abgesetzt.
Hierbei musste ich noch einen Wert nach dem Befehl angeben - unschön, aber nicht so schlimm.

Log File:

Code Auswählen Erweitern


2023.02.16 21:02:20.781 5: HA_PZEM_B1: UpdateSetList: setList=reconnect:noArg saveAsModule createAttrsFromParseInfo interval reread:noArg stop:noArg start:noArg close:noArg scanStop:noArg scanModbusObjects sendRaw scanModbusId inactive active Alarm_Threshold_Voltage_high Alarm_Threshold_Voltage_low Modbus_ID Shunt__A:100A,50A,200A,300A Reset
2023.02.16 21:02:20.781 5: HA_PZEM_B1: UpdateSetList: getList=Voltage__V:noArg Current__A:noArg Power__W:noArg Energy__kWh:noArg
2023.02.16 21:02:27.348 4: HA_PZEM_B1: set called with Reset (h9042) setVal = 1
2023.02.16 21:02:27.350 5: HA_PZEM_B1: GetSetChecks with force
2023.02.16 21:02:27.350 5: HA_PZEM_B1: GetSetChecks returns success
2023.02.16 21:02:27.353 5: HA_PZEM_B1: set packed hex 31 with n to hex 0001
2023.02.16 21:02:27.356 4: HA_PZEM_B1: DoRequest called from SetLDFn created new request, read buffer empty,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset)
2023.02.16 21:02:27.357 5: HA_Modbus_1: QueueRequest called from DoRequest with h9042, qlen 0 from master HA_PZEM_B1 through io device HA_Modbus_1
2023.02.16 21:02:27.358 5: HA_Modbus_1: ProcessRequestQueue called from QueueRequest as direct:HA_Modbus_1, qlen 1, force, request: request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.00 secs ago
2023.02.16 21:02:27.359 5: HA_Modbus_1: checkDelays busDelayRead, last activity on bus was 206.532 secs ago, required delay is 1
2023.02.16 21:02:27.359 5: HA_Modbus_1: checkDelays sendDelay, last send to same device was 206.617 secs ago, required delay is 0.1
2023.02.16 21:02:27.360 5: HA_Modbus_1: checkDelays clientSwitchDelay is not relevant
2023.02.16 21:02:27.360 5: HA_Modbus_1: checkDelays commDelay, last communication with same device was 206.530 secs ago, required delay is 0.1
2023.02.16 21:02:27.361 3: HA_Modbus_1: Send custom request function code 66: request fields:  values:  results in packed pdu 42
2023.02.16 21:02:27.362 4: HA_Modbus_1: ProcessRequestQueue (V4.5.1 - 14.2.2023) qlen 1, sending 01428011 via /dev/ttyUSB0@9600,8,0,2, read buffer empty,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.00 secs ago,
response: no id, no fcode
2023.02.16 21:02:27.369 5: HA_Modbus_1: Send called from ProcessRequestQueue
2023.02.16 21:02:27.370 5: HA_Modbus_1: Profiling Send, before Idle, now is 21:02:27.369, Send started at 21:02:27.369, Idle started at 21:00:57.165
2023.02.16 21:02:27.371 5: HA_Modbus_1: Profiling add 90.204 to sum for Idle (now is 21:02:27.369, start for Idle was 21:00:57.165)
2023.02.16 21:02:27.371 5: DevIo_SimpleWrite HA_Modbus_1: 01428011
2023.02.16 21:02:27.373 5: HA_Modbus_1: Profiling Wait, before Send, now is 21:02:27.373, Wait started at 21:02:27.373, Send started at 21:02:27.369
2023.02.16 21:02:27.374 5: HA_Modbus_1: Profiling add 0.004 to sum for Send (now is 21:02:27.373, start for Send was 21:02:27.369)
2023.02.16 21:02:27.375 5: HA_Modbus_1: ReadAnswer called from SetLDFn
2023.02.16 21:02:27.376 5: HA_Modbus_1: Profiling Read, before Wait, now is 21:02:27.376, Read started at 21:00:57.150, Wait started at 21:02:27.373
2023.02.16 21:02:27.377 5: HA_Modbus_1: Profiling add 0.003 to sum for Wait (now is 21:02:27.376, start for Wait was 21:02:27.373)
2023.02.16 21:02:27.377 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.9799370765686
2023.02.16 21:02:27.459 5: HA_Modbus_1: ReadAnswer got: 01
2023.02.16 21:02:27.460 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.16 21:02:27.461 5: HA_Modbus_1: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2023.02.16 21:02:27.461 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.89621615409851
2023.02.16 21:02:27.462 5: HA_Modbus_1: ReadAnswer got: 0142
2023.02.16 21:02:27.462 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.16 21:02:27.462 5: HA_Modbus_1: ReadAnswer got no valid frame after HandleFrameStart, wait for more data
2023.02.16 21:02:27.463 5: HA_Modbus_1: ReadAnswer remaining timeout is 1.89439296722412
2023.02.16 21:02:27.463 5: HA_Modbus_1: ReadAnswer got: 01428011
2023.02.16 21:02:27.464 5: HA_Modbus_1: ParseFrameStart called from ReadAnswer protocol RTU expecting id 1
2023.02.16 21:02:27.464 4: HA_Modbus_1: ParseFrameStart (RTU, master) extracted id 1, fCode 66 and potential data
2023.02.16 21:02:27.465 5: HA_Modbus_1: HandleResponse called from ReadAnswer
2023.02.16 21:02:27.465 5: HA_Modbus_1: ParseResponse called from HandleResponse
2023.02.16 21:02:27.466 3: HA_Modbus_1: parse custom response function code 66: data:  with unpack code none to fields  results in values:
2023.02.16 21:02:27.467 4: HA_Modbus_1: HandleResponse error, current frame / read buffer: 01428011, id 1, fCode 66,
request: id 1, write fc 66 h9042, len 1, value 0001, master device HA_PZEM_B1, reading Reset (set Reset), queued 0.11 secs ago, sent 0.11 secs ago,
response: id 1, fc 66, len 1, error: Invalid checksum 4280 received. Calculated 7e80
2023.02.16 21:02:27.468 5: HA_Modbus_1: ResetExpect for HandleResponse from response to idle
2023.02.16 21:02:27.469 5: HA_Modbus_1: Profiling Idle, before Read, now is 21:02:27.469, Idle started at 21:00:57.165, Read started at 21:02:27.376
2023.02.16 21:02:27.470 5: HA_Modbus_1: Profiling add 0.093 to sum for Read (now is 21:02:27.469, start for Read was 21:02:27.376)
2023.02.16 21:02:27.471 5: HA_Modbus_1: DropFrame called from ReadAnswer - drop 01428011


Der Befehl wird wahrscheinlich ausgeführt, das eine Antwort mit dem positiven FC 66 kommt (sonst FC 194), aber bei der Auswertung kommt:
Invalid checksum 4280 received. Calculated 7e80 und die Antwort wird verworfen.
Auch die Angabe einer Länge in h9042 von 0 oder 1 hat keine Besserung gebracht.

//Roger