PHP Information läuft voll mit require_once aufrufen

Heidewinkler · 10. Mai 2020 um 07:58

Ich habe folgendes schon mal unterModules geschildert aber keine richtige Antwort bekommen.

Wenn man sich mal eine Weile die PHP Informationen anschaut fällt auf dass mehrmals in der Minute und in unregelmäßigen Abständen die Threads mit requre_once Aufrufen voll laufen. Am häufigsten sind es …bumaas…HM_Inventory und …Blind_controll Aufrufe.

Es gibt zwar keine Probleme damit aber ist schon ungewöhnlich zumal z.B. HM_Inventory nicht mal ausgeführt wird (Interval=0)
Vielleicht hat ja hier einer eine Erklärung.

bumaas · 10. Mai 2020 um 08:49

Du könntest mal versuchen, die in require_once genannte Datei mal umzubenennen.
Dann wäre interessant zu sehen, wer sich beschwert …

Heidewinkler · 10. Mai 2020 um 11:01

Ich habe mal die module.php umbenannt.

10.05.2020, 10:51:15 | FlowHandler | Kann Daten nicht zur Instanz #55898 weiterleiten: 
Warning: require_once(C:\ProgramData\Symcon\modules.store\bumaas.1\HM_Inventory\module.php): failed to open stream: No such file or directory in C:\Windows\System32- on line 2 
 
Fatal error: require_once(): Failed opening required ‚C:\ProgramData\Symcon\modules.store\bumaas.1\HM_Inventory\module.php‘ (include_path=’.:C:\ProgramData\Symcon\scripts’) in C:\Windows\System32- on line 2

#55898 ist der HM Inventory Report Creator

bumaas · 10. Mai 2020 um 15:16

Ob es daran liegt, dass sich das Modul für die Kernel Messages registriert hat?

        $this->RegisterMessage(0, IPS_KERNELMESSAGE);

Nall-chan · 10. Mai 2020 um 16:27

Eher wohl weil es sich an den Datenfluss hängt.
Aber da sollte eigentlich nichts passieren, weil du ja gar keine ReceiveData Methode deklariert hast.
Außer das hier intern etwas geändert wurde und diese Methode immer in der ipsmodule Klasse existiert.
Dann reicht es wenn du einen ReceiveDataFilter setzt, welche nie zutrifft.
Michael

bumaas · 10. Mai 2020 um 19:52

Es passiert auch nichts. Zumindest wird von meinen Modulmethoden keine aufgerufen.
Aber es sieht ungesund und systembelastend aus.

paresy · 10. Mai 2020 um 20:05

Wenn das Modul am Datenfluss hängt, wird ReceiveData aufgerufen. Egal, ob dein Modul diese überschreibt oder nicht. Da muss, wie Nall Chan schon sagte, einfach ein ungültiger ReceiveFilter gesetzt werden.

paresy

bumaas · 11. Mai 2020 um 08:47

Verstehe. Ich lerne immer an der Doku und an Beispielen. Bislang ist mir noch nirgends ein ungültiger Receive Filter aufgefallen. Daher ist das neu für mich und vielleicht für andere auch.

Da werde ich wohl alle meine Module mal überprüfen müssen.

Ein Beispiel/Hinweis in der Doku wäre sicherlich nicht schlecht.

Würde es ein UnregisterMessage nach einem KR_READY auch tun, wenn man nur auf den KR_READY warten will?

paresy · 11. Mai 2020 um 08:56

Tatsächlich hat dies nichts miteinander zu tun. RegisterMessage ist der MessageSink. Der wird bei deinem Beispiel fast nie aufgerufen.

Das Problem ist ReceiveData und somit der Datenfluss der vom HMSocket befeuert wird. Der Filter limitiert die Datenpakete auf nur die, die du wirklich brauchst. Per default empfängt man aber alles.

paresy

Nall-chan · 11. Mai 2020 um 09:16

Mir war das auch so nie bewusst.
Allerdings hatte ich schon immer einen Filter gesetzt.

github.com

Nall-chan/HomematicExtended/blob/8508b8faf64e4efd63b28a1632af35ebdff192a3/Programme/module.php#L60


}
/**
 * Interne Funktion des SDK.
 *
 * @access public
 */
public function ApplyChanges()
{
    parent::ApplyChanges();
    $this->SetReceiveDataFilter(".*9999999999.*");
    if (!IPS_VariableProfileExists('Execute.HM')) {
        IPS_CreateVariableProfile('Execute.HM', 1);
        IPS_SetVariableProfileAssociation('Execute.HM', 0, 'Start', '', -1);
    }
    if (IPS_GetKernelRunlevel() <> KR_READY) {
        return;
    }
    if (!$this->HasActiveParent()) {

Vielleicht auch, weil es mir damals beim testen aufgefallen ist und ich habe es nur vergessen. Teilweise brauche ich ja auch wirklich Daten vom Datenfluss.
Michael

bumaas · 11. Mai 2020 um 09:48

Dann habe ich es jetzt erst verstanden. Seitdem sich das Modul direkt mit dem HMSocket verbindet, bekommt es auch die Daten Nachrichten.
Da es aber keine verarbeiten will, muss ein Filter gesetzt werden.

Was ist denn ein guter ‚ungültiger‘ Filter?

@NallChan, du wählst in deinem Beispiel

$this->SetReceiveDataFilter(".*9999999999.*");

paresy · 11. Mai 2020 um 10:27

Das ist ein super Filter. Nimm einfach etwas, das extrem unwahrscheinlich ist. (Falls es doch mal zutrifft, ist es egal… Es macht ja nichts kaputt)

Hier eine andere Lösung: dictionary - A Regex that will never be matched by anything - Stack Overflow

Hab ich hier genutzt: SymconLJ/module.php at master Â· symcon/SymconLJ Â· GitHub

paresy

bumaas · 11. Mai 2020 um 17:47

Danke für eure Tipps!

Habe mich jetzt für

$this->SetReceiveDataFilter('(?!x)x');

entschieden. Der trifft nie zu

Heidewinkler · 12. Mai 2020 um 09:16

Mit dem Beta update des HM_Inventory ist es nun viel besser geworden. Das Blind_controll und einige andere kommen aber immer noch, aber seltener.

bumaas · 12. Mai 2020 um 13:01

Der Fall scheint mir hier anders gelagert zu sein.

Einen Teil kann ich mir erklären, da im Modul ein Timer aufgezogen wird:

        $this->RegisterTimer('Update', 0, 'BLC_ControlBlind(' . $this->InstanceID . ', true);');

Seltsamerweise steht aber hinter „Absender“ der Hinweis „RunScript“. Bei anderen Moduln steht da „TimerEvent“. Vielleicht mache ich da noch etwas falsch.

Die RequireOnce Einträge kann ich mir wiederum nicht erklären. Ein Filter scheint da aber wohl nicht zu fehlen, denn ein testweise eingebautes ReceiveData wird nie aufgerufen…